Subject: [Acme] Considerations about ACME BoF

From: Massimiliano Pala <[email-masked]>
Date: Fri, 27 Mar 2015 09:32:22 -0500

Dear ACME BoF-ers,

when I started to write this e-mail I did not expect to get this long - 
since the content might be a bit controversial, I would encourage people 
to stick to the technical arguments and not start a flame war about the 
topics (that happened in the past.. many, many, many times...).

After attending the BoF and speaking with several people, I feel 
compelled to bring to the community's attention some concerns about 
ACME. I have two different types of concerns - procedural (and this 
might require a broader audience, probably a cross post to the ietf ml), 
and technical. I would like people commenting on both.

I think that ALL of the following points should be addresses before any 
decision about forming a new WG or even adopting the proposed I-D as a 
working item is taken.

Here's my concerns.

_*Procedural Issues.*_

*Let's Encrypt.* When the "Let's Encrypt" initiative was presented, I 
was quite confused about the scope. We all agree that IETF is about 
defining protocols on the wire - not promoting specific products or 
business models. However, in this case, I was under the impression that 
the IETF was sponsoring a specific piece of software and a new CA 
initiative that will be soon operational. Besides the fact that the new 
Let's Encrypt CA might (maybe not now) be a commercial viable 
initiative, my question is: why a non-existing, commercially viable, 
non-standard-based initiative is being presented at the IETF ? This is 
really troublesome especially in the view of this creating a precedence. 
What happens when another vendor comes to IETF and presents similar 
pitches about their products - what basis do we have to deny that 
presentation anymore ? This, I think, it is a really important point 
that should be discussed deeply.

*Overstepping the Technical Boundaries.* As it was pointed out during 
the BoF, the proposed initiative does not address any technical issue, 
but, instead, is pushing a specific BUSINESS model. I found very 
inappropriate the examples of "I could not get my certificates in 45 
minutes.." as this is a NON argument. Besides the many issues about an 
automated certificate issuance (even for just a DV cert), the choices 
made by current Internet CAs (I am referring to Internet CAs because for 
corporate or "closed" PKIs automation HAS NEVER BEEN A PROBLEM by using 
current standards) are based on POLICY decisions and not technical 
merits. Is IETF going to be in the policy decision business instead of 
focusing on technical aspects of interoperability?

*Real Scope of ACME.* I think there should be a discussion about where 
this work is supposed to land. If it is another attempt (as noted during 
the BoF) to push further DANE (even when, as pointed out during the BoF, 
there is not much real interest in the real world for it) possibly to 
replace work like WebPKI or PKIX protocols, this should be clearly 
stated. Also, if that is the case, I think we are potentially choosing a 
single-point-of-failure model for trust (DNSSEC) which is scary and 
dangerous especially from a privacy perspective considering who is in 
control of top-domain keys. Privacy advocates should really be concerned 
about this issue.

_*Technical Issues.*_

*Reinventing the Wheel.* During the meeting I already expressed my 
concerns about many different aspects of the proposed scope. First off, 
we have a serious problem with overlapping over EXISTING IETF standards 
for message formats that are perfectly viable and currently deployed in 
a lot of environments. I am referring to the CMC / CMS / EST. Lot of 
time and engineering efforts have been spent over these formats and tons 
of certificates are, today, managed using these formats. Moreover, these 
formats allow for deploying systems with multiple factors of 
authentication and hardware tokens. I should not have to explain to the 
IETF community the horrible mistake to have multiple competing standards 
(we went down that road in the past and it was A HORRIBLE DISASTER) - 
that is why, at each level of the IETF, much attention has been paid to 
avoid this situation. I do not see why this is an exception to this very 
important principle. If the work in the potential WG will continue, ARE 
WE GOING TO RETIRE EXISTING STANDARDS ?

*Message Format.* The argument about ASN.1 vs JSON has to be re-framed 
in a TECHNICAL context instead of the not-so-appropriate argument "ASN.1 
is evil". First off, either we talk about JSON SCHEMA vs. ASN.1 or we 
talk about JSON vs. DER. These are two completely different arguments. 
Since we are at IETF, let's focus on the "bits on the wire". It seems to 
me that the choice is quite clear: DER. The format is much more well 
defined, more compact, and has the required flexibility to accommodate 
for the required data structures. JSON makes sense in a JavaScript 
environment (JavaScript Object Notation) - but not much more outside 
that. JSON is thought to be readable by humans (by design) and has 
several limitations when it comes to encoding binary data (additional 
encoding is required) or non-ASCII names (again, additional encoding is 
required). In a JS environment where everything is UTF16, that is not an 
issue (if you ever worked in the space you would know that that is not 
really true for binary data encoding), but in this context the format 
has SERIOUS limitations that makes it a POOR format choice for the job. 
Moreover, considering the requirement for supporting DER as the 
STANDARDIZED format for ALL PKIX objects, it seems a very odd choice to 
require the use of yet-another-data-format (less efficient when it come 
to the bits on the wire) on top of what already exists and needs to be 
supported. Are we going to change all data formats to JSON ? If not, I 
do not think there are technical reasons to adopt an inferior (from a 
bits-on-the-wire perspective) than what we have and works today.
*
**Weak Points in I-D. *As I pointed out during the BoF, the problem to 
solve about providing automation for certificate management is 
discoverability of the services provided by a CA. In particular, I am 
referring to the fact that even if you convince a CA to adopt 
yet-another-format, there is no discussion about how the different CAs 
will be "discovered" - which ones support the new protocol ? The 
draft-barnes-acme-01 says:

    " The ACME client presents the operator with a list of CAs from
           which it could get a certificate.
           (This list will change over time based on the capabilities of CAs
           and updates to ACME configuration.)  The ACME client might prompt
           the operator for payment information at this point."

