Re: [IETF-PKIX] digitalSignature vs. nonRepudiation

[Bill Burr <william.burr@xxxxxxxx>]

It seems to me that these two bits are trying to split much too fine a
hair.  The best solution would be to eliminate one or the other.  I wasn't
a participant in the discussions that led to the inclusion of both in the
Key Usage field, and have no real idea what was on the participants mind in
making this distinction, but there doesn't seem to be any real agreement
about just what non-repudiation actually means.

I would say that non-repudiation is, or ought to be, a property, rather
than a service or a usage, which any digital signature ought to be designed
to have, to as high a degree as practical, and which is greatly affected by
other circumstances of the signature (e.g., date-time stamps, or whether a
gun was pointed at the head of the signatory when he executed the signature).

The idea of an explicitly repudiable digital signature is repugnant.  So,
if setting the digitalDignature bit while not setting the nonRepudiation
bit means, in effect, "I reserve the right to deny I ever signed this," I
think I'd like to see that combination banned. If I have such a
certificate, can I use it to authenticate myself to log onto a system, do
some mischief, then repudiate that I ever logged on?

If the point of the nonRepudiation bit is just to say this is a bit
stronger kind of a key or signature, then I that may be OK, but
certificatPolicies, if you believe in them, may be a better way to express
this.  At any rate, if this is the case, setting nonRepudiation while
leaving digitalSignature unset, makes no sense.

I'm afraid that what we have here is another example of the kind of a camel
that we often get from a standards committee, which designs in the abstract
for the ages, and supplies answers for questions that haven't been and
don't need to be asked.  I'd prefer to see one of the bits eliminated
altogether. Failing that, I'd like to profile both bits as either set or
not set together, but never just one or the other.



At 04:26 PM 11/22/97 -0700, you wrote:
>I agree in setting both if the CA issuing the cert is issuing it for more
>than just I&A, as would/should most commercial CAs such as banks or
>merchants.
>
>I also believe that, because the options are in the extension, a lawyer
>could argue against non-repudiation if it is not set, even though the
>re;liant party knows who signed something and that what was signed has not
>been altered since signing.
>
>If someone were contesting (attempting to repudiate) a signed agreement
>because non-repudiation was not set, then that would probably go in front of
>a court fro final arbitration.  If they both were set, then that reason is
>at least eliminated.
>
>michael
>
>
>-----Original Message-----
>From: Simonetti David <simonetti_david@bah.com>
>To: ietf-pkix@tandem.com <ietf-pkix@tandem.com>
>Date: Monday, November 17, 1997 1:45 PM
>Subject: digitalSignature vs. nonRepudiation
>
>
>>I am attempting to implement the key usages as defined for the keyUsage
>>extension.  I am stumbling upon digitalSignature and nonRepudiation.
>>
>>I define the key usage digitalSignature as a public key which affords
>>the services of authentication and data integrity.
>>
>>Of course, nonRepudiation affords the service of non-repudiation.
>>
>>My question is, with only nonRepudiation set (and not digitalSignature),
>>is it true that my public key can be used only to provide the service of
>>non-repudiation, and NOT the services of authentication and data
>>integrity?  If this is true, I'm curious to know how this is
>>implemented.
>>
>>I claim that if the nonRepudiation bit is set, that I can use that key
>>to implement authentication and data integrity, and also claim
>>nonRepudiation of the originator.  Since authentication and data
>>integrity are services provided under digitalSignature, I believe that
>>when nonRepudiation is set, digitalSignature should also be set.
>>
>>I'd like to hear agreements or disagreements with my line of reasoning.
>>
>>Dave Simonetti
>>
>>
>
>
Regards,

Bill Burr