RE: specific policies used in conjunction with anyPolicy

"David A. Cooper" <david.cooper@nist.gov> Thu, 22 March 2001 22:13 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23245 for <pkix-archive@odin.ietf.org>; Thu, 22 Mar 2001 17:13:07 -0500 (EST)
Received: from localhost (daemon@localhost) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA28151; Thu, 22 Mar 2001 14:12:30 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Mar 2001 14:12:27 -0800
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA28115 for <ietf-pkix@imc.org>; Thu, 22 Mar 2001 14:12:25 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA16060; Thu, 22 Mar 2001 17:12:26 -0500 (EST)
Message-Id: <4.2.2.20010322164837.00ab9a30@email.nist.gov>
X-Sender: cooper@email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Date: Thu, 22 Mar 2001 17:12:09 -0500
To: Trevor Freeman <trevorf@Exchange.Microsoft.com>, ietf-pkix@imc.org
From: "David A. Cooper" <david.cooper@nist.gov>
Subject: RE: specific policies used in conjunction with anyPolicy
In-Reply-To: <CC2E64D4B3BAB646A87B5A3AE97090420D0F46DB@speak.dogfood>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe

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:david.cooper@nist.gov] 
>Sent: Wednesday, March 21, 2001 12:32 PM
>To: ietf-pkix@imc.org
>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?