Looks good to me. I think it would also be useful to provide guidance to ACME clients as to which CA to contact so as to support use of an LRA and/or transition from one CA to another.
For example, lets say the initial CA was AliceCert.com and the site decides to use BobCert.com instead. The site has to continue to post AliceCert.com CAA records until all the issued certs have expired. But the site wants all servers to make requests for new certs to BobCert.com. For any largish certificate deployment such as a house circa 2025 with a hundred plus connected IoT devices, an LRA type approach is going to be desirable. The consumer buys a doorbell, they want the doorbell to use TLS and thus it needs a cert. They want all the certs in their house to come from the same CA and be managed through one box. For this particular type of application, we might well be looking at an entirely new type of cert, something below DV in scope, possibly not even a WebPKI cert at all. It might be a cert whose status is more akin to a PGP subkey than what we have dealt with to date. A CAA record is the natural place to put an entry to say 'go to here to request a certificate'. This is similar to the 'sufficient' issue that was discussed but I don't think the same objection applies. I do not like the 'sufficient' concept because in my world the CA can always reject a request for any reason or no reason at all. On Fri, Apr 22, 2016 at 11:06 PM, Randy Bush <[email protected]> wrote: >> https://datatracker.ietf.org/doc/draft-landau-acme-caa/ > > thanks. seems simple and makes sense. > > randy, for adoption > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
