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

On Thu, Mar 24, 2016 at 5:42 AM, Ron <ron@debian.org> wrote:

> On Thu, Mar 24, 2016 at 04:45:06PM +1100, Martin Thomson wrote:
> > On 24 March 2016 at 09:33, Karthik Bhargavan
> > <karthikeyan.bhargavan@inria.fr> 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.
>

I think it's safe to say that any system which is designed to support
re-validation with any frequency cannot involve email.

However, note that ACME supports renewal of certificates without
re-validation.

--Richard

>
> 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
>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>