Definitely not. Their CPS requires that these keys be generated by an HSM and no HSM would ever generate these, so there's little reason to believe they're following any of their other controls.
My vague and inexperienced read on their description boils down to "we were doing something weird and non-standard as part of our key ceremony because we intended these keys to be exported, and because of that process weirdness we blundered and gave the HSM faulty instructions."
The most likely explanation is that they generated the weak key externally, imported it into the HSM, generated the CSR from it, and finally had Root CA sign it.
A FIPS HSM does not forbid one to import keys into it.
But shouldn't such a HSM support key attestation (and the parent require such attestation)? Attestation would also track whether a key was imported or generated on the HSM, and of sufficient length.
Attestation is not required by the compliance standard for browser CAs (WebTrust) and it is also quite vendor-specific and not very interoperable, so it is not commonly done.
The Root CA must sign requests after authentication, but a "manual" approval is also accepted if done with the appropriate oversight with witnesses (clearly not the case here).
Of course it's not required, as we see here. The question is why not? Getting a simple code-signing cert seems to have more stringent requirements in that it either requires attestation or CA-issued hardware.
My big fear about HSM is that they are inscrutable by design. There is no way to verify they are working as advertised. Plus side, all sorts of fancy hardware to protect your keys. Down side, all sorts of fancy hardware that obscures flaws in the implementation.
I think I'd prefer open source hardware built from off the shelf components glued into a secure enclosure. That way you can destructively audit a few at random if the application matters enough to justify the cost.
Definitely not. Their CPS requires that these keys be generated by an HSM and no HSM would ever generate these, so there's little reason to believe they're following any of their other controls.
According to https://bugzilla.mozilla.org/show_bug.cgi?id=2083449 they actually did use an HSM? Though some of the jargon is a bit beyond me, maybe this will finally get me to learn more PKI stuff.
> The hardware used for each of the issuers is in the attached file. These HSMs are FIPS 140-2 Level 3 compliant.
My vague and inexperienced read on their description boils down to "we were doing something weird and non-standard as part of our key ceremony because we intended these keys to be exported, and because of that process weirdness we blundered and gave the HSM faulty instructions."
The most likely explanation is that they generated the weak key externally, imported it into the HSM, generated the CSR from it, and finally had Root CA sign it.
A FIPS HSM does not forbid one to import keys into it.
But shouldn't such a HSM support key attestation (and the parent require such attestation)? Attestation would also track whether a key was imported or generated on the HSM, and of sufficient length.
Attestation is not required by the compliance standard for browser CAs (WebTrust) and it is also quite vendor-specific and not very interoperable, so it is not commonly done.
The Root CA must sign requests after authentication, but a "manual" approval is also accepted if done with the appropriate oversight with witnesses (clearly not the case here).
Of course it's not required, as we see here. The question is why not? Getting a simple code-signing cert seems to have more stringent requirements in that it either requires attestation or CA-issued hardware.
I’ve asked this question before and the answer was that not all HSMs support it and they're too expensive to replace.
> no HSM would ever generate these
You trust the magic black box far more than I do.
My big fear about HSM is that they are inscrutable by design. There is no way to verify they are working as advertised. Plus side, all sorts of fancy hardware to protect your keys. Down side, all sorts of fancy hardware that obscures flaws in the implementation.
I think I'd prefer open source hardware built from off the shelf components glued into a secure enclosure. That way you can destructively audit a few at random if the application matters enough to justify the cost.
Yeah IMO they should just close up shop. Just like Diginotar.
They had one job, and they blew it. The system is based on trust and they've lost it.
I'm going to remove their roots from all my stuff in any case.
it should not