On 05/10/2017 00:38, Nick Lamb wrote:
On Wednesday, 4 October 2017 20:19:22 UTC+1, Gervase Markham wrote:
Would it be an acceptable solution to add these intermediates to OneCRL?
I can't think of any reason this isn't a good idea, the intermediate claims
never to issue anything Firefox (the consumer of OneCRL) would want to trust.
However if I understand the situation correctly, this situation is already very
low risk anyway with no reasonable expectation that it could be exploited
against a competent SSL/TLS client which for some reason still accepts SHA1 and
of course no risk for e.g. modern Firefox which doesn't accepts SHA1 anyway. If
I haven't understood (please anyone jump in) then my assessment may be utterly
wrong.
In this part of Doug's hierarchy actual OCSP responses are from a dedicated
OCSP signer using SHA1. It might prove possible for attackers to force a
collision here by manipulating the details they present, but since it's
dedicated to this purpose they can't use the signature in the response to make
something else like an X.509 certificate, it won't be trusted in that context.
So this is useless practically speaking.
The certificates Doug wants permission to issue - for that dedicated signer
itself - are also signed with SHA1 and that signature is trusted on an X.509
certificate, so that could be a target. BUT they're signing something that's
directly under Doug's control, not an attacker, so there's no avenue here for
collision.
Longer term (not currently I think) there would be the risk of second-
preimage attacks on SHA-1. But those would completely wreck all
historical SHA-1 certificates no matter when or how safely issued (an
attack could even be run in parallel against all SHA-1 certs in the CT
logs and CCADB, especially those not issued from a depth:0 constrained
SubCA).
So that is not an argument against SHA-1 signed revocation
infrastructure certificates for historic SHA-1 CA hierarchies.
Another question though, in the particular case of GlobalSign, isn't it
the case that all SHA-1 certificates chain to the old GlobalSign root
(04:00:00:00:00:01:15:4b:5a:c3:94), while all SHA-256 or higher chain to
new GlobalSign R3 root (04:00:00:00:00:01:21:58:53:08:a2) or one of the
other GlobalSign Rx roots (including the R2 root now owned by Google).
If so, would the proposed SHA-1 OCSP certs chain only to the old root?
Would that old root be completely unused by current NSS clients
(Firefox, Thunderbird, Redhat, ...)?
Has GlobalSign successfully revoked the R3 to old cross certificate
(that failed to be revoked due to that OCSP bug a while back).
If all 3 answers are Yes, couldn't that old root just be removed from
the root store with a comment (for the benefit of "clone" root stores)
that this root CA cert has exited the BR scope to become a dedicated
SHA-1 only CA used for people needing backwards compatible certificates.
Of cause GlobalSign could continue telling SHA-256 customers to include
the old-to-R3 cross certificates in chains supplied to clients that may
have old root stores without R3 (such as Microsoft systems not
subscribing to automatic CA updates), as those systems would only trust
the old root and not distrust it over this. Again, this relies on the
old root not being explicitly blocked in a way that would barf at its
inclusion in an alternative certificate chain.
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
