> > > 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. >
I'm slightly adverse to changing this to a MUST. There's been some recent discussion[0] on redirects in domain validation by the CA/Browser Forum validation working group that makes it pretty clear there isn't a universal agreement on how CA's should handle redirects. While I disagree with the proposals to ban following redirects outright there is a possibility that consensus goes that direction and a MUST for processing redirects in ACME could be problematic. Unfortunately I think this is a case where some CAs will decide following redirects in certain conditions is acceptable and where other CAs will decide to never follow a redirect and ACME shouldn't prescribe CA policy. I understand that this makes provisioning a challenge response such that it will be inter-operable with all ACME CAs more difficult but there are a number of ways I expect this would be challenging beyond support for redirects (e.g. one CA may heed the recommendation to use DNSSEC and one may not. A challenge response provisioned behind a domain with an invalid DNSSEC configuration would not interoperate). [0] - https://cabforum.org/pipermail/validation/2018-August/000990.html On Wed, Aug 29, 2018 at 11:26 AM, Alexey Melnikov <[email protected] > wrote: > Hi Richard, > On 29/08/2018 16:03, Richard Barnes wrote: > > Hi Alexey, > > Thanks for the comments. A couple of replies are below; resulting edits > are in this PR: > > https://github.com/ietf-wg-acme/acme/pull/442 > > > I deleted comments where we are in agreement. More comments below: > > > --Richard > > > On Wed, Aug 29, 2018 at 7:14 AM Alexey Melnikov <[email protected]> > wrote: > >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-acme-acme-14: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thank you for this very important document. I would like to switch to >> "Yes", >> but please first review and respond to my comments: >> >> First mentions of JSON and HTTPS need references. >> >> 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. > > > > >> 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). > > > > >> 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. > > https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-7.3 > > The WG discussed this and decided not to have more negotiation here. See, > e.g.: > > https://mailarchive.ietf.org/arch/msg/acme/TW8sbspUIGDGbIldaqWW0k9jKYo > > That is fine. > > > > >> (Similar text in other sections!) >> > > I don't see "sort order" anywhere else, or other relevant usage of > "order". Do you have other places in mind? > > This might have existed in earlier versions. I will double check. > > > > 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. > > 9.6. URN Sub-namespace for ACME (urn:ietf:params:acme) >> >> Repository: URL-TBD >> >> Who needs to fix this value? >> > > There's a request to the RFC editor below. > > > Ok. > > > >> 9.7.1. Fields in Account Objects >> >> o Field type: The type of value to be provided, e.g., string, >> boolean, array of string >> >> Here and in all similar registries: I think you should insert "JSON" >> before >> "type" to make it clear that types are only restricted to JSON type >> choices. >> > > It's a JSON object. If you define a non-JSON type, you're gonna have a > bad time. > > > Maybe I am dealing with too much CBOR/CDDL recently, which allows for more > types. > > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
