Menu
▾
▴
Re: [Ejbca-develop] EJBCA is checking for serial number collisions after generating the certificate
|
From: Tomas G. <to...@pr...> - 2019-03-12 15:27:04
|
> I could think of using a serial number that includes a nodeIDs and > timers (nanosecond?) + randomness. That is perhaps an area you could > look into if you are interested in this topic. Patches will be considered. Jaime, I agree somewhat that checking for collisions before could have some statistical value as well, i.e. the pool of potential collisions is limited to the issuance latency (including CT submissions) and level of concurrency. If you have a patch I'd love to see it. Cheers, Tomas On 2019-03-12 16:17, Tomas Gustavsson wrote: > >> But the colliding precertificate is still published outside to the CT >> Logs, which could lead to the following scenario: > > Yes this was concluded in the first email exchange already. > > Do you agree that CT is never used when certificate serial numbers are > short? > > Do you have an estimate on the risk of serial number collision when > using 16 or 20 byte serial numbers? > >> I think that the call to verify if the newly generated serial number is >> about to collide with an existing one should be performed early, before >> any signature is generated in the pre-certificate or the real certificate. > > This is a reasonable assumption if you are running on a single node > system with not too high level of concurrency. > However, we must consider CA systems running in a clustered environment, > with several nodes across multiple data centers, with a very high level > of concurrency (i.e. 100s of certificate per second issued). The only > really safe way I can see to check in a multi-node clustered environment > is to abort if it turns out another node has accidentally generated the > same serial number, and then to remediate this. > > I could think of using a serial number that includes a nodeIDs and > timers (nanosecond?) + randomness. That is perhaps an area you could > look into if you are interested in this topic. Patches will be considered. > > Reading on the mozilla list (and code), I understand it that some other > CAs only uses nodeID and random serial numbers to protect against > collisions, i.e. only randomness on each node. > > Kind regards, > Tomas > > On 2019-03-12 15:51, Jaime Hablutzel wrote: >> >> >> On Tue, Mar 12, 2019 at 7:58 AM Tomas Gustavsson <to...@pr... >> <mailto:to...@pr...>> wrote: >> >> >> Now you are getting into semantics. I believe you read the code correct. >> The definition used by me is a difference between "internally generated" >> and "issued by the CA". >> >> The code is there to guard against any certificate with duplicate serial >> numbers being "issued from the CA". This is done by verifying, after the >> certificate has been created in memory, but before it is stored >> anywhere, or returned to anything outside the internal RAM >> >> >> But the colliding precertificate is still published outside to the CT >> Logs, which could lead to the following scenario: >> >> 1. A certificate is issued for a subject X with a random serial number A >> and it is appropriately stored and published to CT Logs. >> 2. A new certificate for subject Y is about to be generated and the >> random serial number generation process generates the same serial number >> A (very unlikely but not impossible). >> 3. A precertificate for the new certificate is signed and published to >> CT Logs. >> 4. The final certificate is signed but never stored in system because of >> the check made by >> org.cesecore.certificates.certificate.CertificateCreateSessionBean#assertSerialNumberForIssuerOk. >> >> And now there are two different precertificates with the same serial >> number published into CT Logs which is to be considered a misissuance as >> indicated in RFC 6962, "3.1. Log Entries": >> >> The signature on the [precertificate] TBSCertificate indicates the >> certificate authority’s intent to issue a certificate. This intent >> is considered binding (i.e., *misissuance of the Precertificate is >> considered equal to misissuance of the final certificate*). >> >> >> And additionally, revoking the misissued precertificate will revoke the >> previously issued correct certificate. >> >> Note: I haven't verified if CT Logs would accept two different >> precertificates with the same serial number, but I think they will. >> >> >> of the >> running process, that there are no issuer/serialnumber collisions. There >> are other similar guards available as well, such as applying a unique >> database index preventing storage of certificates with duplicate >> issuer/serial. >> >> And of course, the most effective guard is to use serial numbers with >> sufficient length, making the probability of collisions unlikely to >> happen anytime at all. >> >> The code does what what it was designed to do. Do you see any issues >> with the code? >> >> >> I think that the call to verify if the newly generated serial number is >> about to collide with an existing one should be performed early, before >> any signature is generated in the pre-certificate or the real certificate. >> >> >> >> Do you use short serial numbers? >> I do not recommend that you use shorter serial numbers than 64 bits, >> unless you have a very special use-case. >> >> Regards, >> Tomas >> >> PS2: In EJBCA 7.1.0 a new validation step will be added giving the >> possibility of running validation of a pre-sign-certificate, which is >> signed by a dummy key, before the CT pre-certificate is created. The >> purpose is not to look for or prevent collisions though, but can be used >> for other validation before anything CT related is generated. >> >> >> On 2019-03-12 13:19, Jaime Hablutzel wrote: >> > On Tue, Mar 12, 2019, 3:53 AM Tomas Gustavsson <to...@pr... >> <mailto:to...@pr...> >> > <mailto:to...@pr... <mailto:to...@pr...>>> wrote: >> > >> > Hi Jaime, >> > >> > Good point about CT pre-certs. With "no certificates" we mean >> the final >> > certificate. >> > >> > >> > The final collisioning certificate is generated too. Take a look >> at the >> > source code before the call >> > >> to org.cesecore.certificates.certificate.CertificateCreateSessionBean#assertSerialNumberForIssuerOk. >> > >> > The CT pre-certificate is by definition not a >> > "certificate", it's a "pre-certificate" and can by construct >> (poison >> > extension) not be used as a certificate. >> > >> > Of course, the issuance of a pre-certificate has it's own >> consequences >> > such as having to revoke it. >> > Though, as you know, CT is only used for public trust issued >> > certificates, and there it is not allowed to use 32 bit serial >> numbers. >> > In fact more than 64 bit serial numbers are needed. This makes >> this >> > discussion mostly academic. >> > >> > Regards, >> > Tomas >> > >> > >> > On 2019-03-11 16:37, Jaime Hablutzel wrote: >> > > Quoting >> > > >> > >> from https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/OVKywVZIBgAJ: >> > > >> > > In addition to random serial numbers, EJBCA checks for >> collisions, >> > > so even in the very unlikely event of equal serial >> numbers being >> > > generated, *no certificates with duplicated serial numbers >> > should be >> > > issued from a CA based on the EJBCA software*. By >> comparison, >> > > collisions do happen regularly in testing when using 32 >> bit serial >> > > numbers (and are averted), so the underlying checks >> function as we >> > > expect. >> > > >> > > >> > > Where the highlighted text is not correct, because, as observed >> > from the >> > > trunk source around r31776, if a newly generated random >> serial number >> > > (generated by >> > > org.cesecore.certificates.ca >> <http://org.cesecore.certificates.ca> >> > >> <http://org.cesecore.certificates.ca>.internal.SernoGeneratorRandom#getSerno) >> > > results that is being used by an existing certificate, a new >> > > collisioning certificate is still generated (and CT >> precertificate >> > > published!) but it is discarded only before trying to store >> it in the >> > > database, when the collision validation is performed >> > > >> > >> (org.cesecore.certificates.certificate.CertificateCreateSessionBean#assertSerialNumberForIssuerOk). >> > > >> > > It isn't the expected behaviour. Isn't it?. >> > > >> > > -- >> > > Jaime Hablutzel - RPC 994690880 >> > > >> > > >> > > _______________________________________________ >> > > Ejbca-develop mailing list >> > > Ejb...@li... >> <mailto:Ejb...@li...> >> > <mailto:Ejb...@li... >> <mailto:Ejb...@li...>> >> > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> > > >> > >> > >> > _______________________________________________ >> > Ejbca-develop mailing list >> > Ejb...@li... >> <mailto:Ejb...@li...> >> > <mailto:Ejb...@li... >> <mailto:Ejb...@li...>> >> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> > >> > >> > >> > _______________________________________________ >> > Ejbca-develop mailing list >> > Ejb...@li... >> <mailto:Ejb...@li...> >> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> > >> >> >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... >> <mailto:Ejb...@li...> >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> >> >> -- >> Jaime Hablutzel - RPC 994690880 >> >> >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop >> > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
