FW: [dss] Text as required by action 06-06-05-02 - revised

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

Apologies - in my haste missed a change to one of the new pieces of text -
disregard my prev mail.

Nick

-----Original Message-----
From: Nick Pope [mailto:nickpope@secstan.com]
Sent: 12 June 2006 16:53
To: OASIS DSS TC; Juan Carlos Cruellas
Subject: FW: [dss] Text as required by action 06-06-05-02



Juan Carlos,

As we discussed following Inmas comment on RFC 3161 timestamp on XML
signatures and looking into your proposals, I suggest:

a) That we reword 3.5.2.2 (and the equivalent in section 4) to explicetly
cover the case of XML Timestamps on XML Signatures

b) That we add a 3.5.2.3 (and equivalent in section 4) to cover the case of
RFC 3161 Timestamps on XML Signatures

c) That these clauses be re-worded to apply IF the type attribute is RFC
3161 / XMLtimestamp urn as appropriate (leaving open for other timestamp
types).

See below specific revisions to your proposals.

Nick

> -----Original Message-----
> From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu]
> Sent: 09 June 2006 16:30
> To: 'OASIS DSS TC'
> Subject: [dss] Text as required by action 06-06-05-02
>
>
> Dear all,
>
> According to what we agreed in our last conf call below follow proposals
> for changes in the core so that
> signature time-stamps in XML management refers to XAdES.
>
> While re-reading the related parts I have also noticed some things that
> I think should be changed.
>
> Below follows the list of things that I propose we should change. There
> are references to line numbers and
> sections. After that I make a cross-check with some of the comments
> raised in the public comments list so that
> we can agree whether they are suitably treated by the proposed text.
> Please note that I am working on CD 4 document.
>
>
> ------------------------------------
>

> 1. Section 3.5.2 line 1025. Page 26.
>
> Original text: "In particular the DSS XAdES profile [DSS-XAdES-P]..."
>
> Proposed text: "In particular the DSS AdES profile [DSS-AdES-P]..."
>
> RATIONALE: The title of the profile has actually changed to AdES as it
> contains details for XAdES and CAdES
> signatures. The reference itself should also be changed. See note for
> change at the end of the list.
>
> -------------------------------------
>
> 2. Section 3.5.2 line 1038. Page 26
>
> Original text: "Two scenarios for the timestamping of CMS sigantures are
> supported...."
>
> Proposed text: "Two scenarios for the timestamping of both CMS and XML
> sigantures are supported...."
>
> RATIONALE: Certainly the cores is supporting the timestamping of both
> types of signatures. Not mentioning
> the XML signature would be misleading.
>
> -------------------------------------
>
3. Add below
"The following subsections specify the use of RFC 3161 timestamps with CMS
signatures and the use of XML Timestamps or RFC 3161 timestamps for both
scenarios."


4 Line 1060 Change title to:
"3.5.2.2 Processing for XML Timestamps on XML signatures"

> 5. Section 3.5.2.2 lines 1068 to 1072 page 27
>
> Proposal. Substitute the whole paragraph from these lines to the
> following one:
>
> "The present specification defines a format for XML timestamp tokens. In
> addition
> XAdES defines a mechanism for incorporating signature timestamps in XML
> signatures.
[Previous proposal to be replaced as below]

If the type attribute in this optional input is
urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken then the XML
signature
MUST contain a <dss:timestamp> as defined in section 5.1, placed in a
<xades:XMLTimeStamp> within a <xades:SignatureTimeStamp> as defined in
[XAdES].

>
> RATIONALE: This text clearly indicates our resolution, ie:
>
> 	. Any XML time-stamp over the signature is created, MUST follow the
> syntax that we define;
> 	. Incorporation must be as specified in XAdES.
>
> -------------------------------------
>
> 6. Section 3.5.2.2 line 1078, page 27
>
> Original text: "urn:ietf:rfc:3275"
>
> Proposed text: "urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken"
>
> RATIONALE: I think that the previous value was a mistake: it identified
> a XML signature, not the XML time-stamp
> token, as it must do.
>

7. Add section 3.5.2.3  Processing for RFC 3161 Timestamps on XML signatures

[New text to be produced based on existing 3.5.2.2]

> -------------------------------------

7+.  Replace line 1523, 1524 with

 - RFC 3161 Timestamps on CMS signatures
 - XML Timestamps on XML Signatures
 - RFC 3161 Timestamps on XML Signatures

>
> 8. Section 4.3.2 line 1524 page 37
>
> Original text: "XML signature timestamp tokens"
>
> Proposed text: "XML timestamps tokens on XML signatures"
Delete "-" in "time-stamp" and corrected spelling in original

