Re: [Trans] Prior knowledge of certificate serial number
Erwann Abalea <eabalea@gmail.com> Wed, 24 September 2014 20:58 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 5437B1A19F9 for <trans@ietfa.amsl.com>; Wed, 24 Sep 2014 13:58:51 -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 A7QLaULxdlS8 for <trans@ietfa.amsl.com>; Wed, 24 Sep 2014 13:58:41 -0700 (PDT)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDDF51A036D for <trans@ietf.org>; Wed, 24 Sep 2014 13:58:40 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id hq11so7171027vcb.34 for <trans@ietf.org>; Wed, 24 Sep 2014 13:58:40 -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=aAFJE/qvWoL/qoXQr/UL3VsBNqQgi3qI8qjpsPHSkug=; b=doI3xpjnQ5TKwjHJjSJMyevoJHujf4cQEnNQ+u+IEXmFaktatEvNAi7UygSGZjaRc6 PFjrJAHZFxciaD+T7fbEroJNluR99moZgOBZU/jB5P1DI5fUgPFEmLXZHo/zDHqTRYev NlxjXqPKP428WC7+VpLykP908rvbGacPZQ/+SQBP6+11AEYOeE+Ks16C0aarmAOoVv3l vHiF7uAKiTQNzLMefEYudaCJHk8r4jYTu8+8eEeeBWHs1fwAnnKJkZ9kBAZJzfYLZVIF yiYfsl5dGRY8rc20ond2Id8Ee6Nul7p8wv7Z6Qug0tg93dIqL/Tq5sxEbWJRMg2riRx9 kagQ==
MIME-Version: 1.0
X-Received: by 10.220.44.80 with SMTP id z16mr7721341vce.7.1411592319945; Wed, 24 Sep 2014 13:58:39 -0700 (PDT)
Received: by 10.52.156.168 with HTTP; Wed, 24 Sep 2014 13:58:39 -0700 (PDT)
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607D14080F3@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <54219AF0.6040901@gmail.com> <544B0DD62A64C1448B2DA253C011414607D1408063@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <CA+i=0E5bkax-X2FK=2whsT3pH-k8H0DfjGLuRAci5tX=whCxmQ@mail.gmail.com> <544B0DD62A64C1448B2DA253C011414607D14080F3@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Date: Wed, 24 Sep 2014 22:58:39 +0200
Message-ID: <CA+i=0E6jYVAJajM6GcybhPBkxecr8d5UG1Sov4_WR-7v_0j-RA@mail.gmail.com>
From: Erwann Abalea <eabalea@gmail.com>
To: Rick Andrews <Rick_Andrews@symantec.com>
Content-Type: multipart/alternative; boundary="047d7b34313ccc51a60503d5f2a1"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/7p4k1UI9L-9GslNh2Vb7SYgz0KM
Cc: Melinda Shore <melinda.shore@gmail.com>, "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Prior knowledge of certificate serial number
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: Wed, 24 Sep 2014 20:58:51 -0000
Well, that's possible, of course. Explaining this to an auditor may be tricky. I wanted to make it clear that if, for example, you generate the Precert at date D with {notBefore=D, notAfter=D+3y}, finalize the push to all the logs on day D+1, and issue the final cert immediately after that, thus on day D+1, you MUST NOT have the final certificate with {notBefore=D+1, notAfter=D+1+3y}. It won't work. 2014-09-24 21:42 GMT+02:00 Rick Andrews <Rick_Andrews@symantec.com>: > Erwann, > > > > Isn’t it possible that I log a Precertificate in one or more log servers > and then can’t issue the final certificate, either because of log server > failure or failure of my issuance system? The log server records my INTENT > to issue a certificate, but I don’t think it COMPELS me to issue that > certificate. I must be able to reject that order, change the date and > serial number and start over. > > > > We worked around the issuerName+serialNumber constraint by storing > certificates in one table, Precertificates in another. > > > > -Rick > > > > *From:* Erwann Abalea [mailto:eabalea@gmail.com] > *Sent:* Wednesday, September 24, 2014 12:18 PM > *To:* Rick Andrews > *Cc:* Melinda Shore; trans@ietf.org > *Subject:* Re: [Trans] Prior knowledge of certificate serial number > > > > Bonsoir Rick, > > > > If the dates set in the final certificate is different than the dates used > in the Precertificate, the browser won't be able to verify the SCT. That > means that all the Precertificates you publish for the same final > certificate MUST be identical in every aspect. > > > > We also have an issuerName+serialNumber constraint in database, that's why > Option 1 isn't an easy task. > > > > 2014-09-24 21:05 GMT+02:00 Rick Andrews <Rick_Andrews@symantec.com>: > > Melinda, > > At Symantec we know the serial number prior to issuance, because we > generate it and put it in the TBSCertficate. > > The only problem we have with serial numbers is in the case where we fail > to get enough SCTs to put in the cert. We'll retry the operation up to 48 > hours, but we always want to set the notBefore date to the day we issue the > cert, so we don't short-change customers (believe me, there are customers > who notice). But if we update the notBefore date and retry the logging > operation, we have to change the serial number too. Otherwise we might log > different certs with the same serial number in different logs, and that > would be inconsistent. However, we use the combination of issuer name and > serial number as a unique key for that order in our database, so changing > serial numbers is challenging. The simpler alternative is to reject the > order and ask the customer to start over, but that's a bad customer > experience. We're not sure yet how we'll solve this, but we'll figure > something out (we don't expect 6962-bis to provide a solution). And while > we hope that this situation will occur very rarely > , it could happen, so we're preparing for it. > > -Rick > > > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Melinda Shore > Sent: Tuesday, September 23, 2014 9:08 AM > To: trans@ietf.org > Subject: [Trans] Prior knowledge of certificate serial number > > One of the questions that's come up is whether or not it's reasonable to > expect that CAs will (or can) have knowledge of a certificate's serial > number prior to issuance - it's one of the basic questions that needs to be > considered in the context of the precertificate discussions. > We'd be grateful if any CAs (particularly ones with a CT implementation > either in the works or planned) could give some feedback on that. > > Thanks, > > Melinda > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > > > > > -- > Erwann. > -- Erwann.
- [Trans] Prior knowledge of certificate serial num… Melinda Shore
- Re: [Trans] Prior knowledge of certificate serial… i-barreira
- Re: [Trans] Prior knowledge of certificate serial… Rick Andrews
- Re: [Trans] Prior knowledge of certificate serial… Erwann Abalea
- Re: [Trans] Prior knowledge of certificate serial… Rick Andrews
- Re: [Trans] Prior knowledge of certificate serial… Erwann Abalea
- Re: [Trans] Prior knowledge of certificate serial… Rick Andrews
- Re: [Trans] Prior knowledge of certificate serial… Stephen Kent