[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: > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]