From: IETF Secretariat [mailto:[email protected]]
Sent: Tuesday, February 07, 2017 12:26 PM
To: [email protected]; [email protected]
Subject: IETF WG state changed for draft-ietf-acme-acme
The IETF WG state of draft-ietf-acme-acme has been changed to "In WG
Last Call" from "WG Document" by Rich Salz:
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
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.1, I think it is desirable to add a requirement that the
ACME server SHOULD OCSP Staple.
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.
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: s/function as both an ACME/functions as both an ACME/
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.2: s/associated to an account/associated with an account/
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:
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 ]].
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 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\
In Section 8.2, I cannot understand the figure. Please correct it.
Section 9.1: s/man in the middle/man-in-the-middle (MitM)/
Russ
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
