[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Latest ipsec-pki-req-04.txt - EKU

I guess we've been staring at this too long.  Let's try this
again.

I wanted ONE eku in a cert.  I think it is INSECURE to have
"swiss army knife" certificates that do multiple functions.
This comment applies to SMIME, IPsec, TLS -- any cert usage.

Others wanted multiple functions.

I believe (some PKIX lawyer check me on this...) that 2459 allows
any number of EKU's (wanna parse a cert with 572 EKU's, anyone?
Can you say "architecturally irresponsible"?)

I believe we got the text wrong, as I believe the rough consensus on
this is that it should say...

  In a certificate for an IPsec end entity, the extendedKeyUsage field
  (commonly called "EKU") SHOULD be present.  In order to indicate this
  certificate is allowed to be used for IPsec, it MUST contain the
  object identifier iKEIntermediate
  (iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or
  1.3.6.1.5.5.8.2.2). An IKE system that conforms to this profile SHOULD
  NOT accept end-entity certificates that do not follow this rule.

Now, I realize we're going around in circles on this, so I expect others
to shout this down and that first 'MUST' (see my * above) will be watered
down to a SHOULD.

By the way, one thing we meant to do here was to stop talking about
IPsec intermediate vs. end systems, which is a concept we did not
have consensus on.  Again I think this is a security issue.  I don't
want some random can wrapping my packets in IPsec and claiming it was
a legitimate gateway if it was a mere end system.

At 02:04 PM 12/15/99 -0800, Alex Deacon wrote:
>Hello,
>
>
>Greg Carter wrote:
>> 
>> Hi,
>> 
>> 3.1 The extendedKeyUsage field
>> 
>> Maybe I missed it, but did anybody respond why the 
>> extendedKeyUsage MUST
>> contain only the
>> object identifier iKEIntermediate?
>> 
>> This now means all ipsec entities require a special ipsec cert.  
>
>Perhaps I missed this also.  Some reasoning as to why ONLY the
>iKEIntermediate OID can be present in an end entity cert would be great.  
>
>>[snip]
>> 
>> 
>> A. Obtaining a Certificate for a Device
>> "Regardless of the protocol used, a CA who gets an IKE system's
>> enrollment request that includes the subject and 
>> subjectAltName desired
>> for the device MUST include exactly the same subject and 
>> subjectAltName
>> in the certificate."
>> 
>> As I have said before this will require that a user type in 
>> the DN at some
>> console somewhere and get it right.  I don't see the need for this
>> restriction.  I believe the subject can be modified by the CA in CMP
>> (rfc2510).  
>
>I agree completely. 
>
>> A.1 Enrollment requests with PKCS10 plus out of band information
>> 
>> I am glad this has been spelt out, however it should be 
>> mentioned here or in
>> the security considerations section that a hash (fingerprint) 
>> of the ASN.1
>> DER encoded p10 message be done and made available to the operator for
>> verification with the CA.
>
>Agree here also.  
>
>In addition I'd like to clarify the following section of appendix A.1
>
>".... In addition to CMP and CMC, there are
>at least two other non-IETF protocols that have been used by a number
>of IPsec vendors and CAs.
>
>The IPsec market has coalesced around one method of enrollment that is
>not fully defined anywhere other than this document. That method can be
>called "PKCS10 plus out of band" or "P10POUB", described below. All
>IKE systems that need to obtain a certificate for the public key MAY
>do P10POUB, and MAY do CMP and/or CMC in the near future."
>
>You will find that CMC has fully defined the P10POUB method described.  In
>fact, one of the main goals of CMC was to standardize and define the use of
>a simple PKCS#10 and PKCS#7 message for certificate enrollment.  It is known
>as the "simple PKI request/response" method in CMC.
>
>Regards,
>Alex
>
>
>
>
>> 
>
Follow-Ups: References: