Binary Timestamp Verification Text for the TimeStamp Profile

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

As per action from last call, here is some text for the TSP for binary
timestamp verification ... Which could potentially be included in a new
section 4.1.4 Entitled "Basic Verify Processing for CMS RFC3161 Timestamps".



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. This profile handles only
standalone timestamps. For signature timestamps which are embedded in their
respective signatures, please consult the [DSSCore].

There are two scenarios under which this profile can verify a timestamp. In
both cases the timestamp to be verified is included in the SignatureObject
as specified by [DSSCore]. The scenarios are as follows:

1) only the timestamp is present in the Verify request, and the data that
was timestamped is not present 
2) both the timestamp and the timestamped data are present in the request
with the timestamped data passed in as an input document 

The processing by the server is broken down into the following steps.
Differences between the two scenarios above are noted as appropriate:

1.	Cryptographically verify the timestamp token included in the
SignatureObject request element.
2.	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".
3.	Validate that the TstInfo structure has a valid layout as defined in
[RFC 3161].

For scenario 2) above perform optional steps 4, 5 and 6, else go to step 7
4.	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.
5.	Calculate the hash over the contents of the Document included in the
InputDocuments element of this request using the hash algorithm specified in
the timestamp token 
6.	Compare the hash values from the two previous steps, and if they are
equivalent, then this timestamp is valid for the data that was time stamped.

7.	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.
8.	Set the dss:Result element as defined in [DSSCore].

It should be noted that under scenario 1 above, it is assumed that the
client is taking the responsibility for verifying steps 4, 5, and 6
themselves. Under scenario 2, the server is performing this verification for
the client caller.