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

[moshe@xxxxxxxxxxxxxx]

David,

In your reply I didn't found any refernce to to use of the policy
constraints extention with the requireExplicitPolicy field.
>From section 4.2.1.12 of the Oct 14th draft of part 1:

   If the requireExplicitPolicy field is present, subsequent
   certificates must include an acceptable policy identifier. The value
   of requireExplicitPolicy indicates the number of additional
   certificates that may appear in the path before an explicit policy is
   required.  An acceptable policy identifier is the identifier of a
   policy required by the user of the certification path or the
   identifier of a policy which has been declared equivalent through
   policy mapping.

Thus if that extension apear in the certificate path (and it is critical),
any application without a specific policy requiremnt cannot accept that
certificate, which is, I belive what you want.

However there is another issue with critical certificate policies - what
an application should do when it encounters a combination of known and
unknown OIDs? In order to support your example an application should
reject that certificate.

Now let assume that in your example the organization starts replacing
software based keys, whith hardware token, and whishes to specify it
in a certificate policiy OID so that later it will be able to give
different access for people that have a hardware token (because their
key is more secure).

In a later stage, some of the application may be configured to accept only
hardware tokens' certificate.

But the first thing that will happen is that all the application will refuse
to accept the new certificate because they are unaware of that new extension.
Every single application will have to be reconfigured BEFORE the new
certificate are distributed.

If there is a need for a "critical" certificate policies (that is a certificate
policy that degrade the trust of that certificate) we should have a way
to put in the same certificate both "critical" OIDs and non-critical OID.


        Moshe Litvin


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