Re: Cryptographically tying signatures to origins

Actually, you're right and while I said this verbally, it didn't make it into my
proposal online. I blame jet lag.

I would suggest that a variant of this include the complete cert chain.

-Ekr


On Fri, Nov 2, 2012 at 4:16 PM, Mark Watson <watsonm@netflix.com> wrote:
>
> On Nov 2, 2012, at 4:03 PM, Eric Rescorla wrote:
>
>> To elaborate on the point I made in today's meeting, it seems to me
>> that when you boil down the implied *requirements* that Mountie
>> was asking for, they come down to tying any cryptographic operations
>> made by the crypto api to a certificate rooted in the national PKI.
>>
>> This is very difficult for encryption without putting a huge pile of
>> complexity into the TCB. However, it's simple for signature. Consider
>> a new API point called "signWithOrigin(M)". It takes a key and an
>> input message and then signs a new message M' that contains
>> both the original message plus an indication of the origin of the
>> requesting JS. For instance:
>>
>> M' = { "origin":"https://www.example.com", "message":M }
>>
>> The output signature will then be computed over M'.
>>
>> The value of "origin" will be the origin of the JS that is executing
>> in the page (and that requested the signature). [One might imagine
>> having additional CSP-style restrictions like, script-src = self].
>>
>> This would allow any relying party to verify that signatures coming from
>> a given key were generated by "trusted" JS (i.e., JS that came out of
>> an verifiable origin.)
>
> How useful is it for the relying party to know that the origin was "verifiable" without knowing what root certificates were installed in the UA ?
>
> …Mark
>
>>
>> -Ekr
>>
>>
>

Received on Friday, 2 November 2012 15:55:25 UTC