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

[Bill Burr <william.burr@xxxxxxxx>]

At 04:38 PM 12/11/97 -0700, you wrote:
>At this point I confess to being somewhat bemused about the overall purpose
>of the policy OID.
>
>I think that part of the problem may be that we don't seem to have a clear
>understanding of the SUBJECT of a policy OID.  To whom does it apply - the
>issuer of the certificate, or the subject of the certificate?
>
>In other words, is the policy OID a shorthand form of a more or less legally
>binding REPRESENTATION made by the subject of a certificate to the issuer,
>or is the policy OID merely describing the behavior of the CA itself?
>
>My view is that the policy OID serves to protect up to three parties ų the
>CA, the subscriber, and the relying party.  It provides protection to the
>subscriber and/or the CA by providing appropriate legal notice or caveats
>and conditions to the relying  party, and it provides protection to the
>relying party (especially on a closed user group contractual situation) by
>at a minimum reminding the subscriber/signer of her obligations, and may
>also enforce those obligations in the application.
>
>For example, in some of the stuff I am presently working on (representing
>the key quality and process quality of a digital signature, among other
>things), it is necessary to know what properties the SIGNER is willing to
>guarantee, by some mechanism that is TBD ų either contractual or by
>technical enforcement means.
>
>Since there is no convenient way to encode these attributes in the current
>definition of the digital signature itself, I am using policy OIDs to
>indicate a representation or a commitment made by the subject/signer to the
>CA. Likewise, the next higher certificate would include a
>representation/commitment made by the subordinate CA to the higher level CA.
>
>So the question is, to whom does the policy OID in the lowest level
>certificate apply, in general?  And what, if anything, would a policy
>constraint attribute mean in the lowest level certificate? Does it even make
>in sense to turn on the policy constraint for the lowest level certificate?
>Whose behavior is supposedly being constrained?
>
>Alternatively, what is to be gained by having the ability to turn on the
>critical flag for an attribute, if the validating program used by the
>relying party is free to ignore it?
>
>If we only look at the problem from the perspective of the relying party,
>then do we lose the ability to apply any controls on the signing
>application?
>
>Ideally, I'd like the signing application to check the policy OID of the
>certificate that is to be used to validate the signature, and to either
>modify its behavior to conform to the policy, or to refuse to sign if it
>doesn't understand the policy or can't comply, assuming that the attribute
>is marked critical.
>
>Let me propose a strawman interpretation, just to have something for
>everyone to shoot at. This of course applies only to those applications
>which purport to be PKIX compliant.
>
>With respect to the originator:
>
>1.  If a policy OID constraint is included in a certificate that the
>end-user/signer has selected to be used to validate the signature, the
>signing application must be (pre-)configured as implementing, supporting,
>and/or conforming to that policy in order to sign.
>
>2.  If a policy OID is included and marked critical in a certificate which
>the signer has selected to be used to validate the signature, but the policy
>OID constraint is NOT imposed, then the signing application must either be
>configured as implementing, supporting, and/or conforming to that policy;
>OR, the text of any notices contained as policy OID parameters shall be
>presented to the human user for manual approval prior to signing.
>
>With respect to the relying party:
>
>3.  If a policy OID is included in a certificate that was not required by a
>policy OID constraint imposed by a higher level certificate, AND if that
>policy OID is marked critical, then the signature validation
>application/mechanism must either be (pre-)configured to require and/or be
>cognizant of that policy; OR, the text of any notices contained as policy
>OID parameters shall be made available to the human user during the process
>of validating the digital signature.
>
>Comments?
>
>Bob
>
>
>
>Robert R. Jueneman
>Security Architect
>Novell, Inc.,
>Network Services Division
>122 East 1700 South
>Provo, UT 84604
>801/861-7387
>bjueneman@novell.com
>
X.509 clause 12.2.2.6 contains the following statement about the
certificate policies field:

"If the extension is flagged critical, it indicates that the certificate
shall only be used for the purpose, and in accordance with the rules
implied by one of the indicated certificate policies. The rules of a
particular policy may require the certificate-using system to process the
qualifier value in a particular way."

But later on, in clause 12.4.3, weāre told:

"The inputs to the certification path processing procedure are:
a)      a set of certificates comprising a certification path;

b)      a trusted public key value or key identifier (if the key is stored
internally to the certification path processing module), for use in
verifying the first certificate in the certification path;

c)      an initial-policy-set comprising one or more certificate policy
identifiers, indicating that any one of these policies would be acceptable
to the certificate user for the purposes of certification path processing;
this input can also take the special value any-policy;

d)      an initial-explicit-policy indicator value, which indicates if an
acceptable policy identifier needs to explicitly appear in the certificate
policies extension field of all certificates in the path;

e)      an initial-policy-mapping-inhibit indicator value, which indicates if
policy mapping is forbidden in the certification path; and

f)      the current date/time (if not available internally to the certification
path processing module)."

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.

So, it seems to me that weāre left with a rather unenforceable requirement
against applications or users, that they shall not include a policy in the
initial-policy-set unless the application is consistent with the policy.
But does it make any sense to talk about x.509 or PKIX conformance for
applications or users?  Not to me.  Law, business practice or contractual
relationsips may constrain my behavior as an end user, but never X.509 or
PKIX.

What if the special value "any-policy" is set?  We might want to prevent
automatically accepting a certificate with a critical certificate policy,
if "any-policy" is set, but not the specific policy OID.  But I canāt think
of a more rigorous provision that seems practical or desirable.

This leaves folks who want to use the certificate policies field to enforce
something on the relying party pretty well left out.  Too bad.  I think
that we just have to accept that a certificate policy, even a critical
certificate policy, is a representation or a disclaimer made to a relying
party, which the relying party or application may or may not choose to
honor or accept, but the thatās outside the scope of what we can expect to
enforce through X.509 or PKIX.
Regards,

Bill Burr