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

["Nick Pope" <pope@secstan.com>]

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