[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Comments on XML signature guidelines draft
> From: Scott Cantor [mailto:email@example.com] > Sent: Sunday, September 22, 2002 9:02 PM > Subject: [security-services] XML signature guidelines draft (see http://lists.oasis-open.org/archives/security-services/200209/msg00026.html) I passed this on to my colleague Merlin Hughes, who was involved in the XML DSIG working group. Here are his comments: Hi Irving, I think he misunderstands the SignedInfo CanonicalizationMethod; it appears that he is suggesting it applies to all references: it does not, it only applies to canonicalization of the SignedInfo element. If he wishes to recommend the use of exclusive c14n, then it should be used BOTH as the SignedInfo CanonicalizationMethod AND as a Reference Transform. I think if he is mandating the use of exclusive c14n he should include a note to the effect that any namespace prefixes used as character content MUST be included on the Unsuppressed Namespace Prefix list. In particular, he is recommending use of XPath expressions that reference the samlp prefix but he is not mandating that a definition of that prefix be included; this is dangerous: There will be no signed binding of the samlp prefix within the SignedInfo. I'm personally not a fan of "" references or mandatory XPath expressions. I would seriously suggest considering the use of "#id" references. They are faster to process and more intuitive; the main problem is ID value clashes within a document. Alternatively, it might to worthwhile considering XPointer references of the form: "#xmlns(samlp=...)xpointer(ancestor::samlp::XXX)". Although this is ugly, it is more declarative (I am Referencing XXX) and can easily be optimized by processors that recognize the SAML-recommended URI format. It is only an optional part of the XMLDSIG spec, however, so probably can't be used. 4.2 - node set comparisons - this can't be performed if exclusive c14n is recommended; the output of the transform chain will always be an octet stream; not a node set. For that reason, 4.1 and 4.3 are the only viable options. 4.3 is a fine idea; however for it to be effective, this document would have to nail down the _exact_ text to use in the XPath transforms (i.e., whitespace and prefixes). This is why I prefer the XPointer option; you can verify that 1) the XPointer dereferences to the desired element, and 2) that the following transforms are enveloped signature and then exclusive c14n. This is very easy to verify. However, it is also critical to ensure that any necessary non-visibly-utilized namespaces are included in the unsuppressed namespace prefix list. Hope this makes sense.. Merlin ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept for Content Security threats, including computer viruses. http://www.baltimore.com This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses.
Powered by eList eXpress LLC