On dispositions to comments.

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

Dear Ernst Jan.

I have gone through the proposed dispositions to comments on the local signature profile. I would have liked to be able to send this before, but it has been impossible. Please find my comments below:

TAB-829: restates an element definition from the schema. 
-->My Comment: maybe it would be worth, in addition, to your reply,  to consider to introduce upfront in the document that all the xml schema definitions present within the document are copy of the XML schema file and must be considered as informative text, and that in case of discrepancy, definitions within the XML schema prevail.


TAB-827: I have the impression by its mention to the error and the question whether the SignatureObject may contain an error indication, that he has not noticed that the dss:SignResponse extends dss:ResponseBaseType...
---> My comment: maybe in the disposition we could clarify that the dss:SignResponse extends the dss:ResponseBaseType (clause 2.11 in the Core) which may include, among other things, an error indication; in consequence, the dss:SignResponse may, if needed, include the error indication within this inherited element. Additionally, as shown in the XML schema the SignatureObject is optional.

TA-823: Mmmmm... Maybe I have completelly missunderstood the concept that the document tries to define but I would say that the problems of interoperability that the comment signals do not exist. If I have correctly understood, the digital signature vale is, within a XML Sig, the contents of the ds:SignatureValue element, and within CMS, the content of the signature field. Now, to me it is pretty clear that within those elements/fields NOT ONLY PKCS#1 structures may appear...what about the eliptic curves-derived structures? (see RFC 3278 that specifies how to use Elliptic Curve Cryptography within CMS: its clause 8.2 defines an ASN.1 structure whose DER encoding is the actual content of the signature field!)... so I am not sure that both the comment and the reaction restricting the signature value to PKCS#1 are right.

If I am right, I would propose to reject his comment, explaining what I have mentioned above, and maybe improving the text of the definition by making mention to what we are dealing with: the contents of the ds:SignatureValue or the contents of the CMS's signature field....


TA-818. Looking to the document after reading this comment, I noticed something:

Clause 5.4.1.2 Level 2, is a sub-clause of 5.4.1 Conformance Target:Server. In clause 5.4.1.2 I read: "The request from thje client MUST contain the element <localsig:ResponseCode>".... wouldn't this go within clause 5.4.2.2, the peer sub-clause for the client?


Hope this helps Ernst-Jan

Regards

Juan Carlos.