Re: [Acme] Proposed ACME Charter Language

Richard Barnes <rlb@ipv.sx> Thu, 14 May 2015 17:04 UTC

Return-Path: <rlb@ipv.sx>
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 C4D351A8A73 for <acme@ietfa.amsl.com>; Thu, 14 May 2015 10:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 F8rWWkn4KQMK for <acme@ietfa.amsl.com>; Thu, 14 May 2015 10:04:27 -0700 (PDT)
Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28AC11A87C7 for <acme@ietf.org>; Thu, 14 May 2015 10:04:27 -0700 (PDT)
Received: by layy10 with SMTP id y10so76857907lay.0 for <acme@ietf.org>; Thu, 14 May 2015 10:04:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VbF66Kdluj+5hYC9mxml1B/CuCav/8f3bkeXVFy3VKk=; b=hnO0lXMXiZLM7n7mGK8tBUlNCIMfkr11gWczWFBuQ2Uk+MliIo8T9ukv2U+TZ8cSix mfvNukj+y6tOD7unIQVVXQDhYM838yQmy/D5SY9ZspAUuLsEYqbuEfUKHKf327Zm7ZkV DMOdIybEgKVM5b+kZ90dZKTeBNJmXBS5swVYAdZYIFM+/FUw3tD+lDroOy27c85u9Ha8 G1U01ma+auxZVHkELDCH5x1oQdlxn/OoEgzBS9hveuhrQ9Y23LhT4MF+QIEHv/pC8Uoe e0dyljiVe7/FK2oqoh3xC6Yg5cgBTgtHAggdHrqkxqIVhQCICodA3LO47k+w95wLNJFI c/MQ==
X-Gm-Message-State: ALoCoQnp6tMkSA3+XLOyjYy2XAUaVMOKtzVwk1BDevIa5/pZptsrWPRa7VOeWeyd0B/YxlabTaSR
MIME-Version: 1.0
X-Received: by 10.112.119.139 with SMTP id ku11mr3809429lbb.49.1431623065557; Thu, 14 May 2015 10:04:25 -0700 (PDT)
Received: by 10.25.214.162 with HTTP; Thu, 14 May 2015 10:04:25 -0700 (PDT)
In-Reply-To: <CA+9kkMAJ-925hQ+wawkLvEjTaf5f1JRHdrGMtCRhGt9Q8Ntc1Q@mail.gmail.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> <CABcZeBOy2yBEMGMxcDy=E3fvc+OF1sZfvOV7twJHAvKqtrxtLg@mail.gmail.com> <28919F11-9336-41F6-9922-4E3E2DC4E935@gmail.com> <BD7B96B1-CD50-408F-AA06-49C20AB102A6@vigilsec.com> <CA+9kkMAH+U25ZhLq1HhGFHKMAECu+Y1ZJH-h4bOrEXaUQ15LjQ@mail.gmail.com> <87d225qwbq.fsf@latte.josefsson.org> <B30EDBDF-0803-4AB0-9EBB-DD726F617C5B@vigilsec.com> <2dc5d20a27664efe994398ec508f0e7e@ustx2ex-dag1mb4.msg.corp.akamai.com> <1E6924DE-D59C-4323-9658-766937368B98@vigilsec.com> <7F45C649-4C78-441E-8649-45D0F74168C2@vigilsec.com> <m2617wyu1v.wl%randy@psg.com> <CA+9kkMA18=KBtSWnS3murcFT7tfxNAe1Oi2YFNSkhOXTPDAFTw@mail.gmail.com> <m24mngytae.wl%randy@psg.com> <CA+9kkMB4uYr1SVUEqFKOB7AmPe793Mb-zAVU0GCK5d=XH9rsCg@mail.gmail.com> <m23830ysez.wl%randy@psg.com> <CA+9kkMAJ-925hQ+wawkLvEjTaf5f1JRHdrGMtCRhGt9Q8Ntc1Q@mail.gmail.com>
Date: Thu, 14 May 2015 13:04:25 -0400
Message-ID: <CAL02cgT2yO+iLGJBoMe1ejouyvigM3=h0mDx7iRK5c5fbQKdqQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Ted Hardie <ted.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bb0453046767305160db8a1
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/r36Ti1C8twqDqNn8mY-s9bFBfxQ>
Cc: Randy Bush <randy@psg.com>, 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: Thu, 14 May 2015 17:04:29 -0000

On Wed, May 13, 2015 at 7:36 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

> On Wed, May 13, 2015 at 4:22 PM, Randy Bush <randy@psg.com> wrote:
>
>> >>> "ACME certificate management must provide automated methods for
>> >>> revocation parallel to those use to request a certificate"?
>> >>
>> >> what the heck does "parallel" mean?  does it include means to revoke a
>> >> cert for which i have lost the private key and want to use an entirely
>> >> different proof of ownership/control?
>> >
>> > To me it means if you prove control of a domain in order to request a
>> > cert by methods 1, 2, or 3, then you can request revocation if you can
>> > prove control by the same set of methods.
>>
>> and what if i can prove control by method 42?
>>
>
> ​So, the point I'm getting at is that the system ought to provide
> an automated way to request revocation if the requester can meet
> the same bar as it would take to request or renew a certificate.  If 42
> is one of the ways to meet that bar, well and good.  If 42 is not one
> of the ways to meet the original bar, then putting effort to automating
> revocation on that basis seems off to me.  I'm not particularly interested
> in automating revocation on the basis that someone has a court order,
> for example, even if that would be a method to prove you are an authorized
> party.  Sure, you can hand the CA a court order, but they should look
> at it careful like, not automate the revocation.
>

The length of this paragraph is why I liked Russ's first revision ("allow
an authorized party to request revocation").  Ultimately, the CA is going
to have some policy about who it allows to revoke.  The protocol needs to
provide authentication of the requestor to support that policy decision,
but beyond that, the policy is up to the CA.

--Richard


>
>
>> > I do not think it means that you have to pick the same one from the
>> > set, but it is something for the working group to discuss.
>>
>> which is one of the reasons russ's phrasing was so good; it left it for
>> the wg to discuss and did not overly constrain the space.
>>
>>
> ​I think I want a wee bit more constraining here than you do.
>
>
>> > Is there language you like better for that?
>>
>> yes, russ's
>>
>> randy, who has had his say
>>
>
> I'm hardly going to fall on a sword over this, but I wanted to
> explain why I see the issue worth discussion now.
>
> Ted
>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>