Re: [Acme] Proposed ACME Charter Language

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 14 May 2015 16:58 UTC

Return-Path: <hallam@gmail.com>
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 B73DA1A89F9 for <acme@ietfa.amsl.com>; Thu, 14 May 2015 09:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 IrUuxY3810RS for <acme@ietfa.amsl.com>; Thu, 14 May 2015 09:58:03 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (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 D07FA1A89E1 for <acme@ietf.org>; Thu, 14 May 2015 09:58:02 -0700 (PDT)
Received: by laat2 with SMTP id t2so76529575laa.1 for <acme@ietf.org>; Thu, 14 May 2015 09:58:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IhvYKMLn3jpwJoCqpaFjv4sSm3aA4H1KFZUgdzaK4D8=; b=Zd/kxvnPVaVHI40E6b8OjJYdKq6z36IV3Xe+Cd1vBHVbpJHu8noHrB4NngJbF+cxz7 NgYUSVIaAnkEHznZIoADa8f12lSQYo2mp1Ly3NfxaipK9j5wRmxgI7Cmz/2ucFxvHLNU YZfGsRfm//bhrMQ6iZwTpWkLRNVq9mJcJM81hmw21ac6X2yzus/ks00G/IwSmMKpxGOr jIVOVQNWb3QfKHrCf2ruwZPup+93L+73sIHfwmf+DRQNuIfd997Qq+jwoB28B+WYPQuK /QmnVlTBOvbA+sI/zFsu4SMdLdEPkfBMxaM/dLZvC1sU19QlasIrtUuZDauBU4g0/Wy6 KVSQ==
MIME-Version: 1.0
X-Received: by 10.112.202.103 with SMTP id kh7mr3797780lbc.118.1431622681399; Thu, 14 May 2015 09:58:01 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.203.163 with HTTP; Thu, 14 May 2015 09:58:01 -0700 (PDT)
In-Reply-To: <36ae09b7c2bf4d60baca1e8d8ba9fd44@ustx2ex-dag1mb4.msg.corp.akamai.com>
References: <CA+9kkMDB_sc6NLc4zqJAYZq6ELjHCd=6g_9CyH6zTH2cK+0apQ@mail.gmail.com> <36ae09b7c2bf4d60baca1e8d8ba9fd44@ustx2ex-dag1mb4.msg.corp.akamai.com>
Date: Thu, 14 May 2015 12:58:01 -0400
X-Google-Sender-Auth: qYS6h5E1hnc5DB_QIjGFqVc4ctM
Message-ID: <CAMm+LwjcXK8NzwU34wwQ8yFiRvxptS1bQvRPPoAQvD+her3HwQ@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: multipart/alternative; boundary=001a11c3699a609ade05160da14d
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/YXpjT2Or_IY-PAe0j2xs9BUWvhI>
Cc: Ted Hardie <ted.ietf@gmail.com>, "acme@ietf.org" <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 16:58:06 -0000

On Wed, May 13, 2015 at 7:39 PM, Salz, Rich <rsalz@akamai.com>; wrote:

> > https://github.com/letsencrypt/acme-spec/issues
>
> I'd prefer if we just recorded issues there, but discussed them in the
> mailing list.


I would prefer if we avoid getting into practices and policy issues there
as well.

An IETF working group has a finite lifetime and a limited constituency.
Both make it a bad place to decide security policy. We write 'Security
Considerations' not 'Security requirements'.

Validation processes are like algorithms. The IETF can recommend but can't
make a final decision. I think we all agree that it would be a bad thing if
RFC5280 had made SHA-1 support a MUST and that this has in effect been
superseded and this is a good thing.

I don't think we are very likely to be changing crypto algorithms very
frequently in the future. We seem to have a grip on those. But validation
processes seem to me to be something that are not just likely to change, we
would want to keep a watchful eye on.

It isn't even the case that stronger validation mechanisms are necessarily
better or necessarily necessary. We are going to a world where security is
going to be required and insecurity becomes the exception. We are not going
to a world where perfect security is required though. If 'some' security is
required we can get rid of the low assurance security signal (aka padlock
icon) and replace it with a danger signal. for no security.