Re: [Trans] Relaxing section 5.1

Ben Laurie <benl@google.com> Fri, 04 November 2016 15:42 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 BC76812958C for <trans@ietfa.amsl.com>; Fri, 4 Nov 2016 08:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.498
X-Spam-Level:
X-Spam-Status: No, score=-3.498 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_NONE=-0.0001, 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 Si4dD_2lzUxM for <trans@ietfa.amsl.com>; Fri, 4 Nov 2016 08:42:25 -0700 (PDT)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 405DC129590 for <trans@ietf.org>; Fri, 4 Nov 2016 08:42:25 -0700 (PDT)
Received: by mail-ua0-x234.google.com with SMTP id 12so69361268uas.2 for <trans@ietf.org>; Fri, 04 Nov 2016 08:42:25 -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=XD55RBBTge+fwH82DULdl4Ba59U0HsGayQJnE46HbtI=; b=llPa4u6L6H9ZFLvqmCoUVni7kPV+iiG/7zPy5uk6xB7Aep2rCy0nljq4lwEwil+Uyq PpAGF6CtxJTmJSfB5xk6h2Ge0oBCktx+MCKULIDmu2xWwauRQSeBvJJ2UP21pZkWek5L P5bor6JPUvzZc4dzjHefyuElJDSPH3AFM1faOMUr14zF4NnTS5f/5tJ3njx44fHNH/0a bzs1Z0HXYl7wY8mp7aS8ZTIXfeoZjmEGJ3ZiUnkoekjv5G7ZT7FqZsnr6KhT/LnZE+4k ur3rw7H2eLSNAYIYbTvLX8/+JoAyZW5mZMDfpdQGQB1MlMWCB6kiWxNQ8XgXtBBFSukB NXIQ==
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=XD55RBBTge+fwH82DULdl4Ba59U0HsGayQJnE46HbtI=; b=UzocUtAePAeRLBHQo0Fw7IR/pOxw61ffkQ9y03mo6weVqbmDCpM35KCkamhj/pGUGk dXcsy+76Rsqo1JKK8i1no9yMcqyoLn/4nIAphJruLPWyoYnWHVRLc1MMzw241kFyalOM Gy6Zqf7QdXexrxVVzHJuPV4iF+iS2VuxE6wbhySDpMNaJHuqZlTfQ7ItSGUIbHC5Ma1y /4GTiNDRu7zIRwBVBnudoQsQmp4RZgaQtayaRd6Eyj83nzK/TQFacEK8e4ZJ0JGBr/k4 ULebqmcSNeDp+RamgrDztczQLg+tvatMa9VOrK96RyNuc/9MiU14JbmjOkIJA9yTpdwP VfXw==
X-Gm-Message-State: ABUngve6qT2GCjXOmFjZW8xyQstZoBj+Ww8L8b/wHx8+JEHN6TLLmRzMHkTlm1bldnnUEkpqYXX8CBwaGMzjTVKu
X-Received: by 10.159.38.133 with SMTP id 5mr8048755uay.102.1478274144180; Fri, 04 Nov 2016 08:42:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.149.203 with HTTP; Fri, 4 Nov 2016 08:42:23 -0700 (PDT)
In-Reply-To: <CAK6vND-sy2vCP4dufSBV0_-tT3BU1EOj-T4MJnObOQaeO3V2xg@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> <CAK6vND9b4oEOnZR=PtWw-znbsu785Gps87jumAXgFjkro-tptg@mail.gmail.com> <CABrd9SQnFApjrn2zOekHcfgvV6NyFFTr9ObwUdncsUggc7cFNg@mail.gmail.com> <CAK6vND-sy2vCP4dufSBV0_-tT3BU1EOj-T4MJnObOQaeO3V2xg@mail.gmail.com>
From: Ben Laurie <benl@google.com>
Date: Fri, 04 Nov 2016 15:42:23 +0000
Message-ID: <CABrd9SQf3Sp=C9JZgf=OGY2pLL+-cNfxLKWPFq263yGFQ-4Dag@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/sSQzXGabIq8Cvg5wGghfvVW6RD4>
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: Fri, 04 Nov 2016 15:42:27 -0000

On 4 November 2016 at 14:07, Peter Bowen <pzbowen@gmail.com> wrote:
> On Fri, Nov 4, 2016 at 6:33 AM, Ben Laurie <benl@google.com> wrote:
>>
>> The bit you didn't quote does say they the log has to accept valid
>> certs, tho: "Logs MUST accept certificates and precertificates that
>> are fully valid according to RFC 5280 [RFC5280] verification rules and
>> are submitted with such a chain."
>
> Sorry about that.  So the three MUSTs together are:
>
> - Logs MUST verify that each submitted certificate or precertificate
> has a valid signature chain to an accepted trust anchor, using the
> chain of intermediate CA certificates provided by the submitter.
>
> - Logs MUST reject submissions without a valid signature chain to an
> accepted trust anchor.
>
> - Logs MUST accept certificates and precertificates that are fully
> valid according to RFC 5280 verification rules and are submitted with
> such a chain.
>
> When I read these together, I read that Logs must accept _any_
> certificate that is fully valid according to RFC 5280 verification
> rules and chains to any root the log trusts and logs must _only_ log
> such certificates (and no others).
>
> If this is accurate, we need to account for all types of certificates
> being logged, as a log cannot choose to reject certificates for usages
> other than server authentication and the log cannot reject
> certificates that have personal information (e.g. an server
> authentication certificate that states which human requested the
> certificate in the subject).
>
> This seems like a very strong assertion of policy rather than a
> technical discussion of how the CT protocol works.  I would again ask
> the WG to reconsider the requirement levels specified in this section.

FWIW, I tend to agree. I would also note that operationally, we have
already discussed options for logs that are incompatible with these
requirements, for example:

* sharded logs (e.g. by hash(cert) mod n).

* logs that only accept short or long lifetime certificates (this
would allow the working set to be reduced in size for CAs that issue a
lot of short-lived certs).