[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-ipsec-pki-req-01: critical Extended Key Usage?
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
Follow-Ups: