Re: [Acme] Confirming consensus
On Wed, Jul 25, 2018 at 9:46 AM, Salz, Rich < rsalz=40akamai@dmarc.ietf.org> wrote: > There was no email, other than process comments, on these. Therefore they > are (re-)entering WGLC. > > > > @ekr, please put draft-ietf-acme-acme-13 on the IESG agenda. > Due to the changes between -12 and -13, I believe it is appropriate to have another IETFLC. I have requested that. -Ekr > > The other two documents are very short. Does anyone volunteer to do the > shepherd writeup? You can look at https://datatracker.ietf.org/ > doc/draft-ietf-acme-acme/shepherdwriteup/ for a sample. This is a good > way for someone new to the IETF process to get involved. > > > > > > *From: *Rich Salz > *Date: *Wednesday, July 18, 2018 at 3:56 PM > *To: *"acme@ietf.org" > *Subject: *Re: Confirming consensus > > > > 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] Confirming consensus
There was no email, other than process comments, on these. Therefore they are (re-)entering WGLC. @ekr, please put draft-ietf-acme-acme-13 on the IESG agenda. The other two documents are very short. Does anyone volunteer to do the shepherd writeup? You can look at https://datatracker.ietf.org/doc/draft-ietf-acme-acme/shepherdwriteup/ for a sample. This is a good way for someone new to the IETF process to get involved. From: Rich Salz Date: Wednesday, July 18, 2018 at 3:56 PM To: "acme@ietf.org" Subject: Re: Confirming consensus 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
Re: [Acme] Confirming consensus
On Fri, Jul 20, 2018 at 12:05:05AM +0300, Ilari Liusvaara wrote: > On Thu, Jul 19, 2018 at 01:03:14PM -0700, Roland Shoemaker wrote: > > One thing that I forgot to bring up during the meeting was an issue > > that was brought up with regards to the order in which the ACME-TLS-ALPN > > and ACME-IP drafts are standardized. ACME-IP defines how to use IP > > addresses with existing challenges and we’d like to include guidance > > on how to do so with TLS-ALPN, but (as far as I’m aware) we are unable > > to reference IDs in RFCs so we cannot directly reference > > draft-ietf-acme-tls-alpn > > This is incorrect. IDs can normatively reference other IDs, if > there is a "plan" on getting the referenced ID ready to be published. > If needed, the referencing draft waits for the referenced one in > RFC-Editor queue. To expound a bit more, an I-D that gets approved to be an RFC while including a normative reference on another I-D will get stuck in the "MISSREF" state until the depended-on RFC is also ready for publication; this generally also includes the creation of a "cluster" or related proto-RFCs. It is perfectly acceptable for final, published RFCs to have *informative* references to I-Ds, even I-Ds which are not necessarily expected to be published as RFCs. > So I think the easiest way is to just have normative reference > ACME-IP -> TLS-ALPN. This results in them both getting published at the same time, but that is probably fine. -Ben ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Confirming consensus
Ah, awesome. Well that makes life a lot easier! I’ll work to get a version of ACME-IP that includes this up today or tomorrow. > On Jul 19, 2018, at 2:05 PM, Ilari Liusvaara wrote: > > On Thu, Jul 19, 2018 at 01:03:14PM -0700, Roland Shoemaker wrote: >> One thing that I forgot to bring up during the meeting was an issue >> that was brought up with regards to the order in which the ACME-TLS-ALPN >> and ACME-IP drafts are standardized. ACME-IP defines how to use IP >> addresses with existing challenges and we’d like to include guidance >> on how to do so with TLS-ALPN, but (as far as I’m aware) we are unable >> to reference IDs in RFCs so we cannot directly reference >> draft-ietf-acme-tls-alpn > > This is incorrect. IDs can normatively reference other IDs, if > there is a "plan" on getting the referenced ID ready to be published. > If needed, the referencing draft waits for the referenced one in > RFC-Editor queue. > > So I think the easiest way is to just have normative reference > ACME-IP -> TLS-ALPN. > > > -Ilari ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Confirming consensus
On Thu, Jul 19, 2018, 17:05 Ilari Liusvaara wrote: > On Thu, Jul 19, 2018 at 01:03:14PM -0700, Roland Shoemaker wrote: > > One thing that I forgot to bring up during the meeting was an issue > > that was brought up with regards to the order in which the ACME-TLS-ALPN > > and ACME-IP drafts are standardized. ACME-IP defines how to use IP > > addresses with existing challenges and we’d like to include guidance > > on how to do so with TLS-ALPN, but (as far as I’m aware) we are unable > > to reference IDs in RFCs so we cannot directly reference > > draft-ietf-acme-tls-alpn > > This is incorrect. IDs can normatively reference other IDs, if > there is a "plan" on getting the referenced ID ready to be published. > If needed, the referencing draft waits for the referenced one in > RFC-Editor queue. > > So I think the easiest way is to just have normative reference > ACME-IP -> TLS-ALPN. > +1 > > -Ilari > > ___ > 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] Confirming consensus
On Thu, Jul 19, 2018 at 01:03:14PM -0700, Roland Shoemaker wrote: > One thing that I forgot to bring up during the meeting was an issue > that was brought up with regards to the order in which the ACME-TLS-ALPN > and ACME-IP drafts are standardized. ACME-IP defines how to use IP > addresses with existing challenges and we’d like to include guidance > on how to do so with TLS-ALPN, but (as far as I’m aware) we are unable > to reference IDs in RFCs so we cannot directly reference > draft-ietf-acme-tls-alpn This is incorrect. IDs can normatively reference other IDs, if there is a "plan" on getting the referenced ID ready to be published. If needed, the referencing draft waits for the referenced one in RFC-Editor queue. So I think the easiest way is to just have normative reference ACME-IP -> TLS-ALPN. -Ilari ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Confirming consensus
One thing that I forgot to bring up during the meeting was an issue that was brought up with regards to the order in which the ACME-TLS-ALPN and ACME-IP drafts are standardized. ACME-IP defines how to use IP addresses with existing challenges and we’d like to include guidance on how to do so with TLS-ALPN, but (as far as I’m aware) we are unable to reference IDs in RFCs so we cannot directly reference draft-ietf-acme-tls-alpn (and if we were to include guidance on how to use TLS-ALPN with IPs in draft-ietf-acme-tls-alpn we could not directly reference draft-ietf-acme-ip). It might be possible to do this in draft-ietf-acme-tls-alpn by skirting around any references to IP identifiers and just provide the guidance on how to do this _if there is a way_ to do IP for validation but it feels a bit hacky. Does anyone have strong opinions on how to handle this? I feel like the best approach may be to just wait for one document to be standardized and then move onto the second one (probably TLS-ALPN first since it’s slightly more important from my perspective but ¯\_(ツ)_/¯). > On Jul 18, 2018, at 11:47 AM, Salz, Rich > wrote: > > 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] Confirming consensus
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] 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] Confirming consensus
At the IETF last week we had unanimous consensus to change the CAA draft so that it used the term "validation-methods" and not "acme-methods" Does anyone disagree? Please speak up in the next couple of days if you do not agree. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter: RichSalz ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
