Re: [Acme] On multiple CAs and contact-based recovery

[Ron <[e-mail]>]

On Thu, Mar 24, 2016 at 04:45:06PM +1100, Martin Thomson wrote:
> On 24 March 2016 at 09:33, Karthik Bhargavan
> <[e-mail]> wrote:
> > Emails with clickable links are *BAD*; we should enhance their security by
> > linking them better with
> > the ACME account key.
> 
> FWIW, I think that a clickable link could be possible, it just
> wouldn't be able to point to the server.  If, as you suggest, the
> point is to give the ACME client a fresh secret, then the link could
> be changed from:
> 
> https://acme.server.example/recover/<secret>
> 
> to
> 
> acme:recover:<secret>

Personally, I like the idea of moving best practice away from clickable 
links in plaintext email ...

But if integration with existing email infrastructure is desirable,
the other option to consider there might be PGP/MIME.

The downside is you add yet another key to manage and all the things
which come with that.

The upsides are, we get to reinvent fewer wheels, we can have end to
end security for the email exchange (to the point where the entire
exchange could be a signed and encrypted reply to the challenge email),
and the 'exceptional' recovery mechanism requires proof of ownership
of a key which can be kept entirely separate from the normal 'day to
day' use of an acme client - and which might be more likely to be
protected by a strong passphrase than the keys used for automated
acme renewals.

(maybe the reason I lost my account key and need to recover is that
someone broke in and stole the machine it was on, so having something
which can trump that to let me recover and revoke it does seem like a
desirable thing in its own right - but that then poses the problem of
what proof do I need to show to securely change my trump card ...)

In theory, the server and client keys could also be cross-signed,
but that probably doesn't scale to having 7 billion signatures on
the server key :)

All the client would need to do is publish their PGP key on a keyserver
and add the fingerprint of that key as part of their contact details.


But that said, I do also like the simplicity of making this congruent
with the account roll-over process.


> Most operating systems understand how to invoke local software in
> response to that and your proposed flow behaves much the same from a
> user perspective.
> 
> That isn't *as* good as your proposal, I don't think, but it might
> have some usability advantages.

The main downside I see to this, is that if I need to fully automate
the acme client to perform certificate renewals every few weeks,
then it's unlikely to be running on the same machine where I read
email.

Ideally it's going to be running in a sandbox that has very limited
access to or from anything but the acme server, the machines where
certificates need to be deployed, and the people who are authorised
to administer it.

If I was going to add a way to allow people to perform admin actions
on it via email, it probably would be by having them send PGP signed
control messages to it ...

  Ron