Kathleen,
"Mozilla plans to add automation that will use the intermediate
certificate data in Salesforce to create a whitelist of
non-technically-constrained intermediate certificates chaining up to
root certificates in Mozilla's program" [1]
There are many disclosed intermediate certificates that are not intended
to be used to issue id-kp-serverAuth certificates, but which
nevertheless are technically capable of issuing such certificates.
(Example: https://crt.sh/?id=12721488 "GlobalSign Timestamping CA - G2")
Requiring disclosure of such intermediate certificates is perfectly
reasonable. However, ISTM that there is no good reason to whitelist
such intermediates.
So how about adding a tickbox to Salesforce, for each intermediate
certificate, which is unticked by default and is labelled "Not intended
to issue id-kp-serverAuth certs" ?
Then you could use this field to omit unnecessary entries from the
future whitelist, which would help to reduce the attack surface (e.g.
Imagine if the "GlobalSign Timestamping CA - G2" was compromised and the
attacker used it to issue an id-kp-serverAuth cert for www.mozilla.org).
[1]
https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F
P.S. Once SHA-1 is no longer permitted in unexpired publicly-trusted TLS
certs, you'll be able to omit the (large) number of SHA-1 intermediate
certs from the whitelist too.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
