ACTION-37: Write up scenario for simple sign

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 Saturday, 23 August 2008 19:02:24 UTC