[OpenID] Tailoring headers to Consumers

[Nate Klingenstein]

Peter,

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.

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.

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.

Glad to have such a close read of my thoughts,
Nate.

On 2 Jun 2008, at 06:14, Peter Williams wrote:

>  Signing requests can be problematic to enable by default
> because it's a relatively expensive, promiscuous operation for the
> server and very cheap for a client, e.g. a DoS risk.
>
>
> Nothing to do with your argument about orcon release policies or  
> discovery, but is the above really valid?
>
> 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!)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080602/531ecde9/attachment-0002.htm>