Re: [Trans] Relaxing section 5.1

Eran Messeri <eranm@google.com> Wed, 16 November 2016 02:00 UTC

Return-Path: <eranm@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 395F9129538 for <trans@ietfa.amsl.com>; Tue, 15 Nov 2016 18:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 b9PugLTaiyqY for <trans@ietfa.amsl.com>; Tue, 15 Nov 2016 18:00:34 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 F075712954F for <trans@ietf.org>; Tue, 15 Nov 2016 18:00:33 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id g23so207190837wme.1 for <trans@ietf.org>; Tue, 15 Nov 2016 18:00:33 -0800 (PST)
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=y/bnmAETdG5DorEet/mTPlDj83vajuMqxiArit6NF5I=; b=ESxAnoob1JC0TQwLFQzyg2IKlF92M1vSQPhLHRTg1TiIsiv4CsLgHh8K9RCwo3J/72 ZjeZZR4G81DhOHhXZvXGAkTs+agB0L+mk19m5yErrAoWQwY5XtZfBCJVpFgWSlek+Mt3 x4cZzAiKC2SO1fppqCJ0FeEuh1pA3PKXJcC00A7MDzSFgk9d/1kq2Ocy3TmGlxs94+eN mHS37EWX1HdeS96j9NrCMP9jaKm6v5pnxEg2UhaAEWz15GnWIsu6y6VoDnuDvDFHoQ6h j8uinCOA9sNgiq9cDBdjh8Ahu20WD/dPw0tnzXyfKHP3O1EA13AZX5zbSIsQ65pk5m8O sCKw==
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=y/bnmAETdG5DorEet/mTPlDj83vajuMqxiArit6NF5I=; b=CpNKyuvef5P1mvDPDu/oxiaImq67knnFqktwQyMR4I9zC05XIXmzcGjhGZLKt8RtC1 OPeXkY9lV/8jMbWdLY/UZf3S0hXSjW3eFHlnF74zc+W9gGXc5B2I8X3Ik2HaZ2EWp7Ql HeN1+ls257WBSuZnfsVRt7AXyHmHvWpwfb/ZvX6VeVbqKWZHrc2W9xp1uWSms8bYu8yL qURtCGlLJhO9cSkcW5LzkGh1Pw00cJq3vNVZhxhmRjRS07zpdWuKfikX4DQvz0b57Cwy XoRgfGO1WPI2bE+G2o4uRVvAcUUXak6bezcpnG9KOkZMYuKnX60ExDiDs4qhyHtTibRX 3Q+w==
X-Gm-Message-State: ABUngvcoDFYhtTa1Cj8DRR7tF6//wRPz1kpdJhcCexisvcGi1sDD9xtidAzhhW7pUudUKqlTSOz6cWoeBGsno+i6
X-Received: by 10.28.37.2 with SMTP id l2mr7187346wml.86.1479261632467; Tue, 15 Nov 2016 18:00:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.31.21 with HTTP; Tue, 15 Nov 2016 18:00:31 -0800 (PST)
In-Reply-To: <CABrd9SQf3Sp=C9JZgf=OGY2pLL+-cNfxLKWPFq263yGFQ-4Dag@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> <CABrd9SQf3Sp=C9JZgf=OGY2pLL+-cNfxLKWPFq263yGFQ-4Dag@mail.gmail.com>
From: Eran Messeri <eranm@google.com>
Date: Wed, 16 Nov 2016 11:00:31 +0900
Message-ID: <CALzYgEfdDpHkKUZMfLoTd56kXHnE1jQKkSTkwnv3SA1t+Pbr8A@mail.gmail.com>
To: Ben Laurie <benl@google.com>
Content-Type: multipart/alternative; boundary="001a114afa2c22769e0541617021"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/lG6vOXQqL2-lwj4p4y22dqvVeNc>
Cc: Melinda Shore <melinda.shore@gmail.com>, "trans@ietf.org" <trans@ietf.org>, Peter Bowen <pzbowen@gmail.com>
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: Wed, 16 Nov 2016 02:00:36 -0000

My proposed compromise at the trans workgroup meeting yesterday was to
change the MUST in the following paragraph to a SHOULD:
"Logs MUST accept certificates and precertificates that are fully valid
according to RFC 5280 verification rules and are submitted with such a
chain."

I believe that this change allows creating logs that can reject valid
submissions under some circumstances while complying with 6962-bis. And we
wouldn't have to go through WGLC again for such a change.

On Sat, Nov 5, 2016 at 12:42 AM, Ben Laurie <benl@google.com> wrote:

> 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).
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>