Yes, many of these things were already addressed by Jacob and others. On 7 March 2017 at 05:32, Richard Barnes <r...@ipv.sx> wrote: >> S6.3.2 >> >> [...] and MUST reflect [the?] value of the >> "external-account-binding" field in the resulting account object >> >> Is this a direct copy of the MAC that was provided? Do you realize >> that this enables a user with access to any account that was created >> with a binding to replay the binding in new accounts without actually >> having the MAC key? > > > How would that work? ISTM that since the MAC is calculated over the JWK > representation of the account public key, you couldn't re-use the MAC to > convey this authorization to another key.
Yeah, that is a detail I missed (that the MAC has a very specific form isn't established by this point in the doc). > If there is an issue here, we do need to fix it, since the major purpose of > external account binding is to convey authorization, e.g., for EV. > > It is probably overkill to reflect the whole object. I think my preferred > solution would be to just reflect the "kid" value as you suggest. That would be fine. >> [re: Revocation on account deletion] > > > As with all server behaviors here, we can't really be too prescriptive; CAs > will have compliance needs dictated by things like customers or root > programs that will be will override voluntary protocol specifications. Some > cautionary text might be warranted. I realize that there might be cases where termination of an account might result in revocation, but the protocol doesn't need to require it. (I think that this was discussed and resolved by saying that the certificates will not be directly affected by this action.) >> S6.5.1 >> >> In responding to poll requests while >> the validation is still in progress, the server MUST return a 202 >> (Accepted) response >> >> The 202 is an odd choice here. The resource exists and has content, >> so 200 works perfectly well for this purpose. > > > WFM. 200 + Retry-After is OK? Probably. It's a little odd to include Retry-After on a successful response, (503 being more common), but I can't think of anything better. >> S9.4 >> >> Does an ACME server send Referer[sic]? What should it set it to? > > You mean as an SSRF mitigation? In that case, the real question is what > headers the ACME server should send in order to minimize the probability > that an attacked resource would respond to the request. I'm not sure > Referer is great for that; wouldn't Origin be better? And in the Origin > case, I would think the right thing to set it to would be the origin for the > server. I don't mean as anything. The question is simply whether it does or not. It might make it easier to construct a valid response, though I'm not sure that has reads on the ability of an attacker to generate a valid response given the challenge structure. It would set the value to some part of the URL that referred it. Origin is very specific to the web security model. It refers to the origin that is making a request. I wouldn't use it here. > Proposed edits [...] > > https://github.com/ietf-wg-acme/acme/pull/271 I'll review that, thanks. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
