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

From: "Aram Perez" <[email-masked]>
Date: Tue, 07 Sep 1999 17:02:30 -0700

Hi Tom,

My comments are bracketed with [AP1: comments].

[snip]
> 
> ABSTRACT
>
> This document describes those features of a service which processes
> signed doucments which must be present in order for that service to
> constitute a "technical non-repudiation" service.  A technical
> non-repudiation service must permit an independent verifier to
> determine whether a given signature was applied to a given data object
> by the private key associated with a given valid certificate, at a time
> later than the signature.  The features of a technical non-repudiation
> service are expected to be necessary for a full non-repudiation service,
> although they may not be sufficient.
> [AP: You've defined a "'technical non-repudiation' service", but not a "full
> non-repudiation service". I'll use the acronym "TNR" for technical
> non-repudiation and "FNR" for full non-repudiation.]
>
> This document is intended to clarify the definition of the
> "non-repudiation" service in RFC 2459.  It should thus serve as a guide
> to when the nonRepudiation bit of the keyUsage extension should be used
> [AP: We should be consistent with either "nonrepudiation" or
"non-repudiation".
> Also, does "used" mean the same thing as "set"?]
> [TG: "when the nonRepudiation bit should be used" could easily be "... set"
> without any real change in meaning.]
> and to when a Certificate Authority is required to archive CRL's.
> [AP: Does the CA only have to archive CRL's for TNR? Does the CA need to
perform
> a higher due diligence before setting the NR bit? Can the CA set the NR bit
> without the subject requesting that the bit be set?]
> [TG: It is stated above, that FNR incorporates TNR as a core set of
> requirements.  Thus, CRL archiving is only directly mandated for TNR - but
that
> mandates it for FNR as well.]

[AP1: Above you state that TNR is "expected to be necessary" for FNR. This
is different from "FNR incorporates TNR as a core set of requirements". Is
it SHOULD or MUST? Like I commented before, you defined TNR but not FNR.]

> [TG: Higher levels of due diligence are probably needed for FNR.  I doubt if
> they are needed for TNR.]
> [TG: The CA can set the bit if it wishes.  This service does not have the kind
> of heavy-duty legal requirements that FNR is likely to.]

[AP1: So my abuelita (grandmother) may get a cert with the NR bit set
without her requesting it or knowing what it means and inadvertently sell
her house? ]

>
> 1 Introduction
>
> RFC 2459 [1] specifies a bit within the KeyUsage extension called the
> nonRepudiation bit which is "asserted when the subject public key is
> used to verify digital signatures used to provide a non-repudiation
> service which protects against the signing entity falsely denying some
> action, excluding certificate or CRL signing."  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.  Two major categories of service
> have been proposed as potentially providing a non-repudiation service:
> the technical non-repudiation service, which this draft attempts to
> define with greater precision, and a full non-repudiation service
> which is intended to prevent all possible repudiations of a signed
> object or document.  Since a full non-repudiation service is required
> to meet all the requirements of this technical non-repudiation service
> as a prerequisite, the technical non-repudiation service's definition
> is necessary for both [AP: I disagree if you require the NR bit to be set].
> [TG: I'm not defining FNR here.  An FNR set of requirements is likely to
define
> a needed keyPurpose ID in the XKU extension, anyway.  My question is whether
you
> and the other FNR supporters believe that there needs to be some indication in
> the certificate that a given certificate is intended for NR or FNR use.]

[AP1: Wow, I didn't know I was an "FNR supporter" ;-)  When you state
"intended for NR or FNR use" does "NR" mean "TNR"? I can't speak for the
other "FNR supporters", but what I believe is that you can have legally
binding digital signatures that do not have the NR bit set.]

[snip]
> , that the signer has been adequately informed of the content which is signed,
> that the signer is not acting
> under duress, etc. [AP: I think the scope should only include when the NR bit
is
> set, but clearly state that you can have FNR with the NR bit not set (as have
> been stated in the WG).][TG: That is fairly controversial in the WG, and I'm
not
> doing the FNR definition].

[AP1: I'm confused about the scope of the document then. You are not
defining FNR but you state that FNR requires (or is a superset of) TNR. And
for TNR you state that the NR bit must be set.]

>
> 2    Requirements for both 1-way and 2-way NR
>
> 2.1  The signer must submit, with the signature, the signing
> certificate or an unambiguous identifier of that certificate.
> Unambiguous identifiers of certificates include the combination of a
> certificate serial number with an issuer name [AP: You've only given 1
> identifier.][TG: So far, that's right.  I wasn't trying to be exhaustive.]

