On Thu, May 12, 2016 at 1:53 AM, Ryan Sleevi <r...@sleevi.com> wrote:
> 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. > Oh totally. We are already looking at extending OneCRL to do a whitelist of this sort. In fact, I think I said up-thread that this would make the CoAP policy OK because it would limit the universe of possible paths. > > > 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. > I think we're in violent agreement. If we pair the CoAP policy with whitelist / CT, we get to a pretty good state. The only real cost is that it you need to do some computation to figure out whether a given cert needs to be disclosed, but I assume Rob can get that done :) --Richard > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
