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

[Bob Jueneman <BJUENEMAN@xxxxxxxxxx>]

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

>>> "Simonetti David" <simonetti_david@bah.com> 12/11/97 08:26:46 >>>
Moshe,

I respectively disagree with your analysis.  The paranthetical of PKIX-1
is not a reference to cert path validation, but rather is a reference to
how the application *uses* the certificate after validation (please
let's not debate the merits applying requirements to the application).
This is described in X.509 by the quotation I provided in my previous
message.

As an example of a use of a critical certificate policies extension,
let's say that I'm a CA generating and signing certificates for my
private community.  By signing the certificate I am vouching for the
identity of the certificate subject.  I'm concerned about by my
liability if an individual decides to misuse her/his certificate outside
of my community, so within my certificate policy is a statement that the
certificate may never be used for any purpose outside of the community.
I then include the OID of that policy in the certificate policies
extension of every certificate that I generate, and I indicate the
extension as critical.

X.509 states that the certifcate with this extension as critical "shall
only be used for the purpose...implied by one of the indicated
certificate policies."  As a result, an application that claims
X.509-compliance cannot use this certificate for a purpose other than
that stated in the registered certificate policy.  It's not entirely
clear to me yet how an application can truely restrict the use of a
certificate in this manner, but in any case, as the CA that generated
the certificate, I can use this extension to (hopefully) limit my
liability in case of certificate misuse.

Dave Simonetti

moshe@checkpoint.com wrote:
>
> The Certificate Policies extension is not the only factor in validating
> a certificate policie, two other factors are the path validation algorithm
> and the policy constraints extention.
>
> According to the path validation algorithm, an application that has no
> explicit policy requirements has almost nothing to do with the Certificate
> Policies extension, unless there is a policy constraints extention.
> (almost nothing because it should show the user the "User notice" policy,
> but this is a should and not a must).
>
> In view of this the offending sentence:
>
> "(Applications without specific policy requirements are not required to
list
> acceptable policies, AND MAY ACCEPT ANY VALID CERTIFICATE REGARDLESS OF
> POLICY EVEN IF THE EXTENSION IS MARKED CRITICAL.)"
>
> adds no information and is only a clarification of the path validation
> algorithm.
>
> If a CA want to stop that behavour it can use a critical policy
constraints
> etension that contains the requireExplicitPolicy field.
>
> Moshe Litvin
>
> > Bob--
> >  Being relatively new to this mailing list, I did not notice the
sentence you
> > quoted. Knowing the authors, I suspect they have a good reason for
putting that
> > line in there and I would like to hear it. However, I can't imagine that
the
> > reason is good enough to make up for the trouble it may cause! The
lawyers at
> > the clients I work with (large financial institutions, insurance
companies,
> > telecomms, etc.) would "have a cow" if they realized that their software
may be
> > "PKIX conformant" and still not support a critical extension that they
are
> > relying on to possibly limit their liability. What is the point of
marking
> > anything critical with that sentence in the document? Before I rave
anymore,
> > could one of the authors restate their reasoning for including that
sentence?
> > I'd like to hear the other side of the coin. Thanks.
> >
> > Dave Oshman
> > Price Waterhouse LLP
> > Electronic Commerce/Internet Security
> >
> >
> >
> >
> >
> > BJUENEMAN@novell.com on 12/05/97 12:41:54 PM
> > To: Dave Oshman@Price Waterhouse-US, ietf-pkix@Tandem.COM @ Internet
> > cc: kent@bbn.COM @ Internet, wford@verisign.COM @ Internet
> > Subject: Critical extensions and Policy OIDs
> >
> > Dave,
> >
> > So that we are all on the same page, let me refer you to the Oct 14th
draft
> > of part 1, paragraph 4.2.1.5 Certificate Policies, second paragraph:
> >
> > "Applications with specific policy requirements are expected to have a
list
> > of those policies which they will accept and to compare the policy OIDs
in
> > the certificate in that list. If this extension is critical, the path
> > validation software must be able to interpret this extension, or must
reject
> > the certificate."
> >
> > So far so good, although the text tends to put too much emphasis on
> > applications deciding on their own what policy requirements they require
and
> > will enforce, whereas I believe that such decisions will more often be
made
> > by the MIS department and conveyed in the root-level certificate (issued
by
> > the MIS department) which cross-certifies particular CAs and imposes any
> > necessary policy constraints on subsequent certificates.
> >
> > Where the train jumps the track is in the following sentence of the
> > paragraph:
> >
> > "(Applications without specific policy requirements are not required to
list
> > acceptable policies, AND MAY ACCEPT ANY VALID CERTIFICATE REGARDLESS OF
> > POLICY EVEN IF THE EXTENSION IS MARKED CRITICAL.)"
> >
> > This takes the issue well beyond that of a rogue application.  It says
that
> > a PKIX standards-conforming application can ignore an attribute bearing
a
> > Critical marking with impunity -- it doesn't have to even notify the
user
> > that it saw something that it doesn't understand.
> >
> > I believe that this is COMPLETELY UNACCEPTABLE, and I would appreciate
your
> > help in convincing the authors of part-1 (Messrs. Housley, Ford, Polk,
and
> > Solo) to delete this sentence.
> >
> > I think that we are in agreement that if someone goes out and buys an
> > application that is non-conforming, we aren't going to sic the Internet
> > police on him. I'm not trying to prevent anyone from building rogue
> > applications. However, if someone knowingly uses an application that
does
> > not conform to the standard, or does not implement the Critical
attribute
> > correctly, he has to accept the consequences of his actions, and both
the CA
> > and the subscriber should be relieved of any liability that might result
> > from the relying party accepting some transaction that they should have
> > rejected, based on the policy OID and the Critical flag.
> >
> > But if the standard itself says that such markings can be ignored with
> > impunity and still be considered as conforming to the standard, then the
CA
> > and/or the subscriber haven't a leg to stand on, for they have no way to
> > ensure that effective legal notice is provided to any potential relying
> > party.
> >
> > This sentence must be removed or clarified considerably before the
standard
> > can be accepted, IMHO, for the concept of a Critical attribute is
> > fundamental to the entire concept of legal notice which the certificate
is
> > supposed to provide.
> >
> > Bob
> >
> > Robert R. Jueneman
> > Security Architect
> > Novell, Inc.
> > Network Services Division
> > 122 East 1700 South
> > Provo, UT 84604
> > 801/861-7387
> > bjueneman@novell.com
> >
> > "If you are trying to get to the moon, climbing a tree,
> > although a step in the right direction, will not prove
> > to be very helpful."
> >
> > "The most dangerous strategy is to cross the chasm in two leaps."
> >
> >
> > >>> <Dave_Oshman@notes.pw.com> 12/04 2:29 PM >>>
> > Bob, Mike,
> >  I agree completely with the importance of obeying critical extensions.
But
> > I
> > also believe that there will be "rogue applications" that may or may not
> > handle
> > these extensions properly dependent on the specific application. For
> > example,
> > if I have a certificate whose policy is explicitly for signing user
> > certificates, someone may develop an application that allows me to use
that
> > certificate for applying for a credit card exclusively for CAs. The
"relying
> >
> > party" in this case accepts the risk in using that certificate despite
the
> > policy under which it was issued. If used improperly by these rogue
> > applications, Mike is correct in saying that all CA (or other) liability
is
> > relieved. Hopefully, the relying party would have a difficult fight in
court
> > if
> > they wanted to blame the CA who issued that certificate. The point is
that
> > we
> > can only write the specifications, we cannot enforce them.
> >
> > Cheers,
> > Dave Oshman
> >
> > Price Waterhouse LLP
> > Electronic Commerce/Internet Practice
> > >Date:    Wed, 3 Dec 1997 08:34:05 -0700
> > >From:    Mike Smith <mfsmith@ZIONSBANK.COM>
> > >Subject: Re: digitalSignature vs. nonRepudiation
> > >As usual, Bob, I find myself agreeing with your statements.
> > >
> > >A certificate is issued under a certain set of authority policies.  If
> > someone
> > wishes >to rely on a certificate issued under those policies, then the
> > software
> > they use must >be able to process all of the critical extensions
established
> >
> > under that policy or >not honor the certificate.
> > >
> > >If someone does accept a certificate or signature issued with critical
> > extensions >that are ignored or interpreted other than the intent of the
> > issuing CA, then, it is >my belief, the reliant party (and, possibly the
> > entity
> > that modified the code to >accept or ignore the critical extensions) has
> > just
> > relieved the CA of any and all >liability regarding that critical
extension
> > and, quite possibly, the whole >certificate's issued purpose.
> > >
> > >Michael
> > >
> > >>> Bob Jueneman <BJUENEMAN@NOVELL.COM> 12/02/97 11:12AM >>>
> > >Sharon and David,
> > >
> > >My tongue in cheek suggestion that we deprecate the keyUsage field was
made
> > >as a result of my confusion and exasperation in trying to sort though
all
> > of
> > >these different issues.  But if we can't agree on some relatively
simple
> > >meaning, I submit that using the fields will actually be WORSE than
> > >deprecating them, for one person will think that they mean one thing,
and
> > >another person will interpret them differently.
> > >
> > >What good does it do to mark an attribute as critical, if the semantics
are
> > >as undefined or ambiguous as these are?
> > >
> > >And to bring up a somewhat different ubject that I mentioned before,
but
> > >never got closure on, I think that it is completely UNACCEPTABLE to say
> > that
> > >if some particular application does not have, understand, or chose to
> > >implement a security policy, it should be free to simply ignore the
> > critical
> > >marking on a Policy OID constraint. This simply turns the definition of
> > >critical on its head.  The critical usage is provided primarily to
protect
> > >the CA and/or the subject of the certificate from unreasonable reliance
on
> > >the certificate, and to provide a means for IT administrators to
centrally
> > >control what kinds of policies are to be enforced.
> > >
> > >Bob
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >