Re: [Trans] Precertificate format

Matt Palmer <mpalmer@hezmatt.org> Tue, 09 September 2014 01:14 UTC

Return-Path: <mpalmer@hezmatt.org>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883881A02D1 for <trans@ietfa.amsl.com>; Mon, 8 Sep 2014 18:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.421
X-Spam-Level:
X-Spam-Status: No, score=0.421 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
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 xzwQPo8otynI for <trans@ietfa.amsl.com>; Mon, 8 Sep 2014 18:14:54 -0700 (PDT)
Received: from mail.hezmatt.org (mpalmer-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:9e6::2]) by ietfa.amsl.com (Postfix) with ESMTP id A64AB1A02BE for <trans@ietf.org>; Mon, 8 Sep 2014 18:14:54 -0700 (PDT)
Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id D1F54282E0B for <trans@ietf.org>; Tue, 9 Sep 2014 11:14:52 +1000 (EST)
Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 8677BA01A5; Tue, 9 Sep 2014 11:14:51 +1000 (EST)
Date: Tue, 9 Sep 2014 11:14:51 +1000
From: Matt Palmer <mpalmer@hezmatt.org>
To: trans@ietf.org
Message-ID: <20140909011451.GW5645@hezmatt.org>
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com> <CAFewVt5kZqw0-W7PqtFHe7yJUsR9PqVJ6C74ZShgo0qs19wLjA@mail.gmail.com> <544B0DD62A64C1448B2DA253C011414607D07DC251@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607D07DC251@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/8eSIeJ6gTmilnR4rPXY223oI7mM
Subject: Re: [Trans] Precertificate format
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 09 Sep 2014 01:14:56 -0000

On Mon, Sep 08, 2014 at 04:24:26PM -0700, Rick Andrews wrote:
> > The CA may use a Precertificate Signing Certificate to sign the
> > Precertificate, and then sign the final certificate with the production
> > CA certificate.  Then, there would be no duplicate serial number issues.
> 
> Brian, even if the CA uses a Precert signing cert, the precert's issuer
> name has to be that of the ultimate issuer, and the serial number has to
> be that of the ultimate certificate, so I don't think that solves the
> problem.

As the Wikipedians say, "Citation Needed".  My understanding is that there
is no restriction on the contents of the issuer certificate of a precert,
other than:

    a special-purpose (CA:true, Extended Key Usage: Certificate
    Transparency, OID 1.3.6.1.4.1.11129.2.4.4) Precertificate Signing
    Certificate.  The Precertificate Signing Certificate MUST be directly
    certified by the (root or intermediate) CA certificate that will
    ultimately sign the end-entity TBSCertificate yielding the end-entity
    certificate

That's from RFC6962 s3.1, and the wording is identical in rfc6962-bis.xml in
the github repo at the time of writing.

Of all the mentions of "issuer" in 6962, the closest relevant mention I can
find is in s3.2, "Structure of the Signed Certificate Timestamp", in the
paragraph discussing what `tbs_certificate` is, which talks (rather densely)
about how precerts differ from regular certs, and how the TBSCertificate
structure's issuer and AKI extension need to be those of the final
certificate issuer, not the precert issuer.

This variation between the issuer listed in the precert and the *actual*
issuer of the precert would potentially be a problem, if the usual chain
verification methods were employed, but it does mention elsewhere in 6962
(s3.1, para 4) that normal X.509 verification rules "may be relaxed" to
accommodate this sort of situation.  This is reasonable because the chain
verification is for spam prevention, rather than for information security.

For my log implementation, I've just made sure that the signature of the
cert was made by the public key in the next cert up the chain.  I'm not
looking at revocation, notBefore/notAfter, issuer/subject matching, or
anything else of that nature

Nobody other than logs need to verify the chain of the precert, either,
because browsers can verify the signature for the precert and then compare
the contents of the precert (from the log) and the presented cert and make
sure those details match.

- Matt