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

[=JeffH <Jeff.Hodges@neustar.biz>]

sampo@symlabs.com wrote:
 > In recent interop testing we have found several points worth clarifying.

excellent, thanks for the feedback.


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

good point...   or... hm, does it really matter? What you feed in as the value 
of the "SAMLRequest=value"/"SAMLResponse=value" construct assembled in step 2 
of section 2.5, is just going to get extracted and validated on the other end, 
as a string of bytes -- so does it matter?


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

again, does it matter?


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

Ah, clarify this in other words? I guess we assumed since the macroscopic 
encoding is XML that that spec would address any byte-level encoding questions.



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

rationale for explicitly excluding it?  What one is signing is just a string of 
octets...



 > 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

hm...

oh, ok, I think i get what you're asking, good question.

AFAIK, it doesn't really matter which we choose from a protocol standpoint. Is 
there an implementation reason to prefer one over the other?

And does it really matter? In that if one is decoding a message signed&bound 
according to this spec, they can just look at the SigAlg value and "tell" by 
inspection which encoding was employed. yes?



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

ok, so this obviously isn't clear in the spec because otherwise you wouldn't 
have this question.

Our intent is that "...RelayState=value..." is _optional_ in the octet string 
that is constructed in step 2, and subsequently fed into  the signature 
function in step 3 of section 2.5.

Can you suggest a way it can be clarified?


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

ok. can you pls provide an example?


=JeffH