Subject: RE: End-Entity Certificate Policies

From: Russ Housley <[email-masked]>
Date: Tue, 07 Sep 1999 10:32:46 -0400

Stefan:

 >>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.
 >
 >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.

Certificate policies are defined in X.509, Section 3.3.5.  Is says: "A 
named set of rules that indicates the applicability of a certificate to a 
particular community and/or class of application with common security 
requirements. For example, a particular certificate policy might indicate 
applicability of a type of certificate to the authentication of electronic 
data interchange transactions for the trading of goods within a given price 
range."

So, what do these words mean?  They do not seem to exclude any of the 
parties: the CA, the subject, and the certificate user (a.k.a. relying party).

 >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 OIDs, that says nothing about the
 >signers intent. It just points out a bad CA and that CA may get into trouble.

In my view, the certificate user should reject a transaction that is 
associated with an inappropriate certificate policy.  The certificate user 
states which certificate policies are acceptable for the pending 
transaction in the initial-policy-set input to the certificate path 
validation algorithm.  If the path does not support this policy or 
policies, then validation fails.  Further, a set of certificate policy 
qualifier is returned for each valid policy.  These qualifiers are supposed 
to help the certificate user determine if a valid path is appropriate for 
the specific transaction at hand.

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

We do not have such a thing....

 >>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.
 >
 >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.

I grant you that some of the attacks are a result of a certificate user 
trusting a "bad" CA.  However, if the same public key is in more than one 
certificate, similar issues arise.  This provides a mechanism for the 
signer to assert which of those certificates should be used to validate the 
message.  (Using a different public key in each certificate is even better.)

 >>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.
 >
 >many OIDs are acceptable. The CA must however make sure that no certificate
 >contains conflicting policies. But I hope all CAs understand that.

By including multiple OIDs in a certificate, the CA is stating that the 
certificate was issues in accordance with each of the policies.  If the 
certificate policy states a particular use, then the certificate is 
appropriate for that use.  If the certificate policy states a particular 
means of validating identity, then that means was used.

 >>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.
 >
 >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 algorithm gathers the qualifiers associated with each certificate 
policy as it processes the path.  The algorithm returns a set of valid 
certificate policies and a set of qualifiers for each of those certificate 
policies.  I do not see anything in the algorithm that keeps a binding 
between the qualifiers and the certificates that provided them.

 >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.

I think we just said the same thing.  There is no binding.  A certificate 
may provide multiple qualifiers, or it could provide one, or it could 
provide zero.  Can't tell by the output of the algorithm.

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

I do not think that there is any installed base backs any 
view.  Certificate policy handling is absent in most certificate using 
applications and primitive in the rest.  CAs may be more advanced, but you 
cannot really tell given the state of certificate using applications.

 >>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.
 >
 >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.

I belive that it is possible that two CAs can support the same certificate 
policy using different CPSs.  This certificates issued by the two CAs would 
have the same OID but a different CPS pointer.  Now, if one CA issues a 
certificate to the other, the resulting path to an end-entity will have one 
certificate policy OID throughout, but two different CPS pointer qualifiers.

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 08 Sep 1999 14:50:09 +0200

Russ,

We mean almost the same thing, I give some comments though:

>parties: the CA, the subject, and the certificate user (a.k.a. relying party).

Yes, but whatever it says about anyone, it is still an assertion by the CA
and not by the signer of the message.

>the specific transaction at hand.

I agree to all of this.

>We do not have such a thing....

No but others define it. ETSI is defining a structure for a electronic
signature policy in their signature standard. The fact is that this would
be an assertion by the signer, while the certificate policy, by inclusion
in the certificate, is an assertion by the CA.

>message.  (Using a different public key in each certificate is even better.)

I think you are wrong here, As long as relying parties have working trust
models and as long as they know what issuing CA:s, or other characteristics
of a certificate, they require for acceptance of the certificate, there is
absolutely no threat arising from the fact that there are other
certificates out there of other types, certifying the same key.

If this would be a real threat, then that would be the same as saying that
no CA can have control over the reliability in their issued certificates,
since they don't have control over other CA:s issuing certificates for the
same keys.

The only simple and general mechanism that can work here is to recognize
the responsibility of the relying party to determine if a certain
certificate is appropriate for the intended usage. If this is so, then no
one will have to worry about if there are other certificates out there as well.

Trying to twist this around by having the signer to assert the appropriate
certificate, will add a new dimension of trust with new endless "if-based"
requirements.

>means of validating identity, then that means was used.

Agreed.

>between the qualifiers and the certificates that provided them.

Does it have to state that explicitly? The PolicyInformation object carried
in the certificate policies extension contains the policy OID together with
the qualifier.

Obviously you must accept at least one of the policies in the EE
certificate. I would suggest then that it is the qualifier in that
EE-certificate that are to be examined and accepted, thus eliminating this
problem of interpreting the output of the path algorithm.

In this case qualifiers in CA-certificates are never used in path
validation, but may be used in other situations, e.g. when only examining a
CA-certificate or a cross certificate pair.

>certificate policy OID throughout, but two different CPS pointer qualifiers.

I still believe this is illegal in some way, but anyway...
the relying party should use the CPS pointer included in the EE-certificate
qualifier when validating the EE-certificate.

/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
-------------------------------------------------------------------