Sometimes standards bodies can’t move as fast as more nimble and astute users. But that’s no reason for those users to wait on the standards.
A good example came up recently. The standards body that sets rules for code signing is the CA/Browser Forum Code Signing Certificate Working Group (CSWG) and the main standards document is the Baseline Requirements, the current version of which is 3.2.
The effective date for a new rule in version 3.2 – to require Certificate Authorities to use Hardware Security Modules* (HSMs) to create, use, and store customer private keys – was delayed from November 15, 2022, to June 1, 2023.
Why did they do this? I’ll get to that, but there’s an important point to make here: The rule was adopted because using HSMs in this way is best practice – and anyone who follows the subject knows it. If you are running CAs in your own infrastructure, you should be using HSMs to create, use, and store private keys. If you use an outside CA (and everybody does for something), you should insist that they use HSMs. As we’ll see below, not all do.
Get Fast, Easy, and Secure Enterprise-Grade Code Signing With Venafi!
How the CSWG got here
The 3.2 specification lists only one revision, and they have just delayed implementation of that requirement. There are two related points in the revision:
![](https://cdn.venafi.com/994513b8-133f-0003-9fb3-9cbe4b61ffeb/4251c6cc-985d-49ef-9a99-617d412c6def/CA-Browser-HSM-blog-1.png?fm=webp&q=85)
The strikethrough is in the original and is the point of this blog.
The first paragraph says that customer private keys will have to be generated, stored, and used only in a hardware security module certified as compliant at least with FIPS 140-2 Level 2 or Common Criteria EAL 4+. The second paragraph says that if they are to use any other method for private keys, they have to propose them to the Working Group. The deadline for both requirements was November 15, 2022, but it has been pushed back to June 1, 2023.
You can find the reasons for the change in the notes from the September 8 Working Group meeting.
Some of the excuses sound better than others:
- The deadline from adoption to enforcement was too short. Members suggested a standard of one year for enforcing such requirements.
- “[M]arket conditions and supply chain issues may be preventing some from adoption [of] new requirements.” In other words, HSMs are not readily available.
- “[M]ost developers do not read” the Baseline Requirements. [Yes, someone actually said that.]
Blame the laggards, not the CSWG
If you read the work of the Code Signing Working Group over the years, you can only conclude that they have taken a steady and determined course towards advancing code signing standards, and the HSM requirement is a good example of this.
The fact that some on the industry have lagged in adopting best practises is, of course, regrettable. You should make sure that you and your own vendors are not among them.
----
*Hardware Security Module" and "Hardware Crypto Module" are used interchangeably by the CA/Browser Forum, though the Forum prefers Hardware Crypto Module in the Baseline Requirements document.
Related Posts
![Summit 2024 Teaser Photo](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2F537b500f-ee2a-44ba-82b4-d7be0b23506c%2Fsummit-promo-graphic-2.jpg&w=3840&q=75&dpl=dpl_9nMnPWFgUR3MNGqVKD9tfneGCtKt)
Machine Identity Security Summit 2024
Help us forge a new era of cybersecurity
☕ We're spilling all the machine identiTEA Oct. 1-3, but these insights are too valuable to just toss in the harbor! Browse the agenda and register now.