Subject: Re: Non-Repudiation

From: "David P. Kemp" <[email-masked]>
Date: Mon, 16 Aug 1999 13:58:00 -0400 (EDT)

> From: Ed Gerck <[email-masked]>
> 
>
> So, if commerce thrives and actually favors wide reaching return policies
> (i.e., favors not harassing the consumer with a non-repudiation bit of prose),
> why should this WG favor the opposite and introduce PKIX as a tribunal
> over its users, with language such as (2459):
> 
>  " ...to provide a non-repudiation service which protects against the signing
>   entity falsely denying some action"
> 
> I think it is time to stop beating around the bush and calling examples that do
> not fit at all in the case at hand or speak in lawyerly terms, and just make the
> changes needed to make precise the semantics of the nonRepudiation bit.  This
> responsibility falls IMO on the spec authors, but I believe this list has provided
> ample examples and counterexamples.

The relevant text from X.509 is:

    12.2.2.3 Key Usage field

    This field, which indicates the purpose for which the certified public key
    is used, is defined as follows:
    
    ...
    
    b) nonRepudiation: for verifying digital signatures used in providing a
    nonrepudiation service which protects against the signing entity falsely
    denying some action (excluding certificate or CRL signing, as in f) or g)
    below);

This text makes no claims that a NR bit provides a NR service, or that the
private key or certified public key provide a NR service.  What it says is
that the key is to be *USED IN* providing a NR service, i.e.:

  IF there is a system (of legal, procedural and technical elements)
   that does provide protection (including after-the-fact sanctions
   with the purpose of deterrence) against an entity falsely denying
   some action,

  THEN the NR bit indicates that the purpose of the keypair is to support
   such a system.

Is there any disagreement that this is a legitimate, entirely correct,
reading of the X.509 words?

(I do believe that the X.509 text "used in providing a NR service" is
more precise than 2459's "used to provide a NR service", and that the
replacement for 2459 should use the X.509 language.)

> Thus, where IMO the present PKIX spec fails is that by saying too much
> the baby is going with the baby water. The NR text in 2549 (which I
> quoted before) should be simply deleted IMO, as a first correcting action.

If the text were incorrect, then deleting it would be a step towards
clarity.  But the text is correct.  Perhaps, at 129 pages, RFC 2459
does not contain enough descriptive and tutorial information, and the
Security Considerations section should be expanded to explain the
technical and legal requirements for a system to effectively support
non-repudiation.

Or perhaps not :-).

There is, of course, a lot of bath water that goes along with the baby.
The statement "this key is used in providing a confidentiality service"
leaves a tremendous amount unsaid, but is nonetheless a useful statement.