Some minor questions on HTTP semantics: - HEAD new-nonce: If GET is used instead, which is allowed, is 204 returned or 200? "The server SHOULD also respond to GET requests for this resource, returning an empty body". This implies a 200 response with Content-Length: 0, but 204 should be equally valid, so I'm not sure why this needs to differ.
- "If the server already has an account registered with the provided account key, then it MUST return a 200 (OK) response and provide the URI of that account in a Content-Location header field." It should probably be clarified whether the account object is returned in this request. The use of Content-Location here instead of Location is a little odd, but might make sense if the account object is returned. That said, given that an existing account can't be updated by POSTing to new-account I'm not sure that really works. The new-account resource doesn't represent an existing account, so the use of Content-Location here seems inappropriate. Is there a reason to avoid the use of Location here? Moreover, new-authz "accept"/"require" dictates use of 303/Location, so this seems inconsistent. Possibly one or the other should be changed. Previous discussion indicates that 303/Location is perceived as problematic due to HTTP libraries tending to follow it automatically, which makes it hard for ACME implementations to be aware of the final location. I agree with this; personally 200/Location for both new-account and new-authz makes sense to me. - GET certificate: If Accept: application/pkix-cert is used, does rel=up link to intermediate? Is varying links such as rel=up by content negotiation OK? RFC5988 seems to suggest otherwise to me, as it describes a link as being between two resources, not between two resource representations. To be fair, optimal mapping to platonic HTTP semantics often seems to be more of an hope than something ever fully accomplished. These are minor issues. Editorial fixes: s/JSON dictionary/JSON object/: There are no dictionaries in JSON, only objects. s/use when configuring CAA record/use when configuring CAA records/ p31: inconsistent use of full stops. Account Creation: 'containing only the "contact" field' -> terms-of-service-agreed is required too, sentence needs updating Finally, I may as well mention wildcard domains again. I don't really get the aversion to standardizing this. I previously proposed that these be validated by n verification requests from a server to randomly-generated, unguessable labels substituting for a wildcard. This adequately proves that a wildcard is actually configured and that the service located by it is under account control. These would be blind; the hostnames used for the requests wouldn't be shown in the authorization or challenge objects, so the client wouldn't know what names would be used until the verification request comes in. Arguably, though, even this is overkill, and just creating authorization objects for unblinded, randomly generated names substituting for the wildcard would suffice. (In fact, as far as I can tell, nothing in the current spec actually prohibits doing this.) There are real applications for wildcard domains. For example, the ability to create unlimited numbers of secure origins has real value to some classes of web application. -- Hugo Landau I know of no warrant or notice of a kind defined within the Investigatory Powers Act 2016 or the Regulation of Investigatory Powers Act 2000 that has not been brought to the attention of the public. I will always answer questions about these or similar matters, assuming reasonable request rates, unless legally prevented from doing so. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
