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).
Anyhow...
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).
Cheers,
Max
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
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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
