Re: [Trans] Relaxing section 5.1

Ben Laurie <benl@google.com> Thu, 03 November 2016 10:33 UTC

Return-Path: <benl@google.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07E312949F for <trans@ietfa.amsl.com>; Thu, 3 Nov 2016 03:33:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 LuUxkC8zucUn for <trans@ietfa.amsl.com>; Thu, 3 Nov 2016 03:33:49 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 4008F129420 for <trans@ietf.org>; Thu, 3 Nov 2016 03:33:49 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id d65so35943974vkg.0 for <trans@ietf.org>; Thu, 03 Nov 2016 03:33:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XQRPiLYj4q+ikdzOU2VqkW3CS66OyMSFkJ180dfQUO0=; b=CdwhMVjfVvNttPA5DVbOoJZ1H7pVqaOKN41LQo8cEGK5ah1p4F4uvjQfHnwdDBRIqc aKdHAMRRl1QT1rvWexHQr6ftyVJRdMtMmfzsDThAlSnvZab3OWevwynFkXaHuNv1m7KY fakVH4Ewpmf3kZRY3Cgar8UN8tF8bRfqoACZFgahj6ltsnRaIewiz+CWY1fIE9pP3qbQ iFb0v/LRaAQUv5ac7ya+DRw2Ir7KeCaeRdXGmbLYnfjEmY/uNRtMO5gKGxgDAwYczzFH 3K9FK9vijw0PGhG2uGbnkin/HxCA4wihAiIqPsQE3AlTiHMTy14JbQpmAbj6M2ZQ/l6T i8lg==
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:from:date :message-id:subject:to:cc; bh=XQRPiLYj4q+ikdzOU2VqkW3CS66OyMSFkJ180dfQUO0=; b=eMqevfF50paLpmGZb1goCGZrQbuS36xjXPwkfhDu2Ya000zbcWMMVhdbAe0H1JlO03 aY9NUxsEIcZLF+2cuMrv3d4kXpE2hRrup9eY/w7/91UYFARnF8Jfrgs0FBJ70N1FyFg2 Nh/9aILhoJJ7KRdEOcgyeNCVeouPUCj+H75c/7zyg2F0slhlvO58Zj6z+WFk4Qh4Dcox WuxHxFq238FYim0oxd1UU+UzvCcpZLfCffOAIUtjlVdJsnFgho4tK7zyXuShF06zssDh 3gpywbc4nerZ2ZBToQl0nF5RpQGYQ6PbLWzu1P912l1dvspxkKH0CrEIkDT18u/k2p/a fjig==
X-Gm-Message-State: ABUngvfiGudaIor8iyaJuosK0YTmtWRFr+1b40ma8rh/VPmPbNXM30o51o3FUOYFaSou2ZUFT89g+9BbwMkFi0cf
X-Received: by 10.31.130.20 with SMTP id e20mr4895548vkd.149.1478169228247; Thu, 03 Nov 2016 03:33:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.149.203 with HTTP; Thu, 3 Nov 2016 03:33:47 -0700 (PDT)
In-Reply-To: <CABrd9SQ506fFGvrEj=Sknb-Lm3HESGwOvcuG84xovttxwirYSw@mail.gmail.com>
References: <CAK6vND8_4OQ0du0MC8Z5=NJR5ho1EpT-8H41O+Te9tvM3YeNcg@mail.gmail.com> <CALzYgEcuf+WoUVy=vsPYJ7t49ASe_5Tc7ySOuKoYJMzpODHtSA@mail.gmail.com> <1c7240d7-f38d-2011-ad45-587843e0f1f8@gmail.com> <CAK6vND_XeyQsO=4pP12e3HL+r8Cdw_M7Gm1SB5zoQKGHbKUP7w@mail.gmail.com> <CABrd9SQ506fFGvrEj=Sknb-Lm3HESGwOvcuG84xovttxwirYSw@mail.gmail.com>
From: Ben Laurie <benl@google.com>
Date: Thu, 03 Nov 2016 10:33:47 +0000
Message-ID: <CABrd9STKmbJi03e-KLORiDfvPj6QJzk2S_W2RcAJXp2pY0ftvg@mail.gmail.com>
To: Peter Bowen <pzbowen@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/9-xyPNRR4TtWJBG5G1ENeL0olds>
Cc: Melinda Shore <melinda.shore@gmail.com>, "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Relaxing section 5.1
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2016 10:33:52 -0000

BTW, its probably smart to design a more general transparency standard
and then have profiles for different use cases. But we did decide not
to do that until we had other examples of transparency (I'm building
one right now, as it happens, and it is not the only one I am aware
of).

On 3 November 2016 at 10:31, Ben Laurie <benl@google.com> wrote:
> On 2 November 2016 at 14:08, Peter Bowen <pzbowen@gmail.com> wrote:
>>
>> By requiring all logs MUST accept any certificate that chains to a
>> root in the log's root list, 6962bis fails to allow log operators to
>> mitigate any Denial of Service attacks mounted by attempting to log
>> massive numbers of certificates that are not relevant to the log
>> scope.  For example, many existing certification authorities issue
>> both server authentication certificates and certificates for personal
>> identification.  For some roots, acquiring large numbers of these is
>> relatively easy (see discussion of fetching millions of Taiwanese
>> Citizen Digital Certificates in
>> https://smartfacts.cr.yp.to/smartfacts-20130916.pdf)  As written
>> today, a log MUST accept these.  There is no option for a log to
>> require that all certificates must meet some usability criteria.
>
> The requirement is to reject certs that don't meet the criteria, not
> to accept those that do.