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

Cryptographically tying signatures to origins

From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 2 Nov 2012 16:03:22 +0100
Message-ID: <CABcZeBOq5YCatYEkRLGtFCigcnnTUidMhKw=zp1GpJVtWhdfzw@mail.gmail.com>
To: public-webcrypto@w3.org
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.)

Received on Friday, 2 November 2012 15:04:37 UTC

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