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

[Richard Barnes <[e-mail]>]

Updated the PR.  Trimmed below.

On Wed, Aug 29, 2018 at 11:26 AM Alexey Melnikov <[e-mail]>
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.



>