Re: [Acme] Last Call: (Automatic Certificate Management Environment (ACME)) to Proposed Standard

2018-08-09 Thread Richard Barnes
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

2018-08-09 Thread Daniel McCarney
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