This sentence makes sense only if it is referring to a specific piece of 
software - since the discoverability issue is not even mentioned, I 
assume that the authors of the software will have the power to 
DISCRIMINATE which CAs to support. Doesn't this seem NOT APPROPRIATE for 
a IETF wg ? Shouldn't there be a way to discover which CAs support which 
protocol ? If this problem was addressed first, there could be some 
ground for BEGINNING a discussion, but as it is written today, based 
just on this consideration, this document is a non-starter. Again, are 
we in the business of supporting a specific software? Moreover, how are 
the CAs identified ? By Name ? By the Hash of their certificates ? What 
trust is to be put in such a choice ? How stale can that information 
become ? Who is the authoritative information about what is supported by 
a vendor ?
*
**Issued Certificates Trust Issues.* Another important point is about 
what is the level of trust we want to achieve with the proposal and how 
this impacts the inclusion of CAs that support this protocol into 
standard trust stores (e.g., operating systems, browsers, MUAs, etc.) 
Since we have representatives from the browser's community (and I also 
hope from OSes), this is a question that needs to be addressed - would 
the adoption of this protocol be allowed for a Trusted CA ? Since there 
is no actual authentication of the requesting entity - the only level of 
certificates that can be issued is DV (and I have my doubts about that 
too). How is this better than current procedures from a trust 
perspective? Again, I know this is more of a POLICY related than 
technical issue - but these questions need an answer because the 
document itself oversteps the technical boundary, these are the type of 
discussions we also need to address.

_*Conclusions*_

Although I have always pushed for increasing the availability of 
certificates and the deployment of secure communications for almost 
20yrs now, I do think that the proposed work is a non-starter for all 
the reasons I described above. I would like the whole community and the 
area directors to discuss the points above before proceeding any further.

This is Just my personal opinion. Sorry for the long e-mail.

Best Regards,
Massimiliano Pala, Ph.D.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 Mar 2015 15:04:04 +0000

(Apologies - enigmail seems to be randomly sending mail that's
encrypted for me for some weird reason;-)

Hi Max,

Just addressing your "procedural" points.

> might require a broader audience, probably a cross post to the ietf ml),

If/when this list produces charter text that the IESG consider is
ready for review, then that'd be the time at which using the main
IETF list was most useful. (Before that happens, I suspect there'll
be plenty of mail on this list finally followed by a mail asking
for comment on the proposed wg charter that will be sent to the
ietf announce list and copied here.)

> that should be discussed deeply.

I don't agree. The letsencryt.org proposal is only one (proposed)
instance of a CA service, so I think maybe you ended up with the
wrong impression there. The folks working on that are willing to
do the work to produce a protocol that will be able to use any CA
service that wants to talk acme. That all seems like entirely normal
process to me. If we were standardising for a particular service,
I agree that would be problematic, but we are not. If it helps,
I'd block a charter that was only for one particular service.

At least one operational CA service (PHB/Commodo) have expressed
interest already and will I'm sure be active on this list, and
more such would of course be welcome.

> minutes.." as this is a NON argument.

With all due respect to Cullen, I agree:-) I think it's used as a
humorous anecdote basically and I've seen that done in quite a few
contexts in the IETF. But that one non-argument was raised is not
a procedural issue for me.

> Besides the many issues about an

No. But the fact that only about 30% of the alexa top 1M web sites
even do TLS after nearly 20 years shows that we have failed to
provide certificate management technology that sites have found
usable. The acme protocol is another attempt to address that
important audience via automation and some more "modern" tech. That
said, we've also learned a lot more about what helps things work
in this space and there is now a much increased interest in getting
https to be used, hopefully we learn from that and succeed this
time.

The point that automation intersects with policy is arguable I
agree, but again I don't see any procedural issue here. Those kind
of trade-offs are quite normal as we make changes to, or develop
new, protocols.

> control of top-domain keys. Privacy advocates should really be concerned

I think you ended up with the wrong impression here too. What I
heard at the BoF was that the acme proponents were by far most
interested in today's web sites, and today's web PKI, but that
they were not unfriendly to DANE. But even had they been focused
on trying to push the web PKI towards DANE (which is just not the
impression I got), that would be a technical and not a procedural
issue.

Cheers,
S.

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

_______________________________________________
Acme mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/acme

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 27 Mar 2015 16:32:55 +0100

On 2015-03-27 15:32, Massimiliano Pala wrote:

Since "I was there" when EST was created I would like to go back to that discussion.

One of the claimed "features" was that EST was dressed in ASN.1 because "this is what we have".  This is not entirely correct, ASN.1 is still after all these years not an intrinsic developer-exposed feature of Oracle's Java.

JSON is not a replacement for ASN.1, it is rather replacing XML. FIDO Alliance's new U2F token protocol is expressed in JSON so this seems to be where the industry is going.  I don't think we will ever get JSON-certificates though.

The biggest problem is really that NO certificate enrollment system has achieved real or de-facto standards status in end-user computers.  None of the platform vendors appear to have implemented support for EST which BTW isn't that strange since it didn't got a browser interface.

FWIW, I have created a credential enrollment (certificates+other stuff) system which is expressed in JSON and includes a pretty cool (I think so at least...) clear-text signature scheme.  I didn't experience any difficulties in integrating this from ground-up designed 8/10-pass (!) protocol in EJBCA, nor getting the client to run on Android:
https://cyberphone.github.io/openkeystore/resources/docs/keygen2.html#Sample_Run

