Subject: Re: NR -- what the real issues are, and a proposal

From: "Aram Perez" <[email-masked]>
Date: Thu, 19 Aug 1999 16:45:46 -0700

Bob J.,

Since I already repudiated my previous statement about not giving any more
comments on the NR issue, I'll give you my comments on your proposal ;-)

[snip]
> However, since many may want to skip the justification and cut t
> o the bottom line, I'll put the proposal up front, and then justify it:
>
> My proposal is that the text of the nonrepudiation key usage bit I
> n the PKIX RFC (and hopefully in X.509) be revised to unambiguously
> state that the defined semantics of this bit is to indicate the willingness
> of the subscriber to be legally bound by a digital signature which can be
> verified by a certificate that can be established to have been valid at the
> time of signature, where "valid" has the normal meaning of not expired, not
> revoked, etc., etc.

I would vote against this proposal because I think the NR bit should be
deprecated. Why? Because this bit has caused so many problems and
misunderstandings for at least "the last five years or so". Why is it that
no one argues about the other KeyUsage bits? I'll give my answer a bit
later. [I personally believe that there should only be three key usage bits:
digitalSignature, keyEncipherment (with the addition of keyAgreement) and
dataEncipherment. With the exception of NR, the rest are just "refinements"
of the three. But I can live with the current definition (except for NR).]

>
> In addition, I propose that we create an additional indicator of a
> human being's conscious and willful intent to be legally bound by
> a digital signature that would be applied on a message by message
> basis. This additional indicator would require, as an integral part of
> its semantic definition, that an explicit computer-to-human interaction
> be required to provide some reasonable level of ceremonial and due
> caution warning be provided to the user.

I partially agree up to here. My disagreement is in "an additional
indicator". I think there should be more than one indicator depending on
different circumstances and applications.  And to me, having a "ceremony"
implies application level code, not cryptographic engine code and certainly
not a bit in a certificate.

>  In addition, the semantics
> of this indicator should specify that its use must be ENABLED by the
> NR bit ( as redefined) in the certificate which includes the corresponding
> public key.  If the certificate does not have the bit turned on, the
> application is not obligated to request the ceremonial, due caution
> approval; and relying party software should ignore a per-message
> indicator even if present in that case.

I do not agree with "must be ENABLED by the NR bit (as redefined)" or any
indicator in a certificate. Since its the application assisting the user
with the ceremony, I don't think having an additional bit in a certificate
helps if the indicators are present.

>
> The obvious, but not necessarily the only, place to put such a message
> by message indicator would be in the Cryptographic Message Syntax
> used by S/MIME V3, in particular as a new signedAttribute.  Since
> signedAttributes is a SET of self-describing attributes, adding
> an additional one would be very simple.

I have no problem with this suggestion as long as we don't limit it to just
S/MIME. Some other non-X.509 group might want the same or similar indicators
in another PKI such as PGP.

Now for my belief as to why the NR bit is the only bit to cause so much
discussion/confusion/misunderstandings/etc (and hence should be deprecated).
If you look at the other KeyUsage bits, they all refer either to a
cryptographic object (a key, a certificate or a CRL) or to a cryptographic
operation (a digital signature, key agreement or data encipherment). These
tend to be used in "real-time"; the results are generally immediate (e.g. I
encrypt the data I get the ciphertext right away; I verify a certificate
chain and make sure the appropriate certificates have the keyCertSign bit
set). In addition, these bits can be easily enforced at the cryptographic
engine level: the SignData function only works with a signature key and the
EncryptData only works with a data encipherment key.

The NR bit is different. The 2459 definition states that it "protects
against the signing entity falsely denying some action". Below are what I
believe to be some of the issues and misunderstandings:

1) There's a problem with the term "signing entity". This begs the question
that Tony B. raised: What's the difference between a digital signature that
has the NR bit set and a digital signature that doesn't have NR set? (And
unless I missed the correct answer, I don't think anyone really answered it
in a purely technical way.) And if it is a "signing entity", does the DS bit
have to be set also? Is the protection less if the DS bit is set? Is there
no protection if the NR bit is not set?

2) To me, "falsely denying" implies a time lag. I performed my services for
a client after he/she digitally signed a contract. Now I want to collect my
fee and he/she denys signing the contract.

3) To me, "falsely denying" also implies something more that just a
reference to a cryptographic object or performing a cryptographic operation.
This implies "semantics" of what is being signed. Which means that it is
very hard to enforce at the cryptographic engine level. How does the
SignData function know that the data is a contract vs. an SSL block
(corollary to Tony's question)?

4) To me, "falsely denying" also implies that for me to rebut the denial, I
have to have evidence and an impartial third party to evaluate the evidence.
Is the signed contract with the NR bit set sufficient evidence?

5) How is the protection provided? How strong is the protection? Is there
any protection without the NR bit?

6) The NR bit is in the public key certificate. How does that relate to the
how the private key was used and/or mis-used? Does the private key also need
a NR bit?

[snip]

The opinions expressed are strictly my own but I reserve the right to
repudiate any of them ;-)

Regards,
Aram Perez

BTW, did anyone successfully define "technical non-repudiation" in a purely
technical way or did I miss that also?

---

From: Ed Gerck <[email-masked]>
Date: Fri, 20 Aug 1999 15:53:57 -0700

> technical way or did I miss that also?

Yes, you did miss it, but since it may have been buried under an email delluge
and others have also asked the same, let me requote.  I have CC'd others that
may also find this of their interest, in a specific thread.

In a purely technical way, I agree with the definition of Menezes et al. in the
HAC and I recently quoted it in an email to this WG [snipped]:

begin quote----------------------------------------------------------
Subject:  Re: Is this non-repudiation or NR, and why?
Date: Thu, 19 Aug 1999 16:52:42 -0700
From:  Ed Gerck <[email-masked]>
...

To contrast, compare with Menezes et al., in HAC, page 3:

"non-repudiation: preventing the denial of previous commitments or actions"

which is both legally and technically possible (as a function of how it is done)
and is in accord with the name -- non-repudiation. Note that there is no mention
of intent.
....
end quote------------------------------------------------------------

I also note that the above definition uses the word *previous* --  which
is crucial to the whole concept of non-repudiation as understood in
business and is not  present in PKIX or ISO definitions.

Further, it also states that the objective of non-repudiation is to *prevent
denial* -- not put in place a system that would protect against a "false"
denial after the communication event took place (PKIX), nor define a
decision based on what is essentially a rebuttable presumption model
(Ford).

There are thus more than one type of "non-repudiation" at play here,
and I can distinguish 4 different types.  But what all those types of NR
are doing has a common aspect -- they all exist in order to deny
evidence,  not to corroborate evidence.  However, they are most
certainly different in how they handle this process and in what results
they may obtain, even if we just restrict ourselves to the technical
domain -- as the definition from Menezes shows.

Cheers,

Ed Gerck