DSS Core Changes

Dear All,

The following changes apply to the WD44 document sent by Stefan last week.

Regards,

Carlos

Carlos Gonzalez-Cadenas
Chief Security Officer

Diagonal 188-198 Planta 2
08018 Barcelona
tel: 902 303 393
fax: 902 303 394
gonzalezcarlos@netfocus.es
www.netfocus.es

--------------------------------------------------------------------------------------------------

CHANGE PROPOSALS

1. PROPOSED CHANGE 1

a. Location: Section 2.6, Element <Result>

b. Rationale: The error codes don’t follow any convention, provoking some degree of uniformity in them. I propose the following conventions

1. Start the error code with caps, like “IncorrectSignature”

2. When including acronyms in the URNs, use caps, like URI instead of Uri or XML instead of Xml

3. After urn:oasis:names:tc:dss:1.0:resultMajor or urn:oasis:names:tc:dss:1.0:resultMinor, don’t use more colons, in order to facilitate tokenizing processes for clients analyzing the response code, use instead the “_” character.

c. Resulting Error Codes (fix in 2.6 and also replace in the rest of the document)

i. Majors: Success, RequesterError, ResponderError, InsufficientInformation (no changes)

ii. Minors:

1. valid:signature:onAllDocuments -> ValidSignature_OnAllDocuments,

2. valid:signature:notAllDocumentsReferenced -> ValidSignature_NotAllDocumentsReferenced

3. invalid:incorrectSignature -> IncorrectSignature

4. valid:signature:hasManifestResults -> ValidSignature_HasManifestResults

5. valid:signature:InvalidSignatureTimestamp -> ValidSignature_InvalidSignatureTimestamp

6. referencedDocumentNotPresent -> ReferencedDocumentNotPresent

7. KeyInfoNotProvided (no changes)

8. MoreThanOneRefUriOmitted -> MoreThanOneRefURIOmitted

9. NotParseableXMLDocument (no changes)

10. NotSupported (no changes)

11. inappropriate:Signature -> InappropriateSignature

12. GeneralError (no changes)

13. invalid:KeyLookupFailed -> KeyLookupFailed

14. CrlNotAvailiable -> CRLNotAvailable

15. OcspNotAvailiable -> OCSPNotAvailable

16. CertificateChainNotComplete (no changes)

2. PROPOSED CHANGE 2

a. Location: Section 2.8.2, Optional Input <ClaimedIdentity>.

b. Rationale: The <ClaimedIdentity> optional input specifies that “the claimed identity may be authenticated using the security binding, according to section 6 or using authentication data provided in the <SupportingInfo> element”, and enumerates some examples about possible usages (i.e. XML Signature, SAML Assertion, Password, …).

i. In section 6, a concrete and detailed explanation for every security binding is given, but we don’t have such level of information if somebody wants to authenticate their requests using a <ClaimedIdentity> based mechanism. In the <ClaimedIdentity>, these issues are relegated to profiles. That is, we cannot authenticate requests using <ClaimedIdentity> with the core.

ii. IMHO, as interoperability and security issues will appear regarding <ClaimedIdentity>, I would introduce descriptions for the most common mechanisms (XML Signature, SAML Assertions and Passwords) that will encourage interoperability between implementations in such a core issue, and also will incorporate an analysis from the security viewpoint (as securing mechanisms, specially SAML Assertions and also Passwords (due to the difficulties to link the authentication data to the message), are not straightforward). If we include these, it’s likely that profiles will only include other mechanisms when there are good reasons for doing it.

c. Proposal:

i. Include annexes in the core that describe how to use XML Signatures, SAML Assertions and Passwords with the <ClaimedIdentity> optional input, and include a brief security analysis (A DRAFT IS INCLUDED IN THE ATTACHED DOCUMENT AS A STARTING POINT FOR THE DISCUSSION)

ii. Add a reference in the <ClaimedIdentity> optional input linking to these annexes.

3. PROPOSED CHANGE 3

a. Location: Section 3.5.6, Optional Input <IncludeObject>

b. Rationale: Several modifications should be added to address some issues.

i. There should be explicitly noted that many occurrences of <IncludeObject> are supported.

ii. Clarify the impact that this optional input has in the reference creation (i.e. having createReference to true implies creating a new reference, or we’re referring to the reference that will be created due to the basic processing? (Note that the expected behaviour is the latter, but the text needs clarification)).

iii. How this optional input behaves when used in conjunction with other reference-aware optional inputs should be made clear to avoid confusion.

