Re: [Acme] Proposed ACME Charter Language

"Dr. Pala" <director@openca.org> Sat, 02 May 2015 16:53 UTC

Return-Path: <director@openca.org>
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 4346C1A1EF4 for <acme@ietfa.amsl.com>; Sat, 2 May 2015 09:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.804
X-Spam-Level: ****
X-Spam-Status: No, score=4.804 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, HOST_EQ_IT=1.245, HOST_EQ_STATICB=1.372, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=no
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 3FTOuJe2mNx8 for <acme@ietfa.amsl.com>; Sat, 2 May 2015 09:53:18 -0700 (PDT)
Received: from server.hackmasters.net (static-217-133-36-163.clienti.tiscali.it [217.133.36.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93F71A7023 for <acme@ietf.org>; Sat, 2 May 2015 09:53:17 -0700 (PDT)
Received: from nyc.openca.org (unknown [192.168.101.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by server.hackmasters.net (Postfix) with ESMTPS id 9525F4197A; Sat, 2 May 2015 18:53:14 +0200 (CEST)
Received: from localhost (unknown [127.0.0.1]) by nyc.openca.org (Postfix) with ESMTP id 31426154CD54; Sat, 2 May 2015 16:53:13 +0000 (UTC)
X-Virus-Scanned: amavisd-new at openca.org
Received: from nyc.openca.org ([127.0.0.1]) by localhost (blackmamba.openca.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wwAgsb17LNu; Sat, 2 May 2015 12:53:01 -0400 (EDT)
Received: from [10.1.1.51] (unknown [10.1.1.51]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by nyc.openca.org (Postfix) with ESMTPSA id 38289154CD1D; Sat, 2 May 2015 12:53:01 -0400 (EDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-F1FFC8AA-AF3C-4E3C-A33D-5AB7F33CFCF3
Mime-Version: 1.0 (1.0)
From: "Dr. Pala" <director@openca.org>
X-Mailer: iPhone Mail (12D508)
In-Reply-To: <CABcZeBOy2yBEMGMxcDy=E3fvc+OF1sZfvOV7twJHAvKqtrxtLg@mail.gmail.com>
Date: Sat, 2 May 2015 12:53:00 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <D7F0C45A-B514-41A2-A220-5B6601BE582F@openca.org>
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> <CABcZeBOy2yBEMGMxcDy=E3fvc+OF1sZfvOV7twJHAvKqtrxtLg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/Mw2Azl_hxLjc4r-n4IFwpiOF8YI>
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: Sat, 02 May 2015 16:53:22 -0000

Hi ACME,

I just want to point out that it might be the case that the people who are supposed to "argue" about this might not even be aware of the work done in this WG. After reading the charter, it seems to me that the work should have been taken to the PKIX WG.

I also think it would be a good idea to define where and why existing protocols do not work - this is usually a good practice that allow people on focusing on what is the real and documented need and avoid throwing out the baby together with the bathwater. This also goes into the direction of better understanding what part of the work will overlap with existing documents.

On this note, it is still not clear to me is if it is the intention of ACME to deprecate the PKIX work, RFCs, and data formats today in use for certificate management ? Since the charter scope is left pretty much undefined on what will be covered, I think this is a legitimate concern/question...

Cheers,
Max


> On Apr 25, 2015, at 4:05 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> 
>> On Mon, Apr 20, 2015 at 9:11 AM, Russ Housley <housley@vigilsec.com> wrote:
>> Stephen:
>> 
>> If that paragraph were removed, would you be happier with the charter?  If so, consider it gone.  I'm willing to assume that an attempt to replace things that people are using will meet with vigorous discussion.
> 
> I would suggest we do as you propose and remove this text. I think there will
> be plenty of occasion for people in the WG to argue about using existing stuff
> versus building anew.
> 
> -Ekr
>  
>> 
>> 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
> 
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme