Re: [Acme] Considerations about ACME BoF

Scott Rea <Scott.Rea@DigiCert.com> Mon, 30 March 2015 19:36 UTC

Return-Path: <scott.rea@digicert.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C311AD0D6 for <acme@ietfa.amsl.com>; Mon, 30 Mar 2015 12:36:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.212
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8V6CKYdgpRB for <acme@ietfa.amsl.com>; Mon, 30 Mar 2015 12:36:24 -0700 (PDT)
Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CE11AD0D0 for <acme@ietf.org>; Mon, 30 Mar 2015 12:36:24 -0700 (PDT)
Message-ID: <5519A5B6.9010707@DigiCert.com>
Date: Mon, 30 Mar 2015 13:36:22 -0600
From: Scott Rea <Scott.Rea@DigiCert.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: <acme@ietf.org>
References: <551569F6.8020507@openca.org> <55157164.80805@cs.tcd.ie>
In-Reply-To: <55157164.80805@cs.tcd.ie>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [67.137.52.8]
X-ClientProxiedBy: EX1.corp.digicert.com (10.12.0.5) To EX2.corp.digicert.com (10.12.0.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/f1OLErWIB0G2_K7US_BahOTKW-k>
Subject: Re: [Acme] Considerations about ACME BoF
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Mar 2015 19:36:31 -0000

I was at the BoF and just chiming in with my comments here as well...
See inline below...
Regards,
_Scott

On 3/27/2015 9:04 AM, Stephen Farrell wrote:
> (Apologies - enigmail seems to be randomly sending mail that's
> encrypted for me for some weird reason;-)
>
> Hi Max,
>
> Just addressing your "procedural" points.
>
> On 27/03/15 14:32, 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),
> If/when this list produces charter text that the IESG consider is
> ready for review, then that'd be the time at which using the main
> IETF list was most useful. (Before that happens, I suspect there'll
> be plenty of mail on this list finally followed by a mail asking
> for comment on the proposed wg charter that will be sent to the
> ietf announce list and copied here.)
>
>> 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.
> I don't agree. The letsencryt.org proposal is only one (proposed)
> instance of a CA service, so I think maybe you ended up with the
> wrong impression there. The folks working on that are willing to
> do the work to produce a protocol that will be able to use any CA
> service that wants to talk acme. That all seems like entirely normal
> process to me. If we were standardising for a particular service,
> I agree that would be problematic, but we are not. If it helps,
> I'd block a charter that was only for one particular service.
>
> At least one operational CA service (PHB/Commodo) have expressed
> interest already and will I'm sure be active on this list, and
> more such would of course be welcome.
So we have had two potential parties talk about what the output of
potential work might be able to achieve, at the point we come to
drafting a charter, it will be good to understand exactly what is being
sought as standardization because I have to admit, I am a little unclear
at this point. I have to agree with Max though, the presentation at the
BoF had a decidedly promotional flavor of certain proposed product, that
at least for me, seemed a little off kilter with usual IETF MO.
>
>> *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.
> With all due respect to Cullen, I agree:-) I think it's used as a
> humorous anecdote basically and I've seen that done in quite a few
> contexts in the IETF. But that one non-argument was raised is not
> a procedural issue for me.
I agree with Max that this should be a non-argument, and happy to hear
that you agree Stephen
>
>> 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?
> No. But the fact that only about 30% of the alexa top 1M web sites
> even do TLS after nearly 20 years shows that we have failed to
> provide certificate management technology that sites have found
> usable. The acme protocol is another attempt to address that
> important audience via automation and some more "modern" tech. That
> said, we've also learned a lot more about what helps things work
> in this space and there is now a much increased interest in getting
> https to be used, hopefully we learn from that and succeed this
> time.
>
> The point that automation intersects with policy is arguable I
> agree, but again I don't see any procedural issue here. Those kind
> of trade-offs are quite normal as we make changes to, or develop
> new, protocols.
Is this sort focus better for an Implementation Guide rather than a new
RFC if it comes to that?
>
>> *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.
> I think you ended up with the wrong impression here too. What I
> heard at the BoF was that the acme proponents were by far most
> interested in today's web sites, and today's web PKI, but that
> they were not unfriendly to DANE. But even had they been focused
> on trying to push the web PKI towards DANE (which is just not the
> impression I got), that would be a technical and not a procedural
Once again I have to agree with Max on this point, I certainly got the
same impression as Max. If or when we draft material that deals with
security considerations I expect to see some in depth dealing with how
moving to a trust hierarchy of a single anchor vs poly anchor trust is
better from a security perspective. Granted, having too many anchors has
its own issues, but I think going to a single anchor is too far in the
wrong direction - I think we need need something in between where there
is a manageable set of anchors that are audited and trusted to a high
level of assurance...
> issue.
>
> Cheers,
> S.
>
>
>> _*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
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme

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

Em Scott@DigiCert.com
Ph#(801) 701-9636
Ce#(801) 874-4114