> On 22 Nov 2015, at 12:43 AM, Eric Rescorla <[email protected]> wrote:
>
>
> On Sat, Nov 21, 2015 at 2:36 PM, Yoav Nir <[email protected]
> <mailto:[email protected]>> wrote:
>
> > On 21 Nov 2015, at 8:02 PM, Salz, Rich <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > Please see https://github.com/ietf-wg-acme/acme/issues/47
> > <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 <http://yoavnir.com/>”
> [1], I should be able to use a piece of software to get and regularly replace
> a certificate for yoavnir.com <http://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.
>
Right, and for the most part an ACME server will honor the notAfter field in
the request. But if for some reason it has a policy that all certificates must
be valid for at least a month in the future, I think it should issue the
certificate with a notAfter date set to one month in the future, and let the
client decide whether this is useful or not.
Yoav
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
