W3C home > Mailing lists > Public > public-webcrypto@w3.org > November 2012

Re: Cryptographically tying signatures to origins

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>
Message-ID: <B1933A16-C7EB-4C0F-8B4B-FA2E544A1A69@netflix.com>

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 ?


> -Ekr
Received on Friday, 2 November 2012 15:17:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:14 UTC