On Sat, Nov 21, 2015 at 2:36 PM, Yoav Nir <[email protected]> wrote:
> > > On 21 Nov 2015, at 8:02 PM, Salz, Rich <[email protected]> wrote: > > > > Please see https://github.com/ietf-wg-acme/acme/issues/47 for > background, but discuss it here on the mailing list. > > The A in ACME stands for automated, and the protocol we are chartered to > develop is designed to allow getting and maintaining a certificate for a > domain that I own without being exposed to the intricacies of PKI and > without manual intervention. If I own the domain “yoavnir.com” [1], I > should be able to use a piece of software to get and regularly replace a > certificate for yoavnir.com [2] without ever seeing any DER [3]. > > As soon as an ACME server returns an error, the automation goes out the > window, so we should recommend to minimize those cases as much as possible. > Returning a good human-readable message is somewhat helpful, but mostly for > the developer of the ACME client to use in debugging. The error message > will usually be useless for the end-user - the domain owner. > > Going through your examples, of course it makes sense to issue a > certificate with a validity period that is the minimum of the policy > validity period and the requested validity period. We cannot expect the > ACME client to know that “Let’s Encrypt” provides certificate for up to 90 > days, while some other CA provides them for a year. So it makes sense for a > client to always request a long period (a year? 10 years? 1000 years? Why > not?) > There are certainly cases where that's reasonable, but there are also cases where it's attractive to the server to have certs with short lifetimes. One example would be if (as has been discussed elsewhere) browsers skip revocation checks for short-lived certs. -Ekr
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
