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

[Brian E Carpenter <[e-mail]>]

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

On 2007-05-21 20:44, Carl Wallace wrote:
>>> 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.
> 


-- 
NEW: Preferred email for non-IBM matters: [e-mail]


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art