W3C home > Mailing lists > Public > public-identity@w3.org > December 2011

Re: Key Opacity/Identification Issue - Web Cryptography Charter Updated

From: Tom Ritter <tom@ritter.vg>
Date: Sat, 10 Dec 2011 23:37:21 -0500
Message-ID: <CA+cU71kP7vQYnO0_jJ-q4ObJBMF1FdqUVLUzTeYDAcbzYG7UNA@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Anders Rundgren <anders.rundgren@telia.com>, Harry Halpin <hhalpin@w3.org>, "public-identity@w3.org" <public-identity@w3.org>
On 9 December 2011 11:41, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> [1] http://tools.ietf.org/html/rfc5705

I thought I was on board with you Stephen, but after looking over that
RFC I'm just not getting it.  I'm a bit tired, but even after
re-reading it a few times... It seems to just provide a RNG accessible
on the client and server which uses the master secret as a partial
input seed.  Which is useful, but not what I was thinking of a priori.
 How far off am I with that?

Thoughts I had which it definitely isn't:

 - A way to operate on things using the master secret of the
underlying TLS connection
 - A way to operate on things using certificates (server and/or
client) in the underlying connection
 - A way to expose parameters about the underlying connection to a
higher-level protocol (e.g. certificates and chain in javascript
parameters)

The last bullet point I mentioned is something I've been pushing for a
bit.  Especially coupled w/ signing and verifying javascript libraries
- you can implement key pinning and a number of interesting CA
auditing and verification tools if you can read the supplied
certificate parameters.

-tom
Received on Monday, 12 December 2011 12:32:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 12 December 2011 12:32:22 GMT