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
<aamelni...@fastmail.fm <mailto:aamelni...@fastmail.fm>> 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
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
