Re: ACTION-37: Write up scenario for simple sign

It seems like exclusive c14n is only used to avoid namespace leakage 
issues (since you don't need c14n at all in the simple-sign case). I 
wonder if a simplified c14n algorithm that just avoided namespace 
leakage would help.

Thanks,
Sean

Scott Cantor wrote:
> I offered to provide some background on this use case.
> 
> First, a basic description of the spec. SAML defines a number of "bindings"
> that describe how to send XML messages from one place to another. In the
> base standard, the bindings rely on XML Signature for signing messages. The
> signatures live inside the XML messages being signed (enveloped signatures).
> Exclusive c14n is a major requirement there for all the usual reasons. The
> result is that very few languages support the creation or verification of
> signed messages. This is a huge problem and most people using such languages
> gave up on SAML (if they ever looked at it) as a result.
> 
> To fix this, we took advantage of the reliance on HTTP form post as one of
> the main binding "transports", and defined a much simpler mechanism for
> signing a message in which the signature is outside the message, and the XML
> is signed as literal text. In XMLSig terms, this would be a detached
> signature, but:
> 
> - there's no means of referencing the text in an HTML form element so that
> the usual detached XML signature Reference sytax would work
> 
> - there's no partcular value in representing the signature itself as XML
> anyway
> 
> So, the algorithm identifier (which is copied from XML Signature for
> convenience) is concatenated with the XML (as a string) to produce the input
> to the digest, and the signature value and the algorithm are passed as
> separate form elements.
> 
> Abstracting out the requirements, I would say the following:
> 
> The Signature need not be inside the document (detached).
> 
> The message transmission medium allows for the message and the signature
> (and algorithm, etc.) to be packaged together. In this particular use case,
> the medium is an HTML form with the browser being manipulated to submit it,
> which precludes S/MIME.
> 
> Creating and verifying the signature don't require XML processing, let alone
> c14n or transforms, so any language able to handle the cryptography can be
> used.
> 
> As I said in another thread, I'm inclined to view this as a special case in
> which S/MIME would probably be the right solution but isn't usable in this
> particular situation.
> 
> -- Scott
> 
> 
>

Received on Tuesday, 26 August 2008 13:18:07 UTC