Re: [therightkey] Draft charter for a Transparency Working Group

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Dec 12, 2013 at 9:39 AM, Paul Lambert <[e-mail]> wrote:

>
>
> >>
> >> On 12/11/13, 8:55 AM, "Ben Laurie" <[e-mail]> wrote:
> >>
> >>>Who's in?
> >> Very cool concept Š very broad possible applications.
> >> Less interested in HTTPS/TLS, but many applications.
> >
> >Great - can you be more specific what interests you?
>
> 1) Basic logs and the ability to have assurance on time and order
> 2) Distributed authorization systems with an ability to demonstrate the
> existence
>    and ordering of authorization statements
> 3) Time stamps and time synchronization
> 4) Group membership / enrollment
> 5) 'key centric' identity (mappings using hashes of keys as identity)
> 6) Service description and discovery without central registration
>


I am very interested in 5, in fact my strong email addresses are really
just a convenient notation for key centric identity.

But there are two questions here:

1) What should we do?
2) What should we do in the transparency WG?


A draft of the paper I wrote for the IAB/W3C workshop is attached. It
describes the scheme I am currently writing code to support.

The part of the scheme described in the paper is what I consider
'plumbing'. I don't think that I have foreclosed any options by taking the
decisions I did. Most of the design is constrained by previous
specifications and by legacy infrastructure. The decision to use JSON to
encode the 'Prism Hardening Bit' is driven by fashion but I think that is a
good one in this case and I can support it with a use case that JSON meets
but not ASN.1.


But what I don't describe in the paper is the much bigger part of the
scheme that has to do with a next generation PKI model for individual users
built on a synthesis of the PKIX, PGP and CT models.

I could propose that as a WG item but I get the feeling that Stephen is
going to respond that it is research or it should be an experimental or
whatever.

I really want to fix end-to-end email security. But right now the problem
with end-to-end security is not a lack of trust in the key distribution
model. The problem that is killing deployment is that the products are too
difficult to use.

So even though I am building my alternative key distribution infrastructure
on the assumption that there is a CT like infrastructure in place, the
motivation for building that infrastructure is to solve a different problem.


Another area that I have considered and written code for but not yet
described is how to use key centric crypto to secure a Web service.

For example, let us say that we have some infrastructure that lets us
resolve either a hash alone or a hash plus a domain name to a blob of data
that is a policy signed under the corresponding key (a PHingerprint Blob,
fb was already taken).

I am currently using this mechanism to resolve strong email addresses:

<fingerprint>?[e-mail]

We can use just a Web server and the .well-known convention to resolve
(<fingerprint>, example.com) to a policy file.


But while I was writing the proxy I suddenly realized that even though my
email client lets me check the box that says 'use SSL', the client does not
actually check the certificate chain, nor does it let me install my own
root of trust to check the chain against. Which is a pretty big hole. So
what I would like to be able to do to configure my email client is to
specify the mail service connection in a form such as:

phb://example.com/_submit._tcp/<fingerprint>

The corresponding policy would then contain the port and service DNS name
data for connecting to the submit service at example.com.


We can further use this as a discovery mechanism for the phingerprint as
follows:

Let us assume that all the user tells the client is their email address (
[e-mail]) and the client is to work out everything else for
themselves. So the client knows that it wants to talk the SUBMIT protocol
(_submit._tcp) and it knows the domain (example.com). It can now form a
.well-known query for the phingerprint of the corresponding domain:

https://example.com/.well-known/phb/
http://example.com/.well-known/phb/


As a short term measure the user would have to enter a one-time passphrase
to provide initial authentication. But in the longer term this should be
replaced by an out of band confirmation service. When I buy a new device I
want to be able to configure it for use with all my applications through a
one time process in which I tell the device which account(s) to use and
then I get an out of band request for confirmation that this is what I want
to do on an already configured and trusted device.

-- 
Website: http://hallambaker.com/