On 09/02/2017 18:20, Jakob Bohm wrote:
On 09/02/2017 10:59, Gervase Markham wrote:
On 08/02/17 11:25, Jakob Bohm wrote:
My logic is that adding additional entropy to a serial number whose
length is fully controlled by CA procedures can increase the
mitigations against SHA-1 weaknesses. For example if the existing CA
setup uses all bits of the old serial number length for non-random
values, then the required 64 random bits can simply be appended or
prepended.
Requiring randomness in the serial number is only appropriate when some
of the certificate contents are attacker-controlled. This is not true
for an intermediate issued by a CA. And if the CA is an attacker,
restricting them to a serial number of the same length (i.e. not
arbitrary) makes it harder for them to engineer a collision.
Gerv
However as a best practice, a CA may establish internal countermeasures
involving adding entropy even for internal requests for intermediary
certificates. My proposal was to simply not ban that.
For external requests, the issue would be if a specific CA certificate
was previously used to sign certificates whose serial number consisted
of e.g. a 128 bit internally computed value (such as AES128(fixed key,
counter)) and a few bits of fresh entropy (such as 20 bits), then
moving to to the higher requirement of 64 fresh CSPRNG bits might be
best implemented (for some such CA) by changing to those same 128 bits
(for continued uniqueness), plus 64 bits of CSPRNG output. Again my
proposal was not to ban that.
More generally, there might be a Mozilla policy requirement that the
length should be fixed in the (updated) CP/CPS, and the serial number
should be mostly generated by the issuing CA (except for cross-certs).
Strike that exception, the serial number is not dictated by the
requester, even for cross-certs.
While such length-growing security improvements might be hampered by
the need to support legacy parties with hard limits on serial number
length, that would be for each CA to consider and decide.
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
