On Thu, Mar 24, 2016 at 5:42 AM, Ron <[email protected]> wrote: > On Thu, Mar 24, 2016 at 04:45:06PM +1100, Martin Thomson wrote: > > On 24 March 2016 at 09:33, Karthik Bhargavan > > <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
