Re: Client requesting authentication on server & thomson-httpbis-catch

["[e-mail]" <[e-mail]>]

On 21 Mar 2014, at 02:12, Mark Nottingham <[e-mail]> wrote:

> 
> On 20 Mar 2014, at 1:42 am, [e-mail] wrote:
> 
>> So presumably here one could extend the current client "Authorization" header to 
>> something like 
>> 
>>  Authorization: Certificate
>> 
>> So I see that new schemes can be registered at
>> 
>>  http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-26#section-5.1.2
>>  https://www.ietf.org/rfc/rfc2617.txt
>> 
>> This does require server side TLS renegotiation to work, but that's where we are at
>> present.
> 
> I think this makes the most sense, in that then you could send
> 
> Vary: Authorization
> 
> to indicate that the response varies based upon that header.
> Might be good to put a hash of the cert into the header...

In current popular browsers it is not possible for JS to access the certificates in the keystore, or to
calculate their hashes. [1] This would be possible for web crawlers though ( since those can be programmed to
do whatever we want ). In both cases giving the hash of a certificate in advance could leak identifying 
information, and would require the client to have made up its mind in advance as to what certificate 
it wanted  to use. But I suppose if the request follows a response containing  a 
   "WWW-Authenticate: Certificate"
header or if the client knows that it wants to be identified, then that would make sense anyway.

What was the situation in which you could see an advantage of putting a hash of the cert in the header ? ( which header?)

Thanks,

	Henry

[1] But I have not followed carefully the Web Crypto APIs evolution.

> 
> Cheers,
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 

Social Web Architect
http://bblfish.net/