Subject: RE: specific policies used in conjunction with anyPolicy

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 22 Mar 2001 11:58:59 -0800

Dave,
You have made a big leap here which I had not interpreted from the text.
This revolved around who is driving the inputs into the path validation
process. I can conceive instances where an application would want to
pass in a-d. I do not think for one moment that an application would
care about the rest, nor should they. This stuff is already way to
complex, and interdependencies like this are a nightmare. We are on an
uphill battle to get applications to use PK wisely in the first place
because they think it is hard. Now you are asserting that we need to
make PK administrators knowledgeable about what applications they are
supporting and expect that they are intimacy aware of all their needs.
That is not doing to happen. We need clean simple rules if this is to be
successful. So lets start be saying if you assert the all polices OID in
a CA certificate, it is an operational simplification, and the
administrator does not need to add any more.

Trevor

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2001 12:32 PM
To: [email-masked]
Subject: Re: specific policies used in conjunction with anyPolicy

Yes, you may assert both anyPolicy and specific certificate policies in
the same certificate. This may not be specifically stated, but path
processing algorithm (section 6.1.3) does take this possibility into
account.

The reason that this is allowed is exactly the one you stated.
Originally there was a rule that if anyPolicy were included in the
certificatePolicies extension, then no other policy could be included.
This rule was removed when the inhibitAnyPolicy extension was developed.
In the case you mention, the "strict" applications would set
initial-any-policy-inhibit in order to ensure that the path would only
be considered valid under policies that had been explicitly listed in
each certificate. The more liberal applications would not set
initial-any-policy-inhibit and would then (possibly) consider the path
to be valid under more policies.

At 01:11 PM 3/21/01 -0600, Carlin Covey wrote:
>The certificate policies extension allows a sequence of policy OIDs.
>One such policy OID is anyPolicy.  I assume that it is permissible in a
>CA cert to include specific policy OIDs in addition to the anyPolicy
OID.
>The reason I would want to do this is to support applications that
insist
>on finding a specific policy OID, and also support more liberal
applications
>that will tolerate the anyPolicy OID.
>
>draft-ietf-pkix-new-part1-05 does not appear to prohibit using specific
>policy OIDs and the anyPolicy OID in the same CA cert.  Is this true?

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 22 Mar 2001 17:12:09 -0500

Trevor,

I do not see why you think I have made a "big leap". Are you referring to my suggestion that one can assert both anyPolicy and some specific policies or that applications may choose different values for initial-any-policy-inhibit?

First, we have to acknowledge the existence of the inhibitAnyPolicy extension. If a CA includes this extension in a certificate that it issues, then the anyPolicy OID will be ignored in any certificates that follow that certificate in a certification path. If the issuers of those certificates do not specify policies other than anyPolicy in their certificates, then the certification path will either be rejected or will be accepted under no polices. So, if policies are important, and there is the possibility that a CA (or the relying party) will inhibit the processing of anyPolicy, then it will not be sufficient for CAs to assert just the anyPolicy OID. If you want it to be the case that "if you assert the all polices OID in a CA certificate, it is an operational simplification, and the administrator does not need to add any more", then you'll to get rid of inhibitAnyPolicy.

Second, while you may not be able to conceive of an instance where an application would care about the value of initial-any-policy-inhibit, it appears that Carlin Covey can. He stated that he wanted "to support applications that insist on finding a specific policy OID, and also support more liberal applications that will tolerate the anyPolicy OID." The way for an application to specify that it insists on finding a specify policy OID is to set initial-any-policy-inhibit.

>supporting and expect that they are intimacy aware of all their needs.

As I stated above, I was merely describing how Carlin Covey could accomplished what he wanted to do. If you think there is something wrong with what he wants to do, that is a different matter. I was merely pointing out that it is supported by the standard.

>administrator does not need to add any more.

Unless the inhibitAnyPolicy extension is eliminated, this is simply not the case.

> >CA cert to include specific policy OIDs in addition to the anyPolicy OID.
> >The reason I would want to do this is to support applications that insist
> >on finding a specific policy OID, and also support more liberal applications