Re: [IETF-PKIX] digitalSignature vs. nonRepudiation

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

> From: Bill Burr <william.burr@NIST.GOV>
>
> It seems to me that this non-repudiation orange in the barrel of mechanism
> apples is quite evidently causing a lot of confusion.  So, if we take Dave
> Kemp's proposal, which is logically consistent, and consistent with X.509,
> then it means that a certificate with only the digitalSignature bit set may
> be used to sign anything except:
>
> 1. a Certificate
> 2. a CRL
> 3. anything, whatever it is, that is to have the peculiar property of
> non-repudiation.

Item 3 includes anything (every message or item of data meaningful to
a user) that has a signature affixed.

If you have a key with bit 0 set which can't be used for 1, 2, and 3,
then effectively the only thing left which it can be used for is
signing data internal to operation of a communication protocol.  It
seems eminently reasonable that transient data such as nonces would not
"have the peculiar property of non-repudiation" - it isn't meaningful
for a user to "sign" (agree to be bound by) a random number, or record
type codes and length fields, or hashes of handshake messages, or other
such protocol stuff.

The signatures contained in a protocol exchange are clearly intended
to be ephemeral.  You could save them by directing the output of a
sniffer to a file, but the user clearly intended and expected them to
disappear the instant after they had served the purpose of
authentication.  Since such signatures are not intended (authorized by
the user or the CA) to be preserved, there is nothing to repudiate.


> Given all this, it isn't clear to me what if a message signed with a key
> with only digitalSignature set means, and if I should reject the signature,
> or if the signer could then more or less automatically get away with
> repudiating it.


Would it be any clearer if the statement were phrased:

  "... what a message signed with a key with only *authentication* set means,
   and if I should reject the signature, ..."

or

  "... what a message signed with a key with only *dataEncipherment* set means,
   and if I should reject the signature, ..."


In the second case, it's obvious that you can't sign any message with an
encryption-only key, so you should reject the signature.

In the first case, it should be just as obvious that you can't sign any
message with an authentication-only key, so again, you should reject the
signature.

Perhaps the proposal should be to rename keyUsage bit 0 to
"authentication", instead of removing the ability to distinguish between
signed messages and ephemerally-signed random numbers.