At 17:07 29/08/2018 Wednesday, Daniel McCarney wrote: >>Â 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
I would hate if they ever do (as getting dumb devices to redirect http://whatever/.well-known/acme-callenge/* to smarter http server(running the acme client) and http://whatever/* to https://whatever/ for normal users is a lot easier than getting them redeveloped to serve custom content (challenge response) or run native acme-client (as all my dumb devices needing certs currently do with some tweaking, then acme-client just uploads/reconfigs new cert when done) >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>https://cabforum.org/pipermail/validation/2018-August/000990.html > >On Wed, Aug 29, 2018 at 11:26 AM, Alexey Melnikov ><<mailto:[email protected]>[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>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 >><<mailto:[email protected]>[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>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/>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 <http://tools.ietf.org>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>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>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>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 _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
