On Monday, May 22, 2017 at 7:24:42 PM UTC-5, Ryan Sleevi wrote: > https://groups.google.com/d/msg/mozilla.dev.security.policy/yS_L_OgI5qk/OhLX9iyZBAAJ > specifically proposed > > "For example, no requirement of audit by the enterprise holding the > technically constrained intermediate, and no requirement for audit or > disclosure of certificates issued by the enterprise from the technically > constrained subordinate." > > You're certainly correct that, under today's scheme, TCSCs exemption from > requirements under the Baseline Requirements simply requires Self-Audits > (Pursuant to Section 8.7). However, that does not mean that TCSCs must be > on the same infrastructure as the issuing CA - simply that "the CA which > signed the Subordinate CA SHALL monitor adherance to the CA's CP and the > SubCA's CPS" and a sampling audit, by the issuing CA, of either one > certificate or three percent of certificates issued. > > That's a much weaker requirement than subCAs. >
It's true that I set forth a particular goal that I represented as part of my interest in seeing the bar for the issuance of a properly designed TCSC lowered. I concur that the realization of that goal would mean that there are far more unique systems issuing publicly trusted (although within a very narrowly defined window as enforced by technical constraints) certificates. I even concede that that alone does create a potential for compatibility issues should a need arise to make a global web pki-wide change to certificate issuance (say, for example, sudden need to deprecate SHA-256 signatures in favor of NGHA-1 [ostensibly the Next Great Hash Algorithm Instance #1]). For mitigation of that matter, I firmly believe that any research and development in the area of improved techniques for demonizing server administrators would be most beneficial. > > > It seems this discussion is painting TCSCs with a broad brush. I > > don't see anything in this discussion that makes the TCSC relationship > > any different from any other subordinate CA. Both can be operated > > either by the same organization that operates the root CA or an > > unrelated organization. The Apple and Google subordinate CAs are > > clearly not TCSCs but raise the same concerns. If there were 10,000 > > subordinates all with WebTrust audits, you would have the exact same > > problem. > > > > Indeed, although the realities and costs of that make it unpractical - as > do the risks exposed to CAs (as recently seen) in engaging in such > relationships without sufficient and appropriate oversight. If I understand correctly, then, the issue is that you wish to minimize the growth of distinct issuing systems wherever they may occur in the PKI hierarchy, not TCSCs in particular. > > But I'm responding in the context of the desired goal, and not simply > today's reality, since it is the goal that is far more concerning. If I understand correctly, your position is that full disclosure and indexing of the TCSCs is to be desired principally because the extra effort of doing so may discourage their prevalence in deployment? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
