On Fri, May 5, 2017 at 2:21 PM, Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > On 05/05/2017 22:45, Dimitris Zacharopoulos wrote: >> >> >> >> On 5/5/2017 10:58 μμ, Peter Bowen wrote: >>> >> >> I don't know if all implementations doing path validation, use the EKUs >> at the CA level but it seems that the most popular applications use it. >> > > The issue would be implementations that only check the EE cert for > their desired EKU (such as ServerAuth checking for a TLS client or > EmailProtection checking for a mail client). In other words, relying > parties whose software would accept a chain such as > > root CA (no EKUs) => SubCA (EmailProtection) => EE cert (ServerAuth).
This is the Mozilla policy and Mozilla does not do that, so I think we should be fine there. >>> If you look at >>> https://imagebin.ca/v/3LRcaKW9t2Qt, you will see that TCSC will end up >>> being two independent tests. >>> > > > One other question: Does your proposal allow a TCSC that covers both > ServerAuth and EmailProtection for the domains of the same organization? > > Or put another way, would your proposed language force an organization > wanting to run under its own TCSC(s) to obtain two TCSCs, one for their > S/MIME needs and another for their TLS needs? Yes, it allows a single TCSC that does both. The little three diamond symbol means parallel, so both legs are evaluated at the same time. If both get to "Goto B", then it is a single TCSC that can issue both serverAuth and emailProtection certs. Also note that there is no check for pathlen:0 on the TCSC, so it could be a policy CA that has multiple issuing CAs below it. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