Anyway, AMCE seems to stick to PKCS #10 (I did not since it doesn't support end-to-end security) so essentially you got what you wanted :-)

Cheers,
Anders

> Dear ACME BoF-ers,
>
> when I started to write this e-mail I did not expect to get this long - since the content might be a bit controversial, I would encourage people to stick to the technical arguments and not start a flame war about the topics (that happened in the past.. many, many, many times...).
>
> After attending the BoF and speaking with several people, I feel compelled to bring to the community's attention some concerns about ACME. I have two different types of concerns - procedural (and this might require a broader audience, probably a cross post to the ietf ml), and technical. I would like people commenting on both.
>
> I think that ALL of the following points should be addresses before any decision about forming a new WG or even adopting the proposed I-D as a working item is taken.
>
> Here's my concerns.
>
> _*Procedural Issues.*_
>
> *Let's Encrypt.* When the "Let's Encrypt" initiative was presented, I was quite confused about the scope. We all agree that IETF is about defining protocols on the wire - not promoting specific products or business models. However, in this case, I was under the impression that the IETF was sponsoring a specific piece of software and a new CA initiative that will be soon operational. Besides the fact that the new Let's Encrypt CA might (maybe not now) be a commercial viable initiative, my question is: why a non-existing, commercially viable, non-standard-based initiative is being presented at the IETF ? This is really troublesome especially in the view of this creating a precedence. What happens when another vendor comes to IETF and presents similar pitches about their products - what basis do we have to deny that presentation anymore ? This, I think, it is a really important point that should be discussed deeply.
>
> *Overstepping the Technical Boundaries.* As it was pointed out during the BoF, the proposed initiative does not address any technical issue, but, instead, is pushing a specific BUSINESS model. I found very inappropriate the examples of "I could not get my certificates in 45 minutes.." as this is a NON argument. Besides the many issues about an automated certificate issuance (even for just a DV cert), the choices made by current Internet CAs (I am referring to Internet CAs because for corporate or "closed" PKIs automation HAS NEVER BEEN A PROBLEM by using current standards) are based on POLICY decisions and not technical merits. Is IETF going to be in the policy decision business instead of focusing on technical aspects of interoperability?
>
> *Real Scope of ACME.* I think there should be a discussion about where this work is supposed to land. If it is another attempt (as noted during the BoF) to push further DANE (even when, as pointed out during the BoF, there is not much real interest in the real world for it) possibly to replace work like WebPKI or PKIX protocols, this should be clearly stated. Also, if that is the case, I think we are potentially choosing a single-point-of-failure model for trust (DNSSEC) which is scary and dangerous especially from a privacy perspective considering who is in control of top-domain keys. Privacy advocates should really be concerned about this issue.
>
> _*Technical Issues.*_
>
> *Reinventing the Wheel.* During the meeting I already expressed my concerns about many different aspects of the proposed scope. First off, we have a serious problem with overlapping over EXISTING IETF standards for message formats that are perfectly viable and currently deployed in a lot of environments. I am referring to the CMC / CMS / EST. Lot of time and engineering efforts have been spent over these formats and tons of certificates are, today, managed using these formats. Moreover, these formats allow for deploying systems with multiple factors of authentication and hardware tokens. I should not have to explain to the IETF community the horrible mistake to have multiple competing standards (we went down that road in the past and it was A HORRIBLE DISASTER) - that is why, at each level of the IETF, much attention has been paid to avoid this situation. I do not see why this is an exception to this very important principle. If the work in the potential WG will continue, 
> ARE WE GOING TO RETIRE EXISTING STANDARDS ?
>
> *Message Format.* The argument about ASN.1 vs JSON has to be re-framed in a TECHNICAL context instead of the not-so-appropriate argument "ASN.1 is evil". First off, either we talk about JSON SCHEMA vs. ASN.1 or we talk about JSON vs. DER. These are two completely different arguments. Since we are at IETF, let's focus on the "bits on the wire". It seems to me that the choice is quite clear: DER. The format is much more well defined, more compact, and has the required flexibility to accommodate for the required data structures. JSON makes sense in a JavaScript environment (JavaScript Object Notation) - but not much more outside that. JSON is thought to be readable by humans (by design) and has several limitations when it comes to encoding binary data (additional encoding is required) or non-ASCII names (again, additional encoding is required). In a JS environment where everything is UTF16, that is not an issue (if you ever worked in the space you would know that that is not 
> really true for binary data encoding), but in this context the format has SERIOUS limitations that makes it a POOR format choice for the job. Moreover, considering the requirement for supporting DER as the STANDARDIZED format for ALL PKIX objects, it seems a very odd choice to require the use of yet-another-data-format (less efficient when it come to the bits on the wire) on top of what already exists and needs to be supported. Are we going to change all data formats to JSON ? If not, I do not think there are technical reasons to adopt an inferior (from a bits-on-the-wire perspective) than what we have and works today.
> *
> **Weak Points in I-D. *As I pointed out during the BoF, the problem to solve about providing automation for certificate management is discoverability of the services provided by a CA. In particular, I am referring to the fact that even if you convince a CA to adopt yet-another-format, there is no discussion about how the different CAs will be "discovered" - which ones support the new protocol ? The draft-barnes-acme-01 says:
>
> This sentence makes sense only if it is referring to a specific piece of software - since the discoverability issue is not even mentioned, I assume that the authors of the software will have the power to DISCRIMINATE which CAs to support. Doesn't this seem NOT APPROPRIATE for a IETF wg ? Shouldn't there be a way to discover which CAs support which protocol ? If this problem was addressed first, there could be some ground for BEGINNING a discussion, but as it is written today, based just on this consideration, this document is a non-starter. Again, are we in the business of supporting a specific software? Moreover, how are the CAs identified ? By Name ? By the Hash of their certificates ? What trust is to be put in such a choice ? How stale can that information become ? Who is the authoritative information about what is supported by a vendor ?
> *
> **Issued Certificates Trust Issues.* Another important point is about what is the level of trust we want to achieve with the proposal and how this impacts the inclusion of CAs that support this protocol into standard trust stores (e.g., operating systems, browsers, MUAs, etc.) Since we have representatives from the browser's community (and I also hope from OSes), this is a question that needs to be addressed - would the adoption of this protocol be allowed for a Trusted CA ? Since there is no actual authentication of the requesting entity - the only level of certificates that can be issued is DV (and I have my doubts about that too). How is this better than current procedures from a trust perspective? Again, I know this is more of a POLICY related than technical issue - but these questions need an answer because the document itself oversteps the technical boundary, these are the type of discussions we also need to address.
>
> _*Conclusions*_
>
> Although I have always pushed for increasing the availability of certificates and the deployment of secure communications for almost 20yrs now, I do think that the proposed work is a non-starter for all the reasons I described above. I would like the whole community and the area directors to discuss the points above before proceeding any further.
>

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 27 Mar 2015 11:41:16 -0500

