DSS Core comments

[<Frederick.Hirsch@nokia.com>]

Trevor,

Here are some additional questions and comments on Draft 7 of the core protocol , 25 Nov 03, referenced by
line number:

Section 1, line 118.
Generally a profile restricts a specification, perhaps this line should be rephrased:

"The core protocols may also be profiled to constrain optional features and define extension points."

Section 1.1, lines 133-140

We may want to add that the prefixes are not normative, only the namespaces to which they refer and that a change of namespace URI will be required if there are significant changes to the processing rules.

Section 1.3

Even though this will be revised, should we change QNames to URIs at line 188

 

Section 2.4.1

Should ID be required?

 

Section 2.4.2

[271] Add clarifying sentence:

The element content of <XMLData> or <Base64Data>, including all whitespace, is the input to the signature reference hash function - this surrounding element is not included.

 

Section 2.5

[325, 326] Rename element Signature to be "SignatureObject"

I think Signature is too close to ds:Signature, to lead to confusion

 

[371] should XPath have "use="optional" in the schema definition? (this change also applies to the schema document)

 

Section 2.6

Agree with Nick on OptionalOutputs

[376-377] Maybe rephrase to 

 "The <OptionalInputs> element contains options associated with the processing of the request.", since the options may affect processing or what is returned, and not just refine the input.

 

[386] Do we want to define OptionalInputs and OptionalOutputs using a Sequence of dss:AnyType, since the text says it is a sequence of one or more Input or Output items?

 

Section 2.7 [390] Does discussion of URI vs QName apply to results? (Could a result be signed and a QName value cause canonicalization issues?)

 

Section 3

[430] This section is focused on XML Signature (e.g processing rules), yet the request could be to create a CMS signature, for example.

Should we define a signature type SignRequest attribute with default for xml signature (type anyURI, e.g http://www.w3.org/2000/09/xmldsig)?

Not an option, because it is basic to the core processing rules? (this is alternative placement versus 3.4.4 option SignatureType)

 

Section 3.1, [437] typo, "A list..."

 

Section 3.3

[482] Rephrase step 1 suggestion:

1. The server either hashes the element content of each <XMLData> or <Base64Data> element contained within a <Document> element, or copies the hash conveyed in the element content of a <DocumentHash> element contained within a <Document> element. All whitespace is preserved.

 

[485] ] I suggest we add a sentence before step 3:

At this point the server creates an XML Digital Signature using the References created in Step 2, according to the processing rules in the XML Digital Signature recommendation. This is briefly outlined as follows, but the normative reference is XML Dsig:

 

Section 3.3.2

[496] Add a sentence, "When the server creates an enveloped signature, the ds:Reference MUST/SHOULD have a URI with value "". The EnvelopedSignatureTransform is not required, but may be used

 

Section 3.4.5

[527] Does this mean that an <ds:Object><ds:SignatureProperties><dss:Timestamp> is added to an XML Sig? Should be clear what it means to add a timestamp.

 

Section 3.4.6

[537] Should we reuse saml:AudienceRestrictionConditionType for IntendedAudience ?

Having the time constraint seems useful (notbefore, notonorafter) for relying on the signature by this audience, using URI to specify relying party

 

Section 3.4.7

[550] why isn't the schema  simply <xs:element name="KeySelector" type="ds:KeyInfoType" /> ?

 

Section 3.4.8

[558] I do not understand SignedReferences - should this say that it supports applying additional transforms to Reference creation in step 2?

It doesn't seem to specify the RefURI or RefType so cannot replace processing step 2

 

Section 3.4.9

[598] Should property identifiers be URIs instead of QNames? (also schema document and line [622]

 

Section 3.4.10

[634] Add sentence, if correct:

"  The signature is placed immediately after the closing element of the specified element. "

 

Section 4

Similar comment about bringing signature type up to attribute on VerifyRequest

 

Section 4.2

As Nick noted in SignRequest, [706] rename Outputs to  OptionalOutputs

 

Section 4.3

[728] Step 2 applies to References within SignedInfo, perhaps word

"For each <ds:Reference> within <ds:SignedInfo> in the <ds:Signature>, the server finds..."

 

Indicate Manifest reference hash checking is not performed by default, and only is if option VerifyManifests is present (refer to 4.5.5)

 

Section 4.5

 

I think that options that are common to both requests and responses should be in a single section, so we don't duplicate them and possibly introduce

inconsistencies (e.g. ServiceProfile, ServicePolicy, ClaimedIdentity) - e.g. add section 2.8, Common Options

 

Section 4.5.4

At first glance this IgnoreMissingInputDocuments option appears to be inconsistent with XML Dsig processing rules which require ds:SignedInfo ds:Reference checking, but may be ok if distributed processing shared with the client is assumed. In that case perhaps the client should explicitly signal which references it has checked. Even so, this is a security threat, since any document change would be undetected without hash verification for the document the relying party is examining.

 

I propose we eliminate this option since Manifests cover this purpose and avoid these ambiguities and risks, or at least making it clear within the signature that Manifest processing rules are being followed.

 

Section 4.5.8

Should we diverge from XKMS and use URIs instead of QNames

 

Section 4.5.9

What does it mean to rely upon signing time? Does this mean the entire response MUST be signed by the server?

 

Section 4.5.11

I'm having trouble with this wording. Does this mean what is returned is a new signature, with the same information as the original signature, potentially with some additional ds:References, thus providing "signature refresh"? If not a new signature, I don't see how the signature can be securely updated without breaking verification.

 

Section 5.3

Perhaps rephrase:

"Using ds:SignatureType allows conventional digital signature implementations to validate the signature, but additional processing is required to validate

the timestamp properties "(TstInfo, steps 6-9,11 in processing rules 5.6)

 

Section 7.1

We might want to make this URN consistent with Oasis conventions, (e.g. what WSS is proposing?)

 

Section 7.1.1

[1054] Should URI be urn:oasis:names:tc:dss:1.0:name-format:unspecified (e.g. was dss missing?)

 

Section 9.1

Seem to be extra years at [1138], [1141], [1142]?

regards, Frederick

Frederick Hirsch
Nokia Mobile Phones