New Timestamp processing Sections 3.5.2 - 3.5.2.1 - 4.3.2 - 4.3.2.1

["Edward Shallow" <ed.shallow@rogers.com>]

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