Re: [Trans] Prior knowledge of certificate serial number

Rick Andrews <> Wed, 24 September 2014 21:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 740BB1A1A48 for <>; Wed, 24 Sep 2014 14:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.686
X-Spam-Status: No, score=-7.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i3aVL-DVILoA for <>; Wed, 24 Sep 2014 14:20:33 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18F7B1A1A06 for <>; Wed, 24 Sep 2014 14:20:33 -0700 (PDT)
X-AuditID: d80ac3f2-f79d46d0000036e5-4a-5423359ebc05
Received: from ( []) by (Symantec Brightmail Gateway out) with SMTP id 6D.90.14053.F9533245; Wed, 24 Sep 2014 22:20:31 +0100 (BST)
Received: from [] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by with esmtp (Exim 4.76) (envelope-from <>) id 1XWtzB-0007G2-36; Wed, 24 Sep 2014 17:20:29 -0400
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([]) with mapi; Wed, 24 Sep 2014 14:20:28 -0700
From: Rick Andrews <>
To: Erwann Abalea <>
Date: Wed, 24 Sep 2014 14:20:27 -0700
Thread-Topic: [Trans] Prior knowledge of certificate serial number
Thread-Index: Ac/YOlRih496rKeVS92isUdPYVbkIAAAvAQg
Message-ID: <544B0DD62A64C1448B2DA253C011414607D14DF672@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <> <544B0DD62A64C1448B2DA253C011414607D1408063@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <> <544B0DD62A64C1448B2DA253C011414607D14080F3@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_544B0DD62A64C1448B2DA253C011414607D14DF672TUS1XCHEVSPIN_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsVyg+vQH90FpsohBjt7eSw2zHnLbNHWNovF Yu3jiywOzB47Z91l91iy5CdTAFMUl01Kak5mWWqRvl0CV8bW85uZCjrWMlZc2L6EtYFxzwrG LkZODgkBE4nt/2awQthiEhfurWfrYuTiEBJ4xyhxuPMlI4TzilHi9vr1UM4qRomXH34zgbSw CehJbHl8hR3EFhFQlbh98h7YKGYBP4mu/fOYQWwWoHjL+/tsILawgKPEieWXWCHqnSSmf+mE 6jWSuLHtHJjNKxAlMefqOrBeIYEbTBLnXmiB2JwCgRK7jv8CO5sR6NTvp9YwQewSl7j1ZD4T xAsCEkv2nGeGsEUlXj7+xwpRLypxp309I0R9vkT7wb9QuwQlTs58wgJRLylxcMUNlgmM4rOQ jJ2FpGUWkpZZjBxAcU2J9bv0IUoUJaZ0P2SHsDUkWufMZUcWX8DIvopRpqS02LA4tyS/tKQg tcLASK+4MjcRGLnJesn5uZsYwdF7+NMOxpl7HQ8xCnAwKvHw9hgqhwixJpYBVR5ilOBgVhLh VfmoFCLEm5JYWZValB9fVJqTWnyIUZqDRUmc91MIR4iQQHpiSWp2ampBahFMlomDU6qBsT3V VmTRY99iM/fUmk1hGgVK63suWnbs3m3yes7kKvXFC1SdS6N4cj01pj49+K9ub27br+C/GxLN Dj7amMkUvqw6L/22rfihdW0Lj+3JnHRy+u9rrhcbIll1wyo37ns2tTYz80WW34UfXCdOHt0T 90P5ZKqOwtbF1fYNi+Qj/15fadr9jOshtxJLcUaioRZzUXEiAL7sH4XaAgAA
Cc: Melinda Shore <>, "" <>
Subject: Re: [Trans] Prior knowledge of certificate serial number
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Sep 2014 21:20:35 -0000

I agree. For every cert we ultimately issue, the corresponding Precert with matching dates must be in the minimum number of logs.

From: Erwann Abalea []
Sent: Wednesday, September 24, 2014 1:59 PM
To: Rick Andrews
Cc: Melinda Shore;
Subject: Re: [Trans] Prior knowledge of certificate serial number

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 <<>>:

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.


From: Erwann Abalea [<>]
Sent: Wednesday, September 24, 2014 12:18 PM
To: Rick Andrews
Cc: Melinda Shore;<>
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 <<>>:

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.


-----Original Message-----
From: Trans [<>] On Behalf Of Melinda Shore
Sent: Tuesday, September 23, 2014 9:08 AM
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.



Trans mailing list<>

Trans mailing list<>