These are all minor so I didn’t send them to [email protected]. 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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
