Re: [IETF-PKIX] digitalSignature vs. nonRepudiation

[Mike Smith <mfsmith@xxxxxxxxxxxxx>]

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

>Bob,
>
>First let me say that I highly respect all of the opinions that I've
>received.
>
>The key usage flags do play a useful role.  As a single example, they
>allow me to restrict use of my RSA key to either digital signature or
>key encipherment, but never both.  There is enough importance in this
>single role to warrant the extension be made "critical" when used.
>
>If this thread has proved anything, it's at least shown that there is no
>universal interpretation of non-repudiation or how to best implement
>it.  I think we should leave it up to individual communities of users to
>determine how to best implement this in their situation because there is
>not one right answer.  Certificate policies are going to play a mighty
>important role.
>
>Dave Simonetti
>
>Bob Jueneman wrote:
>>
>> >I, in turn, propose that digitalSignature is the mechanism.  If
>> >nonRepudiation is turned on, then the non-repudiation service is
>> >provided; if nonRepudiation is turned off, then non-repuditiation is not
>> >provided.  Why can't it be this simple?
>> >
>> >Dave Simonetti
>> >
>> >
>> I'd like to think that those who have ventured an opinion in this area
are
>> reasonably knowledgable about the subject.
>>
>> But if we cannot agree as what these bits mean, it is not likely that
either
>> CAs or client software will understand or correctly implement the
semantics,
>> no matter what the bottom line is.
>>
>> Maybe we should just deprecate the whole X.509 keyUsage flags entirely --
>> they seem to be doing more harm than good.
>>
>> Can someone make a case for why we should bother with them, if there is
this
>> much confusion about their meaning?
>>
>> Bob