FW: Here is the TimeStamp scope question to post to the list.

["Nick Pope" <pope@secstan.com>]

-----Original Message-----
From: Edward Shallow [mailto:ed.shallow@rogers.com]
Sent: 12 September 2003 17:02
To: 'Nick Pope'
Subject: Here is the TimeStamp scope question to post to the list.


Folks,

One of the more important relationships that exist and influences the
"ProcessingOptions" notion is the one which exists with TimeStamping. May I
ask the team for clarification on 2 scope items as part of the
"ProcessingOptions" discussion.

Scope Questions
***************

1) If one agrees that there could exist more than one type of a timestamp,
which types of timestamps would DSS like to support ? As a starting point,
and in the absence of any suggested references todate, may I be so bold as
to use the ETSI 101 903 definitions as a basis for the question ? Please
refer to the ETSI document for detailed descriptions, sections included. I
believe Tim's submission falls into the categorization below. Forget about
naming conventions for now. Types as follows:

a) AllDataObjectsTimeStamp - a "content" TimeStamp produced before signature
creation over the sequence of all ds:References (this excludes the
SignedProperties), it itself is an optional SignedPoperty (see 7.2.9, and
another TimeStamp variation called IndividualDataObjectsTimeStamp covered in
7.2.10)

b) SignatureTimeStamp - with this timestamp the input for the timestamp hash
computation is the ds:SignatureValue XML element, produced after signature
creation

c) XAdES-T TimeStamp - timestamp computed over the entire XAdES (or DSS
equivalent in our case) structure itself. It would be over the PKCS7 for
non-XML based signatures.

d) There are 2 alternate forms of XAdES-X which can be used and are as
follows:

d1)SigAndRefsTimeStamp - as per SigAndRefsTimeStamp element definition (see
7.5.1)

d2) RefsOnlyTimeStamp - for this type, the hash sent to the TSA will be
computed over the concatenation of CompleteCertificateRefs and
CompleteRevocationRefs elements (see 7.5.2). Offers easier manageability and
performance

e) Archive TimeStamp - timestamp computed over entire XAdES-X-L



2) Given the above, should we separate the agreed upon scope of which
timestamps to cover into "core" and "extended" ? That is, accept a subset
for support in the core protocol and delegate the rest to specific profiles
?