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 protected] Twitter: RichSalz
From: Massimiliano Pala [mailto:[email protected]]
Sent: Friday, March 27, 2015 10:32 AM
To: [email protected]
Subject: [Acme] 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.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
