Subject: IETF blog post on ACME

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2019 13:38:21 -0700

Hey all,

In honor of ACME finally being published as an RFC, my co-authors and I
wrote a quick blog post announcing ACME and why it matters:

https://www.ietf.org/blog/acme/

The tl;dr is:
- Certificates are necessary to make secure applications scale
- Getting a certificate used to be hard, but ACME makes it easy
- Now we can encrypt all the things!

For those of you more at the networking layer, think of it like DHCP --
long ago, IP address assignment was manual and slow, and we needed an
automated way of handing out addresses to make the Internet scale.  Same
thing here, but for the PKI.

Sincere thanks to the many contributors to this work!

--Richard

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 13 Mar 2019 01:16:41 +0000 (UTC)

Richard, 

your IETF blog post says:

"the server that needs a certificate can send in its information in a standard form"
I do get nervous seeing the 'standard' word used in IETF material; the IETF has a specific standards process, IETF material has to be careful in its terminology.

While RFC 8555 is published as an RFC and as a proposed standard, it is not yet an IETF standard.

The Let's Encrypt crowd have been saying: 

"The protocol we use for automated certificate management, ACME, is now finalized as an Internet standard!"
or
"the ACME protocol became an IETF standard with RFC 8555."
or
"
The ACME Protocol is an IETF Standard

It has long been a dream of ours for there to be a standardized protocol for certificate issuance and management. That dream has become a reality now that the IETF has standardized the ACME protocol as RFC 8555."
https://letsencrypt.org/2019/03/11/acme-protocol-ietf-standard.html

which is slightly overstating it (proposed standard is NOT finalized and is NOT an IETF Standard), while inadvertently(?) dismissing the IETF standards process that you'd think active participants would understand...

"in an agreed form" is less misleading, I think.

sigh.

L.
 
Lloyd Wood [email-masked] http://about.me/lloydwood

________________________________
From: Richard Barnes <[email-masked]>
To: IETF discussion list <[email-masked]> 
Sent: Wednesday, 13 March 2019, 7:39
Subject: IETF blog post on ACME

Hey all,

In honor of ACME finally being published as an RFC, my co-authors and I wrote a quick blog post announcing ACME and why it matters:

The tl;dr is:

For those of you more at the networking layer, think of it like DHCP -- long ago, IP address assignment was manual and slow, and we needed an automated way of handing out addresses to make the Internet scale.  Same thing here, but for the PKI.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Wed, 13 Mar 2019 07:28:27 -0400

Hi Lloyd,

In all honesty, I think you've got things the wrong way around here.
Rather than building a wall around the word "standard" and trying to police
it, we should be thinking about whether our usage of those terms makes
sense in the market.

The posts from Let's Encrypt et al. provide data that are informative on
this question.  Many of the participants in the ACME process were newcomers
to the IETF.  That they've put in all the effort to get an RFC published
and still failed to note the various maturity levels should be instructive.

Further discussion on this point is probably a topic for another thread,
though.

--Richard

On Tue, Mar 12, 2019 at 9:17 PM Lloyd Wood <[email-masked]> wrote:

> I do get nervous seeing the 'standard' word used in IETF material; the
> IETF has a specific standards process, IETF material has to be careful in
> its terminology.
>
>
> It has long been a dream of ours for there to be a standardized protocol
> for certificate issuance and management. That dream has become a reality
> now that the IETF has standardized the ACME protocol as RFC 8555."
> which is slightly overstating it (proposed standard is NOT finalized and
> is NOT an IETF Standard), while inadvertently(?) dismissing the IETF
> standards process that you'd think active participants would understand...
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Mar 2019 07:11:04 -0700

> not yet an IETF standard.

This distinction, while true, seems not very helpful.

Many of the most important and widely implemented documents in the IETF are
PS and may take a very long time to be promoted to FS, if ever (IPv6 was
only so promoted last year!). Given that, people often wait to implement
and deploy protocols until they are "standardized" or "finalized", trying
to stop people from calling those documents standards seems
counterproductive (as well as largely futile).

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Mar 2019 07:13:10 -0700

On Wed, Mar 13, 2019 at 7:11 AM Eric Rescorla <[email-masked]> wrote:

> Many of the most important and widely implemented documents in the IETF
> are PS and may take a very long time to be promoted to FS, if ever (IPv6
> was only so promoted last year!). Given that,
>

I don't usually correct myself, but this actually changes the meaning.
There should be no comma after "Given that".

-Ekr

people often wait to implement and deploy protocols until they are
> "standardized" or "finalized", trying to stop people from calling those
> documents standards seems counterproductive (as well as largely futile).
>
> -Ekr
>
>
>
>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 13 Mar 2019 08:37:49 -0700

Lloyd: The blog's usage of "standard" is just regular English ("the server
that needs a certificate can send in its information in a standard form"),
and I don't find this usage problematic in the blog.

FWIW, I'll echo the thought that we really should re-consider our
terminology in light of the actual semantics of our documents in the
marketplace. It's long overdue.

- jana

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Mar 2019 11:38:20 -0400 (EDT)

On Wed, 13 Mar 2019, Eric Rescorla wrote:

> On Tue, Mar 12, 2019 at 6:17 PM Lloyd Wood <lloyd.wood=[email-masked]> wrote:
>       Richard,
> 
>
>       I do get nervous seeing the 'standard' word used in IETF material; the IETF has a specific standards
>       process, IETF material has to be careful in its terminology.
> 
>

And the distinction is only really known by people at the IETF who have
reached nomcom acceptable status. The real world out there only knows
"It's an RFC standard" and "It's not an RFC".

I would be happy if the IETF retired the distinction between Proposed
Standard, Draft Standard and Internet Standard.

I do think Experimental and Informational are useful :)

Paul

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 13 Mar 2019 17:32:15 +0100

> Standard, Draft Standard and Internet Standard.

RFC6410 Reducing the Standards Track to Two Maturity Levels. R. Housley, D.
     Crocker, E. Burger. October 2011. (Format: TXT=12619 bytes) (Updates
     RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI:
     10.17487/RFC6410) 

We already got rid of Draft Standard at the beginning of the decade.

Both Proposed Standard and Internet Standard are IETF standards documents, or standards for short.  If you want to talk about the “Internet Standard” maturity level, “Full Standard” is acceptable vernacular as well.
(Don’t ever use “standards-track” outside IETF… Very confusing. 
Sounds like “tenure track”, as in “not yet quite a standard”.)

Grüße, Carsten

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 14 Mar 2019 00:47:27 +0000 (UTC)

So Proposed standard is a standards document from the IETF, which
is to say that it's an IETF standard, or an Internet standard.

While an Internet Standard is... an Internet Standard.

The capitalization of the S is more crucial here than in
IPsec. Or IPSec. Or IPSEC.

And putting 'Category: Standards Track' on the RFCs doesn't help.
That's a capital S!

Perhaps actual Internet Standards should be given over to
a different organisation - the Internet Standards Organisation,
or ISO, say, so that it's clear than an IETF standard is not a
Standard, because only ISO does Full Actual Capitalized Standards.

Getting rid of Draft Standard lessened confusion with
internet-drafts, which could be considered as draft Draft
Standards. Now, internet-drafts can only be considered to

be proposed Proposed Standards, at least when they're not being
claimed to be Internet standards. Is this an improvement?

L.

I would be happy if the IETF retired.

________________________________
From: Carsten Bormann <[email-masked]>
To: Paul Wouters <[email-masked]> 
Cc: [email-masked]
Sent: Thursday, 14 March 2019, 3:33
Subject: Re: IETF blog post on ACME

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Mar 2019 07:53:12 +0100

On Mar 14, 2019, at 01:47, Lloyd Wood <[email-masked]> wrote:
> is to say that it’s an IETF standard,

Yes.

> or an Internet standard.

No.  That term has unfortunately been taken.
But nobody notices if we simply don’t use it for PS level documents, and nobody will be confused.

> While an Internet Standard is… an Internet Standard.

Yes.

> IPsec. Or IPSec. Or IPSEC.

The proper capitalization is a competence signal.  You don’t have to send that signal.

> And putting ‘Category: Standards Track' on the RFCs doesn't help.

No, it doesn’t.

> That’s a capital S!

Title case.

> Standard, because only ISO does Full Actual Capitalized Standards.

You express your confusion.  I can’t blame you, but we’ll still need to express our disagreement.
Standards for the Internet (which include both levels of maturity) are usually done by the IETF.

> claimed to be Internet standards. Is this an improvement?

Yes.  And it has been for 7.5 years or so.

> I would be happy if the IETF retired.

That, unfortunately, is an attitude that won’t help us achieve our goal.

I’m not going to feed the fauna on this any further, but, yes, terms are important, and the fact that in our usage “Internet Standard” means something different than “Standard for the Internet” is indeed suboptimal.

Changing the terms again would lead to even more confusion in the short term, but might improve things in the long term.  That cost vs. benefit ratio is for anyone to ponder.

Grüße, Carsten

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 14 Mar 2019 09:18:58 -0400

> Yes.  And it has been for 7.5 years or so.

It's really just a process issue for many documents.  If there are 2 or
more interoperable implementations and a fair amount of time has passed to
test them out, a proposed standard can be moved to a full Internet
Standard.  If it's deemed important, documents can easily go though this
process.  ACME has way more than 2 implementations, so I don't think that
will be a hurdle for it moving to an Internet Standard if people are
motivated to make that happen.

Best regards,
Kathleen

> I’m not going to feed the fauna on this any further, but, yes, terms are
> important, and the fact that in our usage “Internet Standard” means
> something different than “Standard for the Internet” is indeed suboptimal.
>
> Changing the terms again would lead to even more confusion in the short
> term, but might improve things in the long term.  That cost vs. benefit
> ratio is for anyone to ponder.
>
> Grüße, Carsten
>
>

-- 

Best regards,
Kathleen

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 14 Mar 2019 11:51:30 -0500

> We already got rid of Draft Standard at the beginning of the decade.

And, if you thought that was the right thing to do ...

>
> Both Proposed Standard and Internet Standard are IETF standards documents,
> or standards for short.  If you want to talk about the “Internet Standard”
> maturity level, “Full Standard” is acceptable vernacular as well.

... you might or might not love
https://www.ietf.org/archive/id/draft-loughney-newtrk-one-size-fits-all-01.txt

(NB: I'm listed as co-author, but IIRC John Loughney was the one who said,
"screw it, we'll never train the rest of the world how we wish the IETF
standards process works, let's just have standards and be done with it!".
After that, the draft practically wrote itself).

As Carsten points out, we've taken half the steps to the 2006
no-maturity-levels proposal already. We just have to take the other half,
if the community thought that was the right thing to do.

Spencer

---

From: S Moonesamy <[email-masked]>
Date: Sat, 16 Mar 2019 12:11:29 -0700

Hi Richard,
At 04:28 AM 13-03-2019, Richard Barnes wrote:
>The posts from Let's Encrypt et al. provide data that are 
>informative on this question.  Many of the participants in the ACME 
>process were newcomers to the IETF.  That they've put in all the 
>effort to get an RFC published and still failed to note the various 
>maturity levels should be instructive.

Certificates which are automatically accepted by a web browser were 
not free before.  The change brought by "Let's Encrypt" is the 
availability of free certificates.

There is the following in the blog article: "Security protocols such 
as TLS 1.3 provide encryption that protects ..."  The video displays 
the following "The connection uses TLS 1.2".

There is an image about web pages using HTTPS over time [1].  Is 
there any data about the number of web pages at the continental level?

Regards,
S. Moonesamy

1. 
https://www.ietf.org/media/images/Screen_Shot_2019-03-12_at_2.53.28_PM.original.png

---

From: Richard Barnes <[email-masked]>
Date: Sat, 16 Mar 2019 15:25:16 -0400

Hi SM,

Responses inline.

> availability of free certificates.

That's not all.  Let's Encrypt enabled free and *automatic* certificate
issuance, both of which helped the ecosystem grow.  The standardization of
ACME allows the "automatic" part to be used across the rest of the industry.

> the following "The connection uses TLS 1.2".

It's an old video :)  And obviously, the same applies to TLS 1.2.

> there any data about the number of web pages at the continental level?

I don't have that data; someone at Mozilla might be able to derive it from
their telemetry.  The source of that graph is <
https://letsencrypt.org/stats/>, which has the US and Japan broken out.

Hope that helps,
--Richard

---

From: S Moonesamy <[email-masked]>
Date: Sat, 16 Mar 2019 13:07:54 -0700

Hi Richard,
At 12:25 PM 16-03-2019, Richard Barnes wrote:
>That's not all.  Let's Encrypt enabled free and 
>*automatic* certificate issuance, both of which 
>helped the ecosystem grow.  The standardization 
>of ACME allows the "automatic" part to be used across the rest of the industry.

Ok.

Yes.

>I don't have that data; someone at Mozilla might 
>be able to derive it from their telemetry.Â  The 
>source of that graph is 
><<https://letsencrypt.org/stats/>https://letsencrypt.org/stats/>, 
>which has the US and Japan broken out.

Thanks for the helpful hint.

Regards,
S. Moonesamy

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 17 Mar 2019 22:07:17 +0100

On Mar 14, 2019, at 17:51, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> … you might or might not love https://www.ietf.org/archive/id/draft-loughney-newtrk-one-size-fits-all-01.txt

Actually, I don’t agree with that document at all.
The statistics used as an (pretty much the main, actually) argument in that document are really not that relevant.
It argues that, at the time, we produced around a hundred new PS documents per year, and about ten new IS documents.  So what?

I’m experiencing the upgrade of a standard from PS to IS right now.
In this process, we have the unique opportunity to really focus on interoperability.
The question is not what to add, but what we need to remove or (slightly) tweak because it didn’t quite interoperate.
The additional quality that we can instill to the final outcome of this process is significant.

So, yes, I see a substantial benefit in producing Internet Standard documents as defined in RFC 6410, and I will be a vocal proponent of keeping the two-step process, even it is only exercised by a small percentage of the standards documents and the fine points about it may not be understood by external experts.

In the end, the unique selling proposition of the IETF is the quality of the standards it produces, and the PS to IS advancement process is rather unique compared to the various review and advancement processes that other SDOs have.

My only critique of RFC 6410 would be that it wasn’t radical enough in revisiting the names we gave to the two stages — they are just not very intuitive (read: outright misleading) for somebody who is familiar with other SDOs.  This is where most of the confusion comes from, not from the two-stage process itself.

Grüße, Carsten

---

From: Keith Moore <[email-masked]>
Date: Sun, 17 Mar 2019 20:38:10 -0400

I'm also very much in favor of retaining the two-step process.

One potential improvement would be for PS RFCs to specify how to perform 
interoperability tests, and where/how to report the results of 
interoperability tests.    A lot of the effort at moving to IS is 
getting people to do the interoperability tests and report the 
results.   And if the tests were designed along with the protocols, 
maybe that would create an incentive to make the protocols less complex.

Keith

On 3/17/19 5:07 PM, Carsten Bormann wrote:
>> … you might or might not love https://www.ietf.org/archive/id/draft-loughney-newtrk-one-size-fits-all-01..txt

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Mar 2019 18:22:24 -0400

Keith Moore <[email-masked]> wrote:
    > interoperability tests.    A lot of the effort at moving to IS is getting
    > people to do the interoperability tests and report the results.   And
    > if the
    > tests were designed along with the protocols, maybe that would create an
    > incentive to make the protocols less complex.

I don't know what's going to happen to codestand.ietf.org, but that
system would seem to be a good place to expand as the place to report to.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-