RE: NR, redux, again.

[MHenry <MHenry@xxxxxxx>]

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