RE: specific policies used in conjunction with anyPolicy

["Trevor Freeman" <[e-mail]>]

David,
Any CA will have to be fully aware of its actions relating to supporting
its client base. Just because it maybe aware of an extensions existence,
does not mean its clients are ware of it. That has nothing to do with
the issue here. Is there any benefit from an explicitly defined policy
over the use of the all policy OID. A parent CA may restrict the range
of policies it is prepared to except from a subordinate using the
all-policy OID, but is there any benefit in wanting that policy explicit
marked. Without some more concrete justification, then the case seems
week, and does not justify the increased complexity we are inheriting.
It is think kind of "feature creep" that will the undoing of this group.
Trevor

-----Original Message-----
From: David A. Cooper [mailto:[e-mail]] 
Sent: Thursday, March 22, 2001 2:12 PM
To: Trevor Freeman; [e-mail]
Subject: RE: specific policies used in conjunction with anyPolicy


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.

At 11:58 AM 3/22/01 -0800, Trevor Freeman wrote:
>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.

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.

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

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

>Trevor
>
>-----Original Message-----
>From: David A. Cooper [mailto:[e-mail]]
>Sent: Wednesday, March 21, 2001 12:32 PM
>To: [e-mail]
>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?