Comments to WD34pre4-set II

[Juan Carlos Cruellas <cruellas@ac.upc.edu>]

Dear all,

As continuation of the message
http://www.oasis-open.org/apps/org/workgroup/dss/email/archives/200508/msg00036.html
sent last Friday August the 26th,
please find below my second set of comments to the
core WD34pre4.


C40. line 815. The sentence should be completed to say that the
client also may set the URI attribute of <ds:Reference>

C41. lines 834-836. At the beginning it is said that step a of
<SignedReferences> processing extends step a of basic processing. But
the text actually introduces a previous step before the step
a ofbasic processing. Would not be better to concatenate these
two steps instead talking of one extending the other?

C42. line 834. The text talls of "the <Document> that has to
be enveloped"... and <SignedReferences> does not deal only with
enveloping signatures, but with other types!. I would propose
to substitute " that has to be enveloped" by "referenced".

C43. lines 837. Should not be better "Applies the transforms
indicated in <ds:Transforms>. Afterwards, the server may apply
any other transform it considers worth according to its policy
for generating a canonicalized octet string as required in ...." instead 
"Add the <ds:Transforms> to
step b"?

C44. line 844. Why the indication "[inserted after i]" does
appear in ii. Usually ii. comes after i. so ....

C45. line 846. I would propose to build a complete sentence with anything
to be indicated written in it, instead of the somehow tricky "[v. will
adapt per definition]".


C46. lines 849-850 Idem C38

C47. line 851. Idem C39.

C48. lines 877-878. The text mentions extracting the XML freeing it from 
ancestors, etc, etc.
Here we find one problem: CMS does not deal with the concept of previous 
transform
to the signature...would not be better to restrict the document to one 
of the two forms
of Base64 so that the server should only to decode to an octet string 
and sign?

C49. lines 882-903. General comment: to re-write it adequating text to 
the actual
different types of <Document> that can be present in the request, ie, 
not mentioning
<XMLData>...

C50. lines 905-927. Idem as C49.


VERIFYING PROTOCOL.

C51.Section 4.3, lines 1075-1121. Adequate text to the currently defined 
types
of <Document>.

C52 line 1085 talks about a <SignaturePtr> pointing to a <Base64> 
document, ie,
a <Base64> containing a Base-64 encoded document envelopning a XML 
signature.
Is this a case that we would like to give support to?

C53. lines 1110-1111. The text seems to me an inheritance of the 
previous versions,
when we allowed to the client to perform certain transforms and the 
server other
transforms, this is why the text "the server applies any transforms 
specified by the
<ds:Reference> that have not already been applied to the input document" 
does appear.
BTW, this is a question: we have been talking of transforms at the 
client and the server
and arrived to some conclusions for the signing protocol. Do these 
conclusions
apply to the verifying protocol? My initial guess would be that yes, 
they should
apply...do we need to think more carefully about that?

C54. linr 1109. I think that the text "If the input document is a
<Document> or an XML element" could lead to confusion. This "input
document" is one of the <InputDocuments> in the request? If so,
the distinction between <Document> and XML element does not make sense.
If the "input document" actually means "signed data object" then the
distinction makes sense, but, why do not call it "signed data object"?

C55. line 1124. Bad reference. It should be "section 4.3 step 1".

C56. lines 1151-1155. This text brings to my mind a more general question:
do we really intend that clients insert in the request the indication of
the transforms that the input documens suffer before being signed? Is this
the kind of more frequent situation that we envisage? I would say that
clients of this service will get a signature, a document and they would
like to almost blindly to put the signature in one place of the request,
the document in another place of the request, send it to the server and
get the answer...whatever the transforms suffered by the document will
have been....

C57. lines 1368-1369. One question, the equality of the hash mentioned
in these lines, does it imply that canonicalization is mandatory for XML?
If so, maybe it would be worth to mention it.

C58. line 1401. Already mentioned in the conf call: substitute "ref" by
"type".



Regards

Juan Carlos.