RE: Confirm decision on identity handling.

[Gregory Lebovitz <Gregory@netscreen.com>]

Paul is totally right on this one. From experience with Project Dploy, where
we tried to get better interop between IPsec vendors and PKI vendors after
talking to many customers about actual usage issues, this is what we found:
It is a daunting task for the deployers to get the cert contents to match
exactly what the VPN application needs. This is true for a variety of
reasons, many of which Paul noted below. The biggest is that often the VPN
deployer has little or zero impact/control/say in how the CA builds certs.
It's just not reality to expect that the VPN can dictate or ensure some
field in the Cert will contain what they need.

This is why many of us have been pushing for disassociating the two.

... [sarcasm ahead] or maybe we can just forget the whole issue because, in
reality, so few deployers even care to try to make certs work with VPNs
anymore because we have screwed it up so badly for them for so long ...

> So, yes you can make this work, but the likelihood of 
> interoperability quickly approaches zero. 

And there is a big difference between being able to be configured to be
interoperable, and being practically *usable*. Matching ID to something in
the cert CAN be done successfully, but actual deployment experience has
proven it almost impossible. Just ask the support teams from the major IPsec
vendors.

Lets try to build something people can actually USE this time, eh?

I vote for disassociating ID from cert contents. (BUT, I proposed text that
would allow for those who desired/required to be able to match if they
wanted to).

> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
> Sent: Tuesday, May 13, 2003 4:30 PM
> To: Scott G. Kelly; ipsec@lists.tislabs.com
> Subject: Re: Confirm decision on identity handling.
> 
> 
> 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
>