Re: [Trans] Relaxing section 5.1

Eran Messeri <> Thu, 03 November 2016 09:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE692129412 for <>; Thu, 3 Nov 2016 02:35:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.197
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1tHLSJsrsutt for <>; Thu, 3 Nov 2016 02:35:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DAF41129490 for <>; Thu, 3 Nov 2016 02:35:00 -0700 (PDT)
Received: by with SMTP id p190so320195154wmp.1 for <>; Thu, 03 Nov 2016 02:35:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id x82mr1004426wmx.129.1478165699219; Thu, 03 Nov 2016 02:34:59 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 3 Nov 2016 02:34:58 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Eran Messeri <>
Date: Thu, 03 Nov 2016 09:34:58 +0000
Message-ID: <>
To: Peter Bowen <>
Content-Type: multipart/alternative; boundary="001a1142dd786c3c4505406245e6"
Archived-At: <>
Cc: "" <>, Brian Smith <>
Subject: Re: [Trans] Relaxing section 5.1
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Nov 2016 09:35:03 -0000

On Thu, Nov 3, 2016 at 1:29 AM, Peter Bowen <> wrote:

> On Wed, Nov 2, 2016 at 1:08 PM, Brian Smith <> wrote:
> > Peter Bowen <> 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
<> 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

> 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