Subject: [Acme] Confirming consensus

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Jul 2018 18:47:48 +0000

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.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Jul 2018 19:56:29 +0000

For completeness, these are
                draft-ietf-acme-acme-13
                draft-ietf-acme-tls-alpn-01
                draft-ietf-acme-ip-02

From: Rich Salz <[email-masked]>
Date: Wednesday, July 18, 2018 at 2:47 PM
To: "[email-masked]" <[email-masked]>
Subject: Confirming consensus

---

From: Roland Shoemaker <[email-masked]>
Date: Thu, 19 Jul 2018 13:03:14 -0700

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 <rsalz=[email-masked]> wrote:
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 20 Jul 2018 00:05:05 +0300

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Jul 2018 17:06:46 -0400

> So I think the easiest way is to just have normative reference

+1

---

From: Roland Shoemaker <[email-masked]>
Date: Thu, 19 Jul 2018 14:32:45 -0700

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 <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 23 Jul 2018 12:37:38 -0500

> If needed, the referencing draft waits for the referenced one in

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

This results in them both getting published at the same time, but that is
probably fine.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Jul 2018 16:46:22 +0000

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 <[email-masked]>
Date: Wednesday, July 18, 2018 at 3:56 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: Confirming consensus

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Jul 2018 09:49:07 -0700

> @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 <[email-masked]>
> *Date: *Wednesday, July 18, 2018 at 3:56 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *Re: Confirming consensus
>
>
>
> *From: *Rich Salz <[email-masked]>
> *Date: *Wednesday, July 18, 2018 at 2:47 PM
> *To: *"[email-masked]" <[email-masked]>
> *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.
>
>
>
> 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.
>
>
>
>
>