>
> RATIONALE: Actually the case that we are dealing with is the signature
> time-stamp token in XML syntax for
> XML signatures, and the former text was not completelly clear on what
> was XML the signature, the time-stamp
> or both. I think that the proposed text is clearer.
>
> -------------------------------------
>
> 9. Section 4.3.2 line 1528, page 37
>
> Original text: "the DSS XAdES profile defines"
>
> Proposed text: "the DSS AdES profile [DSS-AdES-P] defines"
>
> RATIONALE: As in proposal 1.
>
> -------------------------------------
>
> 10. Section 4.3.2.2 line 1556 page 38
>
> Original text: "Processing for XML timestamp tokens"
>
> Proposed text: "Processing for XML timestamps tokens on XML signatures."
>
> RATIONALE: In the line of what I said in proposal 6.
>
>
> -------------------------------------
>
> 11. Section 4.3.2.2 line 1557, page 38
>
> Original text: "The present setion describes the processing rules for
> verifying and XML Signature timestamp
> token embedded within an XML signature as an unsigned property."
>
> Proposed text 1 : "The present setion describes the processing rules for
> verifying and XML Signature timestamp
> token embedded within an XML signature using the incorporation
> mechanisms specified in XAdES."
>
> Proposed text 1 : "The present setion describes the processing rules for
> verifying and XML Signature timestamp
> token embedded within an XML signature using the incorporation
> mechanisms specified in XAdES (i.e., in the
> <xades:XMLTimeStamp> <xades:SignatureTimeStamp> element's child )."
>
> RATIONALE: As agreed explicit mention to XAdES as for how the XML
> time-stamp must come within the XML signature.
> The only doubt I have is about the degree of detail. That is why there
> are two proposed text, being the second
> more detailed, as it explicitly mentions where the XML time-stamp token
> will appear... We can talk on them in
> the conf call.
>

12) Add new section 4.3.2.3 XML timestamps tokens on XML signatures

[Text to be produced based on 4.3.2.1 & 4.3.2.2
>
> A. PROPOSALS FOR CHANGES
>
> -------------------------------------
>
> 9. Section 4.3.2.2 line 1573, page 38
>
> Original text: "Verify that one of the <ds:Reference> element has ...."
>
> Proposed text: "Verify that one of the <ds:Reference> elements has ...."
>
> RATIONALE: It must be plural.
>
>
> -------------------------------------
>
> 10. Section 4.3.2.2 line 1585 to 1592, page 39
>
> Original text: the whole steps 7 and 8
>
> Proposed text:
>
> "7. Take each of the other <ds:Reference> elements and for each one
> proceed to its validation as specified in [XMLSig].
>
> 8. Check that for one of the <ds:Reference> elements the retrieved data
> object is actually
> the <ds:SignatureValue> element and that it contains its digest after
> canonicalization.
>
> 9. Set the <dss:Result> element as appropiate"
>
>
> RATIONALE: The former text was inconsitent with the text in 1571, where
> we said "the <ds:SignedInfo>
> contains at least two <ds:Reference> elements". Former step 7 began
> "Take the other <ds:Reference>" when
> there could actually be more than one.
>
> ADDITIONAL ISSUE: I would like to bring your attention to the proposed
> text in step 8. I tried to say that
> one of the <ds:Reference> elements must contain the digest of the
> canonicalized <ds:SigantureValue> value. Do
> you think that the writing is accurate and clear enough?.
>
>
> -------------------------------------
>
>
> 11. Section 8, Line 2051. Page 24.
>
> Original text: "[DSS-XAdES-P] JC cruellas et al. DSS XAdES Profile.
> OASIS, April 2006"
>
> Proposed text: "[DSS-AdES-P] JC cruellas et al. "Advanced Electronic
> Signature Profiles of the OASIS Digital Signature Service" "
>
>
>
> B. CROSS-CHECK WITH COMMENTS:
>
>
> -------------------------------------
>
> 1. COMMENT BY INMA MARIN OF MAY 16TH.
>
> She says "there is no indication on how a <SignRequest> should be
> created so as to get the timestamping of an existing
> XML signature from the DSS server".
>
> a. Line 1038 in 3.5.2, changed as suggested in proposal 2 would read
>
> "Two scenarios for the timestamping of both CMS and XML sigantures are
> supported...."
>
> It is pretty clear now the the core actually supports XML signatures
> timestamping.
>
> b. Lines 1075 to 1077 (untouched) read
>
> "In scenario b) the incoming signature MUST be passed in on one of the
> following three elements
> <EscapedXML>, <InlineXML> or <Base64XML>"
>
> this instructs readers on how to include the XML signature in the request.
>
> c. New line 1077-1078 changed as suggested in proposal 4 will read:
>
> "The Type attribute of the <AddTimeStamp> optional input SHALL be set to:
> 	urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken"
>
> There was a wrong URI here, the one of XMLSig, which contributed to
> increase confusion here....
>
> I think that with the two highligthed  changes it should be pretty clear
> how to request a XML timestamp on a XML signature.
>
>
> Regards
>
> Juan Carlos.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your
> TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>