Re:-ipsec-pki-req-03 - EKU's

[Rodney Thayer <[e-mail]>]

Regarding the EKU discussion...

I originally put in two kinds of EKU's -- one for end systems and
one for intermediate systems. It is my opinion that you want to be
able to label a certificate with this information:

  -- it's for IPsec
  -- it's for an end system (only this machine)
  -- it's for a gateway ("intermediate") system (it can do IPsec
     for packets it forwards

At the Binghampton bakeoff, we had a disscussion of this, and
(a then-Cisco employee now working in Santa Cruz) complained this was
too complicated, so the consensus was altered to have only one
key usage for ipsec.  Since Intermediate was at that time deployed,
we chose that one.

I still think we need the three factoids in the certificate, somehow.

Per Paul Hoffman's arguments, which I wholeheartedly agree with (much
to my disgust), we should use some PKIX-based style/format/oid/whatever
to communicate these factoids, if in fact they should be conveyed
in the certificate.

I do not know of anyone REQUIRING EKU.  I do know of multiple
implementations of it today.  

So...

I would suggest we put back the other EKU value (which, by the
way, I got assigned by IANA already...) for ikeEndSystem.
If there's a PKIX lawyer in the room, and they have some
mechanism other than EKU that is more culturally compatible
with PKIX, we should discuss that.  As I understand it, EKU
is a "PKIX-style" feature, though, so we're ok on that point.

On the subject of "how many EKU's can you have", I don't think
we should prohibit others, however I vaguely recall this was some
sort of PKIX requirement.  I myself have seen people wanting "swiss
army certificates" which enable SSL, SMIME, IPsec, right turn on
red without stopping, and all sorts of other features.  I happen
to think that's unsafe, but it does seem to be a requirement.  I
would like to allow multiple EKU's.



At 05:51 PM 10/26/99 -0700, Brian Korver wrote:
>Paul Hoffman wrote:
>> 
>> At 04:35 PM 10/25/99 -0700, Brian Korver wrote:
>> >Why require that extendedKeyUsage be mandatory at all?
>> 
>> To identify the cert as being for IKE. I've been told that today's IKE
>> systems use this OID as identification. I believe we should have *one* OID
>> for all IKE implementations, and not try to slice and dice between "client"
>> and "gateway" and so on.
>> 
>> Are there any IPsec implementations using the IPsec OIDs specified in RFC
>> 2459? Are there any implementations that require the use of other OIDs,
>> like IKEend (1.3.6.1.5.5.8.2.1)?
>> 

>Why is there a requirement to identify certificates as "for use with IKE"?
>
>BTW, I haven't heard of any implementations that require these IKE OIDs in
>ExtendedKeyUsage.  Perhaps someone else has.