Re: [Acme] Last Call: (Automatic Certificate Management Environment (ACME)) to Proposed Standard
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 wrote:
> 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 wrote:
>
>> 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 wrote:
>> >
>> > Without looking at them in context that seem pretty reasonable. Happy
>> to review a PR.
>> >
>> > On Wed, Aug 8, 2018, 21:03 Sean Turner wrote:
>> > These are all minor so I didn’t send them to i...@ietf.org. 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
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Last Call: (Automatic Certificate Management Environment (ACME)) to Proposed Standard
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 wrote:
> 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 wrote:
> >
> > Without looking at them in context that seem pretty reasonable. Happy
> to review a PR.
> >
> > On Wed, Aug 8, 2018, 21:03 Sean Turner wrote:
> > These are all minor so I didn’t send them to i...@ietf.org. 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
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Last Call: (Automatic Certificate Management Environment (ACME)) to Proposed Standard
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 wrote:
>
> Without looking at them in context that seem pretty reasonable. Happy to
> review a PR.
>
> On Wed, Aug 8, 2018, 21:03 Sean Turner wrote:
> These are all minor so I didn’t send them to i...@ietf.org. 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
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Last Call: (Automatic Certificate Management Environment (ACME)) to Proposed Standard
Without looking at them in context that seem pretty reasonable. Happy to
review a PR.
On Wed, Aug 8, 2018, 21:03 Sean Turner wrote:
> These are all minor so I didn’t send them to i...@ietf.org. 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
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
[Acme] Last Call: (Automatic Certificate Management Environment (ACME)) to Proposed Standard
NOTE: This is a second last call because of significant changes in -13. The IESG has received a request from the Automated Certificate Management Environment WG (acme) to consider the following document: - 'Automatic Certificate Management Environment (ACME)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-08-08. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Certificates in PKI using X.509 (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. Today, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a certification authority (CA) and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme [1]. Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantive change should be discussed on the ACME mailing list (acme@ietf.org). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ballot/ No IPR declarations have been submitted directly on this I-D. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Last Call: (Automatic Certificate Management Environment (ACME)) to Proposed Standard
The IESG has received a request from the Automated Certificate Management Environment WG (acme) to consider the following document: - 'Automatic Certificate Management Environment (ACME)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-04-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Certificates in PKI using X.509 (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. Today, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a certification authority (CA) and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme [1]. Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantive change should be discussed on the ACME mailing list (acme@ietf.org). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ballot/ No IPR declarations have been submitted directly on this I-D. Last call has been extended an additional 2 weeks due to last call being issued during an IETF meeting. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
