Ed,
Personally, as these definitions are going to be useful to several of the
profiles and it is useful to put the choice of time-stamp placements in one
document, I would suggest that they all go in the core.
Other views?
>
> -----Original Message-----
> From: Edward Shallow [mailto:]
> 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
> ?
>
>
>
>
>
>
> To unsubscribe from this mailing list (and be removed from the
> roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor
kgroup.php.
