New Internet Draft on Non-Repudiation Requirements

[tgindin@xxxxxxxxxx]

     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 <kent@po1.bbn.com> on 08/31/99 10:20:13 AM

To:   "Aram Perez" <aram@apple.com>
cc:   ietf-pkix@imc.org
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