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

[Rich Ankney <rankney@xxxxxxxxx>]

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