[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] New Timestamp processing Sections 3.5.2 - 3.5.2.1 - 4.3.2 - 4.3.2.1, + XML signature time-stamp + new section 4.6.9
sorry - with attachment > -----Original Message----- > From: Nick Pope [mailto:pope@secstan.com] > Sent: 07 March 2006 12:46 > To: Juan Carlos Cruellas; ed.shallow@rogers.com > Cc: 'OASIS DSS TC' > Subject: RE: [dss] New Timestamp processing Sections 3.5.2 - 3.5.2.1 - > 4.3.2 - 4.3.2.1, + XML signature time-stamp + new section 4.6.9 > > > Ed, Juan Carlos, > > I have updated the text as attached. > > Juan Carlos - there are a couple of areas where I have > highlighted for XML time-stamps which require your attention. > > Regards > > Nick > > > -----Original Message----- > > From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu] > > Sent: 06 March 2006 10:11 > > To: ed.shallow@rogers.com > > Cc: 'OASIS DSS TC'; 'Nick Pope'; 'Trevor Perrin'; 'Konrad Lanz' > > Subject: Re: [dss] New Timestamp processing Sections 3.5.2 - 3.5.2.1 - > > 4.3.2 - 4.3.2.1, + XML signature time-stamp + new section 4.6.9 > > > > > > Dear all, > > > > After receiving Ed's text, I have re-generated the parts that deal with > > XML time-stamp and inserted between Ed's text for facilitating Stefan > > his work. > > > > I have also added some comments to Ed's text. Maybe we could comment > > them during today's conf call. > > > > Regards > > > > > > Juan Carlos. > > > > > > ----> Ed's message with my comments and contributions on XML timestamps > > > > > > Hi Everyone, > > > > Sorry for the 1 week delay, it has been crazy here this week. In any > > event, better late than never. Here are the re-written sections I was > > assigned at the last conference call. Feel free to provide > feedback and/or > > corrections: > > > > 3.5.2 Optional Input <AddTimestamp> > > > > The <AddTimestamp> element indicates that the client wishes the > server to > > embed a timestamp token as a property or attribute of the > resultant or the > > supplied signature. The timestamp token will be on the > signature value in > > the case of CMS/PKCS7 signatures or the <ds:SignatureValue> > element in the > > case of XML signatures. For coverage and handling of content > > timestamps, or > > other standalone timestamps which are not part of, or embedded in the > > primary signature being dealt with, readers are asked to refer to > > either the > > Timestamp Profile of this specification, or the XAdES profile of this > > specification. > > > > <JC-2006-3-6>Thinking on it I feel that "content timestamps" do > > not clearly > > signal what we are talking about, ie, timestamps computed on > to-be-signed > > data objects if we do not say it before. Shouldn't we give some short > > definition of the term before using it or use another > term?</JC-2006-3-6> > > > > Below follows the schema definition of this property: > > > > ....... > > > > The Type attribute, if present, indicates what type of > timestamp to apply. > > Profiles that use this optional input MUST define the allowed > values, and > > the default value, for the Type attribute (unless only a single type of > > timestamp is supported, in which case the Type attribute can be > omitted). > > > > > > > > 3.5.2.1 Processing for CMS signature time-stamping > > > > Two scenarios for the timestamping of CMS signatures are > supported by this > > Optional Input. They are as follows: > > > > a) create and embed a timestamp token into the signature being > created as > > part of this SignRequest > > > > b) create amd embed a timestamp token into an existing signature > > which must > > be passed in on this SignRequest > > > > <JC-2006-3-6>I think that the three sentences above would fit better in > > 3.5.2, as they are common to both CMS and XML. </JC-2006-3-6> > > > > > > In both scenarios, the timestamp token created by the server will be RFC > > 3161 compliant and identified as such by means of the token's > content type > > which will carry an OID value of "1.2.840.11359.1.9.16.1.4" indicating a > > timestamp token. The MessageImprint field within the TstInfo > structure of > > the timestamp token will be derived from the signature value of the > > just-created or incoming signature depending on the scenario. As > > such, it is > > by defintion, a signature timestamp as opposed to a content timestamp. > > > > In scenario a) the timestamp which is now embedded in the > > signature, will be > > returned along with the signature in the <SignatureObject> of the > > <SignResponse>. In secnario b) the incoming signature must be > > passed in on a > > <Base64Data> element whose MimeType atrtibute is > > application/pkcs7-signature. The signature and its embedded > timestamp will > > be returned in the <SignatureObject> of the <SignResponse>. > > > > > > > > The caller SHOULD perform all of the following tasks: > > > > - set the SignatureType to "urn:ietf:rfc:3161" > > - include the <AddTimestamp> optional input (the Type attribute may be > > omitted here as it is redundant) > > - pass in the existing signature in a <Base64Data> element whose > > MimeType is > > set to "application/pkcs7-signature" (Sceanrio b) only) > > > > In scenario b) the server SHOULD not verify the signature before > > adding the > > timestamp. If a client wishes that its signatures be verified as > > a condition > > of time stamping, the client should use the <AddTimestamp> > > optional input of > > the Verify protocol. > > > > > > 3.5.2.2 Processing for XML signature timestamps > > > > > > <JC-2006-6-3>As you will see, I have decided to make it explicit > > that the XML signature timestamp only will have TWO <ds:Reference> > > elements, one for the <TSTInfo> and the other for the data that > > actually is timestamping, ie, the <ds:SignatureValue>. I think that > > this makes things easier...<JC-2006-6-3> > > > > In both scenarios, the timestamp token created by the server will be > > aligned with section 5.1 of the present document. It will be a > > <ds:Signature> > > with two <ds:Reference> elements. One of them MUST accomplish the > > following restrictions: > > > > - Its URI attribute will be set to > > "urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken". > > - It will reference a <ds:Object> element whose content is a > > <TSTInfo> > > element. > > > > > > The other <ds:Reference> element MUST accomplish the following > > restriction: > > > > - Its <ds:DigestValue> element will be derived from the > > <ds:SignatureValue> of the just-created or > > incoming signature depending on the scenario. As such, it is > > by defintion, a signature timestamp as opposed to a content timestamp. > > > > In scenario a) the timestamp which is embedded in the signature, will be > > returned along with the signature in the <SignatureObject> of the > > <SignResponse>. In secnario b) the incoming signature must be passed in > > on one > > of the following three elements <EscapedXML>, <InlineXML> or > <Base64XML>. > > The signature and its embedded timestamp will > > be returned in the <SignatureObject> of the <SignResponse>. > > > > The caller SHOULD perform all the following tasks: > > - set the SignatureType to "urn:ietf:rfc:3275" > > - include the <AddTimestamp> optional input (the Type attribute may be > > omitted here as it is redundant). > > > > In scenario b) the server SHOULD not verify the signature before > > adding the > > timestamp. If a client wishes that its signatures be verified as > > a condition > > of time stamping, the client should use the <AddTimestamp> > > optional input of > > the Verify protocol. > > > > > > 4.3.2 Timestamp verification procedure > > > > The following sub-sections will describe the processing rules for > > verifying: > > - CMS RFC 3161 signature timestamp tokens > > - XML timestamp tokens > > > > This section describes signature timestamp processing when the > > timestamp is > > embedded in the incoming signature. Readers are asked to refer to > > either the > > Timestamp Profile of this specification or the XAdES Profile of this > > specification for the processing rules associated with the validation of > > either standalone timestamps of timestamps which cover content > (as opposed > > to signatures). > > > > For definition of the <Timestamp> element see section 5.1. > Details of the > > XML timestamp token can be found in subsection 5.1.1. > > > > > > 4.3.2.1 Verification processing of CMS RFC 3161 timestamp tokens > > > > The present section describes the processing rules for verifying a CMS > > RFC3161 timestamp token passed in on a Verify call within the > > <SignatureObject> of the <VerifyRequest> element. In the CMS > > case, since the > > "signature timestamp" is embedded in the signature as an unauthenticated > > attribute, only the time stamped signature is required for verification > > processing. As such, no additional input is required. > > > > The processing by the server is separated into the following steps: > > > > 1. The signature timestamp is embedded in the incoming signature as an > > unsigned attribute, extract the timestamp token and verify it > > cryptographically. Since it is by definition an enveloping > signature over > > the TstInfo structure contained as its eContent, the token is itself a > > verifiable signature. > > > > 2. Verify that the timestamp token content type is > > "1.2.840.11359.1.9.16.1.4" indicating a timestamp token. > > > > 3. Verify that the token's public verification certificate is > > authorized for > > time stamping by examining the Extended Key Usage field for the > > presence of > > the time stamping OID "1.3.6.1.5.5.7.3.8". > > > > 4. Validate that the TstInfo structure has a valid layout as > per RFC 3161. > > > > 5. Extract the MessageImprint hash value and associated > algorithm from the > > TstInfo structure which will be compared against the hash value > derived in > > the next step. > > > > 6. Recalculate the hash of the data that was originally time stamped. As > > this is signature timestamp, the input to the hash > re-calculation must be > > the signature value of the enclosing signature. > > > > 7. Compare the hash values from the two previous steps, and if they are > > equivalent, then this timestamp is valid for the signature that was time > > stamped. > > > > 8. Verify that the public verification certificate conforms to > > all relevant > > aspects of the relying-party's policy including algorithm usage, policy > > OIDs, time accuracy tolerances, and the Nonce value. > > > > 9. Set the dss:Result element as appropriate reflecting the standardized > > error reporting as specified in RFC 3161. > > > > Note: In the special case where an incoming signature to be verified > > contains an authenticated attribute whose content type is > > 1.2.840.11359.1.9.16.1.4 (indicating a pre-signature creation content > > timestamp token), the DSS server SHOULD return a > > resultmajor:RequesterError > > with a resultminor:NotSupported. It is the intention that these > > scenarios be > > handled by either the Timestamp Profile or the XAdES Profile > depending on > > the nature of the timestamped content. > > > > <JC-2006-6-3>The note speaks only about a signature containing content > > time-stamp, and I think that we agreed in managing this only in XAdES > > profile, not > > in time-stamp profile. I think that we agreed that the time-stamp > > profile was left for isolated time-stamps. I think that the mention > > to timestamp profile should be removed from this note, and maybe added > > another > > note mentioning the isolated timestamp case. Please take a look to the > > note 2 in the section for processing XML timestamp tokens<JC-2006-6-3> > > > > > > 4.3.2.2 Processing for XML signature timestamp tokens > > > > The present section describes the processing rules for verifying a XML > > signature > > timestamp token embedded within a XML signature as unsigned > property. This > > signature may be passed in on a Verify call within the > > <SignatureObject> or > > embedded within a child of a <Document>'s child. > > > > The server will verify the timestamp token performing the steps detailed > > below. If any one of them results in failure, then the timestamp token > > SHOULD be rejected. > > > > 1. As it is a signature timestamp embedded in the incoming > > signature as an unsigned property, extract the timestamp token. > > > > 2. Locate the signature-verification key for the timestamp token. > > > > 3. Verify that the aforementioned verification key is authorized for > > verifying timestamps. If it comes within a public certificate, > verify that > > it is authorized for time stamping by examining the ExtendedKeyUsage > > extension > > for the presence of the time stamping OID “1.3.6.1.5.5.7.3.8”. > > > > 4. Verify that the aforementioned verification key conforms to > > all relevant > > aspects of the relying-party’s policy. Should this key come > > within a public > > certificate, verify that it conforms to all relevant aspects of the > > relying-party's > > policy including algorithm usage, policy OIDs, and time accuracy > > tolerances. > > > > 5. Verify that the aforementioned verification key is > > consistent with the > > ds:SignedInfo/SignatureMethod/@Algorithm attribute value. > > > > > > 6. Verify that all digest and signature algorithms conform to the > > relying-party’s > > policy. > > > > 7. Cryptographically verify the timestamp token. As it is an > > XML signature, > > the server should perform it following the rules established > by XMLDSIG. > > > > 8. Verify that the <ds:SignedInfo> element contains two <ds:Reference> > > elements. > > > > 9. Verify that one of the <ds:Reference> element has its Type > > attribute > > set to > > “urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken”. Take this > > one and proceed as > > indicated below: > > > > a. Retrieve the referenced data object. Verify that it references a > > <ds:Object> element, > > which in turn envelopes a <TSTInfo> element. > > > > b. Verify that the <TSTInfo> element has a valid layout as per the > > present specification. > > > > c. Extract the digest value and associated algorithm from its > > <ds:DigestValue> > > and <ds:DigestMethod> elements respectively. > > > > c. Recalculate the digest of the retrieved data object as > > specified by > > XMLDSIG with > > the digest algorithm indicated in <ds:DigestMethod>, and > > compare this > > result > > with the contents of <ds:DigestValue>. > > > > > > 11. Take the other <ds:Reference> and proceed as indicated below: > > > > a. Retrieve the referenced data object. Verify that this is the > > <ds:SignatureValue> of the time-stamped XML signature. > > > > b. Extract the digest value and associated algorithm from its > > <ds:DigestValue> and <ds:DigestMethod> elements respectively. > > > > c. Recalculate the digest of the retrieved data as specified by > > XMLDSIG with the digest algorithm indicated in the > > <ds:DigestMethod>, > > and compare the computed digest value with the one in the > > <ds:DigestValue> > > element. > > > > 12. Set the <dss:Result> element as appropriate. > > > > > > NOTES: > > 1. In the special case where an incoming signature to be verified > > contains a signed property consisting in a XML timestamp > computed on the > > signed data > > before the signature creation (a <xades:AllDataObjectsTimeStamp> for > > instance), > > the DSS server SHOULD return a resultmajor:RequesterError > > with a resultminor:NotSupported. It is the intention that these > > scenarios be > > handled the XAdES Profile. > > > > 2. In the special case where an incoming signature actually is > > just a XML > > timestamp of a number of data objects, the DSS server SHOULD return a > > resultmajor:RequesterError > > with a resultminor:NotSupported. It is the intention that these > > scenarios be > > handled by the TimestampProfile. > > > > 3. Should the XML timestamp token follow another specification, its > > cryptographic verification and > > subsequent checks should follow the rules established in that > > specification. > > > > > > > > JC-2006-6-3>I think that in our last talk with Ed we agreed in that a > > short section on <AddTimeStamp> was required for verification protocol, > > for the sake of completeness and simetry. Below follows a first > > version.<JC-2006-6-3> > > > > > > 4.6.9 Optional Input <AddTimestamp> > > > > The <AddTimestamp> element within a <VerifyRequest> message > > indicates that the client wishes the server to update the > > signature after its verification by embedding a signature > timestamp token > > as an unauthenticated property or attribute of the supplied signature. > > > > The timestamp token will be on the signature value in > > the case of CMS/PKCS7 signatures or the <ds:SignatureValue> > element in the > > case of XML signatures. > > > > For verification of signatures and their updates with > > other types of timestamps, readers are asked to refer to the XAdES > > Profile of this > > specification. For verification of isolated timestamp tokens, > readers are > > asked to refer to the Timestamp Profile of this specification. > > > > The Type attribute, if present, indicates what type of > timestamp to apply. > > Profiles that use this optional input MUST define the allowed > values, and > > the default value, for the Type attribute (unless only a single type of > > timestamp is supported, in which case the Type attribute can be > omitted). > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]