review comments

["Carlos Gonzalez-Cadenas" <gonzalezcarlos@netfocus.es>]

Hi all,

 

Some comments from my first review of the DSS Spec, following Nick’s request in that direction.

 

I didn’t use the final version of the document, as the OASIS workgroup server has been unavailable this morning, and I had no local copy of the document. I’ll review the changing parts when getting access to the server.

 

1. 2.4.1 Type DocumentBaseType

 

1. RefURI / RefType

 

In the RefURI element, we have the text  “This specifies the value for a <ds:Reference> element’s URI attribute when referring to this input document. The RefURI attribute SHOULD be specified; no more than one RefURI attribute may be omitted in a single signing request.”

 

It is implicit in the text that we’re referring to XML signatures, but I suggest making it explicit to avoid confusion. This applies also for the RefType element.

 

2. SchemaRefs

 

                                                               i.      We have the text “The Document is assumed to be valid against the first <Schema> referred to by SchemaRefs” and later “The server MUST use the schemas to identify the ID attributes and MAY also perform complete validation against the schemas”.

 

If we assume that the document is valid against the first schema, it’s difficult to find any practical case (unless the schemas are duplicated) in which we can validate the document against the first schema and also against another schemas included.

 

                                                             ii.      Apart from this topic, how do we handle schema importing via xs:import , we have two cases

·         The ones with no schemaLocation attribute: Imagine the case (it’s common in the practice) of a schema inside the request that imports other schema that is also included in the request (inline importing).

·         The ones with a schemaLocation attribute: To be able to validate, the server should download the schema.

 

I think the two cases should be analyzed to see 1) if we’re supporting them and 2) how to do it. Even if no change is done, maybe some clarification should be added to the text

 

2. 2.5 Element <SignatureObject>
1. dss:SignatureObject and dss:Document asymmetry: Please see my last email with that subject.
2. XMLDSig example: The real DSS example (<SignaturePtr xmlns:ds=”…) is given less importance than the XMLDSig one. I would eliminate the XMLDSig example and put the DSS one in its place.

 

3. 2.6 Element <Result>
1. Error code conventions: some conventions about error codes should be taken, as they’re not symmetric, some examples

                                                              i.      if we look to urn:oasis:names:tc:dss:1.0:resultminor:incorrectSignature and also urn:oasis:names:tc:dss:1.0:resultminor:HasManifestResults we can see that we’re using capital letters for ones and not for another ones)

                                                            ii.      some others use more than one word separed by semicolon urn:oasis:names:tc:dss:1.0:resultminor:inappropriate:signature  instead of, for example, urn:oasis:names:tc:dss:1.0:resultminor:inappropriateSignature

 

4. 2.8.1 Optional Input <ServicePolicy>
1. Can’t obtain applicable service policy: This is an issue similar to the one we’ve found in <VerificationTime>. Before the latest addition, one could assert to the server the verification time, but was impossible to obtain the verification time used by the server. So <VerificationTime> was renamed to <UseVerificationTime> (the use verb reflects the assertive nature of the optional input), and a new optional input/output was added <ReturnVerificationTimeInfo>/<VerificationTimeInfo>, allowing clients to obtain the verification time applied by the server.

 

In this case, we also can’t obtain the applicable service policy. I propose to use the same strategy, refactor the actual <ServicePolicy> to <UseServicePolicy> and add a new optional input / output <ReturnServicePolicyInfo>/<ServicePolicyInfo>

 

2. Sub-policies: As we’ve discussed in the past, although service policies are a very important piece when determining the applicable server policy for the processing, they alone are not fine-grained enough (they are more related to operational conditions of the service than to applicable specific conditions for the signature creation and verification), as we can find some selectable subpolicies within the service policy scope. A common example is a service provider operating under some conditions covered in a service policy, and under that policy, the service allows the clients to select different signature policies to validate signatures against. It’s not only about signature policies, but also other ones like archival policies, cryptographic policies…. My proposal is to refactor the <ServicePolicy> element to fit these optional subpolicies that can further qualify the request sent by the client.

 

