RE: End-Entity Certificate Policies

[Russ Housley <housley@xxxxxxxxxx>]

Wow.  I did not expect such a flurry of responses in such a short 
time.  Clearly, there is not consensus on this topic (at least not 
yet).  Many people have asked me to explain our reasoning.  I have not had 
the opportunity to run this by Tim, so I hope he does not flame me.  So, 
here goes.


Single Certificate Policy OID

When an end-entity certificate contains more than one certificate policy 
OID, there is ambiguity about the intent of a signer.  On the other hand, 
if the end-entity certificate contains only one certificate policy OID, 
there is no ambiguity.  If an end-entity certificate contains two policies, 
one that says the certificate id for use with non-binding e-mail and 
another that says the certificate is intended for purchases up to $10,000, 
then it is not clear the signer intends when a signature is generated.

One solution for this problem is specified in  RFC 2634, Section 5.4 
(Signing Certificate Attribute Definition).  Here, the signer can state the 
policy that was intended at the time the signature is generated.  Other 
protocols that use the PKIX Certificate Profile do not have similar mechanisms.

I understand the desires expressed by Mack Hicks and Dave Solo for multiple 
certificate policy OIDs in a certificate.  And, I can imagine environments 
where there would not be a problem with this practice.  Perhaps we need 
some guidance about when it is acceptable and when it is not.


Limiting Certificate Policy Qualifiers to End-Entity Certificates

A review of the certificate path validation algorithm shows that one of 
it's outputs is a set of certificate policy qualifiers.  X.509-1997 says 
that a successful validation returns "a set of policies constrained by the 
CAs in the certification path, together with all qualifiers for these 
policies encountered in the certification path."

This means that the certificate user cannot tell which qualifier goes with 
which certificate in the path.  Rather, an unordered set of the qualifiers 
is provided. Since the purpose of qualifier is to provide additional policy 
information to the certificate user (a.k.a. the relying party), it seems 
important that the set of qualifiers not provide 
contradictions.  Especially in the case of the qualifiers specified in RFC 
2459.

Mike Myers suggests that CA certificates should be permitted to include the 
CPS pointer qualifier.  Let's assume that there is a simple path of two 
certificates, the CA certificate and the end-entity certificate.  The CA 
certificate has two certificate policy OIDs, each with a CPS pointer 
qualifier.  The end-entity certificate has a single certificate policy OID, 
also with a CPS pointer qualifier.  When the certificate path validation 
algorithm is executed, one of the outputs will be the certificate policy 
OID that is common to both certificates and the two qualifiers (one from 
the CA certificate and one from the end-entity certificate).  What is the 
certificate user expected to do?  If the URLs are different, the 
certificate user really has no idea what to do.

Russ