Hi Stephen,

comments inline..

> ietf announce list and copied here.)
Ack.
> [...]
I had a different impression. In the interest of moving forward the
discussion I am not going to repeat my point. I acknowledge that
this will be taken in consideration. Thanks.
> more such would of course be welcome.
That is true, however what is proposed and what the expressed interest from
the vendor was are, looking also at the notes, quite different set of 
problems.
AFAIK, the proponents do not want to address those in this proposal - maybe
in future work, but not in scope now.
> usable. The acme protocol is another attempt to address that
I respectfully disagree on this point. First of all I think that 30% is 
not a
bad percentage considering that the computing power required for crypto
was not available until recently (definitely not at reasonable costs 20yrs
or even 10yrs ago - considering the growth of Internet).

More importantly, I think that numbers should be interpreted within the
right context. The right question I would ask is: what is the percentage of
websites that would require authentication and confidentiality is not using
TLS ? I would say that the percentages, in this case, would be a lot 
different.

The second important argument is to analyze why people are not using
certificates - the response might be more related to having to pay for the
certificates rather than "technical" barriers. This is definitely true 
for the
top 1M websites, but it is even more so for personal websites, small blogs,
etc.

For these reasons, I do not think we are using the right numbers here for
justifying the "we have failed" argument.

IMHO, I think that a lot of progress has been made recently (thanks to
"prime time" vulnerabilities and thread awareness due to famous leaks)
about the adoption of certificates and secure ciphers where needed.

Other solutions - e.g. self-signed certificates + certificate pinning could
have been adopted for low-level assurance certificates to reach the 100%
of websites to use TLS (even if it is opportunistic and not tied to 
validation),
but current application layers (arguably rightfully so) will not 
validate those
TLS connections.

IMHO, definitely ACME will not get us to 100%. Not even close. My opinion
is that the people that are using TLS today will have another set of 
tools to
manage their certificates (only for low level of assurance, though) and 
people
who do not use TLS today will continue not using it. Automated certificate
tools (both standards-based and non standard-based exist and are deployed
today).

I guess this is something we can check in 2/3 years in case this work is
pushed forward.

> https to be used, hopefully we learn from that and succeed this
I am sorry, but I completely disagree. There is nothing more "modern" about
what is proposed that has technical advantages over what we have today (as
an extreme example - would you rewrite TCP to use JSON because it is more
"modern" ? This is just a hyperbole, of course, but I guess it might 
help getting
the main point across). If I am wrong, please point out the technical 
advantages
of the chosen solution, otherwise we must concur that this is 
yet-another-format
proposal.

I am not saying that this would stop the work - it is, after all, a 
decision from the
community. However, it would be "curious", after acknowledging this 
point, to
see the proposal moving forward (promoting competing standards that differ,
basically, only in the message format is quite weird for a 
standardization body,
don't you think ?)

Again, we should make it clear if we are ready to retire the existing 
standards or
not and, if so, be prepared to justify to the existing deployed base why 
they have
to switch to a more limited protocol.
> of trade-offs are quite normal as we make changes to, or develop
I think this statement is a bit dangerous and conflicts with the very 
nature of IETF.
I understand the need for trade-offs, but these should be based on technical
considerations. IMHO, other organizations might be more appropriate to 
discuss
non-technical tradeoffs (e.g., CA/B Forum?). Having their feedback 
before moving
forward in this work could be a good idea.
> impression I got), that would be a technical and not a procedural
It is totally possible that I might have mis-interpreted some of the 
comments.
It would be useful to have comments from the acme proponents themselves.

Thanks for your comments.

Looking forward to hear about the technical concerns.

Cheers,
Max

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Mar 2015 23:57:19 -0500

2015-03-27 10:00 GMT-05:00 Stephen Farrell <[email-masked]>:
> DXrxwlJ+snHskMXl7T3Q8QBoKukLeHVHE5MP/vyHWU6pjsOu5QeG79Rz/RHxIK/0
> /1N/W2vSwIHvsuf1a963x7lcATxqOEILq7rrewlBQqWce/qpjw2DMEs3hSwRtnMc
> epUY3EzVMHPgH0ccpruWCBKcdmGn9Bil4eRHtw/tYLv88OE/KU/T2fbcvAapnoxC
> /cZkicXkBanYnq0b4FoNIWwhT4/XhVIWGH4mFb8qPdy0TgRP8t7+E5FBRT7o8SuT
> Wk55oWgYyH36oe85vbaQyVQgxKMpNOQLmTPgMOKsU1RB0f10YxbOKmfdxrfpjVdb

