OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

sampo@symlabs.com wrote:
> 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.

This seems unnecessary to me. The spec does not define the processing rules to say that whitespace inside the XML must be preserved, but rather just elucidates the fact that base64-encoding the whole octet string results in preservation of all internal whitespace for purposes of later signature verification. Since the value of the SAMLRequest (or SAMLResponse) parameter is a SAML protocol message, it's pretty clear to me that only the message, and not any arbitrary octets surrounding it, is the proper input.

Additionally, while a sender that adds leading whitespace to the SAML message before signing may be doing something ill-advised, there's no reason for a recipient to do any sort of trimming before validating the signature. That would entail manipulating the interal content of the octet string input to the signature algorithm; I can't imagine how that would happen.

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

This is a matter of how SAML messages are emitted as XML surface strings, which is generic to all SAML communication, and should not be separately (re)specified in a binding specification. In any event, why should this matter? The SAML message and any surrounding XML or non-XML content is treated as an opaque octet string value internal to the concatenated parameters used as input to the signature algorithm. It's semantic meaning or subsequent parse-ability is generic to SAML, and is irrespective of transport binding/encoding.

> 3. A stance should be taken on use of UTF-8 encoding (presumably
>    this is the only encoding allowed by the binding).

See comment on 2. above.

> 4. A stance should be taken on the UTF byte order mark (BOM). I think
>    it should be outlawed.

See comment on 2. above.

> 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. All the parameters get URL-encoded as part of the browser POST processing; there's no reason to explicitly encode it before insertion into the form. (This question would, of course, apply to the RelayState value as well.) In any event, since the spec does not specify an explicit URL-encoding step (or a DER-encoding step, for that matter) there's no reason to suspect that one might be possible.

> 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
>    My reading of the spec as it stands is that in both cases
>    the material that is signed will be
>      SAMLResponse=...&RelayState=&SigAlg=...
>    I.e. the RelayState= label is present in the signature in
>    all cases irrespective of whether the RelayState was supplied
>    in the request.

This is something that should probably be specified in the same manner it was for the original POST binding.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]