[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Critical extensions and Policy OIDs
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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>