[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