On Sun, Jul 5, 2020 at 5:30 PM Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Matt Palmer via dev-security-policy > > At the limits, I agree with you. However, to whatever degree that there > is complaining to be done, it should be directed at the CA(s) > > which sold a product that, it is now clear, was not fit for whatever > purpose it has been put to, and not at Mozilla. > > Let me quote from the NSS website of Mozilla ( > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Overview): > > If you want to add support for SSL, S/MIME, or other Internet security > standards to your application, you can use Network Security Services (NSS) > to implement > all your security features. NSS provides a complete open-source > implementation of the crypto libraries used by AOL, Red Hat, Google, and > other companies in a > variety of products, including the following: > * Mozilla products, including Firefox, Thunderbird, SeaMonkey, and > Firefox OS. > * [and a long list of additional reference applications] > > Probably it would be good if someone from Mozilla team steps in here, but > S/MIME _is_ an advertised use-case for NSS. And the Mozilla website says > nowhere, that the demands and rules of WebPKI / CA/B-Forum overrule all > other demands. It is simply not to be expected by a consumer of S/MIME > certificates that they become invalid within 7 days just because the BRGs > for TLS certificates are requiring it. This feels close to intrusive > behavior of the WebPKI community. > Mozilla already places requirements on S/MIME revocation: https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#62-smime - The only difference is that for Subscriber certificates, a timeline is not yet attached. The problem is that this is no different than if you issued a TLS-capable S/MIME issuing CA, which, as we know from past incidents, many CAs did exactly that, and had to revoke them due to the lack of appropriate audits. Your Root is subject to the TLS policies, because that Root was enabled for TLS, and so everything the Root issues is, to some extent, subject to those policies. The solution here for CAs has long been clear: maintaining separate hierarchies, from the root onward, for separate purposes, if they absolutely want to avoid any cohabitation of responsibilities. They *can* continue on the current path, but they have to plan for the most restrictive policy applying throughout that hierarchy and designing accordingly. Continuing to support other use cases from a common root - e.g. TLS client authentication, document signing, timestamping, etc - unnecessarily introduces additional risk, and for limited concrete benefit, either for users or for the CA. Having to maintain two separate "root" certificates in a root store, one for each purpose, is no more complex than having to maintain a single root trusted for two purposes; and operationally, for the CA, is is vastly less complex. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
