Re: [Acme] Confirming consensus

2018-07-25 Thread Eric Rescorla
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

2018-07-25 Thread Salz, Rich
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

2018-07-23 Thread Benjamin Kaduk
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

2018-07-19 Thread Roland Shoemaker
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

2018-07-19 Thread Richard Barnes
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

2018-07-19 Thread Ilari Liusvaara
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

2018-07-19 Thread Roland Shoemaker
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

2018-07-18 Thread Salz, Rich
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

2018-07-18 Thread Salz, Rich
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

2017-07-31 Thread Salz, Rich
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