Here’s my proposal (note also we can add some URIs for the Type attribute of the AdditionalPolicy element, and, as usual, some other types could be added in the profiles):

 

       <xs:element name="UseServicePolicy" type="UseServicePolicyType"/>

       <xs:complexType name="UseServicePolicyType">

             <xs:sequence>

                    <xs:element name="ServicePolicy" type="xs:anyURI"/>

                    <xs:element name="AdditionalPolicy" minOccurs="0" maxOccurs="unbounded">

                           <xs:complexType>

                                 <xs:simpleContent>

                                        <xs:extension base="xs:anyURI">

                                               <xs:attribute name="Type" type="xs:anyURI"/>

                                        </xs:extension>

                                 </xs:simpleContent>

                           </xs:complexType>

                    </xs:element>

             </xs:sequence>

      </xs:complexType>

 

 

5. 2.8.2 Optional Input <ClaimedIdentity>
1. <ClaimedIdentity> and <RequesterIdentity>: Are these two ways of doing the same? (authenticating the request). If so, I would recommend to keep only one, reducing complexity for the implementers.
2. Examples: Is it possible to add some annex or annexes including how to use <ClaimedIdentity> in several major cases (i.e. signatures, SAML assertions, passwords)?. I think it’s worth the effort for two reasons 1) maximizing practical/technical interoperability (common-case) without restricting to any other ways to do it 2) security considerations that could be analyzed apply for almost any of the former cases (signatures, SAML assertions, passwords). I’ve done some preliminary work in my profiles that could be used as a starting point for discussion.

 

6. 3.2 Element <SignResponse>
1. <SignatureObject>: Typo, replace it’s by its.

 

7. 3.3.4 Process Variant for <Base64Data>
1. Step 1.b: What should be the behaviour when the IncludeObject’s ObjId attribute is present? (also applies for XML input documents)

 

8. 3.4 Basic Processing for CMS Signatures
1. Step 1.b: I don’t understand this text: “This octet stream has to be returned as <TransformedDocument>/<Base64XML>
2. Step 1.b: Revise the wording “For CMS signatures this only has to be returned in the case of CMS signatures…”
3. Step 2.a: Why step 1.c?. Should it be step 1.e?.

 

BTW, can we move the <DocumentHash> references in 3.4 to 3.4.1?.

 

9. 3.5.6 Optional Input <IncludeObject>

 

I see this optional input somewhat confusing and open to interpretation. I suggest some revision to the whole optional input.

 

1. It’s not said explicitly that multiple occurrences for this optional input are allowed.

 

2. createReference:

 

                                                              i.      I see possible collisions with another ways of creating references.

 

1.       When we have a RefURI expression that points to the enveloped document (by means of an appropriate ObjId): In this case, which is the behaviour if we have createReference asserted to true?. Creating two references?.

 

2.       When using <SignedReferences>:  I was assuming that this optional input completely manages the reference creation. But, in this case, we could also have two or more references (the ones included by SignedReferences and other one included by <IncludeObject>). If we want to preserve the priority/exclusivity of <SignedReferences> when managing reference creation, we could add specific wording to solve that issue.

 

3. 3.5.6.1 XML DSig Variant

                                                              i.      Why do we have a XMLDSig variant if the optional input is only for XMLDSig signatures?

                                                            ii.      With respect to the text “This <Document> (or documents) MUST include a “same-document” RefURI attribute … which references the data to be signed”

1.       Under section 3.3 processing rules, this will force the server to create a <ds:Reference> pointing to the enveloped document, then there’s no need for createReference attribute, as we’re always protecting the enveloped document  (and therefore excluding the possibility for the non-protecting case described in the createReference definition).

2.       What happens if the referred document doesn’t have a “same-document” RefURI? (no behaviour / error codes defined).

                                                          iii.      With respect to the text “Clients MUST generate requests in a way that some <ds:Reference>’s URI values actually will reference the <ds:Object> generated by the server once this element will have been included in the <ds:Signature> produced by the server”

1.       What happens with the enveloping-but-not-protecting case?.

2.       Too much responsibility on the client side… my understanding: “okay, as we have many ways to do it, don’t forget to use one”. I think that we should make this easier, and harden the processing rules to avoid ambiguity.

 

10. 3.5.8 Optional Input <SignaturePlacement>
1. In a similar way as <IncludeObject>, we have the concurrence of the <RefURI> attribute and, in this case, the CreateEnvelopedSignature element.

                                                              i.      What happens if RefURI is not RefURI=””?.

                                                            ii.      Can we use <XPathAfter> and <XPathFirstChildOf> at the same time?.

 

11. Compliant implementations

 

Is it planned to add a compliance section for the protocol?

 

 

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