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

[Ravi <ravivsn@roc.co.in>]

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:
> Meant to reply to the list...
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: Confirm decision on identity handling.
> From:
> "Scott G. Kelly" <scott@airespace.com>
> Date:
> Thu, 15 May 2003 14:29:17 -0700
> To:
> Gregory Lebovitz <Gregory@netscreen.com>
> 
> 
> 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


-- 


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>