[AP1: I think you should give at least two since you state "Unambiguous
identifiers of certificates include..."]

[snip]
>
> 2.3  The signer must include, in the base over which the signature
> is calculated, the time at which the signature was created.[AP: I think this
>  opens up a can of worms: local time, GMT, precision, trusted, etc.]
> [TG: Format is not, and does not have to be, specified for this.  The signer
has
> to trust this time, but either the RP or the escrow holder (depending on 1-way
> vs. 2-way) will be adding a time stamp of their own.]

[AP1: How does the RP or EH (escrow holder) know the signer that the time
was included in the signature?]

[snip]
>
> 3.2  The relying party must save the identity of the signing
> certificate, along with the content of the signature.[AP: Isn't the
>  certificate self-identifiable? Isn't is sufficient to save the certificate?]
> [TG: Content of the signature, not of the certificate.  The full certificate
is
> acceptable, of course, since it contains its own ID.]

[AP1: I'm not sure what you mean by "content of the signature"?]

>
> 3.3  The relying party must check that the signing certificate
> contains a keyUsage extension.  If the extension is not present or does
> not contain the nonRepudiation bit, and the version of the certificate
> is v3 or higher, the submission must be rejected.[AP: I (and others in the WG)
>  believe this is wrong. Above you state the TNR is a requirement for FNR,
> but I think it has been shown in the recent discussions that the NR bit is NOT
> required for FNR.]
> [TG: 1-way NR is not a basis for FNR.  We can discuss this under 4.3,
however.]

[AP1: Ditto above confusion on TNR and FNR.]

[snip]
>
> 4.3  The relying party must check whether or not the signing
> certificate contains a keyUsage extension.  If the keyUsage extension
> is present and the nonRepudiation bit is not set the submission must be
> rejected.[AP: ditto comment as in 3.3]
> [TG: If the group really wants this, I'll put in some wording about how
"larger
> services extending this one may dispense from this requirement".  Note that
> missing keyUsage's are allowed here although not for 1-way.]

[AP1: I think you need a better explanation of the differences between 1 and
2-way NR and why they are needed.]

Regards,
Aram Perez

---

From: [email-masked]
Date: Thu, 16 Sep 1999 15:43:11 -0400

Hi Aram,

     My responses are bracketed with [TG1: comment].
Hi Tom,

[snip]
"non-repudiation".
perform
that

[AP1: Above you state that TNR is "expected to be necessary" for FNR. This
is different from "FNR incorporates TNR as a core set of requirements". Is
it SHOULD or MUST? Like I commented before, you defined TNR but not FNR.]
[TG1: I don't know, because nobody has yet defined an FNR service at all, let
alone one which does not require TNR.  I do not know how an FNR service would
work if one could not submit evidence of the original signature.]

[AP1: So my abuelita (grandmother) may get a cert with the NR bit set
without her requesting it or knowing what it means and inadvertently sell
her house? ]
[TG1: No, it takes more than NR bit use to make a legal contract.  It even takes
more than the NR bit to make TNR - see the rest of this draft.  Su abuela is no
more at risk digitally than in real life.]

define
you

[AP1: Wow, I didn't know I was an "FNR supporter" ;-)  When you state
"intended for NR or FNR use" does "NR" mean "TNR"? I can't speak for the
other "FNR supporters", but what I believe is that you can have legally
binding digital signatures that do not have the NR bit set.]
[TG1: That will depend on the definition of legally binding signatures.
Personally, I'm not convinced that FNR is possible without TNR, but an FNR draft
might well convince most people.]

[snip]
is
not

[AP1: I'm confused about the scope of the document then. You are not
defining FNR but you state that FNR requires (or is a superset of) TNR. And
for TNR you state that the NR bit must be set.]
[TG1: I haven't seen a definition of FNR for which signature evidence
preservation is not essential, but then again I haven't seen much definition of
FNR yet.  Should I point out that "it may be theoretically possible to produce
an FNR service which does not satisfy all the requirements of TNR below", and
leave it at that?]

[AP1: I think you should give at least two since you state "Unambiguous
identifiers of certificates include..."]
[TG1: All right.  A second unambiguous identifier of a certificate is the
combination of issuer name, subject name, and subject key identifier (I hope).]
[snip]
has

[AP1: How does the RP or EH (escrow holder) know the signer that the time
was included in the signature?]
[TG: There will be another time in the format, which is their responsibility.
They can reject a flagrantly forward-dated document, however.]

[snip]
is

[AP1: I'm not sure what you mean by "content of the signature"?]
[TG1: The signature itself, along with any signature attributes in the CMS
sense.]

however.]

[snip]
"larger

[AP1: I think you need a better explanation of the differences between 1 and
2-way NR and why they are needed.]
[TG1: 1-way NR is a relatively minimal service.  It allows the RP itself to
preserve signed objects in such a way that they can be submitted as evidence
later.  2-way NR involves an escrow holder who is independent of the RP.]

Regards,
Aram Perez