EJBCA performs incorrect calculation of validities
Hi all, We were alerted to the fact that EJBCA does not calculate certificate and OCSP validities in accordance with RFC 5280, which has been a requirement since BR 1.7.1 The word "inclusive" was not caught, meaning that a certificate/response issued by EJBCA will have a validity of one second longer than intended by the RFC. This will only cause an incident for certificates of a validity of exactly 398 days - any certificates with shorter validities are still within the requirements. This has been fixed in the coming EJBCA 7.4.3, and all PrimeKey customers were alerted a week ago and recommended to review their certificate profiles and responder settings to be within thresholds. While investigating this we noticed that several non-EJBCA CAs seem to issue certificates with the same non RFC-compliant validity calculation (but still within the 398 day limit), so as a professional courtesy we wish like to alert other vendors to review their implementations and lessen the chance of any misissuance. Cheers, Mike Agrenius Kushner Product Owner, EJBCA ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Notice on SC31 and CAs using EJBCA
To be clear, the change came as a result of following the cabf mailing lists, and was released as soon as it could be fit into our pipeline. All customers were informed through our release mailing list. Cheers Mike Agrenius Kushner Product Owner, EJBCA On Fri, 18 Sep 2020 at 13:35, Arvid Vermote via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > During gap analysis and impact assessment of the changes to the BR in the > > context of SC31 - Browser Alignment, we noted that our legacy platform, > > using EJBCA as issuance backend, did not fully support the changes related > > to not including the "Unspecified" reason code in OCSP responses for the > > certificates that are revoked with that reason. Refer to BR 1.7.1 section > > 7.3 and 7.2.2, this specific requirement is effective as of September 30 > > 2020. > > > > > > > > We raised the issue with PrimeKey and EJBCA version 7.4.2 was released on > > September 14 2020. This message is intended to inform other CA using EJBCA > > software and subject to BR of the above. > > > > ___ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAA record checking issue
On Monday, May 13, 2019 at 1:39:32 AM UTC+2, Matt Palmer wrote: > On Sat, May 11, 2019 at 08:37:53AM -0700, Han Yuwei via dev-security-policy > wrote: > > This raised a question: > > How can CA prove they have done CAA checks or not at the time of issue? > > They can't, just as they can't prove they have or haven't done > domain-control validation. It's up to audits, external adversarial testing, > and the forthright honesty of CAs themselves to proactively report when they > have a problem, to identify when CAs have failed to maintain the necessary > standards. > > - Matt Indeed. It would have been awesome if CAA had included returning a signed token containing the result of the check, but that would probably have been impossible to roll out on all of the world's DNS servers. Cheers, Mike ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Open Source CA Software
On Thursday, March 14, 2019 at 11:54:52 PM UTC+1, James Burton wrote: > Let's Encrypt CA software 'Boulder' is open source for everyone to browse > and check for issues. All other CAs should follow the Let's Encrypt lead > and open source their own CA software for everyone to browse and check for > issues. We might have found the serial number issue sooner. > > Thank you, > > Burton Dude, EJBCA has been open source long enough to be able to legally vote and have a driver's license. Literally. But I agree, and we are open source for exactly that reason. I will add though, and stress, that this was not an issue with how EJBCA generates serial numbers. EJBCA still produces serial numbers with the max entropy for a given serial number length, as configured in number of octets. If you set EJBCA to use 20 octets you'll get 159 bits of entropy, the max available without breaking the RFC, and it's been that way since 2014. To save people time, by the way, here you go: https://svn.cesecore.eu/svn/ejbca/trunk/ejbca/modules/cesecore-common/src/org/cesecore/certificates/ca/internal/SernoGeneratorRandom.java This was not an issue with the source, it was an issue with the end user's understanding of what it means to define an SN length as given number of of octets, how integer octets are defined in x690, and what entropy that can be derived. That is all a documentation failure on our end - we could have been more explicit, and we could have reached out more. There's also the faulty assumption that SN length = entropy. As we've seen, many other CA implementations produce SNs with far less entropy than their length would allow. I'm not saying that there's anything inherently wrong with that, but it illustrates the danger of making assumptions. As we didn't follow cabf at the time we weren't fully aware of the severity of the problem, and assumed that affected parties understood their configurations and raised the SN length. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)
> I think when it comes to specifications with cryptographic relevance (as > unpredictable serials are), less is more; the more inflexible and > unambiguous the spec is, the less likely it will be "creatively > interpreted" in a manner that bypasses the whole point. To someone with > crypto experience and an understanding of the intent, the current > language clearly means "take 64 bits from a CSPRNG once, put whatever > you want around them (or nothing), DER encode, and stuff it into the > serial field". But clearly some implementers interpreted this > differently, and here we are. > > That said, I do think the current exercise is, shall we say, bringing > out some interesting opinions on what an appropriate response to the > problem is. Statements such as: > > > There are no, and has never been any, 63 bit serial numbers created by > > EJBCA. > > ... lead me to significantly reduce my trust in those making them, and > their ability to correctly interpret security-critical standards in the > future. Not everyone gets things right the first time, but owning up to > problems, understanding the technical issue at hand, and accepting > responsibility is a basic tenet of earning community trust. I'm sorry you feel that way, but here's the thing. EJBCA produces whatever length serial numbers you request from it, restricted to an even octet and within the span of 4 to 20. EJBCA set to produce 8 octet serial numbers will produce exactly 64 bit serial numbers, including the MSB. Are you suggesting that a logical behavior for a 8 octet serial number would be to produce a 9 octet serial number and pad the first 7 bits? EJBCA will produce exactly the serial number you've specified, and give you as much entropy as your serial length allows. EJBCA is a general CA implementation with multiple use cases, so it's not built to specifically conform to cabf requirements. As Ryan Sleevi pointed out - It is up to the end customer to understand their own requirements, and to understand that a 64 bit signed integer can in no way or fashion contain 64 bits of entropy. Unless you're going under the presumption that the MSB doesn't count as a part of the serial number (and I've never seen an RFC or requirement pointing to that being the case, EJBCA does not produce 63 bit serial numbers. Cheers, Mike ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: EJBCA defaulting to 63 bit serial numbers
Hi Jakob, On Thursday, March 7, 2019 at 7:30:03 PM UTC+1, Jakob Bohm wrote: > In the cause of the other discussion it was revealed that EJBCA by PrimeKey > has apparently: > > 1. Made serial numbers with 63 bits of entropy the default. Which is > not in compliance with the BRs for globally trusted CAs and SubCAs. This has been the default setting since 2001, predating Ballot 164 quite some. At the time this was more than sufficient, and we hadn't reviewed it. > 2. Mislead CAs to believe this setting actually provided 64 bits of > entropy. I'm presuming that you're not assigning any intention to the above. We have always been open with that EJBCA generates 64 bit serial numbers, compliant with RFC5280 (3280 back then) and X.690. We weren't, at start of the previous thread, aware of the requirements made by CABF Ballot 164 as we've only been active in following the proceedings for the last couple of years, but as vendors we've historically viewed the responsibility configuring EJBCA correctly to meet existing standards as up to the end customer. We've been aware of the BR requirement for some time now, but we were not aware of the detailed previous discussion related to 63 vs 64 bits that has been held. > 3. Discouraged CAs from changing that default. This is not true in the least. Serial number size has been configurable since at least 2008 (long before B164). There is a note in the configuration file about not changing it unless you understand what you're doing, but that pertains to not lowering it below 64 bits. Raising the SN size (and thus entropy) has in fact been done by several of our customers (in response to B164, or for whatever other reason). > This raises 3 derived concerns: > > 4. Any CA using the EJBCA platform needs to manually check if they > have patched EJBCA to comply with the BR entropy requirement despite > EJBCAs publisher (PrimeKey) telling them otherwise. >Maybe this should be added to the next quarterly mail from Mozilla to > the CAs. A patch isn't required as the value is configurable in a config file, and in response to the concerns raised here we've added functionality for changing the serial number size without requiring a change to the config files. Again, I don't agree with your statement that we've told anybody that EJBCA, by default configuration, complies with the BR, as much configuration is needed to issue BR compliant certificates. A correct technical description of serial numbers is documented in the configuration file. The documentation did not consider the above discussion regarding entropy, as 64 bit serial numbers were leagues past the entropy requirements prior to 2016. The documentation absolutely does encourage the end user to feel free to use larger serial number sizes, EJBCA is used in a lot of non public CA use cases, and as such ability to configure according to BR requirement or not is a key feature. It does bear mentioning that the purpose of requiring serial number entropy was to mitigate against pre-imaging attacks against SHA-1, something which today has no bearing whatsoever. While I'm not claiming that there will never ever be a collision found against SHA256, but I hope you understand that this is a compliance issue against a requirement that for now has no has any security impact. > 5. Is it good for the CA community that EJBCA seems to be the only > generally available software suite for large CAs to use? While I agree that diversity is good for any ecosystem, I would remind you that a majority of CA's don't actually run our software, and many run their own proprietary solutions. The availability of EJBCA is likely due to the fact that the vast majority of our code is FOSS (and the rest if always available to customers), which is partly due to our wish to make PKI available to all, and partly because we encourage external inspection of our implementation. > 6. Should the CA and root program community be more active in ensuring > compliance by critical CA infrastructure providers such as EJBCA and > the companies providing global OCSP network hosting. Absolutely, and I would say that many already are. We don't have any goal other than making EJBCA as compliant as possible, and have always aimed to lay a step ahead of existing standards. Since 2016 (as a part of maturing as a software vendor) we changed focus in how we handle requirements work by actively following various standards orgs (including CABF), instead of receiving requirements from our customers. Cheers, Mike ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
Hi, Since EJBCA as a product was mentioned we thought we could chime in with some background and updates. EJBCA was possible the first (certainly one of the first) CA products to use random serial numbers. From the very beginning, 64 bit random serial numbers, from a CSPRNG, were used. This was back in the days when the opinion was that sequential serial numbers had to be used. We had some work convincing some users that random was better than sequential. By default 8 bytes (64 bits) were used, as it's a nice power of 2 number. Back then longer serial numbers were frowned upon and there were product out there that could not even parse 16 byte serial numbers, so 8 bytes was a good choice that was compatible. As years went by we introduced the possibility to use longer serial numbers, through a configuration setting at build time. This setting is no convenient to use (automatically persisted across upgrades etc) in our Appliance and cloud platforms, and we had on the roadmap to remedy this with a more use friendly setting. A very strong goal of EJBCA, and PrimeKey, is to be standard compliant with both open standards and regulations, and thus we are not completely satisfied with debating 63 vs 64 bits. We are planning to release a fix version with a convenient per CA setting, and default to larger serials, in short time. Any existing CA will be easily configured to use between 4 and 20 octets serial numbers for future issuance. Serial numbers must be compliant with RFC5280 and X.690, which is the test we do on the output from the CSPRNG, only using compliant ones. https://jira.primekey.se/browse/ECA-4991 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. Looking back at the origin to when public CAs moved form sequential to random serial numbers we believe this originated from the weakness in SHA1, making a preimage attack at least theoretically possible against SHA1. EJBCA was very early on supporting SHA256 as well. To our knowledge there are no known preimage attacks against SHA256, correct us if we're wrong. In other words, we do not consider this a security issue, but (only) a compliance issue. Cheers, Tomas Gustafsson (CTO) and Mike Agrenius Kushner (PO EJBCA) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
