Re: Cryptographically tying signatures to origins

On Fri, Nov 2, 2012 at 8:16 AM, 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

Other work group efforts (eg: Public Key Pinning from the IETF) can be
used to provide some degree of authentication/privilege reduction
there.

Regardless though, the "verifiable" part is that it what the user
agent sees the origin, not what JS sees the origin - so it cannot be
spoofed.

Received on Friday, 2 November 2012 15:35:21 UTC