Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Alan Doherty <[e-mail]>]

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:[e-mail]>[e-mail]> 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:[e-mail]>[e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/acme