On Monday, May 22, 2017 at 11:50:59 AM UTC-5, Gervase Markham wrote: > So your proposal is that technical requirements should be enforced > in-product rather than in-policy, and so effectively there's no need for > policy for the EE certs under a TCSC. > > This is not an unreasonable position. >
That is a correct assessment of my position. If we are able to unambiguously enforce a policy matter by technological means -- and most especially where such technological means already exist and are deployed -- that we should be able to rely upon those technology constraints to relieve the administrative burden of auditing and enforcing compliance through business process. > > How do the various validation routines in the field today validate a > > scenario in which a leaf certificate's validity period exceeds a > > validity period constraint upon the chosen trust path? Is the > > certificate treated as trusted, but only to the extent that the > > present time is within the most restrictive view of the validity > > period in the chain, or is the certificate treated as invalid > > regardless for failure to fully conform to the technical policy > > constraints promulgated by the chain? > > Good question. I think the former, but Ryan Sleevi might have more info, > because I seem to remember him discussing this scenario and its compat > constraints recently. > > Either way, it's a bad idea, because the net effect is that your cert > suddenly stops working before the end date in it, and so you are likely > to be caught short. Here I would concur that it would be bad practice for precisely the reason you indicate. I was mostly academically interested in the specifics of that topic. I would agree that extending the certificate lifecycle to some period beyond the max EE validity period would alleviate the need. Having said that, I can still envision workable scenarios and value cases for such technically constrained CA certificates even if it were deemed unacceptable to extend their validity period. > > > I submit, then, that the real questions become further analysis and > > feedback of the risk(s) followed by specification and guidance on > > what specific constraints would form up the certificate profile which > > would have the reduced CP/CPS, audit, and disclosure burdens. As a > > further exercise, it seems likely that to truly create a market in > > which an offering of this nature from CAs would grow in prevalence, > > someone would need to carry the torch to see such guidance (or at > > least the relevant portions) make way into the baseline requirements > > and other root programs. Is that a reasonable assessment? > > Well, it wouldn't necessarily need to make its way into other places. > Although that's always nice. Agreed. I primarily made mention of the other rules, etc. because it occurs to me that part of the same standards of what might qualify for preferential / different treatment of technically constrained subCAs with respect to disclosure might also neatly align with issuance policy as might pertain in, for example, your separate thread titled "Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection" The question of audit & disclosure requirements pertaining to technically constrained subCAs seems to be ripe for discussion. I note that Doug Beattie recently sought clarification regarding this question on the matter of a name constrained subCA with the emailProection eku only several days ago in the thread "Next CA Communication" Thanks, Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
