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

[Alexey Melnikov <[e-mail]>]

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 
> <[e-mail] <mailto:[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
>     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.