Re: [Acme] Proposed ACME Charter Language

Stephen Farrell <> Mon, 20 April 2015 16:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E08221B2F41 for <>; Mon, 20 Apr 2015 09:06:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ed46ZX6V32LD for <>; Mon, 20 Apr 2015 09:06:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2766B1B2F3B for <>; Mon, 20 Apr 2015 09:06:01 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDD4FBE80; Mon, 20 Apr 2015 17:05:59 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gm9udLk41R3g; Mon, 20 Apr 2015 17:05:58 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id C7258BE7C; Mon, 20 Apr 2015 17:05:57 +0100 (IST)
Message-ID: <>
Date: Mon, 20 Apr 2015 17:05:56 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Russ Housley <>
References: <> <> <>
In-Reply-To: <>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Acme] Proposed ACME Charter Language
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, 20 Apr 2015 16:06:03 -0000

On 20/04/15 16:57, Russ Housley wrote:
> Stephen:
> I did not see the ACME effort as trying to throw everything out.

If it is not used, then I don't think we're throwing it out:-)

> Rather, throw out the parts that have been an impediment to the kind
> of automation proposed by ACME, but document the shortcoming.

Sorry, I'm still not getting it. I don't see any need for ACME
to document why CMP etc failed or what was wrong with CMP that
may have caused it to fail. And the same for CMC etc. BTW by
"fail" here I mean: not used by the major deployed PKIs on the
public Internet.

I also see no need at all to even try to re-use ASN.1 PDU
structures that are defined in CRMF etc.

I do think that ACME ought learn from the past of course, and
am confident that there will be enough participants involved
who have that history for that to not be problematic.

But I do not think ACME ought be required to re-use any ASN.1
PDU definitions from any previous RFCs on this topic.

Do we agree or disagree on that last? (I'm trying to get to
quite specific meanings for "duplicate.")


> Russ
> On Apr 20, 2015, at 11:43 AM, Stephen Farrell wrote:
>> Hi Russ,
>> This bit puzzles me a lot, other bits puzzle me a little:-)
>> On 20/04/15 16:23, Russ Housley wrote:
>>> The ACME WG will not duplicate work from previous IETF 
>>> certificate management efforts.
>> If accepted, that would seem to me to nullify the entire effort.
>> Can you explain why I'm reading it wrong?
>> ACME absolutely will duplicate work from previous IETF certificate
>> management efforts that have failed to get traction over the last
>> decade and a half. That is entirely fine IMO and needs no explicit
>> justification whatsoever since we have 15 years of crystal clear
>> non-use, outside of niche environments. (It is true that what is
>> now considered a niche was not so considered back then.)
>> In fact I believe anyone who claims such duplication is a problem
>> should be the one to provide evidence for that by documenting
>> exactly why and at what scale.
>> It is just not credible for us to pretend that CMC, CMP, or EST are
>> widely used for certificate management on the public Internet. If
>> I'm wrong there I would really love to see the evidence but absent
>> such, duplicating bits of functionality present in current RFCs
>> that are not at all widely used is what is needed for this effort
>> and needs to be encouraged.
>> I think we really ought bottom out on this aspect before chartering
>> - it'd be dumb of us to charter an ACME WG that has to fight all
>> the CRMF battles over again, or the ASN.1 vs. whatever issues. So I
>> hope lots of voices chime in and say what they think.
>> S.
>> _______________________________________________ Acme mailing list