Re: [Acme] Considerations about ACME BoF

Massimiliano Pala <> Fri, 17 April 2015 16:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 477981A6EDE for <>; Fri, 17 Apr 2015 09:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AeA14ceUmyd0 for <>; Fri, 17 Apr 2015 09:34:23 -0700 (PDT)
Received: from ( [IPv6:2001:4830:1600:2f4::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EBC8A1A1BFF for <>; Fri, 17 Apr 2015 09:34:19 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37C5041D56 for <>; Fri, 17 Apr 2015 18:34:16 +0200 (CEST)
Received: from localhost (unknown []) by (Postfix) with ESMTP id C9CDA154C770 for <>; Fri, 17 Apr 2015 16:34:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5h_5ozchFUvu for <>; Fri, 17 Apr 2015 12:34:08 -0400 (EDT)
Received: from iMassi.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 97766154C741 for <>; Fri, 17 Apr 2015 12:34:08 -0400 (EDT)
Message-ID: <>
Date: Fri, 17 Apr 2015 12:34:02 -0400
From: Massimiliano Pala <>
Organization: OpenCA Labs
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------010204040209030004090904"
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: Fri, 17 Apr 2015 16:34:32 -0000

Hi all,

thanks to all the people who actually took the time to read the message 
and provided valuable and technical opinions (i.e., Rich) - I hoped to 
see more technical discussions, but it seems that not many people want 
to engage there.

Thanks to Stephen Farrel for sharing his own experience - which can be 
read in different ways, I think. To me, that demonstrated that it is 
easy to get a certificate (that is not a problem) and that, at the same 
time, PKI technology itself is not fool proof (in this case the 
certificate-retrieval process was easy, the issues were with the 
revocation infrastructure and bad client behavior - non-standard). I 
fear that this proposal tries to address the wrong problem because we do 
not want to deal with other issues (service discovery and revocation 
information distribution).


Although I still think that the proposed work seems (in my opinion) more 
related to policy rather than the need of a new protocol, I would 
suggest that the following aspects to be taken in serious considerations:

  * *Please try to avoid re-inventing the wheel.* Maybe a document for
    the WG could provide how to use the building blocks we have today in
    the protocol (e.g., CMS/CMC vs. JSON-ish). Reinventing the wheel is
    usually not a good idea, especially when there is not real data on
    what is actually needed. Although, it was always one of the main
    point to make sure we were not duplicating work within the IETF, it
    seems people do not care that much about that now. If possible,
    please don't.
  * *Keep compatibility with existing standards.* As I said repeatedly,
    I fear the duplication of standards and multiplication of data
    formats. This is tightly connected to the first point but goes a bit
    further than that - especially if the charter of the WG will cover
    several aspects of certificate provisioning and life-cycle.
  * *Keep the scope clear and focused.* Many different opinions have
    been given about what this WG might address - usability, format,
    business models, a protocol for "personal" websites, etc. none of
    which focused on technical limitations we have today (nobody pointed
    out anything that we can not do today with existing standards) -
    this is quite confusing. If possible, please, keep the work on the
    technical side.

And, if possible, keep the discussion about the technical aspects and 
open to any possible business models (and possible policy requirements).


On 3/27/15 10:32 AM, 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...).
> 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 
> *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.
> _______________________________________________
> Acme mailing list