Re: Critical extensions and Policy OIDs

["Simonetti David" <simonetti_david@xxxxxxx>]

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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >