Subject: me tarzan- me jane suggested text change

From: "[email-masked]" <[email-masked]>
Date: Tue, 25 Mar 2003 13:14:01 -0500

Per the  SF discussion surrounding whether the ID payload must match the ID
in a presented cert, I would like to add my vote for increased clarity. 
To do so,
I believe the following text represents the spirit of the WG:

In section 2.15, to the sentence that states:

"Optionally, messages 3 and 4 MAY include a certificate, or certificate 
chain providing evidence
that the key used to compute a digital signature belongs to the name in 
the ID payload."

Add the following"

" The exact requirement for mapping the name in the ID payload to an 
acceptable key is a local matter
and outside the scope of this document".

Jeff

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Mar 2003 15:17:39 -0500

At 1:14 PM -0500 3/25/03, [email-masked] wrote:
>in a presented cert, I would like to add my vote for increased 
>clarity. To do so,
>"Optionally, messages 3 and 4 MAY include a certificate, or 
>certificate chain providing evidence
>that the key used to compute a digital signature belongs to the name 
>in the ID payload."
>
>Add the following"
>

I don't think the latter text helps, since it does not tell a peer 
whether the match is required or not, and thus interoperability 
problems will persist. I think Paul Hoffman made this point in his 
comments at the mic.

Steve

---

From: Ravi <[email-masked]>
Date: Wed, 26 Mar 2003 09:19:00 +0530

In my view, making ID check is local matter might result in
deployment interoperability problem. I don't see any problem 
in making sure that both ID in the payload and ID in the 
certificate match with ID configured in the IKE policies.
That is, all three have to be same. Does anybody see problem
in comparing IDs and ensuring that they are same and making 
this mandatory? 

Thanks for your time

-- 

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>

---

From: Ravi <[email-masked]>
Date: Wed, 26 Mar 2003 19:07:16 +0530

Thanks for your time

--

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 26 Mar 2003 10:13:15 -0500

Ravi,

I guess the concensus I heard was that there are at least 2 reasons why 
we dont
want to require this match:

1) Current difficulties in cert creation. This means that some folks 
want to share
a cert between multiple identities.
2) Once you have a cert, there is confusion about how you extract an 
identity from
the cert, ie there are too many options for inserting an ID into a PKIX 
cert.

The conclusion is that there needs to be some way for a cert recipient 
to say that
a cert is acceptable to be used by the sending identity. BUT, the 
identities claimed in
ID payload and cert need not match. This is equivalent to saying 
acceptability is a local
matter. Since this is a confusing point to more than one, I was 
suggesting that it be clarified
in the spec. I do not believe that adding clarity about intent leads to 
increased
interoperability problems.

Jeff

Ravi wrote:

> [email-masked] <mailto:[email-masked]> wrote:
> 
>> 
> The views presented in this mail are completely mine. The company is 
> not responsible for whatsoever.

---

From: Ravi <[email-masked]>
Date: Thu, 27 Mar 2003 15:28:32 +0530

I understand this now better. But one question:
You mentioned that there are several options for inserting ID in
PKIX certificate ( I am sorry I don't have much knowledge of PKIX,
I will read it through though later). But, once the node gets the
peer certificate, I think ID is the only way for the node to identify
the certificate. In this case, I assume that node has to extract
the ID from the certificate for making decision whether to accept
the peer or not. So, a node should have intelligence of extracting
the ID OR IDs from the certificate.

   If the ID in the payload and ID of the certificates can be different,
then the IKE node has to have mapping between 0the ID payload and certificate
ID(s), which could be extra configuration.

   It is not a problem and I wanted to make sure that my understanding
is correct. 

      Thanks

[email-masked] wrote:

>
> Ravi,
>
> I guess the concensus I heard was that there are at least 2 reasons 
> why we dont
> the cert, ie there are too many options for inserting an ID into a 
> PKIX cert.
>
> in the spec. I do not believe that adding clarity about intent leads 
> to increased

--