Re: [saag] IETF 93 Agenda Request - Key Discovery

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

On Thu, Jul 16, 2015 at 2:57 PM, Viktor Dukhovni <[e-mail]>
wrote:

> On Thu, Jul 16, 2015 at 12:20:49PM -0600, ? Matt Miller wrote:
>
> > I would like to request a 10 minute slot during SAAG on Thursday to
> > discuss entity key discovery and <
> > https://tools.ietf.org/html/draft-miller-saag-key-discovery-00 >.
>
> Sorry, I won't be in Prague.  A few concerns:
>
>    * Retrieval of unencrypted private keys over HTTPS seems
>      rather risky (perhaps a bad precedent).  One might instead
>      specify that these are to made available as PKCS#12 or similar
>      objects that support passphrase encryption.  The client would
>      then extract the secret keys by using local knowledge of the
>      applicable passphrase.
>
>    * Finally, I am skeptical that the WebPKI CAs are a good fit
>      for key management beyond the usual web server certificates.
>      Trusting all of the usual suspects to also secure public keys
>      for long-term content encryption (S/MIME, ...) not just
>      authentication keys for web servers should not be done lightly.
>
>      Perhaps this is a space, where proof of control of the domain
>      needs to be stronger than WebPKI DV certs.  As I see it the
>      confidence in the validity of a certificate is:
>
>         EV >> DANE >> DV
>
>      Since EV does won't scale to provide universal coverage, this
>      is a space in which HTTPS with WebPKI may be inadequate.
>
>    * This seems to want to support public-key lookup for email
>      accounts.  You're perhaps aware of the DANE WG drafts in
>      this space, perhaps these should be at least mentioned.
>      Do we want competing (proposed) standards in this space?
>

Since DANE has now been around for what, four years without making much
headway, I think we should be very clear in saying that the field is wide
open to alternatives.

That said, as a CA, the last thing I ever want to see is a customer's
private key. If it is not the liability that would kill me, I would have
lawful access demands every hour of the day and night to handle. People
have asked me to provide that type of service on numerous occasions. It
isn't for lack of demand that it does not exist.


The way I propose to address the problem is to use end-to-end security and
a personal PKI to manage the keys.

https://tools.ietf.org/html/draft-hallambaker-cryptomesh-00

Setting up a PKI for myself and devices I own is pretty straightforward. I
am the only CA and the only root of trust. Deploying a PKI that allows
Carol to vouch for Alice's key to Bob is a hard problem. Deploying a PKI
that allows Alice's mobile phone to vouch for Alice's laptop computer is a
much easier problem.

As a CA I am more than happy to store someone's encrypted private key.

I do not use PKCS#12 in the mesh following my 'no new ASN.1' design goal.
It is a seriously complex and poorly documented spec. I am using JOSE JWE
instead. But PKIX works fine for the trust paths. (apart from discovering
that I have to write my own path construction engine because the existing
ones are built on some very peculiar assumptions but that is the
implementations not the code).