On 30/03/15 16:34, Richard Barnes wrote: > After some further thought on this issue, I would like to propose the > following course of action: > > 1. Remove the CNNIC root certificates > 2. (possibly) Temporarily add the CNNIC intermediate certificates
After consideration, I want to record two potential problems with this proposal. 1) It encourages bad practice, and arguably requires CNNIC to violate the BRs. Both Mozilla (as a Potentially Problematic Practice) and the BRs tell CAs not to issue certs directly from their embedded certificates. The BRs has a whole section on this (section 12), which says: "Root CA Private Keys MUST NOT be used to sign Certificates" and then goes on to give a limited set of exceptions, none of which apply to CNNIC issuing EE certs. What is a "Root CA"? According to the BRs, it is "the top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates". CNNIC's embedded intermediates, in this plan would meet the first half of that definition, but not the second (due to the artificial pathLength constraint). So you could argue this both ways in terms of the letter of the law, but the fact remains that issuing directly from your embedded certs is bad practice. 2) It subverts end-user choices. If the level of concern at their inclusion is any guide, some end-users may well have configured their trust store not to trust CNNIC's roots. If we remove those roots and add the intermediates, AIUI those decisions will no longer be respected, and those browsers will trust CNNIC certs again. Without meaning to, we will have accidentally subverted user trust choices in a way which almost perfectly restores trust in certs they have chosen not to trust, with no notification and no side-effects. This second issue concerns me particularly, given Mozilla's stance on user sovereignty. Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
