Re: [Trans] Precertificate format

Erwann Abalea <eabalea@gmail.com> Tue, 16 September 2014 10:37 UTC

Return-Path: <eabalea@gmail.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 571B91A0538 for <trans@ietfa.amsl.com>; Tue, 16 Sep 2014 03:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, 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 L7bbUhR_Viws for <trans@ietfa.amsl.com>; Tue, 16 Sep 2014 03:37:08 -0700 (PDT)
Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978441A0547 for <trans@ietf.org>; Tue, 16 Sep 2014 03:37:08 -0700 (PDT)
Received: by mail-vc0-f180.google.com with SMTP id hq11so4757797vcb.11 for <trans@ietf.org>; Tue, 16 Sep 2014 03:37:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GMauoT/lK+15/1dJwHVgBJCFgNgXB9BrEzIuKKxrZMU=; b=ZXy4B1A78evakTN+IDjHmTXFt9RRCikJJxVrkB+S7Z/f2zYHyS+QbnxRyEpVs/eI6i mEV0Um3vsJ+rbhaTy9yf2iRIf8MeyW0gDmp9jBRmfyGMUVpG51nG/IOtcjJa9sLo50m0 aqYJZYXW6H4zmMVLzSiFuUcYZYM9qNQQbxQvC/QQhCb6E8aGZhZmk2qvtSvOjQ2xNTd5 VTfffPlnN4eFWekA7jVbq38gpYJYpQjNFByCph9GN+ZR/Kc87t3ylT10UnT/zNGU4xOq cAzmqfF5YaNCFssiZiBwe18/idWK8SDwWz4eC3BYCGEW4hMfkJP7oLO/yyrw/luVV76c rFag==
MIME-Version: 1.0
X-Received: by 10.52.52.136 with SMTP id t8mr23987329vdo.21.1410863827684; Tue, 16 Sep 2014 03:37:07 -0700 (PDT)
Received: by 10.52.156.168 with HTTP; Tue, 16 Sep 2014 03:37:07 -0700 (PDT)
In-Reply-To: <54181031.9010309@comodo.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> <5416EFD8.1040801@comodo.com> <54181031.9010309@comodo.com>
Date: Tue, 16 Sep 2014 12:37:07 +0200
Message-ID: <CA+i=0E7iOEYno_Ji+h3TUMeOQp8meBWK_1Hp87k=Hr-Edq--jg@mail.gmail.com>
From: Erwann Abalea <eabalea@gmail.com>
To: Rob Stradling <rob.stradling@comodo.com>
Content-Type: multipart/alternative; boundary=089e0115f04846941505032c5515
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/6OtB6ewafUEfp7gFfpw3bkLDT7Q
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: Tue, 16 Sep 2014 10:37:11 -0000

Bonjour Rob,

Thanks for your valuable comments, we're currently implementing this in our
CA, and the RFC5280 conformance of the PreCert Signing Certificate scenario
is pleasing. No need to remove our constraints or cheat to circumvent
them...

2014-09-16 12:25 GMT+02:00 Rob Stradling <rob.stradling@comodo.com>om>:

> On 15/09/14 14:55, Rob Stradling wrote:
>
>> On 15/09/14 14:27, Erwann Abalea wrote:
>>
> <snip>
>
>> 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.  :-(
>>
>
> Sorry, ignore that.  Looks like the certificate-transparency.org code is
> actually copying the Issuer Name and AKI from the Precertificate Signing
> Certificate.  That's correct.
>

Ok. So the reference code takes for granted that the CA will use the same
strategy to populate the PreCert Signing Certificate and the final issued
certificate. That's not an unusual assumption, but:


> Nonetheless, I still think RFC6962 needs an erratum to deal with the
> optionality of the various AKI components.


+1
This should be stated somewhere.

-- 
Erwann.