Subject: Re: Meaning of Non-repudiation

From: [email-masked]
Date: Sun, 12 May 2002 15:24:07 -0600

I've finished some more of the taxonomy .... SC27 is big on evidence,
proof, audit trails and time-stamping.

try clicking on "evidence" (new to the concept section at the start of the
glossary frame).

[email-masked] on 5/11/2002 11:44 pm wrote:

while i was at it, i thot i would go ahead and update the merged security
glossary with the latest from ISO SC27
http://www.garlic.com/~lynn/secure.htm

some of the new defintions (from merged security taxonomy/glossary; i'm
still working on taxonomy for many of the new terms in the latest sc27
glossary).

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 15 May 2002 18:19:09 +0200

After taking a few days off, I have analyzed the storm of the e-mail
exchanges on that topic.

The core of the problem is that some people, by claiming requesting some
"clarifications" on these two bits, would like to change their semantics.  

:-(

The roadmap provides a good summary of what happened in the past:

   (...) many discussions were needed to arrive at
   a common agreement on the meaning of the digitalSignature (DS bit)
   and nonRepudiation (NR bit) bits and when they should be set. The
   group quickly realized that key usage extension mixes services and
   mechanisms. The DS bit indicates a mechanism - a public key used to
   verify a digital signature. The NR bit indicates a service - a public
   key used to verify a digital signature and to provide a non-
   repudiation service. When trying to indicate when each bit should be
   indicated arguments were based on:

   The lifetime of the object being singed. Some felt that the DS bit
   should be set when the certificate is used to sign ephemeral objects
   (e.g., bind tokens) while the NR bit should be set for things that
   are survive longer (e.g., documents). Of course, the problem with
   this distinction to determine how long is the time period for
   ephemeral?

   A conscious act taken by the signer. Many felt that the NR bit should
   be set only when the subject has expressly acknowledged that they
   want to use the private key to sign an object. Signing a document say
   where there is a conscious decision by the subject would be
   appropriate for the key usage extension to contain NR, but when the
   key is used for authentication purposes, which can occur
   automatically and more frequently, the DS bit is more appropriate.

   The discussion also concluded that since some authentication schemes
   occur automatically, that the DS bit and NR bit should never be set
   together in the same certificate. Some agreed to the differentiation
   of the bits based on the time, but did not agree that the two could
   not be in the same key usage extension.

   The procedures followed by the CA. Some felt that NR bit was kind of
   'quality mark' indicating to the verifier that the verifier could be
   assured that the CA is implementing appropriate procedures for
   checking the subject's identity, performing certificate archival,
   etc. Other felt that it was not entirely the CAs job and that some
   other entity must be involved.

   In the end the WG agreed to a few things:

   - Provision of the service of non-repudiation requires more than a
     single bit set in a PKC. It requires an entire infrastructure of
     components to preserve for some period of time the keys, PKCs,
     revocation status, signed material, etc., as well as a trusted
     source of time. However, the nonRepudiation key usage bit is
     provided as an indicator that such keys could be used as a
     component of a system providing a non-repudiation service.

   - The certificate policy is the appropriate place to indicate the
     permitted combinations of key usages. That is, a policy may
     indicate that the DS and NR bits can not be set in the same
     certificate while another may say that the DS and NR bits can be
     set in the same certificate.

   [2459bis] includes new text indicating the above agreements.

In addition to these explanations I would like to quickly reply to Sharon to
say her that I disagree (as others) when she says that the only meaning of
the NR bit is to say that the CA has no knowledge of the value of the
private key. This would rule out CAs generating key pairs and would not be
backward compatible with the current meaning.

Now let us attempt to CLARIFY the meaning.

David Kemp offered good explanations on these two bits:

DS bit: the key is used to sign data, nonces or challenges that can be
verified in real-time (entity authentication and data origin authentication
services).

NR bit: the key is used to sign data that can be verified at a later time 
(non–repudiation service).

I would offer these additional explanations:

When the DS bit (bit 0) is set, this means that the private key MAY have
been used in an environment that is not fully controlled by the private key
holder. In practice, this means that private keys related to certificates
that have the DS bit set, will be used for entity authentication (e.g.
signing challenges or nonces) or for data origin authentication (signing
data that has not necessarily been reviewed).

Since the environment is not fully controlled by the private key holder, the
private key holder COULD deny that his key was used to sign a transaction,
because he could claim that he was believing that his private key was used
in an authentication process. 

Some authorities (like CRL Issuers) can sign by using a key related to a
certificate that only has the DS bit set because they always chose what they
sign and will never use that same key in an authentication exchange. 

When the NR bit (bit 1) is set, this means that the private key holder will
only use its private key in an environment that he can control and which
allows him to be confident of the data that is being effectively signed.

The signer cannot claim that he was believing that his private key was
simply used in an authentication process that he could not control. 

Denis