Hi there:
PMHager wrote:
> Correct, as I already denoted these are from the obsolete RFC2459.
>
> As the IETF/PKIX charter could not define a consenting set of flags,
> Steve Kent had suggested to drop them and leave it to the IPsec WG.
> This has been done by RFC4809: Its recommendation is not to use any
> extKeyUsage and, if necessary now to use:
>
> id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 }
>
> As RFC4809 just over 2 years old and till now its OID is not in the
> databases from Alvestrand or the ITU, it is very likely that products
> in the field still support the former ones. This is ok, as long as
> it is done in conformance with X509's extKeyUsage definition:
>
> If the extension is flagged critical, then the certificate
> shall be used only for one of the purposes indicated.
>
> If the extension is flagged non-critical, then it indicates
> the intended purpose or purposes of the key, and may be used
> in finding the correct key/certificate of an entity that has
> multiple keys/certificates...
>
Be *VERY* careful with this interpretation - RFC5280 states for EKU:
"If the extension is present, then the certificate MUST only be used
for one of the purposes indicated."
Thus removing the X.509 restriction for constraining based on
criticality - if you are going to conform to RFC5280, then the mere
presence of an EKU constrains the usage of that particular certificate.
Have fun.
Patrick.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
