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

[Juan Carlos Cruellas <cruellas@ac.upc.edu>]

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).