Critical extensions and Policy OIDs

[Bob Jueneman <BJUENEMAN@xxxxxxxxxx>]

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