On Tue, Dec 15, 2015 at 12:25 PM, Noah Kantrowitz <[email protected]> wrote:
> > > On Dec 15, 2015, at 7:17 AM, Michael Wyraz <[email protected]> wrote: > > > > Stephen, > >> Yes, I understand that and didn't actually refer to LE at all in my > mail. > > I'm sorry if I missunderstood you with that. > > > >> Basically, IMO only after we first get a "now" that works > > We have a working HTTP-01 spec, implementation and CA. What's missing > > for "a 'now' that works"? > > > >> Personally the optional thing in which I'm much more interested is a > >> simple put-challenge-in-DNS one where the CA pays attention to DNSSEC, > >> since that's the use-case I have and that would provide some better > >> assurance to the certs acquired via acme. I can see that there might > >> also be value for some (other) folks in SRV if it means no need to > >> dynamically change DNS. But, if someone is saying "we must all do > >> these more complex things for security reasons" then they are, in this > >> context, wrong. And my mail was reacting to just such a statement. > > Why not just placing a static public key to DNS that is allowed to sign > > ACME requests for this domain? Simple, no need for dynamic updates (yes, > > it's standardized for years but AFAIK not seen very often in real world > > scenarios). > > Anything that makes deployment _harder_ than the current LE client is a > move in the wrong direction. UX matters, with security more than just about > anything else. Unless you can propose a user flow to go with this change, > no amount of hypothetical correctness is worth having a tool no one will > use. > Harder for whom? The current scheme isn't going to work for any geolocation based systems and is a terrible fit for enterprise. The workflow for using a LRA would be as follows: 1) Set up your ACME local RA on some host, e.g. lra.example.com 2) Generate a self signed cert for the LRA 3) Calculate the fingerprint of the KeyInfo blob (see https://tools.ietf.org/html/draft-hallambaker-udf-00) MD2UR-3PN64-TMQ26-HERIT-PVDOR-6FI42 4) Create a CAA record with some tag: example.com CAA acme 0 "lra.example.com lra=MD2UR-3PN64-TMQ26-HERIT-PVDOR-6FI42" At this point, we have published all the necessary control information to allow acme clients to automatically discover the LRA they are to connect to for issue of certificates and the issuing CA has all the information needed to authenticate the requests. Note that in this particular case, the mechanism used to authenticate the client to the LRA is out of scope of ACME because it is no longer a WebPKI authentication, it is an internal configuration decision. The simplest mechanism is probably for the acme client to generate a keypair for that particular host and use that to authenticate host requests to the LRA. The LRA would require some UI to authorize requests of course. In a production environment, it might not be desirable to generate the server keys on the servers that are actually going to use them. Alternatively we might want to use the co-operative key generation technique I demonstrated at CFRG in Prague. If you are managing one server, a simple protocol is simplest. If you are managing more than one then it probably is not. One of the main ways in which PKIX became so complicated was that people tried to make it much simpler than the problems required. So instead of one revocation/status/validation mechanism we ended up with four incompatible schemes. The use of LRAs has been absolutely standard in enterprise PKI for 20 years. This is a feature we know is essential CAA was originally designed to present all the information required to manage certificate issue.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
