Subject: Re: New Internet Draft on Non-Repudiation Requirements

From: "Aram Perez" <[email-masked]>
Date: Tue, 31 Aug 1999 13:09:21 -0700

Tom Gindin wrote:

I haven't reviewed your document yet, but I have one question/comment
below...

>      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,

Does the certificate for this countersignature have the NR bit set? If yes,
do you need another countersignature with NR, etc, etc.? If no, is the
countersignature repudiable?

Regards,
Aram Perez

> 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: [email-masked]
Date: Tue, 31 Aug 1999 16:46:07 -0400

"Aram Perez" <[email-masked]> on 08/31/99 04:09:21 PM

To:   [email-masked]
cc:
Subject:  Re: New Internet Draft on Non-Repudiation Requirements

Tom Gindin wrote:

announcement
of

[Tom Gindin]   Yes, the certificate for the relying party's countersignature
should have the NR bit set.  However, this does not mean that you need yet
another countersignature.  Just because a signature is created using an
NR-capable certificate doesn't mean that it invokes this full service in all
cases, or else someone (and I don't know who it would be) would have to check
the relying party's CRL, for example.

Regards,
Aram Perez