[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 <MHenry@PEC.com> 11/02/99 11:32AM >>>
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:	tgindin@us.ibm.com [SMTP:tgindin@us.ibm.com] 
> Sent:	Tuesday, November 02, 1999 12:23 PM
> To:	Tony Bartoletti
> Cc:	Bob Jueneman; oscar.jacobsson@celocom.com; ietf-pkix@imc.org 
> 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: azb@llnl.gov                                   LLLLLLLL
> 
>