Comments on Core Draft 11, 3 Feb 04 (long, resend)

[<Frederick.Hirsch@nokia.com>]

Comments and proposals for Draft 11 of DSS Core, 3 Feb 04.

Line numbers refer to pdf:
http://www.oasis-open.org/apps/org/workgroup/dss/download.php/5292/oasis-dss-1.0-core-spec-wd-11.pdf

(1). I propose we switch from QNames to URLs for consistency and to
avoid various known issues with QNames used as values (e.g.
canonicalization if signed)

 Properties/Identifier, section 3.4.6, line 685-7, schema line 713
 Change from QName to anyURI
 
 (2) I propose we use URL(s) for the dss namespace(s). This has the
advantage that optionally the schema can be retrieved from the URL.
OASIS is defining a standard for defining such persistent URLs, other
TCs like WSS have adopted this approach. 

(3) Editorial comments on overview (section 1.3, line 163)

Might help reader to add subsections:
1.3.1 Signing and Verifying Protocol (before line 163)
1.3.2 XML TimestampToken (break line 197, before First...)
1.3.3 RequesterIdentity XML Element (break line 199, before Second...) 

Update line 180:
bandwidth and protect the privacy of the document content.

(The input documents to be signed or verified can be transferred in
their entirety, or the client can hash the documents itself and only
send the hash values, to save bandwidth and protect the privacy of the
document content. )
 
 Change line 190 from "data to use in verifying" to:
 
 data necessary to verify the signature (such as certificates and
CRLs)...

(4) Since Document and DocumentHash share common document structure, it
might make sense to derive them from a common type, something like
follows:

<xs:complexType name="DocumentBaseType" abstract="true">
        <xs:sequence>
            <xs:element ref="ds:Transforms" minOccurs="0"/> 
        </xs:sequence>
        <xs:attribute name="ID" type="xs:ID" use="optional"/>
        <xs:attribute name="RefURI" type="xs:anyURI" use="optional"/>
        <xs:attribute name="RefType" type="xs:anyURI" use="optional"/>
    </xs:complexType>
</xs:element>

<xs:element name="Document" type="DocumentType" />
<xs:complexType name="DocumentType">
  <xs:complexContent>
    <xs:extension base="DocumentBaseType">
      <xs:choice>
        <xs:element ref="dss:XMLData"/>
        <xs:element ref="dss:Base64Data"/>
      </xs:choice>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>


<xs:element name="DocumentHash" type="DocumentHashType" />
<xs:complexType name="DocumentHashType">
  <xs:complexContent>
    <xs:extension base="DocumentBaseType">
      <xs:sequence>
        <xs:element ref="ds:DigestMethod"/>
        <xs:element ref="ds:DigestValue"/>
      </xs:sequence>
     </xs:extension>
  </xs:complexContent>
</xs:complexType>

(5) Add text to RefURI definition, line 272:
 
 "The RefURI attribute SHOULD be specified, no more than one RefURI
attribute may be omitted in a single signing request."

(6) Add clarification to Document element description before line 291:

"The document hash for signing is created from the element content of
XMLData (i.e. the <XMLData> tags are not included), or from the content
of the <Base64Data> element after it is base64 decoded. "

(yes this reinforces the processing rules here for the reader)

Do we need to say something about spaces in the XMLData element content?

(7) Why can't a SignaturePtr point outside the document and hence have
type anyURI instead of IDREF?
(Schema, line 390)

(8) Editorial - it may make sense to put the non-optional result section
before the optional input sections (e.g 2.8 before 2.6)

(9) Why is resultMajor a string instead of a URI? Seems URI would be
consistent with minorCode and better defined? (schema, line 462)

(10) Editorial
section 2.7.1 ine 428, replace "the client thinks he does" with "the
client expects"

section 2.7.2, same change, line 435

(11) Does it ever make sense to include an embedded policy statement
rather than a policy URI? Probably not.

(12) Editorial, 2.7.3 ClaimedIdentity, change "MUST further" to "MUST"

(13) SignResponse, line 525 section 3.2
Why must a SignResponse not include a SignaturePointer? If such a
pointer used a URI then the client could retrieve the signature later
from a server via HTTPS GET and the URI?

(14) Add to processing rule step 2a at end, line 562:

"A signature MUST NOT be created if more than one RefURI is omitted in
the set of input documents."

(this is explicit in ds:Signature rules, but probably worth making
explicit here)

(15) IntendedAudience, section 3.4.3 line 611

Presumably this does not have the same meaning as a SAML
AudienceRestriction, ie. the signature may be passed to other audiences
later.

(16) SignedReferences processing rule implication is not clear
At 3.4.5 line 638-640, this is not clear. Which second step is referred
to? Is a mixture of SignedReferences and non-SignedReferences possible?

(17) Properties, Value. Can a Property have more than one Value?
Should schema have maxOccurs="1" (line 715)

(18) Editorial, VerifyRequest, section 4.1, line 771

remove "(i.e. deleting the signature)" - the signature isn't actually
deleted, but the signature processing rules must exclude the signature -
this parenthetical might make it more confusing.

(19) Editorial, line 773, replace "A list of" with "The"

(20) Would it make processing of SignaturePtrs easier if InputDocuments
were first in VerifyRequests?

If so, move InputDocuments element first in schema sequence, lines
777-779

(21) Basic Processing, step 3, line 815, it isn't clear how the
transform verification will work if some transforms are added
transparently by a signing server. If the verification is done at a
different server with different rules, how are transforms known other
than trusting the list?

(22) Why aren't ReturnTimestampTime and Output TimestampTime defined in
the Timestamp profile instead of core? Sec 4.5.6, line 971

(23) Clarify that a signature may only be updated by adding unsigned
attributes. Otherwise a new signature must be created to apply the key
to changed content. Section 4.5.8, line 991

(24) Transformed Document line 4.5.9
Might a client want to see the result of applying combinations (1 or
more of the transforms)?

Is use of an index fragile for references - is order always guaranteed?
Should XPath be considered?

Should the result include the Transform(s) used, to confirm correctness
of operation?

(25) 5.1.1 , line 1081, XMLTimeStampToken
Shouldn't Reference for "this document" contain "" for URI? This would
Sign entire XMLTimeStampToken, excluding enveloped signature. Is this
what is wanted and being said here? 

(26), Creation Time ins section 5.1.2, line 1099

Shouldn't we replace "was started" with "completed". Ie time is from
when entire request has been received (effective start) until entire
operation done.

(27) SAML reference should be updated to SAML 1.1, line 1355
http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-
bindings-1.1.pdf


(28) Draft 11 is missing revision history entry

regards,

Frederick

Frederick Hirsch
Nokia