Subject: [Trans] Prior knowledge of certificate serial number

From: Melinda Shore <[email-masked]>
Date: Tue, 23 Sep 2014 08:08:16 -0800

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

---

From: [email-masked]
Date: Wed, 24 Sep 2014 15:13:57 +0200

Hi Melinda,

You´ve made a good point and this is the way we´re implementing CT at Izenpe. 

Iñigo Barreira
Responsable del Área técnica
[email-masked]
945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

-----Mensaje original-----
De: Trans [mailto:[email-masked]] En nombre de Melinda Shore
Enviado el: martes, 23 de septiembre de 2014 18:08
Para: [email-masked]
Asunto: [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
[email-masked]
https://www.ietf.org/mailman/listinfo/trans

---

From: Rick Andrews <[email-masked]>
Date: Wed, 24 Sep 2014 12:05:51 -0700

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:[email-masked]] On Behalf Of Melinda Shore
Sent: Tuesday, September 23, 2014 9:08 AM
To: [email-masked]
Subject: [Trans] Prior knowledge of certificate serial number

Thanks,

Melinda

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 24 Sep 2014 21:17:31 +0200

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 <[email-masked]>:

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

-- 
Erwann.

---

From: Rick Andrews <[email-masked]>
Date: Wed, 24 Sep 2014 12:42:22 -0700

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

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:[email-masked]<mailto:[email-masked]>] On Behalf Of Melinda Shore
Sent: Tuesday, September 23, 2014 9:08 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Trans] Prior knowledge of certificate serial number

Thanks,

Melinda

_______________________________________________
Trans mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trans

_______________________________________________
Trans mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trans

--
Erwann.

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 24 Sep 2014 22:58:39 +0200

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 <[email-masked]>:

> 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:[email-masked]]
> *Sent:* Wednesday, September 24, 2014 12:18 PM
> *To:* Rick Andrews
> *Cc:* Melinda Shore; [email-masked]
> *Subject:* Re: [Trans] Prior knowledge of certificate serial number
>
>
>
> Bonsoir Rick,
>
>
>

-- 
Erwann.

---

From: Rick Andrews <[email-masked]>
Date: Wed, 24 Sep 2014 14:20:27 -0700

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 [mailto:[email-masked]]
Sent: Wednesday, September 24, 2014 1:59 PM
To: Rick Andrews
Cc: Melinda Shore; [email-masked]
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 <[email-masked]<mailto:[email-masked]>>:
Erwann,

-Rick

From: Erwann Abalea [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, September 24, 2014 12:18 PM
To: Rick Andrews
Cc: Melinda Shore; [email-masked]<mailto:[email-masked]>
Subject: Re: [Trans] Prior knowledge of certificate serial number

Bonsoir Rick,

-Rick

-----Original Message-----
From: Trans [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Melinda Shore
Sent: Tuesday, September 23, 2014 9:08 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Trans] Prior knowledge of certificate serial number

Thanks,

Melinda

--
Erwann.

--
Erwann.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 25 Sep 2014 11:19:06 -0400

Melinda,

> either in the works or planned) could give some feedback on that.
I've expressed concern that many of the Web PKI CAs may not be
tracking the CT work. I suggest you contact someone at the CABF and
ask them to conduct a poll of their members. I propose two questions:

1. Is anyone from your organization tracking the IETF TRANS WG?

2. Would your (Web PKI) certificate issuance process be adversely
affected if you
- generated a TBScertificate, including all the fields normally present 
in certs you issue
- submit this TBScert structure to two or more third parties (over the 
Internet)
- wait to receive a (newly-defined) extension value from each of these 
parties
- insert the extension values into the cert and sign it, without 
changing any of the
cert fields in the TBScert from step 1

Steve