Subject: [Acme] New issue: Clarify how to handle bad requests

From: "Salz, Rich" <[email-masked]>
Date: Sat, 21 Nov 2015 18:02:11 +0000

Please see https://github.com/ietf-wg-acme/acme/issues/47 for background, but discuss it here on the mailing list.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 22 Nov 2015 00:36:27 +0200

> On 21 Nov 2015, at 8:02 PM, Salz, Rich <[email-masked]> wrote:
> 

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?)

OTOH if the client has requested a certificate with a notBefore in two weeks and the CA has a policy prohibiting not-yet-valid issuance (I don’t know why it would have that kind of policy, but policies are explicitly out of scope by the charter) then perhaps this CA cannot provide the features that this ACME client is asking for. But is any harm caused by issuing a certificate that is valid immediately? Taking this to an extreme, I could ask for a certificate with notBefore in June 2016 and notAfter in December 2016, and instead receive a certificate that is valid immediately and expires in February 2016. That has no overlap with my requested dates, and in all likelihood this certificate is useless to me. But is there harm in issuing it? The client can always revoke it and never deploy it if it is useless to it.

The same is true for special requested key usages, alternate names and extensions. If an ACME client is asking for a certificate with BasicConstraints setting CA to true, giving them an end-entity certificate is mostly useless, but that is up to the client to decide. 

I’m sure there are cases where an error message is appropriate, but we should mostly try to avoid it. We do need strong language that the client should verify that the received certificate meets their needs and alert the user if not.

Yoav

[1] I don’t. That’s somebody else. 
[2] It’s really not me. I know very little about diapers.
[3] We should all be so lucky.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 21 Nov 2015 14:43:47 -0800

On Sat, Nov 21, 2015 at 2:36 PM, Yoav Nir <[email-masked]> 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

---

From: Yoav Nir <[email-masked]>
Date: Sun, 22 Nov 2015 00:52:10 +0200

> On 22 Nov 2015, at 12:43 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> On Sat, Nov 21, 2015 at 2:36 PM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On 21 Nov 2015, at 8:02 PM, Salz, Rich <[email-masked] <mailto:[email-masked]>> 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].
> 
> where it's attractive to the server to have certs with short lifetimes. One example

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