Subject: Re: [Acme] Last Call: <draft-ietf-acme-acme-13.txt> (Automatic Certificate Management Environment (ACME)) to Proposed Standard

From: Sean Turner <[email-masked]>
Date: Wed, 8 Aug 2018 21:03:03 -0400

These are all minor so I didn’t send them to [email-masked].  Also, once we settle on whether these are okay, I can submit a PR if you’d like (or not if that’ll be faster).

0) abstract

r/certificate authorities/certification authorities

and then you can:

r/certification authority (CA)/CA

1) s1

r/certificate authorities/certification authorities (CAs)
r/certificate authorities/CAs
r/CA web page/CA’s web page
r/confusion/frustration and confusion
r/infrastructural/infrastructure (?)
r/PKIX authentication/PKIX-based authentication (?)
r/WebPKI/Web PKI (? or should it go: r/Web PKI/WebPKI)

2) s3

r/TLS certificates/certificates for TLS

3) s4

r/in that certificate in order for
   the CA to sign the requested certificate./
in that request certificate in order for
   the CA to issue the requested certificate.

4) s6.1

Add reference for Access-Control-Allow-Origin header.

4) s6.2

r/For newAccount requests, and for revokeCert requests authenticated by
   certificate key, there MUST be a "jwk" field./
For newAccount requests, and for revokeCert requests authenticated by
   certified keys, there MUST be a "jwk" field.

5) s6.4 - since the previous section was JWS headers maybe:

r/the Replay-Nonce header/the HTTP Replay-Nonce header

6) s6.4.1 - I assume it’s ABNF there, but based on RFC 7231 I guess it’s worth a reference:
New header field values ***typically*** have their syntax defined using ABNF ([RFC5234]) …
So maybe add the following right before the ABNF:

  The ABNF [RFC5234] for the Replay-Nonce header field follows:

7) s6.5: need references?

r/"Retry-After” header/"Retry-After" header [RFC7231]
r/"Link” header/"Link" header [RFC8288]

8) s6.6: maybe the reference for the ACME URN namespace should be to section 9.6?

r/(within the
   "urn:ietf:params:acme:error:" namespace):/
(within the ACME URN namespace
   "urn:ietf:params:acme:error:"):

r/ACME URN [RFC3553] namespace/ACME URN namespace (see Section 9.6)

9) s7.1: add reference for REST?

r/REST/REST [REST]

[REST]    Fielding, R., "Architectural Styles and the Design of
              Network-based Software Architectures", 2000,
              http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.

10) s7.1.1: Should the "URL in values” in the table match the examples later in the section? i.e.,:

r/New nonce/new-nonce
r/New account/new-account

and so on?

11) s7.4.2: add reference for Accept Header?

r/an Accept header/an Accept header {RFC7231]

12) s7.4.2: could also point to application/pkcs7-mime for PKCS7 certs-only messages.

13) s7.6: If the revocation request fails, which error is returned?  THe draft often 

14) s9.1: Was there any thought given to an optional parameter indicating how many certs would be in the chain?

15) s9.3: Should the reference be: [this-RFC, Section 6.4.1] to match some of the other entries in the registry?  Or at least refer to [this-RFC]?

Cheers,

spt

---

From: Richard Barnes <[email-masked]>
Date: Wed, 8 Aug 2018 21:48:11 -0400

Without looking at them in context that seem pretty reasonable.   Happy to
review a PR.

On Wed, Aug 8, 2018, 21:03 Sean Turner <[email-masked]> wrote:

> These are all minor so I didn’t send them to [email-masked].  Also, once
> we settle on whether these are okay, I can submit a PR if you’d like (or
> not if that’ll be faster).
>
> 0) abstract
>
> 15) s9.3: Should the reference be: [this-RFC, Section 6.4.1] to match some
> of the other entries in the registry?  Or at least refer to [this-RFC]?
>
> Cheers,
>
> spt
>
>
>
>

---

From: Sean Turner <[email-masked]>
Date: Wed, 8 Aug 2018 23:42:21 -0400

Okay two PRs:

https://github.com/ietf-wg-acme/acme/pull/432
https://github.com/ietf-wg-acme/acme/pull/433

And three issues:

https://github.com/ietf-wg-acme/acme/issues/434
https://github.com/ietf-wg-acme/acme/issues/435
https://github.com/ietf-wg-acme/acme/issues/436

spt

> On Aug 8, 2018, at 21:48, Richard Barnes <[email-masked]> wrote:
> 
> Without looking at them in context that seem pretty reasonable.   Happy to review a PR.
>

---

From: Daniel McCarney <[email-masked]>
Date: Thu, 9 Aug 2018 10:40:01 -0400

Thanks for the review/PRs Sean.

I left a +1 for PR 433. Richard: can that be merged?

I left some feedback on PR 432 and a question on issue 435.

On Wed, Aug 8, 2018 at 11:42 PM, Sean Turner <[email-masked]> wrote:

> > 14) s9.1: Was there any thought given to an optional parameter
> indicating how many certs would be in the chain?
> >
> > 15) s9.3: Should the reference be: [this-RFC, Section 6.4.1] to match
> some of the other entries in the registry?  Or at least refer to [this-RFC]?
> >
> > Cheers,
> >
> > spt
> >
> >
> >
>
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 9 Aug 2018 11:30:16 -0400

I merged 433 and +1'ed some of your comments on 432.

People on the mailing list: Please note there is some discussion in the
linked issues.

--Richard

On Thu, Aug 9, 2018 at 10:40 AM Daniel McCarney <[email-masked]> wrote:

>> > These are all minor so I didn’t send them to [email-masked].  Also,
>> once we settle on whether these are okay, I can submit a PR if you’d like
>> (or not if that’ll be faster).
>> >
>> > 0) abstract
>> >