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

[[e-mail]]

> From: IETF Secretariat [mailto:[e-mail]]
> Sent: Tuesday, February 07, 2017 12:26 PM
> To: [e-mail]; [e-mail]
> 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