Re: [Acme] Considerations about ACME BoF

Scott Rea <> Mon, 30 March 2015 20:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A8A521AD361 for <>; Mon, 30 Mar 2015 13:00:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.212
X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wqY_t3FjQqHs for <>; Mon, 30 Mar 2015 13:00:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF89B1ACCEB for <>; Mon, 30 Mar 2015 13:00:14 -0700 (PDT)
Message-ID: <>
Date: Mon, 30 Mar 2015 14:00:13 -0600
From: Scott Rea <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
X-ClientProxiedBy: ( To (
Archived-At: <>
Subject: Re: [Acme] Considerations about ACME BoF
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Mar 2015 20:00:18 -0000

My perspective in line below Leif...

On 3/30/2015 1:02 AM, Leif Johansson wrote:
> On 03/27/2015 03:32 PM, Massimiliano Pala wrote:
>> 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...).
> Hi Max,
> I found myself disagreeing with just about everything you said below...
>> 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.
> 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.
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.
>> *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?
> 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.
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.
>> *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.
> 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.
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.
>> _*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
> 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.
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...
>> *Message Format.* The argument about ASN.1 vs JSON has to be re-framed
> Sigh.
> 	Cheers Leif
> _______________________________________________
> Acme mailing list

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

Ph#(801) 701-9636
Ce#(801) 874-4114