iv. ObjId usage should be RECOMMENDED, as the RefURI of the to-be-enveloped document MUST be (per spec) a same-document URI pointing to the object, and Id-based pointing (#some-id, #xpointer(id(‘some-id’)), # here()/ancestor::ds:Signature/ds:Object[@id=’some-id’] or the like) is the strongest available option (and allows easy verifiability by the server)

1. IMHO position-based XPaths, like here()/ancestor::ds:Signature/ds:Object[1] SHOULD not be valid, as there’s no ordering restriction for the server when placing <ds:Object>s,

2. <ds:Object>’s content XPaths, like here()/ancestor::ds:Signature/ds:Object[Invoice] or the like may result in several ds:Object, if we don’t have some way to uniquely identify the contents.

v. Clarify the same-document reference handling (with RefURI), including how to handle error situations.

vi. Add text to express that the server doesn’t need to guarantee that the <ds:Object> elements are introduced in any specific order.

c. Proposal

i. For issue i

1. Add between lines 1174-1175: “Multiple occurrences of this optional input can be present in a single <SignRequest> message. Each occurrence will cause the inclusion of an object inside the signature being created.”

ii. For issue ii and iii

1. Add to the end of line 1212: “BEFORE performing Basic Processing (as specified in section 3.3.1)”

2. Replace lines 1185 – 1187 with

“This attribute set to false inhibits the creation, carried by the Basic Processing specified in section 3.3.1, of the <ds:Reference> associated to the RefURI attribute of the input document referred by the WhichDocument attribute, effectively allowing clients to include <ds:Object> elements not covered/protected by the signature being created.

Note: The creation of a reference pointing to the enveloped document MAY be still possible (even when this attribute is set to false) when the Basic Processing is overridden due to concurrence of other optional inputs (i.e. when the <SignedReferences> optional input (section 3.5.9) includes a <SignedReference> element whose WhichDocument attribute is equal to the WhichDocument attribute present in this optional input).”

NOTE: This text unambiguously declares that the usefulness of this attribute is circumscribed to inhibit the reference creation when basic processing is in place (not overridden, as in the case of SignedReferences), excluding any other interpretations, like that having createReference=true

3. Replace lines 1185 – 1187 with

“e. If CreateReference is set to false, exclude this <Document> from the set of <Document>s ready for further processing.”

The server then continues with Basic Processing, as specified in section 3.3.1, for the rest of the <Document>s.”

NOTE: Clarification, adding a new step e. to make sure implementers don’t forget about that.

iii. For issues iv, v and vi

1. Replace lines 1202 – 1211 with

“For each <IncludeObject> the server creates a new <ds:Object> element containing the document, as identified using the WhichDocument attribute, as its child. This object is carried within the enveloping signature. The ordering of the <IncludeObject> optional inputs MAY be ignored by the server.

This <Document> MUST include a “same-document” RefURI attribute (having a value starting with “#”) which references either:

- The whole newly-created <ds:Object>.

- The relevant parts of the newly-created <ds:Object>’s contents to be covered/protected by the signature (only applicable when the <Document> element contains either <Base64XML>, <InlineXML> or <EscapedXML>)

If the result of evaluating the expression included in the RefURI attribute doesn’t fit in any of the options described above, the server MUST reject the request using a <ResultMajor> RequesterError qualified by a <ResultMinor> InvalidRefURI

Note: As the server could not include the <ds:Object> elements in any specific order (discouraging the usage of expressions like here()/ancestor::ds:Signature/ds:Object[2]), it is RECOMMENDED either to use ID-based referencing to the <ds:Object> (using the client-generated ID included in the ObjId attribute) or to rely on expressions based on <ds:Object>’s contents that allow to unambiguously refer to the included object or their relevant parts.

2. Add after line 588

“urn:oasis:names:tc:dss:1.0:resultminor:InvalidRefURI

The value of the RefURI attribute included in an input document is not valid.”

4. PROPOSED CHANGE 4

a. Location: Section 3.5.8, Optional Input <SignaturePlacement>

b. Rationale:

i. Clarify the same-document reference handling (with RefURI), including how to handle error situations.

1. What happens when the enveloping document is not being referenced in any way (i.e. when we have a RefURI=”some-dsObject-id”)? (Technically I think that’s easily detectable as we should have an empty node-set (due to the enveloped signature transform)).

ii. XPathAfter and XPathFirstChildOf

1. Include that they cannot appear at the same time in a request

iii. Clarify the processing rules

1. Make the reference to Basic Processing more symmetric to allow easy comparation.

2. Correct some errors when CreateEnvelopedSignature=false

3. Step 5 does not get executed conditionally to the reference creation (no reference, nothing to add).

4. Duplicated EnvelopedSignatureTransform text.

iv. Add some text for the case of non-enveloped signature

c. Proposal

i. For issue i

1. Eliminate lines 1245-1246, as this is duplicated contradictorily with text in lines 1290-1294.

2. BTW, line 1247, which “child elements”?

3. Replace lines 1290-1294 with

2. The RefURI attribute MUST be set to include a “same-document” URI which references either:

- The whole <Document> containing the signature (by using a RefURI=””)

- The relevant parts of the <Document> to be covered/protected by the signature (by using a “same-document” RefURI attribute having a value starting with “#”, like RefURI=”#some-id”, RefURI=”#xpointer(/)”, RefURI=”#xpointer(/DocumentElement/ToBeSignedElement)” or the like).

Note: In both cases, the whole <ds:Signature>object containing the transform gets excluded from the computation, due to the usage of the Enveloped Signature Transform.

ii. For issue ii

NOTE: Finally there’s no need for changes, as the schema explicitly includes a xs:choice for these elements.

iii. For issue iii

1. Add to the end of the line 1296: “BEFORE performing Basic Processing (as specified in section 3.3.1)”

2. As in step 7 we’re not describing a concrete instruction (as the result construction is not described here), but only describing how the result should look like, I propose

1. Move text from step 7 to the end of step 3.

3. Step 6 is not an instruction,

1. Line 1323: Remove “6.”

4. Replace lines 1303-1322 with the following

“4. If createEnvelopedSignature equals to true,

a. Perform Basic Processing for the enveloping <Document>, as described in section 3.3.1 with the following amendments:

a. Omitted

b. Esentially the same, with the additional requirement of adding an EnvelopedSignatureTransform as the first transform in the <ds:Transforms> list (even preceding transforms used for extraction).

Note: This is necessary because the EnvelopedSignatureTransform would not work if there was a Canonicalization before it. Similar problems apply to transforms using the here() function. If such are to be supported, the use of Base64XML or EscapedXML MAY be required. (REVISE THE TEXT IN BOLD AS CONTAINS TYPOS IN THE ORIGINAL VERSION)

c. Unchanged

d. Unchanged

i. Unchanged

ii. Unchanged

iii. Unchanged

iv. Unchanged

v. Unchanged (Note: the requirement imposed in 1.b of having the EnvelopedSignatureTransform as the first transform in the <ds:Transforms> list MUST be observed).

2. Omitted

3. Omitted

b. After creating the <ds:Reference> due to the modified Basic Processing, make it available for the Basic Processing, as required in 3.3.1 Step 2.”

iv. For issue iv

1. Add after the line 1295:

“To create a non-enveloped signature, the client produces a request as above, but setting the CreateEnvelopedSignature to false. This will cause the signature to be placed inside the document, but no reference is created to this document due to this optional input, and therefore this document MAY not be covered/protected by the signature.

Note: The creation of a XMLDSig enveloped signature MAY be still possible (even when the CreateEnvelopedSignature attribute is set to false) when the Basic Processing is overridden due to concurrence of other optional inputs (i.e. when the <SignedReferences> optional input (section 3.5.9) includes a <SignedReference> element whose WhichDocument attribute is equal to the WhichDocument attribute present in this optional input, whose RefURI attribute contains an appropriate “same-document” reference and whose <ds:Transfoms> element contains an EnvelopedSignatureTransform).”

5. PROPOSED CHANGE 5

a. Location: Section 3.5.2, Optional Input <AddTimestamp>

b. Rationale:

i. Update the schema to properly reuse the UpdateSignatureInstructionType.

ii. There’s no error code for dealing with unsupported timestamp types.

iii. There’s no need for using Type with CMS signatures in the core

iv. In both scenarios, signatures should not be validated.

v. We’re not covering now the timestamping for enveloped signatures

vi. Issues with the timestamping existing XML signatures

c. Proposal:

i. For issue i

1. Replace lines 1037-1041 by

<xs:element name=”AddTimestamp” type=”dss:UpdateSignatureInstructionType”/>

NOTE: Maybe the UpdateSignatureInstructionType definition should be included in this optionalinput, as this is the first occurrence.

ii. For issue ii

1. Add after line 1045

“When the timestamp type is not supported, the server MUST reject the request using a <ResultMajor> RequesterError qualified by a <ResultMinor> UnsupportedTimestampType. When the signature doesn’t support the inclusion of a type of timestamp, the server MUST reject the request using a <ResultMajor> RequesterError qualified by a <ResultMinor> UnsupportedSignatureTimestamp. ”

2. Add after line 596

“urn:oasis:names:tc:dss:1.0:resultminor:UnsupportedTimestampType”

The timestamp type is not supported by the server.

urn:oasis:names:tc:dss:1.0:resultminor:UnsupportedSignatureTimestamp”

The timestamp type is supported by the server, but it’s not compatible with the signature to be time-stamped”

iii. For issue iii

1. Remove lines 1066-1067

iv. For issue iv

1. In lines 1068, 1092 and 1104, replace “Note: In scenario b) the server” by “Note: The server”

v. For issue v

1. Replace lines 1088-1089 with the following

“The signature and its embedded timestamp SHALL be returned either in the <SignatureObject> (for enveloping/detached signatures) or included inside the document contained in the <DocumentWithSignature> element (for enveloped signatures)”

2. Also add this text after line 1101.

vi. For issue vi

1. Several problems to discuss

1. We cannot timestamp enveloped signatures

1. For now, add to the end of line 1091 and also 1103: “The signature MUST be enveloping or detached in order to be time-stamped by the server.”

2. Implementing XML Signature timestamping implies examinating the content (as there’s no discriminator like in the CMS signatures’ MimeType atribute). But this leads to ambiguity, as the server doesn’t have a (easy) way to differentiate when the client wishes to timestamp a signature or when the client wishes to create a new signature over the passed signature (i.e countersignature) adding a timestamp to the newly-created one.

NOTE: In my opinion, we should create (in the future) a TimestampingRequest (I’ve heard this to someone in the TC) supporting signature timestamping (the scenario b of the AddTimestamp) and also including the functionality described in the timestamping profile.

EDITORIAL CHANGES

1. EDITORIAL CHANGE 1

d. Location: Section 3.5.6.1, XML DSig Variant Optional Input <IncludeObject>

e. Rationale: There is no need for having a XML DSig variant, as the <IncludeObject> optional input is only valid for XML Signatures.

f. Proposal:

i. Eliminate line 1199.

2. EDITORIAL CHANGE 2

g. Location: Section 3.4, Basic Processing for CMS Signatures

h. Rationale:

i. Modify this section to be more symmetric with its XML counterpart.

ii. Move some <DocumentHash>-related text included in the basic processing to its natural place, the <DocumentHash> variant.

i. Proposal:

A COMPLETE PROPOSAL FOR SECTION 3.4 IS INCLUDED IN THE ATTACHED DOCUMENT. NOTES

i. SECTION 3.4 APPEARS HERE AS 1.1 DUE TO WORD AUTOMATIC NUMERATION

ii. CHANGE CONTROL WORD FEATURE IS ENABLED TO SEE WHERE THE CHANGES ARE

iii. STEFAN: TAKE CARE AS THE SECTION NUMBERS ARE NO LONGER REFERENCES (THESE SHOULD BE RESTORED IN THE EDITION PROCESS IF TAKING THIS DOCUMENT AS A SOURCE FOR MAKING CHANGES)

3. EDITORIAL CHANGE 3

a. Location: Section 3.4, Basic Processing for CMS Signatures

b. Proposal:

i. Replace lines 976 – 979: “This octet stream has to be returned …” with

“For CMS signatures that are external/detached/”without eContent”, this octet stream has to be returned inside the <Base64XML> element of a <TransformedDocument> optional output.

Note: The rest of CMS signatures encapsulate the signed data inside its eContent field.”

NOTE: THESE CHANGES HAVE BEEN INCLUDED IN THE TEXT PROPOSAL FOR EDITORIAL CHANGE 3

4. EDITORIAL CHANGE 4

a. Location: Section 3.5.6, Optional Input <IncludeObject>

b. Rationale:

i. Refactoring some text for a clear explanation of what an enveloping signature is

ii. Capitalize attribute names (the rest of attributes in the doc appear capitalized)

c. Proposal:

i. For issue i

1. Line 1174: Remove “as follows”.

2. Cut lines 1200-1201 and paste in line 1174.

ii. For issue ii

1. Lines 1179, 1191 and 1218: Replace hasObjectTagsAndAttributesSet by HasObjectTagsAndAttributesSet

1. Attribute in line 1218 also needs to conform to the typographical conventions for attributes.

2. Line 1195: Replace createReference by CreateReference

5. EDITORIAL CHANGE 5

a. Location: Section 3.5.9, Optional Input <SignedReferences>

b. Rationale: Move the schema after the element description (as in the rest of the document)

c. Proposal:

i. Move schema (lines 1408-1426) after line 1353.

6. EDITORIAL CHANGE 6

a. Location: Section 3.5.8, Optional Input <SignaturePlacement>

b. Rationale: Several typos in the optional input

c. Proposal:

i. Lines 1256 and 1259: change <Xpath by <XPath to be in line with the schema.

ii. Line 1303 and 1295: replace createEnvelopedSignature by CreateEnvelopedSignature.

1. Attribute in line 1295 also needs to conform to the typographical conventions for attributes.

7. EDITORIAL CHANGE 7 (SUBJECT TO JC REVISION)

j. Location: Section 2.5, Optional Input <SignatureObject>

k. Rationale:

i. Shorten XPath example (no need to include two examples).

l. Proposal:

i. Replace example content in lines 475-486 by

“<SignaturePtr xmlns:ds=http://www.w3.org/2000/09/xmldsig# XPath=”//ds:Signature”/>

ii. Remove lines 468(from E.g) to 474.

dss message