On 10/30/2015 08:04 AM, Hugo Landau wrote: > - 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? Agreed. > - 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. Agreed. > - 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. I have a pull request that simplifies the TLS SNI challenge by removing the multiple zName provision: https://github.com/ietf-wg-acme/acme/pull/22.
> - The proof of possession challenge specifies acceptable certificates, rather > than acceptable keys. Is there some reason for this? I think the notion is that most people don't have an easy way to find a private key associated with a particular public key, but if we give them a whole certificate, it's easier to figure out which machine uses that certificate, and from there where the private key might be. > 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. I think the current notion of Proof of Possession is that it would be used in cases where the CA knows about an overlapping certificate. I can't think of a particular policy need to require proof of possession across account keys, but I can see that there might be one. > - 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. Unfortunately this would expand the size of the challenges array dramatically. If there were some future challenge that wanted to do a similar thing, the result would be combinatorial blowup. > - 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. Agreed. > - 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". I agree. I think the best approach is to require an explicit POST /acme/new-cert for each issuance. Eric Rescorla has pointed out that this requires keeping ACME account keys on the server that handles issuance, or putting them on there every N months, where N is the certificate renewal period. The goal of including GET-based renewal with no authentication was to make it possible to keep account keys mostly offline, and bring them online manually every M months, where M is the expiry period for relevant authorization objects. The assumption, of course, is that M >> N. This wind up dependent on CA policy, but as a first approximation, M might be 12 months. So under GET-based renewal, the sever operator still needs to do some manual steps once a year to ensure their certificates stay up to date. I think that violates on of ACME's main goals: to reduce accidental certificate expiration through automation. Additionally, GET-based renewal assumes that server operators don't want to rotate their keys with each new issuance. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
