Adding to this discussion, and to support that there were -in fact-
different interpretations (all in good faith) please check the issue I
had created in Dec 2017 https://github.com/awslabs/certlint/issues/56.
My simple interpretation of the updated requirement in 7.1 at the time
was that "no matter what, the resulting serial number should be at least
64 bits long". However, experts like Peter Bowen, Rob Stradling and Matt
Palmer, paying attention to details of the new requirement, gave a
different interpretation. According to their explanation, if you take
64-bits from a CSPRNG, there is a small but existing probability that
the resulting serialNumber will be something smaller. So, "shorter"
serial numbers were not considered a violation of the BRs as long as the
64-bits came out of a CSPRNG.
I am personally shocked that a large part of this community considers
that now is the time for CAs to demonstrate "agility to replace
certificates", as lightly as that, without considering the significant
pain that Subscribers will experience having to replace hundreds of
thousands of certificates around the globe. It is very possible that
Relying parties will also suffer availability issues.
As discussed before, automation is one of the goals (other opinions had
been raised, noting security concerns to this automation). Centralized
systems like large web hosting providers or single large Subscribers
like the ones already mentioned in current incident reports, can build
automation easier. However, simple/ordinary Subscribers that don't have
the technical skills to automate the certificate replacement, that
struggled to even install certificates in their TLS servers in the first
place, will create huge burden for no good reason.
I don't know if others share the same view about the interpretation of
7.1 but it seems that some highly respected members of this community
did. If we have to count every CA that had this interpretation, then I
suppose all CAs that were using EJBCA with the default configuration
have the same interpretation.
BTW, the configuration in EJBCA that we are talking about, as the
default number of bytes, had the number "8" in the setting, resulting in
64-bits, not 63. So, as far as the CA administrator was concerned, this
setting resulted in using 64 random bits from a CSPRNG. One would have
to see the internal code to determine that the first bit was replaced by
a zero.
IMO, Mozilla should also treat this as an incident and evaluate the
specific parameters (strict interpretation of section 7.1, CAs did not
deliberately violate the requirement, a globally-respected software
vendor and other experts had a different allowable interpretation of a
requirement, the security impact on Subscribers and Relying Parties for
1 bit of entropy is negligible), and consider treating this incident at
least as the underscore issue. In the underscore case, there was a SCWG
ballot with an effective date where CAs had to ultimately revoke all
certificates that included an underscore.
Thanks,
Dimitris.
On 9/3/2019 6:32 π.μ., Peter Bowen via dev-security-policy wrote:
On Fri, Mar 8, 2019 at 7:55 PM Matthew Hardeman via dev-security-policy <
[email protected]> wrote:
On Fri, Mar 8, 2019 at 9:49 PM Ryan Sleevi <[email protected]> wrote:
I consider that only a single CA has represented any ambiguity as being
their explanation as to why the non-compliance existed, and even then,
clarifications to resolve that ambiguity already existed, had they simply
been sought.
Please contemplate this question, which is intended as rhetorical, in the
most generous and non-judgmental light possible. Have you contemplated the
possibility that only one CA attempted to do so because you've stated your
interpretation and because they're subject to your judgement and mercy,
rather than because the text as written reflects a single objective
mechanism which matches your own position?
Matthew,
I honestly doubt so. It seems that one CA software vendor had a buggy
implementation but we know this is not universal. For example, see
https://github.com/r509/r509/blob/05aaeb1b0314d68d2fcfd2a0502f31659f0de906/lib/r509/certificate_authority/signer.rb#L132
and https://github.com/letsencrypt/boulder/blob/master/ca/ca.go#L511 are
open source CA software packages that clearly do not have the issue.
Further at least one CA has publicly stated their in-house written CA
software does not have the issue.
I know, as the author of cablint, that the main reason I didn't have any
confusion. I didn't add more checks because of the false positive rate
issue; if I checked for 64 or more bits, it would be wrong 50% of the
time. The rate is still unacceptable with even looser rules; in 1/256
cases the top 8 bits will all be zero, leading to a whole the serial being
a whole byte shorter.
I do personally think that the CAs using EJBCA should not be faulted here;
their vendor added an option to be compliant with the BRs and it was very
non-obvious that it had a bug in the implementation. Based on my
experience with software development, we should be encouraging CAs to use
well tested software rather than inventing their own, when possible.
Thanks,
Peter
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
