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

Re: draft-ietf-ipsec-pki-req-01: critical Extended Key Usage?

The two sections were meant to be consistent, I'll pull the criticiality
reference.

I hear a variety of opinions about multi-usage certificates.  The CA people
seem to dislike it, the IPSec implementors seem to think it's theologically
acceptable but unnecessarily complex, and users seem to sometimes actually
want it.  I meant to make the document allow this possibility, because I 
don't see an IPSec reason to preclude it.


At 11:36 AM 9/30/98 -0400, you wrote:
>I noticed the following statement in Section 3.3 (Validation) of pki-req-01:
>
>"3. ExtendedKeyUsage SHOULD be checked to ensure the certificate is valid
>for the system in question, including the criticality fields.  This
>extension MUST be treated as critical."
>
>Later, in Sec. 3.4.3 (IPsec validity checking), it's stated that:
>
>"4. if extendedKeyUsage is present it must contain either iKEIntermediate or
>iKEEnd.  If additional EKU object identifiers are present then their use is
>a locally defined matter."
>
>As a goal, I'd like to avoid declaring a need to proliferate large numbers
>of per-protocol certificates for a single principal unless there's a
>compelling need to do so.  It seems natural that a user might obtain a
>certificate initially for use with one protocol (which might or might not be
>IPsec) and then want to use it with additional protocols without
>re-registering (assuming that this is consistent with CA-specified policy),
>and ability to satisfy this goal depends on the profiles involved.   
>
>The flexibility in 3.4.3 seems like a reasonable compromise: IPsec
>components can use a certificate with no EKU, but if the CA inserts an EKU,
>that EKU must list an IPsec OID as one of the intended usages.  I'm not sure
>how to interpret the text in 3.3, and would recommend removing or clarifying
>the references to criticality.  In particular, I believe that IPsec
>components should be willing to accept certificates with non-critical
>ExtendedKeyUsage extensions.  If this weren't the case (i.e., if only
>critical EKU extensions were acceptable), this would unnecessarily restrict
>the PKIX profile (which permits either critical or non-critical EKUs).  
>
>--jl
>
References: