[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] FW: Here is the TimeStamp scope question to post to the list.
Ed and Nick, I mostly agree with you. Some considerations for those that may worry about having so many options: 1. First, each type deals with different purposes. Certainly is very easy to understand the difference between time-stamping the documents that I have to sign and the signature produced itself. In addition, the concept of the last one ArchiveTimeStamp is also easily translated to plain words: it is a time-stamp that is applied over the signature and all the cryptographic material managed in the first verification of the signature itself, for keeping the signature safe of cryptographic breaks.... A bit more difficult seems to be the other two: the ones dealing with references to the cryptographic material.... 2. This means that different business cases will require one or several of these time-stamps, but that the decission of which one(s) will usually have to be made by designers of the systems that will likely profile it in accordance, or alkternatively, for those individual with few background, some advices can be given by the server itself or even the recepient of the signed document (for instance, public agencies....). What I mean is taht I think that time-stamps will be used in environments where somebody will have established a set of rules identifying what kind of time-stamps need to be managed.... Juan Carlos. At 10:41 15/09/2003 +0100, Nick Pope wrote: >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: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 >> ? >> >> >> >> >> >> >> 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. > > > > > >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_workgroup.php. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]