[security-services] RE: Comments on XML signature guidelines draft

[Scott Cantor <cantor.2@osu.edu>]

> I passed this on to my colleague Merlin Hughes, who was 
> involved in the XML DSIG working group. Here are his comments:

Excellent, thanks.

> 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.

Yep, I did, and this was pointed out to me previously. I finally "got
it" after the second re-read. This will be corrected.

> 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.

This was an oversight on my part when I wrote the text, as it was on my
list to document.

> I'm personally not a fan of "" references or mandatory
> XPath expressions. I would seriously suggest considering
> the use of "#id" references.

So would I, but XPath doesn't require a SAML schema change, and #id
does. We simply can't do it in a best practice document for 1.0.

OTOH, there was a proposal by another commenter to simply use the
original XPath transform and the AssertionID/ResponseID/RequestID XML
attributes and reference the generated ID values that the SAML generator
is inserting. They aren't XML ID's, so they can't be used as an XPointer
ID, but they could be used in an XPath transform, or as an XPointer
Reference, for that matter.

> 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.

I think for the time being it's worth including. Some of the other ideas
tossed around are optional parts of the spec, for better or worse.

> 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.

Yes, I see the problem.

> 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.

I think this is worth considering, particularly since it still avoids
the use of the original slow XPath transform. It seems like we have to
either avoid optional pieces of the spec and use the original XPath
transform, or pick which optional piece to use, an XPointer Reference or
an XPath2 Transform.

If we can get a sense of the implementations around and whether XPointer
support is common, that might help decide the question.

Thanks again for the comments.

-- Scott