Re: [Acme] Proposed ACME Charter Language

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 20 April 2015 16:34 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 9CE941A0218 for <acme@ietfa.amsl.com>; Mon, 20 Apr 2015 09:34:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3Lw3OPTcG9u for <acme@ietfa.amsl.com>; Mon, 20 Apr 2015 09:34:29 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2341A1F73 for <acme@ietf.org>; Mon, 20 Apr 2015 09:34:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C3BFEBE7C; Mon, 20 Apr 2015 17:34:07 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byzTCGCwyc2H; Mon, 20 Apr 2015 17:34:05 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BF373BE77; Mon, 20 Apr 2015 17:34:05 +0100 (IST)
Message-ID: <55352A7D.2080201@cs.tcd.ie>
Date: Mon, 20 Apr 2015 17:34:05 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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 <housley@vigilsec.com>
References: <6A9C3116-8CC9-472C-8AA8-F555D060834C@vigilsec.com> <55351EAB.1060905@cs.tcd.ie> <E81896AA-245F-48B7-9B38-86AC30D2F82A@vigilsec.com> <553523E4.2090808@cs.tcd.ie> <84718B26-1DA3-4D46-8B6F-B615806229D7@vigilsec.com>
In-Reply-To: <84718B26-1DA3-4D46-8B6F-B615806229D7@vigilsec.com>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/FoQ-6WZveKSWf-M7t3d1YaPXwsU>
Cc: IETF ACME <acme@ietf.org>
Subject: Re: [Acme] Proposed ACME Charter Language
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, 20 Apr 2015 16:34:31 -0000

Hi Russ,

On 20/04/15 17:11, Russ Housley wrote:
> Stephen:
> 
> If that paragraph were removed, would you be happier with the
> charter?  If so, consider it gone.  

I would be happier yes. But I think we're better off having the
discussion now, before chartering, since otherwise we may end up
re-doing it a number of times.

If that discussion ends up with rough consensus for a "don't
duplicate" position then text such as you propose would be correct.
If that discussion ends up with rough consensus on a "duplicate
away, earlier efforts failed" position then it'd probably be a
good idea to say so in the charter text. (So, your bit of puzzling
text is very useful in the end - it may force us to get this out
of the way early.)

> I'm willing to assume that an
> attempt to replace things that people are using will meet with
> vigorous discussion.

Right. People are using CMC, but not afaik when dealing with any
public CAs for getting certificates for public Internet services.
I think CMP has some similar but much smaller set of real uses. (*)
And I'm not sure if EST has gotten traction. SCEP has uses but
that's another kettle of cans of worms and fish;-)

I think it would be better to have the vigorous discussion about
CMC vs.ACME-JSON-etc (if that's the one we need to have) before
we form the WG. But is that in fact the meat of your concern here?
If so, then I assume you'd be arguing for use of CMC/CRMF PDUs
in ACME messages. If not, I'm not back to being puzzled. Can you
clarify?

Cheers,
S.


(*) Last I checked, there still were a set of real users of CMP that
meant it would be wrong to declare it HISTORIC. If that's changed
since, it might be a fine thing to do though, and I'm happy to help
there, so if anyone has info please let us know, though that'd be
better done via mail on the pkix list (and then saag) and not here.


> 
> Russ
> 
> 
> On Apr 20, 2015, at 12:05 PM, Stephen Farrell wrote:
> 
>> 
>> 
>> 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.")
>> 
>> Cheers, S.
>> 
>> 
>> 
>>> 
>>> 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 Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
>>> 
>>> 
>>> 
> 
> _______________________________________________ Acme mailing list 
> Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
>