Re: [Trans] Relaxing section 5.1

Peter Bowen <> Fri, 04 November 2016 14:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F3011294FE for <>; Fri, 4 Nov 2016 07:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 rNTm5EaT-pgA for <>; Fri, 4 Nov 2016 07:07:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 43615129495 for <>; Fri, 4 Nov 2016 07:07:52 -0700 (PDT)
Received: by with SMTP id d128so31094144ybh.2 for <>; Fri, 04 Nov 2016 07:07:52 -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=rox/k2TptN5JOKZoxWSQlNUdIsdZrxq63pkyzysm5A4=; b=jM4fJSmgP4DIeQ6oM7VEXghxOtRrR0M0U4tpelvAv+47RikVJo0KH5T+/lLfYzsUAk fMCPhG+d2RksvgALzdHExCKdFf3ym1g9RqzVZ070UnnAK8fiwTdjPI69Fys/fslGxEWU IdWeCisDnl7GhdcLkh77YZ02uN7fNduAE5Jwudxmn8QfCmJcpLP0dP5lC+E9H56KBNfM nRmKd9U+RnUJrmL/2LtZdKn9oe61IVxdaGVDTN7iF35j2v89ucEE8eF6G4TkoZz1LDqr HNkjd7AWyGwYBupBo1jtHysRmfQgHkUo45WAlF51TOqXl7ijlahk1htc8fzZDmK3z9mu 4cJQ==
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=rox/k2TptN5JOKZoxWSQlNUdIsdZrxq63pkyzysm5A4=; b=LSBGtswsjL2XtlOoTBe1JSN3/qxslve1Ix3KtQ0uVQl1aFw7NI6tDb+5Pzyag5s9jH rJoArNus9zlbVs8M3kmGqu/p5f2mT0Tt5/e2+mibP5VVPue/iQUkK7PrdJKD09LJQXtl aBPeiH0+4m6fe3RKXESEjaOtmiDKXWq3X7fmjEzinVyFuQa1ISZ59lJApyEgHOUn8sKR D/w3Mw6zBIK3tBRfgNiMfVROzXS6BrHrX66xxvmUv0ThhV9I9OJGni2BzhnurEbte58J fm1ZVIkptLAOX2/NbL4zgnsnIdL06wrhg3Pp94IvOxOjRWo6E3QKsmKO8Enyljcz1+J8 n0yA==
X-Gm-Message-State: ABUngvfZRtp034KyN48DkfEQuvU77kyKjObo1nSBc2NWRwd7WyubAUvdv2RxQ7q4XfYdBkWi/B8dKWreB30+GQ==
X-Received: by with SMTP id l73mr1946849itc.115.1478268471285; Fri, 04 Nov 2016 07:07:51 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 4 Nov 2016 07:07:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Peter Bowen <>
Date: Fri, 04 Nov 2016 07:07:50 -0700
Message-ID: <>
To: Ben Laurie <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: Melinda Shore <>, "" <>
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: Fri, 04 Nov 2016 14:07:53 -0000

On Fri, Nov 4, 2016 at 6:33 AM, Ben Laurie <> 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.