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 >
- [Trans] Precertificate format Melinda Shore
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Melinda Shore
- Re: [Trans] Precertificate format Brian Smith
- Re: [Trans] Precertificate format Rick Andrews
- Re: [Trans] Precertificate format Hill, Brad
- Re: [Trans] Precertificate format Matt Palmer
- Re: [Trans] Precertificate format Matt Palmer
- Re: [Trans] Precertificate format Eran Messeri
- Re: [Trans] Precertificate format Tomas Gustavsson
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Carl Wallace
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Hill, Brad
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Brian Smith
- Re: [Trans] Precertificate format Hill, Brad
- Re: [Trans] Precertificate format Brian Smith
- Re: [Trans] Precertificate format Brian Smith
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Brian Smith
- Re: [Trans] Precertificate format Kyle Hamilton
- Re: [Trans] Precertificate format Watson Ladd
- Re: [Trans] Precertificate format Tomas Gustavsson
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Melinda Shore
- Re: [Trans] Precertificate format Melinda Shore
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Jeremy Rowley
- Re: [Trans] Precertificate format Erwann Abalea
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Erwann Abalea
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Erwann Abalea
- [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Melinda Shore
- Re: [Trans] Precertificate format Stephen Davidson
- Re: [Trans] Precertificate format Ben Laurie
- [Trans] Fwd: Precertificate format Erwann Abalea
- Re: [Trans] Fwd: Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Russ Housley
- Re: [Trans] Precertificate format Rob Stradling