Summary of revised identity changes

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

Greetings again. At the request of some folks from the WG, here is a 
summary of changes that the revised identity proposal makes. 
Hopefully, this list clears up any questions.

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.

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. 
Either side can say "I can take certificates as a hash-and-URL". If 
you can't accept a hash-and-URL (for instance, because you can't 
resolve URLs), you can tell the other side that easily.

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). There is only one form for the 
hashes, and it matches the form that is already used in PKIX.

d) You can accept hash-and-URL of certs instead of the certs 
themselves. This helps prevent fragmentation of UDP packets for large 
certificates. The receiver can cache the certificates he/she has 
received and look them up by their hash, so resolving the URL might 
not even be necessary.

I hope this helps!

--Paul Hoffman, Director
--VPN Consortium