Re: Confirm decision on identity handling.

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

At 3:18 PM -0700 5/13/03, Scott G. Kelly wrote:
>Basically, every example given so far uses an ID value which can be
>verified against the cert. Can anyone give a realistic example of a case
>where we would *not* want the ID to match something in the cert?

The ID can always match something in the cert. The question is 
really, can we force the specific ID to match something in the 
specific cert. In order to do so:

- The VPN administrator has to control the CA that issues the certs 
so that he/she can get the right value into the right slot of the 
certs. Sometimes this is easy, sometimes this is impossible (such as 
when some other person in IT controls the CA and as a "better idea" 
for how the identities in the certs should look, or when the company 
has chosen an inflexible CA product).

- The user has to know which identities are in their cert.

- The UI for the user's VPN system (often client software) has to be 
flexible enough to handle the different types of identities.

Even if those three requirements are met, the receiving software has 
to know where in the cert to look for the identity. Email addresses 
and FQDNs can be in either the Subject or SubjectAltName. And I've 
even see IP addresses in the Subject, as the CommonName.

So, yes you can make this work, but the likelihood of 
interoperability quickly approaches zero. Even if we said "the cert 
must have the identities here", there is lots of CA software out 
there that will ignore that new rule. Further, since lots of IKEv1 
software will expect the certs to look differently, boxes that want 
to speak both IKEv1 and IKEv2 may need (at least) two certificates 
for the same identity. The admin interface for that situation will be 
ugly, to say the least.

--Paul Hoffman, Director
--VPN Consortium