It's good to see that you are enthusiastic about encryption
everywhere.  I personally hope that we don't lose sight of the
secondary goal of usability in the quest for better security.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 28 Mar 2015 14:01:35 +0000

> secondary goal of usability in the quest for better security.

Yep, nicely ironic. But see my next mail where I apologized for
whatever enigmail bug caused that. (And here's hoping it doesn't
affect this;-)

S.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 28 Mar 2015 15:34:11 -0400

> whatever enigmail bug caused that. (And here's hoping it doesn't

I believe that bug was introduced in enigmail 1.8 and resolved in 1.8.1,
fwiw.  Please contact me off-list (or on [email-masked]) if
you're still having this problem with a version that is not 1.8.

       --dkg

---

From: Leif Johansson <[email-masked]>
Date: Mon, 30 Mar 2015 09:02:02 +0200

Hi Max,

I found myself disagreeing with just about everything you said below...

> that should be discussed deeply.

What do you mean "when"? It happens all the time in the IETF. In fact
when the IETF tries to do design (rather than build on existing work)
we often turn out camels.

Personally I don't give a hoot about who comes up with an idea if it is
a good one and letsencrypt has come up with a few good ones.

> focusing on technical aspects of interoperability?

Good engineering always takes business models into account. The problem
statement - "getting certificates takes too long and is too complex" -
is imo a valuable one and one that should be addressed as quickly as
possible.

> control of top-domain keys. Privacy advocates should really be concerned

The argument that acme or letsencrypt is somehow "anti DANE" is
uninformed (and also wrong).

On the contrary, letsencrypt could use DANE TLSA records as DV proofs
which would drive deployment of DANE.

> WE GOING TO RETIRE EXISTING STANDARDS ?

Standards are only as useful as the problems they solve and the goals
they help us achieve.

If our goal is to increase the use of TLS by making it easier to obtain
certificates, then the current protocols for certificate life-cycle
management have not been very successful.

Re-inventing the wheel is sometimes the right thing to do - esp if you
manage to make wheel lighter and a bit more round.

> *Message Format.* The argument about ASN.1 vs JSON has to be re-framed

Sigh.

	Cheers Leif

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 30 Mar 2015 16:38:02 +0000

Thanks for your detailed note.  I want to make sure we have started to address your issues. Stephen responded to the procedural ones, and from your reply it appeared to me that you are, basically, satisfied.  Let me talk to the technical points you raise.

Reinventing the wheel.  Many parties have invented certificate enrollment protocols before, including the IETF and W3C and various commercial organizations. None of them have been very successful in meeting an important need: setting up a certificate for a small independent website. The best we seem to have is “have a human click here.”  Perhaps that’s a mindshare or deployment, as opposed to strictly a technical, issue, but I tend to think not, and based on the sentiment in the room, many people share that opinion.

Message format. Definitely something for the WG, once formed, to decide.

Weak points in the draft, which is about discoverability.  This is a general issue, and probably outside the scope of this group.  How is this problem solved now with existing enrollment packages?  (That’s almost a rhetorical question but not quite.)

Issuer trust issues:  I think this probably imposes some requirements on the protocol. For example, explicitly identifying the issue CA, and perhaps its trust chain, in the response messages so that the appropriate local configuration can be done.

So, in my view, you’ve raised some good questions that need to be addressed, but haven’t convinced me that this effort would be fundamentally flawed from day one. I would love to see if others share your view.

                /r$
--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

From: Massimiliano Pala [mailto:[email-masked]]
Sent: Friday, March 27, 2015 10:32 AM
To: [email-masked]
Subject: [Acme] Considerations about ACME BoF

Dear ACME BoF-ers,

Here's my concerns.

Procedural Issues.

Let's Encrypt. When the "Let's Encrypt" initiative was presented, I was quite confused about the scope. We all agree that IETF is about defining protocols on the wire - not promoting specific products or business models. However, in this case, I was under the impression that the IETF was sponsoring a specific piece of software and a new CA initiative that will be soon operational. Besides the fact that the new Let's Encrypt CA might (maybe not now) be a commercial viable initiative, my question is: why a non-existing, commercially viable, non-standard-based initiative is being presented at the IETF ? This is really troublesome especially in the view of this creating a precedence. What happens when another vendor comes to IETF and presents similar pitches about their products - what basis do we have to deny that presentation anymore ? This, I think, it is a really important point that should be discussed deeply.

Overstepping the Technical Boundaries. As it was pointed out during the BoF, the proposed initiative does not address any technical issue, but, instead, is pushing a specific BUSINESS model. I found very inappropriate the examples of "I could not get my certificates in 45 minutes.." as this is a NON argument. Besides the many issues about an automated certificate issuance (even for just a DV cert), the choices made by current Internet CAs (I am referring to Internet CAs because for corporate or "closed" PKIs automation HAS NEVER BEEN A PROBLEM by using current standards) are based on POLICY decisions and not technical merits. Is IETF going to be in the policy decision business instead of focusing on technical aspects of interoperability?

Real Scope of ACME. I think there should be a discussion about where this work is supposed to land. If it is another attempt (as noted during the BoF) to push further DANE (even when, as pointed out during the BoF, there is not much real interest in the real world for it) possibly to replace work like WebPKI or PKIX protocols, this should be clearly stated. Also, if that is the case, I think we are potentially choosing a single-point-of-failure model for trust (DNSSEC) which is scary and dangerous especially from a privacy perspective considering who is in control of top-domain keys. Privacy advocates should really be concerned about this issue.

Technical Issues.

Reinventing the Wheel. During the meeting I already expressed my concerns about many different aspects of the proposed scope. First off, we have a serious problem with overlapping over EXISTING IETF standards for message formats that are perfectly viable and currently deployed in a lot of environments. I am referring to the CMC / CMS / EST. Lot of time and engineering efforts have been spent over these formats and tons of certificates are, today, managed using these formats. Moreover, these formats allow for deploying systems with multiple factors of authentication and hardware tokens. I should not have to explain to the IETF community the horrible mistake to have multiple competing standards (we went down that road in the past and it was A HORRIBLE DISASTER) - that is why, at each level of the IETF, much attention has been paid to avoid this situation. I do not see why this is an exception to this very important principle. If the work in the potential WG will continue, ARE WE GOING TO RETIRE EXISTING STANDARDS ?

Message Format. The argument about ASN.1 vs JSON has to be re-framed in a TECHNICAL context instead of the not-so-appropriate argument "ASN.1 is evil". First off, either we talk about JSON SCHEMA vs. ASN.1 or we talk about JSON vs. DER. These are two completely different arguments. Since we are at IETF, let's focus on the "bits on the wire". It seems to me that the choice is quite clear: DER. The format is much more well defined, more compact, and has the required flexibility to accommodate for the required data structures. JSON makes sense in a JavaScript environment (JavaScript Object Notation) - but not much more outside that. JSON is thought to be readable by humans (by design) and has several limitations when it comes to encoding binary data (additional encoding is required) or non-ASCII names (again, additional encoding is required). In a JS environment where everything is UTF16, that is not an issue (if you ever worked in the space you would know that that is not really true for binary data encoding), but in this context the format has SERIOUS limitations that makes it a POOR format choice for the job. Moreover, considering the requirement for supporting DER as the STANDARDIZED format for ALL PKIX objects, it seems a very odd choice to require the use of yet-another-data-format (less efficient when it come to the bits on the wire) on top of what already exists and needs to be supported. Are we going to change all data formats to JSON ? If not, I do not think there are technical reasons to adopt an inferior (from a bits-on-the-wire perspective) than what we have and works today.

Weak Points in I-D. As I pointed out during the BoF, the problem to solve about providing automation for certificate management is discoverability of the services provided by a CA. In particular, I am referring to the fact that even if you convince a CA to adopt yet-another-format, there is no discussion about how the different CAs will be "discovered" - which ones support the new protocol ? The draft-barnes-acme-01 says:

Issued Certificates Trust Issues. Another important point is about what is the level of trust we want to achieve with the proposal and how this impacts the inclusion of CAs that support this protocol into standard trust stores (e.g., operating systems, browsers, MUAs, etc.) Since we have representatives from the browser's community (and I also hope from OSes), this is a question that needs to be addressed - would the adoption of this protocol be allowed for a Trusted CA ? Since there is no actual authentication of the requesting entity - the only level of certificates that can be issued is DV (and I have my doubts about that too). How is this better than current procedures from a trust perspective? Again, I know this is more of a POLICY related than technical issue - but these questions need an answer because the document itself oversteps the technical boundary, these are the type of discussions we also need to address.

Conclusions

Best Regards,
Massimiliano Pala, Ph.D.

---

From: Scott Rea <[email-masked]>
Date: Mon, 30 Mar 2015 13:36:22 -0600

I was at the BoF and just chiming in with my comments here as well...
See inline below...
Regards,
_Scott

> more such would of course be welcome.
So we have had two potential parties talk about what the output of
potential work might be able to achieve, at the point we come to
drafting a charter, it will be good to understand exactly what is being
sought as standardization because I have to admit, I am a little unclear
at this point. I have to agree with Max though, the presentation at the
BoF had a decidedly promotional flavor of certain proposed product, that
at least for me, seemed a little off kilter with usual IETF MO.
> a procedural issue for me.
I agree with Max that this should be a non-argument, and happy to hear
that you agree Stephen
> of trade-offs are quite normal as we make changes to, or develop
Is this sort focus better for an Implementation Guide rather than a new
RFC if it comes to that?
> impression I got), that would be a technical and not a procedural
Once again I have to agree with Max on this point, I certainly got the
same impression as Max. If or when we draft material that deals with
security considerations I expect to see some in depth dealing with how
moving to a trust hierarchy of a single anchor vs poly anchor trust is
better from a security perspective. Granted, having too many anchors has
its own issues, but I think going to a single anchor is too far in the
wrong direction - I think we need need something in between where there
is a manageable set of anchors that are audited and trusted to a high
level of assurance...

