Re: [Trans] Precertificate format

Eran Messeri <eranm@google.com> Tue, 09 September 2014 09:24 UTC

Return-Path: <eranm@google.com>
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 B9AE71A898C for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 02:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.03
X-Spam-Level:
X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
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 Tb-MxQP8obnD for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 02:24:11 -0700 (PDT)
Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4031A6F93 for <trans@ietf.org>; Tue, 9 Sep 2014 02:24:11 -0700 (PDT)
Received: by mail-vc0-f172.google.com with SMTP id hy10so3023313vcb.3 for <trans@ietf.org>; Tue, 09 Sep 2014 02:24:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ou9JVUaJb4pNAa2SRxX3hEQ9LS2qAXNjLpPzQbHXGQM=; b=Y9YCTYeIeHjjOPnuySL0lFxy0YKXpojsmihnV7ZnyyExM0lN+ZNUetELL2Zj1YxXgs WhfjQ/4GFU/SF7E8rA1SyvfZy9QPb4JRyyim8ozZhGNqqxoMqOZ8kr710t/GLePIB3rq okUgqgBjsTuBJNaPZeLwjep9RjLVk2BfODb+Ic0wwuWknoGBv1b13q92bV3JwXYQAJOc NDrYhjp6F0ENW6f4e15AW6l5msx4d+483fAzZGRJtNayfq0fJoIHz1WpiYhFoo/wQZuY GiDdsb+45x0+HkgrvK6ZaYRNNoeK3rSEg6ehrN2ynTaV+ywUMwAS+mBlCPZPajDzbIXg Xc0Q==
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:date :message-id:subject:from:to:cc:content-type; bh=Ou9JVUaJb4pNAa2SRxX3hEQ9LS2qAXNjLpPzQbHXGQM=; b=BrBwBRXwwvmfnd/g9oae/vGxMM401fekcXC/ScE+1glZRKNHklhoiX5WTbwRRsb+PH opUGzjY1AavvIKJjz2MOtu0bhb1VOnZu8wyCTrcumVrr1fM+Xs+ezRCZmkjpbZR9YFH4 XWADoxg1TFeGPT9eJY6S+DmllApTv7KsNzQRrpUUaDkeEyux0W9RDph/EP1Nqj3rssVM f25GPFCDaZmbBzZ0IR+WX1BHCN3QTnHsO8vMd2p+zETqLW7KE+1gFCpIlCW2XsKOScqZ Kwll8KvA9/X/s/FM0Rwf/wL/KCFPDvlTc9+FeTIGsLu05UVC1jjP57Ur97zme9EYtVJl uS4A==
X-Gm-Message-State: ALoCoQlBgQDGKfWCldpR2+eVOsC5czc0eSCcVRUlvLVCXzRJPQurUENCnfRPcrjk6ZLqrMlvi3cs
MIME-Version: 1.0
X-Received: by 10.52.30.2 with SMTP id o2mr24834039vdh.12.1410254650343; Tue, 09 Sep 2014 02:24:10 -0700 (PDT)
Received: by 10.52.2.138 with HTTP; Tue, 9 Sep 2014 02:24:10 -0700 (PDT)
In-Reply-To: <20140909011451.GW5645@hezmatt.org>
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com> <CAFewVt5kZqw0-W7PqtFHe7yJUsR9PqVJ6C74ZShgo0qs19wLjA@mail.gmail.com> <544B0DD62A64C1448B2DA253C011414607D07DC251@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <20140909011451.GW5645@hezmatt.org>
Date: Tue, 09 Sep 2014 10:24:10 +0100
Message-ID: <CALzYgEee_=1HTBvF3MQEZeeZc9VL_rK2eRjwVjOnhZKEO+8r=w@mail.gmail.com>
From: Eran Messeri <eranm@google.com>
To: Matt Palmer <mpalmer@hezmatt.org>
Content-Type: multipart/alternative; boundary="20cf307d06b27a1ed005029e7f6d"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/KHmxq6AfuXz44nnzI21l0SBhzUY
Cc: "trans@ietf.org" <trans@ietf.org>
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 09:24:14 -0000

I see two issues:
* What should the precertificate contain.
* What should be the format of the precertificate.

First I'd like to point out that there already is a way to issue
precertificates without violating section 4.1.2.2 in 5280:
As Matt correctly pointed out, when a Precertificate  is signed by a
Precertificate Signing Certificate, then the log produces a signature over
a TBSCertificate that _uses the final issuer's identity_, not the one in
the Precertificate Signing Certificate (hence the requirement that the
Precertificate Signing Certificate will be signed directly by the
certificate that will ultimately sign the end-entity certificate the
Precertificate represents).
That is explained in section 3.2 of RFC6962 ("Structure of the Signed
Certificate Timestamp") or in compliant code
<https://github.com/google/certificate-transparency/blob/master/java/src/org/certificatetransparency/ctlog/LogSignatureVerifier.java#L149>.
 We could do a better job of explaining this in RFC6962-bis (I personally
found it confusing when implementing the Java CT API).

On what precertificates should contain:
Seems like there's a consensus that it should be all data in the final
certificate, except for the serial number, for which there's no agreement.
The argument against including the serial number, raised mostly by Stephen,
is that it may be difficult for CAs who use HSMs to determine/generate the
serial number in advance. I don't recall any CA strongly supporting this
position (and, given precertificates from several CAs have already hit CT
Logs, that's definitely not an issue for several CAs).
The argument for including the serial number is its necessity for revoking
a certificate - Somebody has mentioned alternative revocation mechanisms
that do not require it but have not provided any references, and all
current mechanisms I know of require the serial number.
We all realize the requirement for pre-generating the serial number is a
disruptive one for the certificate issuance process - Given the authors of
RFC6962 have tried hard not to introduce disruptive changes, I think this
is a reasonable given the necessity of the serial number.
Melinda, how do you propose we reach a consensus on the issue if serial
number inclusion?

On the format of precertificates:
As far as I understand the main motivation behind exploring alternative
formats is the desire to avoid two (bitwise-different) X.509 certificates
with the same serial number, signed by the same issuer.
Recall that the log requires a signature over the to-be-issued certificate
as an indicator of the CA's intent to issue a certificate, but that format
does not have to be the same as the one that will be signed by the log
itself.

My proposal is that the structure the log signs would remain the
TBSCertificate as RFC6962-bis describes today, but the data structure for
the Precertificate could be something else:
A structure described using ASN.1 notation or a very crude transformation
over the TBSCertificate (like a signature over the base64-encoded DER
representation of the TBSCertificate).
The main concern here is that CAs should be able to sign this structure
(basically, an arbitrary blob) with the issuer's key.
Which encoding / formats are CAs comfortable with?

The reason for distinguishing the data structure the log signs from the one
the CA submits is simplifying client implementation - to make CT easy to
adopt by as many TLS clients as possible, we should avoid as much as
possible introducing additional requirements on clients. The ability to
manipulate X.509 certificates is an ability a TLS client should already
have, which is why I suggest we stick to that format for the data structure
the log signs.


To sum up, I propose:
* Finding out how to reach a consensus regarding the serial number
inclusion.
* Changing only the Precertificates format that is signed by certificate
issuers, keeping the X.509 TBSCertificate as the data structure signed by
logs.
* Soliciting feedback from certificate issuers on what encoding / formats
are they comfortable signing using the final issuer's key.

Eran

On Tue, Sep 9, 2014 at 2:14 AM, Matt Palmer <mpalmer@hezmatt.org> wrote:

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