Re: [Trans] Precertificate format

Rob Stradling <rob.stradling@comodo.com> Mon, 15 September 2014 13:55 UTC

Return-Path: <rob.stradling@comodo.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 4B89E1A0358 for <trans@ietfa.amsl.com>; Mon, 15 Sep 2014 06:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level:
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, 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 ae61hxQQbIMX for <trans@ietfa.amsl.com>; Mon, 15 Sep 2014 06:55:39 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5D21A0357 for <trans@ietf.org>; Mon, 15 Sep 2014 06:55:38 -0700 (PDT)
Received: (qmail 25590 invoked by uid 1000); 15 Sep 2014 13:55:36 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 15 Sep 2014 14:55:36 +0100
Message-ID: <5416EFD8.1040801@comodo.com>
Date: Mon, 15 Sep 2014 14:55:36 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Erwann Abalea <eabalea@gmail.com>
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com><540E28FD.7050809@gmail.com> <540ECD3A.4040704@primekey.se><540F4598.5010505@bbn.com><CABrd9SSg5=wuierLoqAU00pMHxgGx+=ai5mHv4u5t6zm43yDWg@mail.gmail.com><5410779A.20209@bbn.com><CABrd9STnjqDBF4-5ABJ86M_d0bwRyjRNjRW6Hnj9UpeYC7Xz9A@mail.gmail.com><5411BDE4.1060508@bbn.com><CABrd9STAHzg_KJi=nA7hsvz+k0SMS+bg6c3hcBtUwfOUm=hqTQ@mail.gmail.com><5411E6B4.5040401@bbn.com><02c365fdc2b8478fb78f310382ae0bb7@EX2.corp.digicert.com><CA+i=0E4bKzn6DB73H7p8k+kDyrku54WhU5ZFcA2g5zY69Kn-Hg@mail.gmail.com><5416B216.6050904@comodo.com> <CA+i=0E6svuD8RGNWqHaywtGm17JWz7Mw005OhRbnb+hPDrdrSw@mail.gmail.com>
In-Reply-To: <CA+i=0E6svuD8RGNWqHaywtGm17JWz7Mw005OhRbnb+hPDrdrSw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Vdkx5aWqeHPI80oZF8fSQjYGnBA
Cc: "trans@ietf.org" <trans@ietf.org>, Jeremy Rowley <jeremy.rowley@digicert.com>
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: Mon, 15 Sep 2014 13:55:41 -0000

On 15/09/14 14:27, Erwann Abalea wrote:
> 2014-09-15 11:32 GMT+02:00 Rob Stradling wrote:
>     Yes.  The log removes the poison extension, and (if a Precertificate
>     Signing Certificate was used) it also changes the issuer name and
>     AKI to match those of the final certificate's issuing CA.  This
>     behaviour can remain the same.
>
> Concerning these last changes (issuer name and AKI), are they under the
> responsibility of the certificate issuer, or of the log signer?

Hi Erwann.  That was my understanding too until Emilia corrected me a 
few days ago!

> My understanding was that it's the issuer's job.

No, it's the log signer's job.  The Precertificate's Issuer Name and AKI 
need to match the Precertificate Signing Certificate's Subject Name and SKI.

Upon receipt of a Precertificate, the log signer does the following:
   1. Verify the Precertificate's signature.
   2. Extract the TBSCertificate part of the Precertificate.
   3. Remove the poison extension.
   4. Change the Issuer name to match the Issuer name of the final 
cert's issuer.
   5. Change the AKI to match the SKI of the final cert's issuer.
   6. Use that modified TBSCertificate to construct the SCT.
   7. Generate the SCT signature.

> AKI being a variable extension, how could the log know which one of
> {issuerName+serialNumber}, {keyIdentifier},
> {issuerName+serialNumber+keyIdentifier} content will be found in the
> final certificate?

Funny you should mention this.  Right now I'm working on SCT 
verification code for OpenSSL with Steve Henson and Emilia.  Just a few 
minutes ago Steve asked the very same question you've just asked here.

So I just looked at the language in RFC6962 Section 3.2.  I think "the 
TBSCertificate also has its Authority Key Identifier changed to match 
the final issuer" is sufficiently vague that we need to file an erratum 
to RFC6962 to specify exactly how to deal with the optionality of the 
various AKI components.

I also just looked at the certificate-transparency.org code for 
inspiration, but it seems to be doing completely the wrong thing!  It's 
copying the final cert issuer's AKI rather than SKI.  :-(

> If it's the log signer's job, then in the PreCert signing certificate
> situation, there's no non-conformance to RFC5280 (regarding to
> issuerName+serialNumber uniqueness).

Correct.  The serialNumber is identical, but the issuerName is different.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online