[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary of revised identity changes
> a) For certificate authentication, in messages 3 and 4, you no longer
> send both an ID and a certificate. Instead, you send only a
> certificate and the receiver gets your identity from the certificate.
> IKEv1 developers still cannot agree on how to use the identity with
> the certificate. For example, some implementers reject messages where
> the ID doesn't match any of the names in the certificate, others
> accept it, still others don't even read the ID field, and still
> others don't read the names from the certificate. The new proposal
> eliminates the ambiguity.
I like this. we still need to better nail down what should be done
with the names inside the certs.
> b) By telling the kind of ID that is accepted in messages 1 and 2,
> you can safely avoid sending certificates if they are not needed.
also a good thing.
> c) Certificate requests are now hashes of the public key of the trust
> anchor, not the DN name. This makes it clearer to each side exactly
> which key is the trust anchor, since some trust anchor names are not
> unique (such as after a key rollover).
.. and you'd present both hashes *during* a graceful key rollover.
> d) You can accept hash-and-URL of certs instead of the certs
> themselves. This helps prevent fragmentation of UDP packets for large
> certificates.
yes. only "downside" is that it removes one source of pressure to
keep certs small (perhaps a losing battle, though).
- Bill