Re: [Acme] WGLC comments: draft-ietf-acme-tls-alpn-01 (Re: Confirming consensus)
On Thu, Aug 9, 2018 at 12:32 PM Sean Turner wrote: > 5) General: Okay so I’m no cryptographer, but should the hash algorithm used > in the challenge correspond to the hash algorithm used in the PRF/HKDF? I > mean if I’m going to use TLS 1.3 and TLS_AES_256_GCM_SHA384 should I really > use SHA-256? The same input isn't fed into two different PRFs, so I believe that this is OK. ___ 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
[Acme] WGLC comments: draft-ietf-acme-tls-alpn-01 (Re: Confirming consensus)
Couple of comments: 0) s2: Use the update text: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1) s3: For the base64URL safe text can you point to the base document; I think it’s s6.1? 2) s3/s5.1: OID CLASH! id-pe 30 is already assigned. See: https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1 3) s4: Insert obligatory reference to RFC4086 (https://datatracker.ietf.org/doc/rfc4086/) for the randomness considerations of the token. I’ll submit something against acme-acme so you may just be able to borrow that. 4) General: How are you addressing the algorithm agility concerns raised in BCP 201 (https://datatracker.ietf.org/doc/rfc7696/)? Is it just going to be v2 if you need SHA-384? 5) General: Okay so I’m no cryptographer, but should the hash algorithm used in the challenge correspond to the hash algorithm used in the PRF/HKDF? I mean if I’m going to use TLS 1.3 and TLS_AES_256_GCM_SHA384 should I really use SHA-256? 6) s5: I’d probably just add the following in s5. I think everybody knows what’s going on, but it’s good to be specific: [[RFC Editor: please replace below by the RFC number.]] spt > On Jul 18, 2018, at 15:56, Salz, Rich > wrote: > > For completeness, these are > draft-ietf-acme-acme-13 > draft-ietf-acme-tls-alpn-01 > draft-ietf-acme-ip-02 > > From: Rich Salz > Date: Wednesday, July 18, 2018 at 2:47 PM > To: "acme@ietf.org" > Subject: Confirming consensus > > As discussed in a separate thread, we added mandatory-to-implement JSON > signing crypto (TLS 1.3 signing algorithms); note that this does not affect > the certificates themselves. > > We decided to move draft-ietf-acme-tls-alpn and draft-ietf-acme-ip to working > group last call. > > If you disagree with either of these decisions, please speak up by Monday. > Note that the WGLC for the main document is being re-run in parallel with > IESG and soon IETF review. > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] WGLC call for draft-ietf-acme-star-03
A couple of comments: 0) abstract: r/exposed to an attacker/exposed to an unauthorized user It’s not just attackers, you could unwittingly disclose your key and still need to revoke it. 1) abstract and s1.2: in abstract: r/short- term and automatically renewed (STAR) certificates/short- term and automatically renewed (STAR) X.509 certificates in s1.2: r/Short-Term, Automatically Renewed X.509 certificates/Short-Term and Automatically Renewed X.509 certificates. 2) s1.1 and s1.2: Identity Owner or Identifier Owner? 3) s1.3: Use the text BCP14: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 4) s2 and s1.2: I think you should drop the term NDC and the paragraph describing the optional protocol. You can easily say in I-D.sheffer-acme-star-request that the model in draft-ietf-acme-star can be extended to also include the NDC. I kept thinking why on earth is NDC here - it’s only mentioned twice (after s5 is removed) and clearly looks like a hook that is not needed in this draft. You already get the reference to I-D.sheffer-acme-star-request from s1.1. I could see dropping that section too, frankly. 5) s2.3: An error is returned in step 2. I didn’t see a “terminated” error in draft-ietf-acme-amce and there’s not one defined here. 6) s3.1.1: Can you use the same way of describing the attributes as in draft-ietf-acme-acme: e.g. recurrent (required, boolean). 6) s3.1.1: should recurrent-start-date "optional" be “OPTIONAL”? It’s stating a 2119-requirement right? 7) s3.1.1: What is returned if the notBefore and notAfter is included? 8) s3.2: Again can you use the same way of describing the attributes as draft-ietf-acme-acme. 9) s4.1: It seems like some of this advice is just about STAR certificates it seems to be providing advice about *all* server certificates. Does it belong in this draft? 10) s7.2: While I tend to agree that defining the time for "short” is probably futile don’t you at least have to address some kind of concerns about getting it wrong? spt > On Jul 26, 2018, at 10:36, Salz, Rich > wrote: > > This message begins a two-week working group last call for > draft-ietf-acme-star-03. This was supposed to enter WGLC at IETF 101 in > London, but the chairs dropped the ball. > > If anyone is willing to shepherd this document, please also speak up. > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme ___ 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
Re: [Acme] Last Call: (Automatic Certificate Management Environment (ACME)) to Proposed Standard
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
