Subject: Re: NR, redux, again.

From: Oscar Jacobsson <[email-masked]>
Date: Mon, 01 Nov 1999 18:16:50 +0100

Bob Jueneman wrote:
> Oscar, that's a thought, and one of a number of possibilities.
> 
> But one of the most important issues that your suggestion brings up
> is whether NR has anything to do with a CA  AT ALL, and therefore
> whether it is appropriate to represent in a CertPolicyId extension.

True.

I am, however, regretfully ignorant regarding the requirements existing
and emerging digital signature legislation might set on the presence or
absence of keyUsage bits in end-entity certificates. There may, for all
I know, exist Certification Authorities that are legally bound to set,
and thus applications legally bound to interpret, the non-repudiation
bit in a certain fashion.

//oscar

---

From: MHenry <[email-masked]>
Date: Tue, 2 Nov 1999 13:32:29 -0500

Tom,
Is there an agreed opon list of what must be archived in order to 
support NR for a signature? It would seem that the list must include: the
original document, the signature in question (in case there are advances in 
computing or algorithms to attack the cryptographic primitives used),
the certificate used to compute the signature, all certs used to sign that
cert, the CRLs for all certs involved.

Mike Henry
Performance Engineering Corporation
> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Tuesday, November 02, 1999 12:23 PM
> To:	Tony Bartoletti
> Cc:	Bob Jueneman; [email-masked]; [email-masked]
> Subject:	Re: NR, redux, again.
> 
> (snip)
> All,
> 
> I think we have long agreed that a single NR-bit is of very limited
> utility in conveying the range of qualities we may need to assert in
> non-repudiation.  (Ed Gerck's taxonomy and Tom Gindin's codification
> are certainly a solid representation of this range.)  In particular,
> as Bob reminds us, there is no a-priori reason to assume that NR is
> strictly (or even best) the job of the CA.
> 
> As a exercise, it may be useful to imagine that you are going to set
> yourself up as an "Full-Serve Digital NR Service" but you are NOT a CA.
> Of course, you will be involved with digital documents, signatures,
> certificates, independent time-stamps, and countless other concerns.
> Now the question to ask is "What, if anything, would you want a given
> certificate's NR-bit to signify?"  Of what utility is it to you?
> 
> Being a full NR service, I imagine you will certainly be archiving
> relevant objects as a matter of course, so do you care if the CA is
> providing (redundant) long-term storage?  I doubt so.  Hence the
> association of cert NR-bit with cert "lifetime" is misplaced.
> 
> [Tom Gindin]   The CA is the logical candidate to provide long-term
> storage
> for CRL's in those cases where NR is supported.  Because a revocation may
> carry a claim about "invalidityDate", the NR service cannot be sure when
> it
> has sufficient evidence that the subject of the certificate for the
> signing
> key pair will not claim that the signature was invalid because of key
> compromise - simply having a CRL dated later than the signature is not
> enough.  However, this is not an issue with certificate lifetime.  I know
> of no other long-term storage that any NR service can expect from the CA.
> 
> I can understand why some folks (CAs) would like to limit the NR-bit
> to such a simple notion.  It is "do-able", and they are under pressure
> to "do NR" from some quarters.
> 
> [Tom Gindin]   CRL archiving is all the CA needs to do to support NR.
> That
> does not mean that it is all that must be done for NR.
> 
> Comments?
> 
> ___tony___
> 
> Tony Bartoletti                                             LL
> IOWA Center                                              LL LL
> Lawrence Livermore National Laboratory                LL LL LL
> PO Box 808, L - 089                                   LL LL LL
> Livermore, CA 94551-9900                              LL LL LLLLLLLL
> phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
> email: [email-masked]                                   LLLLLLLL
> 
>

---

From: MHenry <[email-masked]>
Date: Tue, 2 Nov 1999 14:26:23 -0500

Bob,
I followed your and Ed Gerck's arguments closely during the earlier
discussion. I was quickly persuaded that your analysis of the issue
was correct. 
I have to make recommendations to a client as to what must be 
archived in order to support NR. The objects that listed previously
 appear to support  the "traditional/technical/syntactical " concept of NR.
What additional objects should be archived in order to support your
evolving concept of NR?

Mike

> From:	Bob Jueneman [SMTP:[email-masked]]
> Sent:	Tuesday, November 02, 1999 1:52 PM
> To:	Tony Bartoletti; [email-masked]; [email-masked]'
> Cc:	[email-masked]; [email-masked]
> Subject:	RE: NR, redux, again.
> 
> Mike,
> 
> Some of us, at least, would like to go substantially beyond the
> traditional technical/syntactical validation of NR, which you have stated 
> reasonably well.  And that, of course, is the primary issue.
> 
> In particular, there is the question of conscious INTENT or volition --
> did I really mean to affix my legally binding signature to this document,
> or 
> did some automaton get carried away and apply my signature to 
> something I personally never approved? (Consider the S/MIME v3 
> digitally signed receipt for a message as an example of a protocol 
> that involves a digital signature, but not necessarily a signature 
> that represents either approval of the contents, or even volition.)
> 
> In addition, even if volition were present, is the key management, etc., 
> associated with that signature of sufficient strength that I the user
> would wish to have the risk associated with being legally bound by
> that signature, even one nanosecond from now (i.e., during the
> certificate validity period), much less 40 years from now?
> 
> To my way of thinking, these issues are far more important to establishing
> the long-term legal validity of my signature on a contract than the fact
> that 
> the certificate wasn't revoked. After all, I would only have reason to
> revoke
> my key if I suspected that it had been compromised, and it would be
> an unusually stupid attacker who would compromise my key and let me 
> know about it.
> 
> In addition, just because the certificate was revoked doesn't mean that 
> my signature wasn't valid, if it can be proven that I in fact did sign the
> 
> document in question, presumably by some other, more conventional 
> forensic or testimonial methods.
> 
> So, as Ed and others have already pointed out, the convention technical
> definition is neither necessary nor sufficient to establish
> nonrepudiation.
> 
> What we really have to deal with are two issues:
> 
> 1.  Who bears the burden of proof with respect to a challenged signature, 
> under what circumstances, and
> 
> 2.  Who bears the risk of loss if it can reasonably be established that
> the 
> subject of the certificate in fact did NOT sign the document.
> 
> Unless or until we can answer those questions, nonrepudiation is just
> a technical artifact -- not much more than a convenience or an
> inconvenience,
> depending on whose side you are on.
> 
> Bob
> 
> 
> 
> >>> MHenry <[email-masked]> 11/02/99 11:32AM >>>
> Tom,

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 02 Nov 1999 11:52:15 -0700

Mike,

did I really mean to affix my legally binding signature to this document, or 

To my way of thinking, these issues are far more important to establishing
the long-term legal validity of my signature on a contract than the fact that 
the certificate wasn't revoked. After all, I would only have reason to revoke
my key if I suspected that it had been compromised, and it would be
an unusually stupid attacker who would compromise my key and let me 
know about it.

So, as Ed and others have already pointed out, the convention technical
definition is neither necessary nor sufficient to establish nonrepudiation.

2.  Who bears the risk of loss if it can reasonably be established that the 
subject of the certificate in fact did NOT sign the document.

Unless or until we can answer those questions, nonrepudiation is just
a technical artifact -- not much more than a convenience or an inconvenience,
depending on whose side you are on.

Bob

Tom,

Mike Henry