Re: me tarzan- me jane suggested text change

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

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

jpickering@creeksidenet.com wrote: >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: >> >>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 >> >>jpickering@creeksidenet.com wrote: >>> >>>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 >> >>-- >> >> >>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 >> >> -- 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