After having read the specification in its current draft form, I have the following comments and questions:
- The expiry date on authorization objects is a date and not a timestamp. This seems undesirable; in some cases it may be desired to issue an authorization for a very short period of time, such as 30 minutes. Shouldn't this field be a timestamp and not a date? - The tls-sni-01 specification seems to allow SANs not of the form *.acme.invalid to appear. Is there any use case which requires this leeway? If there's no reason to allow it, it seems like something which should be prohibited. - One ambiguity in the tls-sni-01 specification seems to be whether validation servers are allowed to query for the Z(0) value or not, or only Z(i) for i > 0. This should probably be clarified. - The proof of possession challenge specifies acceptable certificates, rather than acceptable keys. Is there some reason for this? Moreover, how is the ACME server supposed to state a certificate for a key which has never issued a certificate, such as an account key? It cannot create the necessary signature if it is to create a self-signed certificate. SubjectPublicKeyInfo (or JWK) seems more appropriate here. - The proof of possession challenge specifies multiple certificates. It could be changed to support only a single certificate, instead allowing multiple proof of possession challenges to be used in combinations. This would allow multiple prior keys to be required. On the other hand, I can't immediately think of a use case, so that might be overkill. - Some examples in the spec POSTing to challenges specify the "type" field, while others don't. The field seems redundant, although being explicit here might be desirable in much the same spirit as the "resource" field. Which way is this supposed to go? - The use of Location and Content-Location headers seems a bit quirky. Location, as far as I can tell, has no defined semantics for status code 200. In the GET <issued certificate URI> case, it seems redundant, but the example seems to suggest it should be present. - New certificate requests can be responded to either with a certificate or deferral to another URI from which a certificate can (eventually) be obtained. This seems like an overcomplication; the deferral case can support the immediate case just as well. - Automatic renewal seems dubious, especially in an era of certificate transparency. Eventually all certificates issued will probably be logged, and it would be troublesome to have certificates issued and logged which have been issued on purely speculative grounds. If I issue a certificate via an ACME CA, and then I switch to another CA, I don't want the old CA continuing to issuing certificates, even if nobody can use them. In the future CAs might use the prior issuance of other certificates for the same domain by other CAs, as detected via CT, as a risk indicator. I think this is alluded to in the specification: "domain for which known certs exist from other CAs". As it is, expiration provides a last resort measure taking a certificate out of play if e.g. the private key is lost, and the certificate cannot be revoked. With implicit renewal you have to wait until the applicable authorizations expire, presumably. It seems like a somewhat fundamental principle that a CA's issuance of a certificate must be connected with an explicit request by a domain to do so. Since ACME is all about automation clients can explicitly request a new certificate trivially if they so choose, so the value of this mechanism seems dubious. - GET-triggered renewal is better, but it also seems like a needless weakness. The specification itself mentions that this makes certificate URLs so called "capability URLs", but the W3C article on capability URLs makes clear they aren't exactly preferred. Not to mention that GET requests aren't supposed to change state; and I'd argue that submission to a CT log is at least in spirit such a change. If there is some reason why some ACME clients might have difficulty generating a new CSR (either from a previous CSR or from the previous certificate), one option might be to allow a certificate URL to be passed in new certificate requests instead of a CSR. Taking this route would make certificate URLs immutable, removing the Content-Location complication, which seems like a win. Hugo Landau _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
