On 11/03/2016 07:40, Charles Reiss wrote:
On 03/03/16 19:48, Ryan Sleevi wrote:
On Thursday, March 3, 2016 at 9:20:07 AM UTC-8, Andrew Ayer wrote:
It's also troubling that a CA may be allowed to continue issuing
non-serverAuth certs with SHA-1 from an issuer that is also used
for serverAuth certs. Again, a collision attack could be used to
forge a trusted serverAuth cert.
I urge that this hole be fixed in both Mozilla policy and the BRs,
not just by clarifying the cert/pre-cert equivalence, but also by
forbidding an issuer that is trusted for serverAuth from signing
_anything_ with SHA-1.
A resounding +1 to this. This goes back to the core goal - if a
certificate has id-kp-serverAuth / is in scope for the BRs, the only
way to make a reasonable argument about the cryptographic operations
is if _everything_ issued by that CA is seen in scope.
This is not just a matter for SHA-1; consider an intermediate with
id-kp-serverAuth and id-kp-emailProtection. If, in the issuance of
S/MIME certificates, the CA leaves off the EKU from the leaf, and
issues a commonName of "example.com", then that certificate - though
intended for email - can now be used for TLS authentication. This is
wholly independent of SHA-1 deprecation.
And I'd guess that (based on lack of EKU and existence of rfc822Name
SAN) this SHA-1 certificate is an example of precisely that problem:
https://crt.sh/?id=15019496
(used in the wild for a TLS server as of this writing:
https://censys.io/ipv4/194.145.239.217)
That seems a particularly clumsily generated certificate:
- DNS name (for https?) in CN, but not repeated as a SAN (as per PKIX).
- SAN present but does not include the server name from the CN, this
might make some PKIX-based clients fail to match the name to the
certificate.
- SHA-1 certificate with apparently intended https usage issued after
2016-01-01.
- e-mailaddress in DN placed before CN (tradition is after, so the
matchable CN for older browsers is the first element of the DN).
- No EKU extension and no Netscape usage extension.
For this reason, I'm a strong supporter in mandating that the scope
of Mozilla's policies - and, more importantly, the expectation of BR
compliance - extends to include _all_ certificates issued from an
intermediates capable of causing TLS certificate issuance, even if
those leaves are not intended for TLS.
Indeed, if an intermediary is not technically constrained, it should be
subject to the BRs. But if it is technically constrained to the
maximum extent possible and audited for anything that could not be
constrained away, it should remain exempt, such that CAs can continue
to support platforms that are stuck in the past for purposes that don't
interfere with modern clients.
Code signing for various Microsoft platforms is a key example of such a
situation. The Microsoft platforms that are still restricted to SHA-1
signatures are also restricted to old CA lists, so setting up new roots
for supporting those is not viable, and not every CA has an old root
they can "throw away", like Symantec did with some of the branded roots
they had accumulated.
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
