- From: Mark Watson <watsonm@netflix.com>
- Date: Fri, 2 Nov 2012 15:16:37 +0000
- To: Eric Rescorla <ekr@rtfm.com>
- CC: "<public-webcrypto@w3.org>" <public-webcrypto@w3.org>
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:17:06 UTC