On 25/02/2019 11:42, Scott Rea wrote:
G’day Paul,
I cannot speak for other CAs, I can only surmise what another CA that is as
risk intolerant as we are might do. For us, we will collision test since there
is some probability of a collision and the test is the only way to completely
mitigate that risk.
There is a limitation in our current platform that sets the serialNumber
bit-size globally, however we expect a future release will allow this to be
adjusted per CA. Once that is available, we can use any of the good suggestions
you have made below to adjust all our Public Trust offerings to move to larger
entropy on serialNumber determination.
However, the following is the wording from Section 7.1 of the latest Baseline
Requirements:
“Effective September 30, 2016, CAs SHALL generate non-sequential Certificate
serial numbers greater than zero (0) containing at least 64 bits of output from
a CSPRNG.”
Unless we are misreading this, it does not say that serialNumbers must have
64-bit entropy as output from a CSPRNG, which appears to be the point you and
others are making. If that was the intention, then perhaps the BRs should be
updated accordingly?
We don’t necessarily love our current situation in respect to entropy in
serialNumbers, we would love to be able to apply some of the solutions you have
outlined, and we expect to be able to do that in the future. However we still
assert that for now, our current implementation of EJBCA is still technically
complaint with the BRs Section 7.1 as they are written. Once an update for
migration to larger entropy serialNumbers is available for the platform, we
will make the adjustment to remove any potential further isssues.
Regards,
I believe the commonly accepted interpretation of the BR requirement is
to ensure that for each new certificate generated, there are at least
2**64 possible serial numbers and no way for anyone involved to predict
or influence which one will be used.
This rule exists to prevent cryptographic attacks on the algorithms used
for signing the certificates (such as RSA+SHA256), and achieves this
protection because of the location of the serial number in the
certificate structure.
If all the serial numbers are strictly in the range 0x0000000000000001
to 0x7FFFFFFFFFFFFFFF then there is not enough protection of the signing
algorithm against these attacks.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
