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 protected]>:
> 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 protected]]
> *Sent:* Wednesday, September 24, 2014 12:18 PM
> *To:* Rick Andrews
> *Cc:* Melinda Shore; [email protected]
> *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 protected]>:
>
> 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 protected]] On Behalf Of Melinda Shore
> Sent: Tuesday, September 23, 2014 9:08 AM
> To: [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/trans
>
> _______________________________________________
> Trans mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/trans
>
>
>
>
>
> --
> Erwann.
>
--
Erwann.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