-- 
Scott Rea, MSc, CISSP
VP GOV/EDU Relations & Sr. PKI Architect
DigiCert, Inc.
2600 West Executive Parkway
Suite 500
Lehi, Utah 84043
http://www.digicert.com
(800) 896-7973

Em [email-masked]
Ph#(801) 701-9636
Ce#(801) 874-4114

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Mar 2015 21:00:06 +0100

Hi Scott,

> at least for me, seemed a little off kilter with usual IETF MO.

"Off kilter" is too vague for me to process, but please do chime in
with specific comments when we get to charter text development. Or
before then is fine too.

> Is this sort focus better for an Implementation Guide rather than a new

The case being made is that a new protocol is needed. But if you
have an implementation guide at which to point, then that'd be
interesting to see. I don't know of any current cert mgmt protocol
that could do what acme calls for without the kind of surgery that'd
amount to as much effort really. But that's a technical and not a
procedural point.

> is a manageable set of anchors that are audited and trusted to a high

Sorry - any impression that acme is predicated upon dane is wildly
mistaken. If someone still thinks that then I'd ask that you follow
up with me (or someone else) offlist as that is so off-base as to
be only distracting for this list.

And nor will any standardised flavour of acme have only one root
built-in to the protocol, neither the dnssec root, nor any other.

