Re: [Acme] Considerations about ACME BoF

Jeremy Rowley <> Mon, 30 March 2015 23:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 47A951AD376 for <>; Mon, 30 Mar 2015 16:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.212
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zd2HZ2UH3Jv1 for <>; Mon, 30 Mar 2015 16:42:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C732E1ACCFE for <>; Mon, 30 Mar 2015 16:42:23 -0700 (PDT)
From: Jeremy Rowley <>
To: Leif Johansson <>, "" <>
Thread-Topic: [Acme] Considerations about ACME BoF
Thread-Index: AQHQaJrpM4Cv1wHCoEeq1oEfr7ZQcp01AjcAgADZbICAAAuoAP//opPA
Date: Mon, 30 Mar 2015 23:42:20 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 30 Mar 2015 23:42:25 -0000

I think your last sentence illustrates the fundamental issue - the discussion of creating another CA isn't really scope of the standards body (as it's purely the establishment and operation of a business practice). The discussion should revolve around the proposed technology rather than the operations of one implementer. 

>From the IETF's mission page:
"The IETF's mission is 'to make the Internet work better,' but it is the Internet Engineering Task Force, so this means: make the Internet work better from an engineering point of view. We try to avoid policy and business questions, as much as possible. If you're interested in these general aspects, consider joining the Internet Society. Most participants in the IETF are engineers with knowledge of networking protocols and software. Many of them know a lot about networking hardware too".    

During the BoF, there seemed to be a lot of unnecessary discussion about business operations and policy. 


-----Original Message-----
From: Acme [] On Behalf Of Leif Johansson
Sent: Monday, March 30, 2015 2:42 PM
Subject: Re: [Acme] Considerations about ACME BoF


> There was no evidence presented that this is a common industry 
> problem, but rather a single anecdote of a particular individual - 
> that is certainly not the basis for creating a new standard. 
> Quantifying this assertion for the industry may produce adequate 
> justification for a new standard, but a single isolated experience 
> does not IMHO meet the minimum bar of justification.

I think Stephen provided a credible argument earlier (the only-30%-of-alexa-top-1M-use-tls argument).


> I actually think Max is making the opposite argument - that the 
> proposal is "anti CA" (or maybe anti X.509) and "pro DANE" and asking 
> for justification of why we want to move away from the current 
> implementation base to an unproven trust model that extremely few have 
> demonstrated a willingness to adopt at this point.

OK so that makes even less sense to me. How is creating another CA anti-CA?

	Cheers Leif

Acme mailing list