Re: [Acme] ACME draft is now in WGLC.

[Russ Housley <[e-mail]>]

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