On Thursday, May 5, 2016 at 6:57:21 AM UTC-7, Peter Bowen wrote:
> Nope, not acyclic. Already seen proof of that.
Correct - the Web PKI is a distributed, directed, cyclic graph.
> Consider the inverse.
>
> A root CA issues a CA certificate that is technically constrained
> (KP=serverAuth, permittedTree=dNSName:example.com, all other forbidden). It
> has no path length constraint. There is no disclosure required of this
> certificate, by policy.
>
> The subject of that constrained certificate issues another certificate. You
> propose disclosure is required of the child. But there will be no link to
> any root disclosed.
>
> How does this make sense?
I have to agree with Peter here. I'm actually surprised to see Richard arguing
otherwise, since the intent was, when drafting this language in the previous
update, to make it CoAP - the point at which the graph becomes 'snipped'
because the risks are localized and contained.
In the case of:
Root
|- Intermediate 1 ("Technically Constrained")
|- Intermediate 2 (no constraints)
|- Leaf
The 'risk' scenario here is if Intermediate 2 is signed by another party. But
I'm not sure how disclosing "Intermediate 2" makes any difference in that. If
anything, it creates more noise - it makes people think that leaf was issued
unconstrained, when it wasn't. The suggestion that Intermediate 2 should also
be Technically Constrained is also not terribly appealing - that's adding more
bytes for no value, other than the presumption of saving work for those
monitoring the system, but I would argue that in order to be able to
meaningfully monitor (meaning not raise false positives, and have actionable
signals), they already need a global view.
I'm hesitant to play the interpretation game on the policy, and rather than
suggest a reading that would support that position, suggest we try to resolve
this. I'm still unclear of the objective value, and curious what Richard's
position would be on the scope of the BRs is, since Gerv's representations of
Mozilla's position with respect to BR scope have seemed in line with the CoAP
view.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
