Subject: New Internet Draft on Non-Repudiation Requirements

From: [email-masked]
Date: Tue, 31 Aug 1999 15:33:06 -0400

I think that we should remember that the NR bit is supposed to cause CRL
archiving  as well.  In any case, while I haven't seen the official announcement
yet, my new "Technical NR Requirements" draft is available at
http://www.ietf.org/internet-drafts/draft-gindin-pkix-technr-00.txt or in the
"internet-drafts" directory on the usual shadow sites as
draft-gindin-pkix-technr-00.txt

     Subsequent review of this draft has suggested a new addition to the set of
requirements for "1-way" NR, as follows:

3.4  The relying party should create, and save with the data submitted, a
package containing a current time stamp signed by an independent authority.
This object signed by the independent authority should include, in addition to
the time stamp, one of the following: a countersignature created by the relying
party, a copy of the "signature block" of the submitted document, or the entire
submitted document.

          Tom Gindin

Stephen Kent <[email-masked]> on 08/31/99 10:20:13 AM

To:   "Aram Perez" <[email-masked]>
cc:   [email-masked]
Subject:  Re: Deprecate the NR bit?

At 8:53 AM -0700 8/30/99, Aram Perez wrote:

>Ron Ramsay wrote:
>
>> Except that the NR bit cannot be added to the certificate by the
>> application!
>
>But the application can add a much better indicator to the data that needs
>to be part of the evidence that supports non-repudiation as has been
>proposed on this mailing list.

Not all applications may be trusted to properly assert invocation  of NR
services.  By including the NR bit in a cert, we have a (potentially)
higher assurance mechanism that can allow or prohibit an application from
invoking NR services.  For example, if one provides an application with
access to certs ONLY with NR=0, we can ensure that these apps cannot assert
that they are acting in an NR capacity on behalf of the user. This is a
very useful security facility and a good reason to keep the NR bit.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Tue, 31 Aug 1999 13:26:10 -0700

[email-masked] wrote:

>      my new "Technical NR Requirements" draft is available at

I believe your draft, even without the addition (which has its pros and cons IMO),
is indeed working to fill the gap you mention in it:

 "Extensive discussions in the PKIX WG have revealed that the description of
 the non-repudiation service contained in this passage is not widely enough
 understood or agreed upon to characterize any given service as providing or
 not providing a non-repudiation service."

In regard to the name of that bit, keeping it as "non-repudiation" is now IMO
not so misleading because the context is clear.  I am also glad you focused
on "what", "how" and "when" instead of "who" and "why" and that you clearly
state what non-repudiation would really be if taken to task:

 "a full non-repudiation service which is intended to prevent all possible
 repudiations of a signed object or document."

which helps the reader to differentiate what PKIX NR is not.

I have no comments and congratulations.

Cheers,

Ed Gerck