Subject: RE: End-Entity Certificate Policies

From: Russ Housley <[email-masked]>
Date: Thu, 02 Sep 1999 15:33:28 -0400

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

---

From: Bill Burr <[email-masked]>
Date: Thu, 02 Sep 1999 16:45:57 -0400

>then it is not clear the signer intends when a signature is generated.

But, is it clear that one CP will necessarily be that specific?  A single
policy  might allow several applications, or it might speak to assurance
level rather than constraining applications at all.

Moreover, when I sign something with my John Hancock, do I state the policy
under which I sign it, and have a separate signature for every kind of
document I sign?  Why do I have to with certificates?  And, is it your
supposition that the certificate used to sign a document is always bound
with the signed document?  
 
>certificate user really has no idea what to do.
Regards,

Bill Burr

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 02 Sep 1999 23:00:13 +0200

Russ,

Comments in line.

>then it is not clear the signer intends when a signature is generated.

This is to me a bad way to view certificate policies. Certificate Policies
are assertions by the CA to relying parties. It is NOT an assertion by the
signer. When a signer signs a message, the intention of the signer is only
expressed in that message, not in any certificate.

Even if there are many certificates out there for the signers public key,
the signer goes free of liability for any "bad" certificate. And if some of
these certificates has ambiguous policy OID:s, that says nothing about the
signers intent. It just points out a bad CA and that CA may get into trouble.

What you are talking about seams to be more appropriate for signature
policies, which would be asserted by the signer.

>protocols that use the PKIX Certificate Profile do not have similar
mechanisms.

With all respect to the attacks expressed in section 5, any attempt to
solve this by having the signer assert appropriate certificate content, is
to address the issue from the wrong angle. These attacks do in the first
place assume that a relying party trusts any bad CA.

If that is so (i.e. the relying parties trust hierarchy is broken) or a CA
within that trust hierarchy is bad. Then there are so many other potential
problems, that you basically are sucked any way.

These problems must be treated by each relying party by having working
trust models originating from trusted roots. If you have that, then you are
fixing non-existing problems. If you don't have that, you can't fix
anything anyway.

>some guidance about when it is acceptable and when it is not.

many OIDs are acceptable. The CA must however make sure that no certificate
contains conflicting policies. But I hope all CAs understand that.

>contradictions.  Especially in the case of the qualifiers specified in RFC 

I believe you read X.509 wrong here. The full text of that section continues:

"Unless any-policy is returned, the certificate user shall ONLY use the
certificate in accordance with ONE of the identified policies and shall
process all qualifiers for THAT policy present in the certification path."

Now how is that possible if you return an un-ordered set of the qualifiers,
not related to their associated policies.

The path processing algorithm does further not use separate variables for
policies and for qualifiers. A reasonable interpretation of the algorithm,
given these facts, must be that all policy objects in the process is
handled together with their associated qualifiers, and thus should be
presented that way in the output.

Your interpretation must be wrong here, or do you have an installed base of
softwares to back your view?

>certificate user really has no idea what to do.

See above +
This example suggest that a CA issue a certificate under two different
CPSs, That seams to be a false case. 

If there would be a guideline it should say that a certificate may include
many policy OIDs but should only indicate one CPS. One CPS may very well
reflect multiple policies. 

>Russ

/Stefan

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------