> On 21 Nov 2015, at 8:02 PM, Salz, Rich <rs...@akamai.com> 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?) 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. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
