Subject: [Fwd: Confirm decision on identity handling.]

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 15 May 2003 14:30:04 -0700

Meant to reply to the list...

Subject: Re: Confirm decision on identity handling.
From: "Scott G. Kelly" <[email-masked]>
To: Gregory Lebovitz <[email-masked]>
Date: Thu, 15 May 2003 14:29:17 -0700

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

---

From: Ravi <[email-masked]>
Date: Sat, 17 May 2003 17:29:27 +0530

Hi,
        I think you are also saying that comparison of  ID in the ID 
payload and Certificate is local matter. As a sender ID payload should 
be sent.

        ID in ID payload might have to match with certificate ID while 
sending as the receiver might be comparing the ID in ID paylaod and 
certificate.

Regards,
Ravi.

Scott G. Kelly wrote:
> ------------------------------------------------------------------------
> 
> Subject:
> Re: Confirm decision on identity handling.
> From:

-- 

The views presented in this mail are completely mine. The company is not
responsible for whatsoever.
------------------------------------------------------------------------
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page <http://www.roc.co.in>