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>]

sorry - with attachment

> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com]
> Sent: 07 March 2006 12:46
> To: Juan Carlos Cruellas; ed.shallow@rogers.com
> Cc: 'OASIS DSS TC'
> 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
>
>
> 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).
> >
> >
> >
> >
> >

timestamp-revs-NPrev-b.doc