Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.

[Michael StJohns <[e-mail]>]

At 11:54 AM 2/20/2013, Dr Stephen Henson wrote:
>On 20/02/2013 16:26, Erwann Abalea wrote:
>> 
>> They can define their own extension, like MS ApplicationPolicy, or NetscapeCertType.
>> They can also rely on CertificatePolicies (which they do for EV certificates,
>> and are starting to do for DV/OV).
>> 
>
>When this issue has come up before CertificatePolicies has often been mentioned
>as an option but without many details.
>
>How would this work in practice?


The simplest way would be to just use the EK usage OIDS (not the EKU cert extension OID) as "policies".  You'd have to include each and every one in all of the CA's in the chain in the policy extension (or the anyPolicy policy), but that's probably easier than defining a whole new extension and modifying the path processing algorithms to add another path-binding extension.  I'd probably also include the EK oid in the EKU of the end certificate to actually signal the cert can do what the EK oid says it can do, otherwise you get some issues where the intermediate CA has the usage bits set to sign code (for example).

A different way might be to define a "BindingExtendedKeyUsage" policy and use that in conjunction with the EKU extension to signal that the set of OIDs in an EKU must be a subset of the parents EKU OID set (and for purposes of path walking will be reduced to a subset during evaluation).  Unfortunately, the semantics of the policy extension are more in tune with turning on things (e.g. if policy A is present in the chain then you get treated better) than turning off things.  In this case, you'd have to change the meaning of the policy to say that if its present in any parent then the path processing has to do the "binding key usage" processing to that parent, otherwise the last CA in the path can just decline to place the policy in the cert it issues.

But I'd like to note that this treatment of EKs as a general class is pretty short sighted.  There are few if any key usages that you really want to control from the root, and those are more properly handled as part of the path processing implementation based on the chain characteristics, rather than trying to do something like general path-like processing for the EKU based on the parent CA.

E.g. if the attributes for the trust anchor for this chain says that the chain can't be used for signing code, then the presence of the appropriate code signing EK oid is ignored.


>Steve.
>-- 
>Dr Stephen N. Henson.
>Core developer of the   OpenSSL project: http://www.openssl.org/
>Freelance consultant see: http://www.drh-consultancy.co.uk/
>Email: [e-mail], PGP key: via homepage.
>_______________________________________________
>pkix mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pkix