Updated the PR. Trimmed below. On Wed, Aug 29, 2018 at 11:26 AM Alexey Melnikov <[email protected]> wrote:
> >> 6.4.1. Replay-Nonce >> >> The "Replay-Nonce" header field includes a server-generated value >> that the server can use to detect unauthorized replay in future >> client requests. The server MUST generate the value provided in >> Replay-Nonce in such a way that they are unique to each message, with >> high probability. For instance, it is acceptable to generate Replay- >> Nonces randomly. >> >> The value of the Replay-Nonce field MUST be an octet string encoded >> according to the base64url encoding described in Section 2 of >> [RFC7515]. Clients MUST ignore invalid Replay-Nonce values. The >> ABNF [RFC5234] for the Replay-Nonce header field follows: >> >> base64url = [A-Z] / [a-z] / [0-9] / "-" / "_" >> >> This is not correct ABNF. Change range syntax in Section 3.4 of RFC 5234 >> > > I've updated to try to fix this, but your review on the PR would be > appreciated. > > The correct form is (I didn't check if you usxe correct hex values): > > base64url = (%x40-5A) / (%x61-7A) / (%x30-39) / "-" / "_" > > (I.e., don't include "%x" after "-" and don't have spaces before or after > "-".) BTW, you can use "BAP"on tools.ietf.org to verify ABNF. > Done. > > >> Please add normative references for Retry-After and Link header fields. >> > > These already have normative references at their first appearance: > > https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-6.5 > > Do you think those references are incorrect? > > > I was reading out of order, so this is fine. But a new nit: "header" --> > "header field". ("Header" is a collection of all HTTP header fields present > in a request or response). > Did a scan through, and I think I hit all of these. LMK if you see others. > > >> In 7.1.2: >> >> contact (optional, array of string): An array of URLs that the >> >> Which URI schemes are allowed (or at least expected) here? >> > > Basically, servers must support "mailto", and may support others; they can > specify their requirements in an error message. > > You don't mention "mailto:"; till later and you don't even mention "tel:". > I appreciate that you don't want to have an exhaustive list here, but I > think you should still provide a bit more guidance. > Added a forward pointer to the guidance below. If you have other things you'd like to recommend, please send text. > > In 8.3: >> >> The server SHOULD follow redirects when dereferencing the URL. >> >> Why only a SHOULD? >> > > Some server operators wanted to have the option to require that the > validation work on the first request. > > > I think SHOULD basically makes redirects non interoperable. I think a bit > more text explaining why SHOULD or change this to MUST. Also, if there are > some security issues related to redirects, adding a pointer here would be > good. > Fair point. I've changed to MUST for now; let's see if anyone objects on the mailing list. >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
