Hi Gregory,
Gregory Lebovitz wrote:
>
> 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.
I agree with Paul (and you) that it is difficult to reconcile the way
some PKI vendors build certs with the way identities are expressed in
ipsec policies (and ID payloads), although there are ways to build DN
filters if one is determined to solve these problems. However, the
bottom line is that if certs are to be meaningful as ipsec
authenticators, then there must be *some* way to identify acceptable
certs in the recipient's policy. And as an aside, I'll point out that
IPsec deployments are not constrained to using a particular PKI vendor's
certs - many vpn vendors have fielded CAs which *can* build
appropriately structured certs (if only we could all agree on what that
means from an interop standpoint).
Even if you say the ID is not related to the cert in any way, you still
have a problem, though: you must, upon deriving a policy based on the
ID, verify that the cert matches the policy somehow - you must be able
to represent a certificate filter in your policy no matter which way you
do this. And you must ensure that if there are multiple policies for
which the same cert might be acceptable, that only the "correct" one is
chosen. This implies the ID must be bound to the cert somehow.
Again, I suggest that we consider not *requiring* ID payloads with certs
(relying instead upon the recipient to derive an identity from the
cert), and that if we must support ID payloads when certs are used, that
processing the ID payloads be optional, so that two independent
implementations are able to interoperate whether they are present or not
(even if the recipient ignores the ID payload).
Scott