[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ipsec-pki-req-03.txt
Greg wrote, excerpting:
>
> From section 3.1 The extendedKeyUsage field:
>
> "In a certificate for an IPsec end entity, the extendedKeyUsage field
> commonly called "EKU") MUST be present and MUST contain only
> 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."
>
> Why must the certificate only have the one extended key
> usage? This is too
> restrictive.
I strongly agree, in the interests of avoiding unnecessary proliferation of
per-application certificates. Is there a compelling reason which warrants
erecting a barrier so that certificates which are to be usable for IPsec
purposes must not be used by other applications, at least if those other
applications also employ EKUs?
I like the idea of only having one IPSec
> extended key usage
> bit though. Could we stick with PKIX and say that if flagged
> critical then
> it must only have one value. Therefore you could remove the "and MUST
> contain only the object identifier iKEIntermediate..." since
> that would be
> covered by PKIX RFC 2459 section 4.2.1.13 for critical
> extended key usage
> extensions.
I'm not sure I follow this. RFC-2459, 4.2.1.13, states re EKU that: "If the
extension is flagged critical, then the certificate MUST be used only for
one of the purposes indicated." This doesn't preclude coexistence of
IPsec's iKEIntermediate OID as one value in a critical EKU along with other
OIDs belonging to other applications.
--jl