S.

---

From: Scott Rea <[email-masked]>
Date: Mon, 30 Mar 2015 14:00:13 -0600

My perspective in line below Leif...
Regards,
_Scott

> a good one and letsencrypt has come up with a few good ones.
I think Max and Stephen resolved this earlier on the list. There are
good ideas in the Lets Encrypt proposal, I think the objection was more
about how the proposal was presented and what the end goal was. IETF
should not be in the process of picking and choosing products and the
concern was the Lets Encrypt proposal in the BoF felt more like a
product proposal rather than here are some good ideas for a generalized
protocol. As I said, I think this has been addressed now.
> is imo a valuable one and one that should be addressed as quickly as
There was no evidence presented that this is a common industry problem,
but rather a single anecdote of a particular individual - that is
certainly not the basis for creating a new standard. Quantifying this
assertion for the industry may produce adequate justification for a new
standard, but a single isolated experience does not IMHO meet the
minimum bar of justification.
> which would drive deployment of DANE.
I actually think Max is making the opposite argument - that the proposal
is "anti CA" (or maybe anti X.509) and "pro DANE" and asking for
justification of why we want to move away from the current
implementation base to an unproven trust model that extremely few have
demonstrated a willingness to adopt at this point.
> manage to make wheel lighter and a bit more round.
I think this is entirely the wrong question to ask  - perhaps we should
first ascertain whether making certs easier to obtain is an actual
problem. No one has presented the proof of that yet. Certainly I can
easily generate my own certs till the cows come home, thus making them
easy to get. But my self-signed certs are not going to make adoption of
TLS increase because the issue of trust is not addressed by the self
signed certs. The question we should be asking is how can we make
trusted certificates easier to get for TLS purposes...

Em [email-masked]
Ph#(801) 701-9636
Ce#(801) 874-4114

---

From: Leif Johansson <[email-masked]>
Date: Mon, 30 Mar 2015 22:41:56 +0200

<...>

> minimum bar of justification.

I think Stephen provided a credible argument earlier (the
only-30%-of-alexa-top-1M-use-tls argument).

<...>

> demonstrated a willingness to adopt at this point.

OK so that makes even less sense to me. How is creating another CA anti-CA?

	Cheers Leif

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Mar 2015 15:00:31 -0700

On Mon, Mar 30, 2015 at 1:00 PM, Scott Rea <[email-masked]> wrote:
> demonstrated a willingness to adopt at this point

Hmm, I'm not sure how you and Max got this out of the discussion in the
meeting, but perhaps I can clarify.

ACME has two potential interactions with DANE.

1. DANE can be used a "proof type" to allow ACME CAs to determine that
a given entity controls a given domain.

2. If an ACME CA (or any CA) issues free certificates based on DANE, then
this is a potential way to allow DANE-based trust to get wider deployment.
This isn't really a property of ACME but rather of free, automatic issuance,
regardless of the protocol.

But in neither case is ACME really about moving to the DANE trust model.

Best,
-Ekr

---

From: Jeremy Rowley <[email-masked]>
Date: Mon, 30 Mar 2015 23:42:20 +0000

I think your last sentence illustrates the fundamental issue - the discussion of creating another CA isn't really scope of the standards body (as it's purely the establishment and operation of a business practice). The discussion should revolve around the proposed technology rather than the operations of one implementer. 

>From the IETF's mission page:
"The IETF's mission is 'to make the Internet work better,' but it is the Internet Engineering Task Force, so this means: make the Internet work better from an engineering point of view. We try to avoid policy and business questions, as much as possible. If you're interested in these general aspects, consider joining the Internet Society. Most participants in the IETF are engineers with knowledge of networking protocols and software. Many of them know a lot about networking hardware too".    

During the BoF, there seemed to be a lot of unnecessary discussion about business operations and policy. 

Jeremy 

-----Original Message-----
From: Acme [mailto:[email-masked]] On Behalf Of Leif Johansson
Sent: Monday, March 30, 2015 2:42 PM
To: [email-masked]
Subject: Re: [Acme] Considerations about ACME BoF

<...>

> There was no evidence presented that this is a common industry 
> problem, but rather a single anecdote of a particular individual - 
> that is certainly not the basis for creating a new standard. 
> Quantifying this assertion for the industry may produce adequate 
> justification for a new standard, but a single isolated experience 
> does not IMHO meet the minimum bar of justification.

I think Stephen provided a credible argument earlier (the only-30%-of-alexa-top-1M-use-tls argument).

<...>

> I actually think Max is making the opposite argument - that the 
> proposal is "anti CA" (or maybe anti X.509) and "pro DANE" and asking 
> for justification of why we want to move away from the current 

	Cheers Leif

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 16:55:37 -0700

> During the BoF, there seemed to be a lot of unnecessary discussion about business operations and policy.

This is, after all, a protocol that aims to support a particular set
of operational models, and will need to support a range of policies
(where those policies are largely constrained by the CA/Browser
forum).  These are valid points of discussion given how they might
constrain the technical aspects of the protocol.

If you think a particular statement needs to be called out as
inappropriate, I encourage you to do so.

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 30 Mar 2015 20:36:15 -0700

