<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Peter,<div><br></div><div>In TLS/SSL, the client performs the first encryption. To get a signed authentication request with federated identity on port 80, issuance of an HTTP GET is all that's needed. This is a bigger issue with XML than query strings, of course. The numbers I've seen suggest that the risk here isn't significant either way, indeed, but it's still worth mentioning. Since an identity system is critical for so many applications, we should make sure it's solid.</div><div><br></div><div>Another reason we don't use signed requests by default is that it's actually really handy to be able to spoof requests in a lot of cases, e.g. a portal linking into a third party's website with an IdP/OP pre-selected to avoid discovery.</div><div><br></div><div>A third reason is that there isn't much to be gained by signed requests, because spoofed requests aren't really dangerous when there's a key available for encryption and metadata describing the relying party and its trusted endpoints. XRDS would probably be pretty useful here in the OpenID world.</div><div><br></div><div>Glad to have such a close read of my thoughts,</div><div>Nate.</div><div><br></div><div><div><div>On 2 Jun 2008, at 06:14, Peter Williams wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><blockquote dir="ltr" style="margin-right: 0px; "><div dir="ltr"> Signing requests can be problematic to enable by default <span class="Apple-converted-space"> </span><br>because it's a relatively expensive, promiscuous operation for the <span class="Apple-converted-space"> </span><br>server and very cheap for a client, e.g. a DoS risk. </div><div dir="ltr"> </div><div dir="ltr"> </div></blockquote><div dir="ltr">Nothing to do with your argument about orcon release policies or discovery, but is the above really valid?</div><div dir="ltr"> </div><div dir="ltr">In the web generally, we enable SSL clients to sign and propose signed client auth messages everyday. Servers have various remedies, including using appropriate crypto (OAEP) to address the associated cryptanalysis issues facing the secret key, policy (prohibiting acceptance/processing of client auth), and imposing delegated keying ciphersuites (using ephemeral keying applying HSMs easily capable for $100 of doing a ten thousand 1024bit RSA signature verifications a second, for the 100s the ephemeral 1024bit key is in service!)</div></span></blockquote></div><br></div></body></html>