Re: [IETF-PKIX] Critical extensions and Policy OIDs

[Warwick Ford <wford@xxxxxxxxxxxx>]

I know we did not express things very well but, with the current model in
X.509 (like it or not), there are two quite distinct uses of cert policies
in certs:

1. A relying party may only find a chain acceptable to its purposes if
certain policies are declared by CAs.
2. A CA may only stand behind a cert if it is used, by a relying party, in
accordance with a certain policy stipulated by the CA.

In general, 1 is supported by noncritical Cert Policy extensions and by the
explicit policy indicator in the Policy Constraints extension; and 2 is
supported by critical Cert Policy extensions.  Don't mix these up.

The calculation of the intersection of the two sets at one point in the
validation algorithm is purely a performance expedient -- it so happens
that if there is a null intersection of these two sets at this point then
there is no way you can end up with a validated chain, hence you might as
well exit.

Warwick


At 05:06 PM 12/12/97 -0500, Rich Ankney wrote:
>Bill Burr said:
>> Note that no input to the cert. path processing procedure includes any
>> rules or way to understand what is implied by any policy.  Some
>application
>> simply sets, possibly under user control, the initial-policy-set of
>> policies that it will accept.  If we assume a general purpose certificate
>> path processing module, hopefully serving all the different applications
>> that may use certificates, it’s hard to envision how any automatic
>> enforcement of  critical policies can be accomplished in the cert. path
>> processing procedure.  I can’t believe that certificate path processing
>> module can reasonably check for anything except the initial-policy-set,
>if
>> it sees a certificate policy field that is flagged critical.  I for one
>at
>> least, certainly want to divorce the certificate path processing from any
>> obligation to understand the application, or we wind up with a different
>> cert. path processing module for every application, I’m afraid.  And
>X.509,
>> it seems to me is not really, nor should it be, an application standard.
>>
>
>Farther down in the description of path processing, X.509 states that, when
>a critical policy extension is encountered, that set of policies is
>intersected
>with the current value of "authority-constrained-policy-set", which is
>initialized
>to "any-policy".  This is checked vs. what the user input as
>"initial-policy-set"
>to make sure their intersection is not empty. The "authority-constrained-
>policy-set" is returned from the path-processing algorithm.  It seems to me
>that this will cause the behavior we (or at least I) want:  only critical
>policies are allowed to make it through path processing, and be returned to
>the caller, even if
>the user input "any-policy" initially.  I suspect that what should be
>returned
>is the intersection of the authority-constrained set and the
>user-constrained
>(initial) set, though; but that may be a flaw in X.509.
>
>Regards,
>Rich
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------