On Thu, May 5, 2016 at 9:56 AM, Peter Bowen <[email protected]> wrote: > > > On May 5, 2016, at 6:50 AM, Richard Barnes <[email protected]> wrote: > > > > On Thu, May 5, 2016 at 8:32 AM, Peter Bowen <[email protected]> wrote: > >> > >> I will disagree. I think the intent is to "prune" the tree > > > > > > Oh, if only it were a tree, and not a DAG. Well, *hopefully* acyclic. > > Nope, not acyclic. Already seen proof of that. > > > > >> once either > >> a technical constraint is hit or when the set of allowed key purposes > >> ceases to include serverAuth. I also think that path length > >> constraints should be taken in to account. > >> > >> That being said, because multiple cross-certificates can exist with > >> the same subject, it is possible that one path would be pruned but > >> there is another path that is unconstrained, which would result in > >> disclosure being required. > >> > > > > Let's label the alternative policies here as C (for "cert") and CoAP (for > > "cert-or-all-parents"), according to what must be constrained. > > > > I appreciate the desire to bound disclosure here. CoAP does result in a > > lower disclosure burden for CAs. However, I have two major concerns > about > > it: > > > > 1. You need global state to evaluate it. Evaluating the disclosure > > requirement for a certificate requires that you evaluate a "not exists" > > qualfiier -- "there does not exist a certification path that is not > > constrained". You can't do that unless you know all possible > > cross-certifications. That might sound feasible for the CA itself, but > for > > a third party like an auditor or a relying party (e.g., Mozilla), it's > > pretty daunting. The only way that could possibly be practical is if the > > universe of CAs were explicitly bounded, i.e., there were a whitelist of > > subordinate CAs. > > > > 2. It leads to bad operational scenarios. With C, a CA knows when they > > create the subordinate CA certificate whether it needs to be disclosed or > > not. With CoAP, a subordinate CA can suddenly become unconstrained, if > any > > of their parents gets an un-constrained cross-signature. This would > > require them to go through all the expense and complexity of audits on > > short notice. > > > > I appreciate that both of the proposed policies are well-formed. But > given > > the above, I would have a hard tiem finding CoAP practical. > > 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. >
Well, "no link" is a little strong, since the constrained intermediate does exist. But I grant that it is a bit odd for there to be no link in the disclosed data set. > > How does this make sense? > It at least has the benefit of making the policy uniform: The rule "When you create a subordinate CA certificate, you must either include technical constraints or disclose it" could apply uniformly to all CAs in the PKI, constrained or not. Maybe the question here is whether the "for all" qualifier points up the "tree" or down: - All parents must be constrained [CoAP] to be exempt from disclosure - All children must be constrained [C] to be exempt from disclosure After all, you could remove the "no link" oddity above by saying that if the constrained CA issues an unconstrained subordinate, then it must be disclosed. This still leaves me thinking that C is more practical, since it aligns the "for all" qualifier with the power relationship: A subordinate can't control what its parents do, so it can't guarantee that all its parents are constrained. But a CA can control what its subordinates do, by revoking a misbehaving subordinate. --Richard > > Thanks, > Peter > > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
