Rich asked to me to divide my comments into technical and editorial. This are
the same comment that I sent earlier with that categorization.
Russ
= = = = = = = =
TECHNICAL
In Section 5.1, I think it is desirable to add a requirement that the ACME
server SHOULD OCSP Staple.
In Section 5.5, please add a MUST statement about the size of the nonce value
(before base64url encoding).
In Section 6.1.1, how does the key-change entry in the table in section 6.1.1
relate to the figure in Section 6.1? The other entries in this table seem to
have an obvious companion in the figure. I think the figure should to show how
the key-change is used update the acct.
Section 6.1.1 says:
"caa-identities" (optional, array of string): Each string MUST be a
lowercase hostname ...
How are IDNs handled? Are all U-labels converted to A-labels?
Section 6.1.3 says:
status (required, string): The status of this order. Possible
values are: "pending", "processing", "valid", and "invalid".
Should the list of possible status strings should also include "expired"? If
not, the text should say that the status will be set to invalid if the
authorizations are not accomplished before the expiration time.
Section 6.1.4 says:
... Servers MUST verify any identifier values that
begin with the ASCII Compatible Encoding prefix "xn-" as defined in
[RFC5890] are properly encoded. ...
I think you want to require the A-labels to be converted to U-labels and back
again, and then reject the label if the converted A-label does not match the
original A-label.
In Section 6.3.3, the list of steps clearly includes checking the signature on
the inner JWS in step 4, but I do not see a step that checks the signature on
the outer JWS. I think the both signature checks need to be explicit in the
steps.
Is an additional subsection in Section 6.3 needed to deal with lost account
signature private keys? I assume that some out-of-band mechanism would be
needed to delete the account so that a new one can be created.
Section 6.4.2 says:
The default format of the certificate is PEM (application/x-pem-file)
as specified by [RFC7468]. ... The client may request other formats by
including an Accept header in its request. For example, the client
may use the media type application/pkix-cert to request the end-
entity certificate in DER format.
RFC 7468 defines the textual encoding for certificates, but it does not define
the application/x-pem-file media type. I cannot find a registration for the
application/x-pem-file media type.
Also, please add a reference to RFC 2585; it specifies the
application/pkix-cert media type.
In Section 8.2, I cannot understand the figure. Please correct it.
EDITORIAL
Please use the terminology from RFC 5280. Throughout the document:
s/certificate authority/certification authority/
s/issuing authority/certificate issuer/
Also, please use the correct expansion for PKIX (PKI using X.509).
In Section 1, please define ACME.
Also in Section 1:
s/Certificates in the Web PKI [RFC5280]/Certificates [RFC5280] in the Web PKI/
In Section 5.2, please repeat the reference for the JWS specification at the
front of this section.
Section 5.2 says:
In the examples below, JWS objects are shown in the JSON or flattened
JSON serialization, with the protected header and payload expressed
as base64url(content) instead of the actual base64-encoded value, so
that the content is readable. Some fields are omitted for brevity,
marked with "...".
The example is above this text (below), and there is no "..." in it.
Section 6.1.1: s/function as both an ACME/functions as both an ACME/
Section 6.1.2: s/associated to an account/associated with an account/
Section 6.1.4 says:
scope (optional, string): If this field is present, then it MUST
contain a URI for an order resource, such that this authorization
is only valid for that resource. If this field is absent, then
the CA MUST consider this authorization valid for all orders until
the authorization expires. [[ Open issue: More flexible scoping?
]]
This scoping seems fine. Please remove the [[ question ]].
In Section 6.5, should the example use different challenges for "http-01",
"tls-sni-02", and "dns-01"?
Section 7.2: s/in A and AAAA records/in the DNS A and AAAA resource records/
Section 7.3: s\by an A/AAAA record\by the DNS A and AAAA resource records\
Section 9.1: s/man in the middle/man-in-the-middle (MitM)/
Russ
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
