[pkix] Fwd: Considerations about ACME BoF

[Massimiliano Pala <[e-mail]>]

Hi PKIX,

I just want to draw your attention to some discussion about a proposal 
for a new WG (ACME) that is coming out of a non-WG forming BoF.

I forward you my post to the list because I think it might be useful to 
gather your attention and maybe your contribution to the discussion 
about the proposed work (that, IMHO, seemingly overlaps with the 
standards we worked on in PKIX).

Cheers,
Max


-------- Forwarded Message --------
Date: 	Fri, 27 Mar 2015 09:32:22 -0500
From: 	Massimiliano Pala <[e-mail]>
To: 	[e-mail] <[e-mail]>
Subject: 	Considerations about ACME BoF



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.