[security-services] Comments on XML signature guidelines draft

[Irving Reid <Irving.Reid@baltimore.com>]

> From: Scott Cantor [mailto:cantor.2@osu.edu]
> 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[1])".  Although
this is ugly, it is more declarative (I am Referencing XXX[1])
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.