> I agree with Max that this should be a non-argument, and happy to hear

For me ACME is purely about usability, so Cullen's anecdote is actually 
the only thing that matters. As a user, I want to be able to get a 
server certificate for a cloud server within seconds, and with no manual 
intervention. And if that breaks someone's business model, so be it.

And by the way, ACME with *email* certs could make S/MIME viable again, 
for those of us still using mail clients.

Thanks,
	Yaron

---

From: Scott Rea <[email-masked]>
Date: Tue, 31 Mar 2015 02:22:15 -0600

G'day Yaron,

I will make 2 brief observations:

a) Max and I actually proposed some usability focused work around TLS
certs to the PKIX WG about 6 or 7 years ago, when PKIX was still going
strong, and we were told that usability is not the purvey of IETF, its
purely bits on the wire. So when did IETF morph from bits on the wire to
now include usability?

b) Getting a server certificate for a cloud server within seconds, and
with no manual intervention is possible today with a little scripting on
the server and an appropriate API from one of the existing CAs. If your
current provider cannot do that for you, then I suggest you shop around
a little.

Regards,
_Scott

On 3/30/2015 9:36 PM, Yaron Sheffer wrote:
> For me ACME is purely about usability, so Cullen's anecdote is
> actually the only thing that matters. As a user, I want to be able to
> get a server certificate for a cloud server within seconds, and with
> no manual intervention. And if that breaks someone's business model,
> so be it.
>
> And by the way, ACME with *email* certs could make S/MIME viable
> again, for those of us still using mail clients.
>
> Thanks,
>     Yaron

Em [email-masked]
Ph#(801) 701-9636
Ce#(801) 874-4114

---

From: Richard Barnes <[email-masked]>
Date: Tue, 31 Mar 2015 08:41:59 -0400

> purely bits on the wire. So when did IETF morph from bits on the wire to

This is getting silly.  At some level, the entire Internet is about
usability.  After all, you could order plane tickets over the phone before
Expedia showed up, right?

Protocols are about automating interactions.  The interaction by which a CA
validates an applicant's control over a domain name is one for which we
don't have good standard automation right now.

> the server and an appropriate API from one of the existing CAs.

If you like, you can view ACME as simply a collation and standardization of
those proprietary APIs, so that hosting providers (and server vendors,
etc.) don't have to get locked in to one.

--Richard

> If your

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 31 Mar 2015 14:26:28 +0000

> b) Getting a server certificate for a cloud server within seconds, and with no
> manual intervention is possible today with a little scripting on the server and
> an appropriate API from one of the existing CAs. If your current provider
> cannot do that for you, then I suggest you shop around a little.

Great.  Will you, or the other existing CA's bring the API forward for the potential WG to consider?

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 31 Mar 2015 08:03:47 -0700

Hi Scott,

> purely bits on the wire. So when did IETF morph from bits on the wire to
The IETF works on bits on the wire that are necessary to achieve 
business goals. And those goals certainly include usability.

> current provider cannot do that for you, then I suggest you shop around

I tried that and failed, I guess I should try some more. But anyway, as 
a customer I would like a standard interface so that this "little 
scripting" doesn't lock me into a single vendor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 31 Mar 2015 13:20:27 -0400

On Tue, Mar 31, 2015 at 11:03 AM, Yaron Sheffer <[email-masked]> wrote:
> The IETF works on bits on the wire that are necessary to achieve business
> goals. And those goals certainly include usability.
>
> I tried that and failed, I guess I should try some more. But anyway, as a
> customer I would like a standard interface so that this "little scripting"
> doesn't lock me into a single vendor.

"with a little scripting".

You can protect the golden gate bridge as well, all it takes is "a
little paint".

The problem with "a little scripting" is that if you are serious about
code quality and maintenance it is never so simple. Who is going to be
responsible for this code? Who is going to maintain it? Where is it
going to sit in source control?

Before you can write one line of code, you have to read the
documentation and before you can do that you have to find out where it
is.

Sure, it is not rocket science. But it is several hours worth of
effort and that means $3,000+ in a commercial environment and $1.4
million in the US Govt.

And before you start complaining that if people can't write code they
are incompetent etc, first recognize that working out whether someone
is competent or not is itself a very difficult proposition for a
manager and second go spend some time in a usability lab watching some
people trying to use computers to solve 'simple' problems. It is quite
an eye opener.

You will see folk fat fingering commands and looking up documentation
for stuff they think they do every day and know off by heart. But it
isn't actually that simple because the way the brain works, it tends
to equate ability to plan with ability to execute and it is vastly
over-optimistic in estimating time taken to do things.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 31 Mar 2015 14:03:09 -0400

> goals. And those goals certainly include usability.

... the IETF also works on what the participants in the WG happen to
decide is interesting to them.

Perhaps 6 or 7 years ago the participants in the PKIX WG simply didn't
like your proposal, and decided that they didn't want to work on it.
The "usability isn't the perview of the IETF" may have simply been a
politer way of saying "ick".

I have an idea for protocol that is unusable, and doesn't really
benefit anyone. The protocol is simply bits on the wire; it doesn't
necessarily follow that the IETF will want to work on it :-P

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 31 Mar 2015 18:02:43 -0400

> necessarily follow that the IETF will want to work on it :-P

Actually, there was a W3C working group on TLS usability round about
that very time. So it might have been simply that W3C had the speaking
stick at the time.

There are two sorts of usability considerations that affect IETF
protocols. One is user experience design which we don't actually do.
The other is user convenience which has always been in scope.

Having to enter information manually into six different systems isn't
a user experience issue but it is user convenience.