On Wednesday, May 31, 2017 at 10:34:34 AM UTC-5, Gervase Markham wrote: > However, that discussion suggests to me that we should do the following: > > * Given CT, and the need within it to disclose TCSCs, the privacy > argument seems to have been abandoned. So I think it's reasonable to > also require disclosure of TCSCs themselves. This allows checking that > they are indeed appropriately constrained. The obvious place to put them > is the CCADB but it's possible we could consider something CT-based, as > we don't need to track the paperwork the CCADB stores (audits, etc.). >
Regardless of whether policy would ultimately dictate that they must be disclosed in CCADB, I do think mandatory disclosure via CT mechanisms would encourage public participation in discovery of improperly constrained certificates. It also would ultimately allow potentially affected third parties to monitor for mis-issued TCSCs with constraints that would allow for infringement of their [the affected third parties'] properties. > * So the options for intermediate certs would change from "(technically > constrained) or (publicly disclosed and audited)" to "(publicly > disclosed) and (technically constrained or fully audited)". > > * In terms of my original message, this would mean adding type F) to the > CCADB disclosure list. That would seem to be case, if CCADB disclosure of these is still required in light of CT. If you're not also tracking the additional matters that one would want in CCADB for roots and less stringently constrained intermediates but not for TCSCs, one wonders if there's really value in having them in CCADB? > > * We should consider going above and beyond the BRs by tweaking the > parameters for the section 8.7 audit of the certs below a TCSC. At the > moment, it's "the greater of one certificate or at least three percent > of the Certificates issued". I think it should be more like: MAX(MIN(5 > certificates, all certificates), 3% of certificates). In other words: > > Issued Audited > 0 0 > 1 1 > .... > 5 5 > 6 5 > .... > 166 5 > 167 6 > .... > > Auditing just a single certificate (currently OK up until 33 are issued) > makes it too easy to overlook problems when volumes are small. > > Comments? I still maintain that if the TCSC is correctly construed and the validation library is correct, it would seem difficult for even random hot garbage wrapped with a correct signature by TCSC's key to surface an actual immediate risk to the Web PKI. If I'm right about that, I would ask Mozilla to deviate in the other direction, waiving the 8.7 requirements as to Mozilla's policy for the certs below the TCSC. That said, if the decision is to require compliance in-line with or exceeding the 8.7 requirement, I do like the direction you're heading. One is too small a number to identify a pattern of behavior. > > Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
