Subject: RE: Certificate policy question

From: "Fillingham, David W." <[email-masked]>
Date: Wed, 11 Dec 2002 14:03:28 -0500

Hi Peter:

I don't believe that there is anything in any of the applicable standards
that would suggest a certificate can only comply with a single policy, or
only assert one policy.

X.509, Section 8.1.4 describes how to process certificate paths, including
those that may include multiple policies in the certificate policies
extension.
X.509 Section 8.2.2.6 goes on to describe the Certificate Policies
extension:

"This field lists certificate policies, recognized by the issuing CA, that
apply to the certificate, together with optional qualifier information
pertaining to these certificate policies. The list of certificate policies
is used in determining the validity of a certification path, as described in
clause 10."

Of course, the very name of the Certificate Policies extension implies that
more than one policy may be populated in the extension.

Similarly, RFC 3280 states:

"4.2.1.5 Certificate Policies 

The certificate policies extension contains a sequence of one or more policy
information terms..."

RFC 320 Section 6.1 describes how to process the certificate policies field
when validating certificate paths, including cases where multiple
certificate policies are asserted in end-entity and intermediate CA
certificates.

The real-world use of multiple certificate policy OIDs asserted in CA
certificates is pretty clear.  For example, in the US DoD PKI, we have
defined two different certificate policies:

CLASS 3
CLASS 4

Our policies are written so that certificates increase in assurance from
CLASS 3 to CLASS 4.  By asserting our CLASS 3 and CLASS 4 policy OIDs in our
CA certificates, our CAs can issue valid certificates with either of these
policy OIDs asserted.  For example, one end entity subscriber certificate
asserting a CLASS 3 policy can be issued with subscriber private key
protection provided by software, while another certificate issued from the
same CA may assert CLASS 4 because private key protection is provided in
hardware, and the CA conforms to all other CLASS 4 requirements.

A conceivable use of multiple policy OIDs in end-entity subscriber
certificates would be when a certificate conforms to policies associated
with two different communities.  For example, a certificate issued by a
local agency may conform to a broad Federal Certificate Policy, as well as a
more stringent local agency policy.  Asserting both policies in the
certificate allows the local agency to use the certificate policies
extension to set up some of its higher sensitivity relying party
applications to demand the locally generated certificates, while allowing
external Federal agencies to accept the agency's certificate on the basis of
the Federal policy being asserted.

I hope that application developers will adhere closely to what X.509 and RFC
3280 have to say about certificate policy processing.  If application
developers include more constraints on the certificate policies extension
than the standards call out, that creates real problems for those of us
trying to stand-up large PKIs in policy heterogeneous environments.

Best Regards,
Dave Fillingham

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Wednesday, December 11, 2002 12:19 AM
To:	[email-masked]
Subject:	Certificate policy question

[Warning: This is one of those questions which is probably best answered in
          the Style Guide with a note saying "Don't do that"]

Someone just sent me yet another weird cert [0] which has two different, in
some places mutually exclusive, policies (that is, CPSes) in the
certificatePolicies.  I know the de facto standard handling for this is to
ignore the policy, but what's the official word on this?  Do you pick the
one
you like best and ignore the rest?  Use the LSB of the public key as an
index
to pick one?  Pop up a copy of Acrobat in a dialog box, ask the user to read
the 100-odd-page CPSes, and pick the one with the flashiest graphic on the
cover?

I'd like to at least do *something* in my code other than just ignoring it.

Peter.

[0] The cool thing about 2459/3280's complexity is that everyone gets their
    own mistake arc without ever having to duplicate anyone else's.  Maybe
we
    could formalise this with OIDs or something :-).

---

From: Sharon Boeyen <[email-masked]>
Date: Wed, 11 Dec 2002 16:02:58 -0500

Further to Dave's comments, I want to urge that people remember the
differences
and distinctions between certificate policies and a CPS. They are different.
A 
CA would have a single CPS and that CPS can cover the operations of that CA
in 
issuing certificates that are issued under one or more policies. There are
two 
common 'types' of certificate policy defined today (level of assurance based
and 
certificate use based). In both cases there are valid reasons for including 
multiple certificate policy OIDs in both end user and cross certificates. 

Sharon 
-----Original Message-----
From: Fillingham, David W. [mailto:[email-masked]]
Sent: Wednesday, December 11, 2002 2:03 PM
To: [email-masked]
Subject: RE: Certificate policy question

Hi Peter:

CLASS 3
CLASS 4

Best Regards,
Dave Fillingham

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Wednesday, December 11, 2002 12:19 AM
To:	[email-masked]
Subject:	Certificate policy question

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 12 Dec 2002 14:36:50 +1300

Richard Levitte - VMS Whacker <[email-masked]> writes:

>What kind of certificate are we talking about, an EE certificate or a CA one?

It's an EE cert.

>If I assume a somewhat bastardous attitude, I'd say such a certificate
>invalidates the whole path, IF you end up having those clashing policies in
>your state at the end of path construction/validation.

