On Wednesday, May 11, 2016 at 3:44:54 PM UTC-7, Richard Barnes wrote: > Right, if the monitors are trying to identify all the valid certs, then > it's very important for them to have a full list of intermediates. Maybe > this is yet another positive use of this data set.
Right, but I think the longer-goal is to get it into CT. > (Note that the same > concern would apply to logs filtering on ingress.) Logs shouldn't be filtering on ingress, ideally ;) > It's mainly the discontinuity of Intermediate 2 suddenly transitioning from > the "constrained, so no worries" state to the "needs to be fully disclosed > and audited" state that worries me. Especially when you consider that > there could be a whole chain of intermediates above Intermediate 2, any one > of which could cause this state transition. Who is the concern for? The operators of Intermediate 2? The operators of Intermediate 1? The operators of Root B? > As you note below, it would be incumbent on the issuer of the unconstrained > intermediate 1' to assure compliance. But, you know, we see these "oops, > I missed that one" events all the time around here. Isn't another way to address that via technical means? Such as whitelisting (disclosed) intermediates and only allowing (undisclosed) intermediates if they chain to a constrained intermediate? That's fundamentally our goal with Certificate Transparency, but even in the absence of precerts-in-an-Intermediate (which CAs can totally be doing today *cough*), you could still devise technical means to address that. > The fact that existing policy does apply here is the reason I'm saying I > can live with CoAP. But requiring each intermediate to be constrained > seems more conservative, because it avoids surprise and makes monitoring > more straightforward. I suppose I can buy that. If we had a hypothetical world where, say, every Intermediate had to be accompanied by a requisite number of SCTs, or was perhaps a whitelist driven by public CT data, or was driven by a whitelist driven by Salesforce, would you still see that as valuable? I agree with you that it's conservative, and also provides greater defense in depth, but at greater overhead, so I'm wondering if there's a world where we can have both our speed and our disclosures, and have technical enforcement for both. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
