[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: More on EnvelopingSignature
Dear all, Concerning our previous email, and after looking at the request and thinking further,we would say that, as there is not in the request any ObjId in the EnvelopingSignature optional input,and there is not any Id in the enveloped xml data, the request is not correctly built and the server would generate a signature whose verification would fail. Requester's responsability.... But the issue on the description of the processing is still remaining. If the request is: <dss:SignRequest xmlns:dss="http://www.docs.oasis-open.org/dss/2004/06/oasis-dss-1.0-core-schema-wd-30.xsd"; RequestID="UPCRequestEnvelopingXMLSig_0"> <dss:OptionalInputs> <dss:SignatureType>urn:ietf:rfc:3275</dss:SignatureType> <dss:EnvelopingSignature WhichDocument="BinaryDocId0" ObjId="data"/> </dss:OptionalInputs> <dss:InputDocuments> <dss:Document ID="BinaryDocId0" RefURI="#data"> <dss:XMLData> <upc1:Root xmlns:upc1="http://www.ac.upc.edu/namespaces/ns1"; xmlns:upc2="http://www.ac.upc.edu/namespaces/ns2";> <upc1:Child1 xml:lang="EN">child1 content</upc1:Child1> <upc2:Child2> <upc1:Child21>child21 content</upc1:Child21> <upc1:Child22>child22 content</upc1:Child22> </upc2:Child2> <upc2:Child3> <upc2:Child31>child31 content</upc2:Child31> <upc2:Child32>child32 content</upc2:Child32> </upc2:Child3> </upc1:Root> </dss:XMLData> </dss:Document> </dss:InputDocuments> </dss:SignRequest> Then the server is instructed to add the Id attribute to ds:Object. In this case, in order the verification be successfull, the server has to digest the whole canonicalized ds:Object, not only the xmldata contents....and this process is not indicated anywhere in the core text..... Going a bit further, we could have three general cases....The list below explains them and gives indications of what we think that the server could do in each case. We asume in all of them that the to-be-enveloped input document contains a RefURI....if not, things are per-application based (as indicated in XMLDSIG). 1. EnvelopingSignature without ObjId, NO SignedReferences with Transformations, No transformations indication in the input document: ---> If the input document is a XMLData and it contains an Id that matches the RefURI, the server should only process (canonicalize and digest) the contenst of the element with the Id for generating a valid signature!!. Difficulties for the server, unless the Id is in the root node of the input document....If not Id is present in the document there is no way of generating a valid signature: Requester's responsability.... What about banning this request? 2. EnvelopingSignature with ObjId and NO SignedReferences with transformations AND NO transforms indication in the input document. ---> For generating a valid signature the server SHOULD PROCESS (canonicalize and digest in this case) the whole ds:Object (Not indicated in the core: need for modification?) 3.EnvelopingSignature with or without ObjId AND some transformations within the inputdocument or within SignedReferences. --->The server will process THE INPUT DOCUMENT as indicated in the section corresponding to processing, and the client will be responsible for ensuring that the corresponding RefURI/Id pair and the transforms indicated and/or requested combine so that the built signature may be successfuly verified....Again, it is client's responsability. Do you agree with the summary of the 3 different cases? and what do you think of the server's behaviour that we describe for them? Regards Sergi and Juan Carlos.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]