Re: [Trans] Relaxing section 5.1

Eran Messeri <eranm@google.com> Thu, 03 November 2016 09:35 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 EE692129412 for <trans@ietfa.amsl.com>; Thu, 3 Nov 2016 02:35:02 -0700 (PDT)
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 1tHLSJsrsutt for <trans@ietfa.amsl.com>; Thu, 3 Nov 2016 02:35:01 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 DAF41129490 for <trans@ietf.org>; Thu, 3 Nov 2016 02:35:00 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id p190so320195154wmp.1 for <trans@ietf.org>; Thu, 03 Nov 2016 02:35:00 -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=vuHHcMZ0xWXrqff9P/NXbAuEM+Ob8bAmwJBnSeNKG40=; b=MCNKK4WLWqD6ARSbgJuJKGvNJDTBK6DsTGiPXstL1/tIpf57ZI2MWtjN9VpoNQEQOh zcD0D+5ENBL8E73nNNrtrYRp0DWKuckWHZBtXBxmXeY1by/IBO4fUMa32yKSXzBwHTSc /ucQtzSDfLTXAyqfFF4lZeuSSZvtcQtbAzRsUfMPiReBM5w0SQGDiKuLJHCSRKFlZzpH ikXzJh5uOehU2MdwRbd5nIhfWfTNnu1/V0Ktq6q10YJ8PQshUd766gcEfmK1Hh0BKmwB sqVTjEH5VOgW/nuAJIDG6C8T3sygXeFkdA2fnP7kd9lbg2oRZqIkL7bQJ4vtOalAGEE0 pSDg==
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=vuHHcMZ0xWXrqff9P/NXbAuEM+Ob8bAmwJBnSeNKG40=; b=fJ4JoAbxXHwyzfO1VPvU4lp+SACAlaBDCkUBevipoSrU6kG4GKp8zFzSoWXDUPK5Si jXPswRLlSFsQAHVOEFy0/utaQ8DdIbq4mVh8OSXc5LxUCRX/o1ZolF8EGJjH5HdtqXtM Z/onxScuxAO4L2TXs0cxcZuIiWHpZJ4EJ29yL4sOx0Up2go3Ha5oktE3a3A7AUgCO81x v2VfqKwxqHVbf7aorfd2lmAQAzf46GeGj5flBExV1TQJkO7tzLAb0RMW8Eqo3Ib3t4e2 qmPHyQa6sSHcr0UhqxaqLlnlSr8eNYM546dJLc7o/UWMkXTAV7VhGnyeqLKB9su32EcI 5GNw==
X-Gm-Message-State: ABUngvfYMe7xysmVNMFK6r8GJ8EK0g1IsrhOzEyXHp8sDj+gzHEdwOI0MsOabXeVzoYk26Pw/4qZvOc7u3fsuVMY
X-Received: by 10.28.49.85 with SMTP id x82mr1004426wmx.129.1478165699219; Thu, 03 Nov 2016 02:34:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.31.21 with HTTP; Thu, 3 Nov 2016 02:34:58 -0700 (PDT)
In-Reply-To: <CAK6vND-otfOKf6g5TF3LUki68MF1xiEc23dMsMw8WnJVwoDVVQ@mail.gmail.com>
References: <CAK6vND8_4OQ0du0MC8Z5=NJR5ho1EpT-8H41O+Te9tvM3YeNcg@mail.gmail.com> <CAFewVt4_7VYf3UkP+7drqVLQ7hKAotg1VQEaqgMmw6kJBtzwLA@mail.gmail.com> <CAK6vND-otfOKf6g5TF3LUki68MF1xiEc23dMsMw8WnJVwoDVVQ@mail.gmail.com>
From: Eran Messeri <eranm@google.com>
Date: Thu, 03 Nov 2016 09:34:58 +0000
Message-ID: <CALzYgEcYvuE10Lyr0FTmq6MaD7eaGZNBuQbEE11ow1Z3-xi4qQ@mail.gmail.com>
To: Peter Bowen <pzbowen@gmail.com>
Content-Type: multipart/alternative; boundary="001a1142dd786c3c4505406245e6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/5XLrPBTlwQAfPTooYsZVshYeuwQ>
Cc: "trans@ietf.org" <trans@ietf.org>, Brian Smith <brian@briansmith.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 09:35:03 -0000

On Thu, Nov 3, 2016 at 1:29 AM, Peter Bowen <pzbowen@gmail.com> wrote:

> On Wed, Nov 2, 2016 at 1:08 PM, Brian Smith <brian@briansmith.org> wrote:
> > Peter Bowen <pzbowen@gmail.com> wrote:
> >>
> >> Currently 6962bis section 5.1 says:
> >>
> >>   "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 also
> >>    reject precertificates that do not conform to the requirements in
> >>    Section 3.2."
> >>
> >> Is there a reason this is enshrined as a MUST?  It seems like it
> >> should be up to the log operator to determine their policy.
> >
> >
> > The log can reject the submission (return a non-2xx response) and still
> > incorporate the certificate into the log, especially if it can build its
> own
> > path to a trust anchor it trusts. The only thing that the log is
> prohibited
> > from doing is giving the submitter a 200 response with an SCT when the
> > submitter supplies an incomplete/untrusted chain.
>
> Right, but why?  If the log can fix it up on the fly, why not return a
> SCT?  Why can a log not include a certificate it finds acceptable even
> if it can't link it back to a root?  Why should a log have a separate
> store of certs for "future submission" instead of logging them
> directly?
>
My answer to those is protocol simplicity:  6962-bis specifies the minimum
necessary to build CT logs servers and protocol for clients such that
Certificate Transparency can be implemented.

I actually like the idea of a ct-log-like service that would take partial
submissions and fix them and would be happy to help specifying such a
service. The CT team here has some open-source code for fixing chains
<https://github.com/google/certificate-transparency/tree/master/go/fixchain> on
which such a service could be based. Such a service (when not constrained
by the CT log interface) could be expanded to return multiple valid chains,
for example.

(It could be combined with a proxy submission service - a log-like
interface that takes an add-chain/add-pre-chain submissions and submits
them in parallel to multiple log servers, returning the
SCTList/TransItemList to be embedded in the final certificate or served
alongside it).

My point is that I see the value in automatically fixing submissions and
would happy to collaborate on specifying/building such a service, simply
pointing out it could exist independently of the log specification in
6962-bis.


> I see the worry about spam, but this would seem to be a greater risk
> for the log operator than anyone else.  After all the log has to store
> all the data and transfer it to all the clients, so their bandwidth
> usage is far greater than any given client.
>
> Thanks,
> Peter
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>