RE: [security-services] Simple Sign not so simple

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

> 1. Spec says that whitespace inside the XML is preserved. It would
>    be helpful to mention that whitespace before and after the
>    XML should also be preserved. Or else forbid the leading and
>    trailing whitespace.
> 
> 2. It would be worth mentioning that in addition to the XML document,
>    also the processing instructions, etc. need to be preserved. Or
>    else forbid the <?xml ...> preamble.
> 
> 3. A stance should be taken on use of UTF-8 encoding (presumably
>    this is the only encoding allowed by the binding).
> 
> 4. A stance should be taken on the UTF byte order mark (BOM). I think
>    it should be outlawed.

So, from my perspective (and I'll say up front the BOM issue is beyond my
scope of immediate knowledge), this misunderstands the intent of the spec,
so I would say the errata/change needed is to clarify that what you're
feeding into the digest is exactly the result of base64-decoding the XML.
That's it.

I don't care about whitespace, the XML decl, a DTD, etc. In openssl
parlance:

openssl base64 -d | openssl sha1

ANYTHING you happened to include in the initial base64 operation to encode
it for transport is what you're signing. And the XML encoding is really
orthogonal because base64 isn't aware of that distinction. It's just octets.

If there's some particular implementation issue that makes that a problem, I
didn't run into it, but maybe there is.

> 5. Is the SigAlg included in the signed data in URL encoded form
>    or not, i.e.
> 
>      SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1
> 
>    or
> 
>      SigAlg=http://www.w3.org/2000/09/xmldsig#rsa-sha1

The latter. It's a form POST, and generally speaking what you have access to
in an SP written in something like PHP is going to be the decoded form
variable. That was the intent anyway.

> 6. Handling of following special cases should be clarified
>    a. Response to request that had empty, but present, RelayState.
>    b. Response to request that had no RelayState

Same as the old redirect binding, it's omitted. We can certainly repeat that
text from the original binding.

>    I.e. the RelayState= label is present in the signature in
>    all cases irrespective of whether the RelayState was supplied
>    in the request.

Nope.
 
> 7. For debugging and also clarification of the material to be signed,
>    the example should have additional section that shows the material
>    that was signed.

Providing and example solves this problem. Asking for them is less favorably
viewed.

-- Scott