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

From: Carl Wallace <[email-masked]>
Date: Mon, 21 May 2007 14:44:36 -0400

> > 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 May 2007 09:34:36 +0200

Thanks for the explanations. It's up to Russ and Tim to decide if
any clarification of the text is needed.

> The validate draft provides additional details

I'm a little surprised then that it isn't cited as an
Informational reference. It seems that although it isn't
needed to understand the ERS syntax, it will be needed
for any practical deployment.

     Brian

-- 
NEW: Preferred email for non-IBM matters: [email-masked]