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

[Trevor Perrin <trevp@trevp.net>]

Hi Frederick,

Thanks for the comments.  Reponses inline.


At 10:32 AM 2/7/2004 -0500, Frederick.Hirsch@nokia.com wrote:

>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

We've switched to URIs for everything except Properties.  I thought we 
could leave those as QNames, because for XML-DSIG signatures, the 
properties *are* XML Elements.  For example, if you wanted to add an 
<xades:SigningTime>, or <xades:SignaturePolicyIdentifier>, those would be 
easy to represent with QNames.

The W3C document on QNames as Identifiers gives some support to using 
QNames this way:
http://www.w3.org/2001/tag/doc/qnameids-2004-01-06
"In attribute values and element content, QNames are often used to identify 
a particular element type; they are, in principle, using QNames as they 
were intended."

We could add the text "A namespace prefix MUST be provided", to make 
processing a little easier.

Given this rationale, do you think it's okay to stick with QNames?


>
>  (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.

We were using URLs, but switched because there appeared to be an OASIS 
convention for forming URNs (followed by SAML and XACML for example), but 
not a convention for URLs.

I guess that's changed?  Could you give a pointer on how we should form the 
URL?



>(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...)

I was sorta trying to make that section fit on one page; otherwise we get a 
mostly blank page.  We could do this, I'm just not sure if it's worth 
it.  The latter 2 sections would be tiny.


>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. )

OK, though I think we should use "confidentiality" instead of "privacy".

>
>  Change line 190 from "data to use in verifying" to:
>
>  data necessary to verify the signature (such as certificates and
>CRLs)...

OK.


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

The schema definitions are shorter the way it is (26 vs. 33 lines).  But if 
you think that would be clearer, we can do that.


>(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."

OK.  Though I'd split that into 2 sentences (change comma to period).



>(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. "

OK.

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

Like what?



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

<SignaturePtr> is only used in a <VerifyRequest>, where you're sending an 
input document that contains a signature.  This accomplishes 2 things (the 
2nd is more important):
  - avoids the overhead of sending the signature twice
  - gives the server the information needed to "delete" the signature from 
the input document, if an enveloped-signature-transform is used.

I think having the client fetch the signature through a URI is unnecessary 
and a little risky.  What's the rationale for this?  If it's to allowed 
delayed retrieval of the signature, I think it would be better to build 
that into the protocol.



>(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)

OK.


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

It takes a fixed number of values, and is non-extensible, so a string is 
shorter, i.e:
"Success", instead of:
"urn:oasis:names:tc:dss:1.0:result:major:Success"



>(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

OK.


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

Is this in reference to the ServerProfile / ServicePolicy URIs?  If so, I 
think we should stick with URIs.


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

OK.


>(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?

The <SignaturePtr> has a limited purpose - just to point to a signature in 
the VerifyRequest input documents.

The SignResponse won't contain output documents, unless the 
<SignaturePlacement>/<OutputDocument> option in 3.4.7 is being used.  Even 
then, the efficiency gain of not sending the signature twice probably isn't 
worth the complexity of requiring the client to evaluate an XPath to get 
the signature.  Though in this case the client may not want the 
signature.  So we could relax this requirement, though I'm also fine with 
leaving it as is.


>(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."

OK.

>(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.

Right.  It's just informative, it might help the server make 
decisions.  Could we make that clearer?


>(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?

Hmm.. Probably the best way to do this is just say step 2. of Basic 
Processing is overridden, and specify an entirely new step 2 that replaces 
it.  I'll do that in the next version.


>  Is a mixture of SignedReferences and non-SignedReferences possible?

No - <SignedReferences> overrides the default behavior where it forms one 
reference for each input document.



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

That's the default, so I think we can leave as-is.


>(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.

OK.


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

OK.


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

I don't know which way is easier.  Input Documents might be large, though, 
so if we keep them at the end the rest of the request message is more readable.


>(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?

Sorry, I don't understand.  In step 3, the server just performs reference 
validation of a <ds:Reference> by checking that it matches some 
<DocumentHash>.  What exactly is the problem?



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

Good point, I'll move them.


>(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

It was purposefully phrased to allow a new signature to be created.  The 
people who wanted this option wanted this (I believe Juan Carlos, for example).



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

Right now the client can only see the result of applying all the transforms 
in a particular <ds:Reference>.  I.e., the client can see what was 
signed.  I think more flexibility wouldn't be worth the effort.


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

I think order is guaranteed - the order of <ds:Reference> elements in a 
signature can't change without invalidating the signature.  An index is 
simpler than XPath.



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

I don't think that's necessary, the client will have unambiguously 
indicated which Transform(s) he wants applied.



>(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?

No.  The XMLTimeStampToken might be embedded in a larger document, and 
URI="" would have the signature cover that larger document.  We don't want 
that.  We just want to reference the enveloped <TstInfo> element.  We could 
do that through an ID reference, but then we have to worry a little about 
ID collisions, so it seems easiest to just omit the URI and let this be 
implied by application context.



>(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.

The CreationTime needs to be filled in before the signature process is 
started, so I think the text is okay.



>(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

OK.



>(28) Draft 11 is missing revision history entry

oops..


Trevor