[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: NR, redux, again.
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
> -----Original Message-----
> From: Bob Jueneman [SMTP:BJUENEMAN@novell.com]
> Sent: Tuesday, November 02, 1999 1:52 PM
> To: Tony Bartoletti; MHenry@PEC.com; 'tgindin@us.ibm.com'
> Cc: oscar.jacobsson@celocom.com; ietf-pkix@imc.org
> 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 <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
> >
> >