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


The main theme of your response seems to be that most things
are obvious for you and therefore no clarification or calling out
is warranted.

Problem is that the SAML newbies that are likely to be attracted
by something containing word "Simple" may not find it as obvious.
We would be doing a service to them and adoption of this spec
if we called out any and all points of potential misunderstanding
we can imagine.

There is no need to respecify - it is sufficient to say something
non-normative to give heads up for a novice implementor and then
provide a pointer to the spec where it is specified.

As far as I understand, there is no intent to publish any implementation
guidelines - thus this material should go to the spec itself.

Cheers,
--Sampo

Ari Kermaier wrote:
> 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.
>
> ::Ari
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>




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