[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] XMLDSIG and v1.05 comments
I agree on items 1-5 (some of them are REQUIRED). Since no one has commented, I will make these changes. (Comments anyone?) I can see some benefits to item 6 (use of the ds:Signature/Manifest) but I am concerned that it will cause systems not to be Interoperable if some systems do this and some don't. Anyone have thoughts? Regards, David Fischer Drummond Group. P.S. Mr. Burdett, would you mind capturing these in the change DB? -----Original Message----- From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com] Sent: Friday, October 19, 2001 3:44 PM To: 'ebxml-msg@lists.oasis-open.org' Subject: [ebxml-msg] XMLDSIG and v1.05 comments I have some comments and change proposals on Section 4.1.3 Signature Generation 1. Line 1088 suggests that ds:CanonicalizationMethod element is optional in ds:SignedInfo. I don't believe it is true. Section 4.3.1 of XMLDSIG spec [1] states that "CanonicalizationMethod is a required element that specifies the canonicalization algorithm applied to the SignedInfo element...". Therefore, I propose we restate the sentence with a "MUST." Para starting 1090 needs to be rewritten too. 2. I also propose we provide a RECOMMENDED algorithm for CanonicalizationMethod as http://www.w3.org/TR/2001/REC-xml-c14n-20010315 (this one omits comments) e.g., <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> 3. Sentence on line 1100 says that the signature is calculated over the SOAP Header. I would argue that the signature be calculated over SOAP-ENV:Envelope instead of SOAP-ENV:Header. This would include the <eb:Manifest> in the SOAP-ENV:Body. Why is this needed? It is possible that ds:Signature element is eliminated from the message after signature validation is done. Beyond that point, the application would look at eb:Manifest to locate the resources. Therefore, the integrity of eb:Manifest element is important. The change from SOAP Header to SOAP Envelope needs to be made in the whole section. 4. Line 1107 talks about the ds:Transform elements. I propose we add another REQUIRED ds:Transform element <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> for the SOAP Envelope after the "enveloped-signature" transform. This new transform will make sure the SOAP envelope is canonicalized before signed. 5. Line 1120 suggests that URI attribute need not match the manifest reference. I don't know what purpose this serves. I propose we delete "However, this is NOT REQUIRED" 6. Line 1103: The Type attribute is optional according to the spec. Note that if the reference type is not manifest [http://www.w3.org/TR/xmldsig-core/#sec-Manifest] the reference (i.e., payload) is required to be validated as per XMLDSIG. We may want to give more control to the application on validation. Therefore, mention of the manifest Type would be good. The manifest itself is an ds:Object which is an element of ds:Signature. I propose we REQUIRE the type attribute for the Reference element of SOAP Envelope with a value of either http://www.w3.org/2000/09/xmldsig#Object or http://www.w3.org/2000/09/xmldsig#Manifest. ---------------------------------------------------------------------------- ---------------------------------------- [1] XML-Signature Syntax and Processing - W3C Proposed Recommendation http://www.w3.org/TR/xmldsig-core/ Cheers, -Suresh ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC