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
On Wed, Mar 13, 2019 at 7:14 AM Eric Rescorla <ekr@xxxxxxxx> wrote:
On Wed, Mar 13, 2019 at 7:11 AM Eric Rescorla <ekr@xxxxxxxx> wrote:On Tue, Mar 12, 2019 at 6:17 PM Lloyd Wood <lloyd.wood=40yahoo.co.uk@xxxxxxxxxxxxxx> wrote: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.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,I don't usually correct myself, but this actually changes the meaning. There should be no comma after "Given that".-Ekrpeople 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
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 lloyd.wood@xxxxxxxxxxx http://about.me/lloydwood
________________________________
From: Richard Barnes <rlb@xxxxxx>
To: IETF discussion list <ietf@xxxxxxxx>
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:
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
