[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New Timestamp processing Sections 3.5.2 - 3.5.2.1 - 4.3.2 - 4.3.2.1
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. 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 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. 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 tiemstamp 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. ... That's it ... See you Monday !!! Ed
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]