[Gen-art] RE: Gen-ART review of draft-ietf-ltans-ers-13.txt

Carl Wallace <CWallace@cygnacom.com> Mon, 21 May 2007 19:53 UTC

Return-path: <gen-art-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqDwx-0003Ek-4M; Mon, 21 May 2007 15:53:47 -0400
Received: from gen-art by megatron.ietf.org with local (Exim 4.43) id 1HqCs3-0000ol-6U for gen-art-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 14:44:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqCs2-0000od-T4 for gen-art@ietf.org; Mon, 21 May 2007 14:44:38 -0400
Received: from scygmxsecs1.cygnacom.com ([65.242.48.253]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HqCs2-0001ob-9U for gen-art@ietf.org; Mon, 21 May 2007 14:44:38 -0400
Received: (qmail 6230 invoked from network); 21 May 2007 18:43:43 -0000
Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 21 May 2007 18:43:43 -0000
Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 21 May 2007 18:43:42 -0000
Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id <YKN3QBTL>; Mon, 21 May 2007 14:44:36 -0400
Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D06059E@scygmxs1.cygnacom.com>
From: Carl Wallace <CWallace@cygnacom.com>
To: Tobias Gondrom <tgondrom@opentext.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, General Area Review Team <gen-art@ietf.org>
Date: Mon, 21 May 2007 14:44:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb
X-Mailman-Approved-At: Mon, 21 May 2007 15:51:32 -0400
Cc: ralf.brandner@intercomponentware.com, Tim Polk <wpolk@nist.gov>, ulrich.pordesch@zv.fraunhofer.de
Subject: [Gen-art] RE: Gen-ART review of draft-ietf-ltans-ers-13.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0748891489=="
Errors-To: gen-art-bounces@ietf.org

> > 1. At the end of section 4.2:
> > 
> >  The data (e.g. certificates, CRLs or OCSP-Responses) 
> needed to verify  
> > the timestamp SHOULD be stored in the timestamp itself or MUST be  
> > preserved otherwise.
> > 
> > I find this insufficiently clear. When would it be 
> acceptable not to 
> > store these data in the timestamp, and if not done so, how 
> would the 
> > retriever know where to look?
> 
> [tg]: There are three main reasons why we did intentionally 
> write this up in this level of detail: 
> At first, most of the verification of a RFC3161-timestamp has 
> been documented very well in the timestamp and CMS 
> specifications. Second, ERS is open for other timestamps as 
> well (e.g. ISO-18014-x) and they may (and do) require other 
> verification data than RFC3161, plus these other formats may 
> not be able to store all the necessary information for 
> verification inside their data structures. 
> And third, as some of the verification data may be dependent 
> on the use case and country where it is verified, the WG 
> works on the I-D 
> http://www.ietf.org/internet-drafts/draft-ietf-ltans-validate-
> 01.txt to describe the verification and the required data in 
> more detail. 

In addition to the above, the "SHOULD be stored in the timestamp"
recommendation is present in the spec because this is the easiest option.
If the timestamp contains all of the verification data, then there is less
work for the verifier to perform.  However, this also freezes the
verification context (if this is the only means of preserving verification
data).  There is a companion specification that defines how to use SCVP and
ERS to preserve certificates and CRLs independent of a data item that is
archived.  This has a few benefits, including decreasing the storage burden
on the archive and avoiding freezing the validation context.  

Regarding your first question, certificates and CRLs may always be omitted
provided they are otherwise preserved and available.  Regarding your second
question, the relying party would need to know where to obtain the preserved
artifacts.  An archive may provide an SCVP interface for this purpose.  

The same situation applies to signatures within archived data, not just for
timestamp signatures.  The validate draft provides additional details, but
is still a work-in-progress.  The requirement is for the verifier to use
verification data that has been preserved.  Including the verification data
in each timestamp is one means of doing so.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art