I have yet to find anything [0] which even notices the two conflicting
policies (there are two different policy OIDs and two pointers to different
CPSes), thus my comment that while standard practice appears to be to totally
ignore policies, I really feel that I should be doing something about it, I'm
just not sure what.

Peter.

[0] At least in the set of generally-used, publicly-available PKI software,
    there are probably commercial/proprietary products around which get it
    right.

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 12 Dec 2002 10:33:48 -0500

That would be a non-conformant implementation. Please read the standard -
your answers are there. 
X.509 clause 8.2.2.6 is the clause that defines the certificatePolicies
extension. It begins 
with "This field lists certificates policies, recognized by the ......". The
path validation clauses 
are consistent with this. I don't see how you could possibly interpret it
any other way. 

One very simple example of where this is useful is a situation where an
enterprise has 2 certificate 
policies differing only in their scope with respect to email. One policy OID
indicates that certificates 
issued under this policy can be used for internal enterprise email. Another
policy OID indicates that 
certificates issued under this policy can be used for external email. A user
who is permitted to to do 
external secure email as well as internal would have both OIDs in their
cert. Any cross certs issued 
to other enterprises with which secure email could be exchanged would
contain ONLY the external email 
OID. Internal users would be configured with acceptable policy sets that
enable them to validate each 
other's internal certificates for internal email. Users in other
organizations would validate only the 
certs that had the policy that was contained in the cross cert relevant to
that enterprise (ie the external
OID).

There are existing environments where techniques such as this are in
operational use today. Other environments
using policy for levels of assurance do a similar thing and a user whose
cert is good for level 3 (but is also 
good for levels 2 and 1) would contain all three OIDs. Different relying
parties, depending on their own local 
security policy, would be validating based on whatever policy is relevant.
So, in this case, for example, a 
relying party who required level 4 would fail validation for that cert but a
relying party who required level 
1 2 or 3 would pass.

Sharon

-----Original Message-----
From: Richard Levitte - VMS Whacker [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 6:14 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Certificate policy question

In message <[email-masked]> on Thu, 12
Dec 2002 14:56:35 +1300, [email-masked] (Peter Gutmann) said:

pgut001> Actually that probably provides the answer to the question: >
pgut001> 1 policy in an EE cert, where one policy isn't a
pgut001> subset/refinement/compatible version of the other [0],
pgut001> demonstrates that the issuer is sufficiently confused over
pgut001> policy issues that the cert should be regarded as following
pgut001> no policy at all :-).

So, out of curiosity, would you regard that cerificate as valid or
invalid (I hope to code better validation into OpenSSL, and handling
of policies is certainly a large part, so I'm interested as well :-))?
I'd opt for invalid unless someone can tell me I should regard as
valid and why.  I'd even go one step further and regard an EE
certificate with more than policy as suspicious, at least.

pgut001> [0] Figuring out how to check for this is left as an
pgut001> exercise for the reader.

:-)

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

---

From: [email-masked]
Date: Thu, 12 Dec 2002 18:16:57 +0000

Peter,

Is is possible for you to disclose what these policies are that are 
contradictory or mutually exclusive?  It would also be useful to know what 
application these certs are meant to be used in.

Thanks.

Khaja

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 13 Dec 2002 20:21:00 +1300

Richard Levitte - VMS Whacker <[email-masked]> writes:

>So, out of curiosity, would you regard that cerificate as valid or invalid (I
>hope to code better validation into OpenSSL, and handling of policies is
>certainly a large part, so I'm interested as well :-))? I'd opt for invalid
>unless someone can tell me I should regard as valid and why.  I'd even go one
>step further and regard an EE certificate with more than policy as suspicious,
>at least.

I regarded it as suspicious and checked the CPS, whereupon I regarded it as
*really* suspicious.  However from some of the other comments posted here, it
makes sense to regard the policies as a OR b OR c rather than a AND b AND c
(or UNION or INTERSECTION or something similar).  It'd be useful to have this
mentioned explicitly somewhere though, since reverse-engineering the effect of
the path-processing algorithm, and then trying to decide whether the effect
achieved when two incompatible policies are present is intentional or
coincidental, is rather tricky.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 13 Dec 2002 20:37:32 +1300

Richard Levitte - VMS Whacker <[email-masked]> writes:

>Additionally, it could be a good thing to have the possibility to distrust
>certain CAs (no, I don't believe a CRL entry is the right thing, or is there
>a reason code that means "the CA made a fool of itself"?  Either way, that
>would also only be possible in a mesh-type PKI, I think).

I've got that in my code, so you can specifically say "I don't trust this CA",
or "I don't trust this CA to issue certificates".  Unfortunately there's no
way to express "I don't trust this CA to not send out its private key as a
PKCS #12 file/encrypt its CRLs so you can't read them/engineer its way out of
a wet paper bag/etc".

>or is there a reason code that means "the CA made a fool of itself"?

There's always my idiotPolicy suggestion :-).

Peter.