Not speaking as to the status quo, but rather in terms of updates/changes which might be considered for incorporation into policy would be to recognize the benefit of name constrained intermediates and allow a reduction in burden to entities holding and utilizing name constrained intermediates, both in SSL Server Authentication, and Email Protection. (Probably also allow that OCSP signing, client authentication, certain encrypted storage extended key usages, etc, be allowed).
>From a perspective of risk to the broader web PKI, it would appear that a >properly name constrained intermediate with (for example) only the Server and >Client TLS authentication ekus with name constraints limited to particular >validated domains (via dnsName constraint along with excluding wildcard >IP/netmask for IPv4 and IPv6) is really no substantively more risky than a >multi-SAN wildcard certificate with the same domains. Indeed, in the kind of >enterprise environment where such an intermediate might be used, it is quite >possible that the one intermediate certificate in an enterprise CA may result >in fewer wildcard certificates being distributed within that organization. >(Electing instead to dynamically generate system and purpose-specific >certificates internally without further direct external issuance cost for the >organization). Similarly name constraints for email protection and client auth certificates within limited domain trees could be useful for S/MIME and login certs. If I am not gravely mistaken with respect to the overall risk to the ecosystem, it would seem that clear rules encouraging issuance of such intermediates in lieu of other mechanisms which require close observation of the eventual signatures issued by the intermediate (Can we really say we trust that a CA cut for an enterprise customer is being held by a trusted CA in their infrastructure and constrained as to EE certificate contents by systems and rules at said CA can really be trusted? Even if the CA says that's how it is?) I would propose, for example, that the intermediate certificate itself and the process which led to its issuance is fully part of the scope of the program and requirements. The validation data to be authenticated and preserved by the CA, etc. With respect to the running of the technically constrained CA, is it possible to reward the narrow technical constraints with a hands-off approach to the use of the intermediate in issuing down-line certificates, especially end-entity certificates? For example, no requirement of audit by the enterprise holding the technically constrained intermediate, and no requirement for audit or disclosure of certificates issued by the enterprise from that technically constrained intermediate. In short, a compromise of the technically constrained intermediate has quite limited scope of harm and generally impacts only matters for which the enterprise that lost control of the technically constrained intermediate is at least one of the parties to any transaction. (For example, a bank losing control of a trusted but technically constrained intermediate might cause an outside customer to believe that they're at the bank's website, but even while the outside customer is a victim the bank is also the victim in this circumstance.) In reality, the loss of a wildcard certificate with the same domain(s) is just as damning for the same bank. The difference is that it is highly probably that a wildcard certificate with those domains will be installed in multiple systems, and far less likely that the technically constrained intermediate certificate will be. In short, as an enterprise customer, managing an in-house PKI infrastructure with external CA costs controlled at the price of issuance of a technically constrained intermediate versus buying hundreds of specific endpoint certificates may be attractive to a category of enterprises with complex needs for shared internal/external trust paths for certificates for certain systems and may encourage better deployment practice by cost optimization. In an ideal world, if (and only if) the integrity of the Web PKI is not compromised by taking a freer hand with technically constrained intermediates of limited scope, it is my belief that overall security and adoption of good practice might be improved by reducing the compliance burdens upon enterprises that would utilize such a constrained intermediate. If this is so, providing clear rules for the standards and issuance of these certificates may create a marketplace for a relatively new and unknown product (technically constrained CAs that are standardized to the point that they're on the price list just like an SSL cert is) to enter the market on more competitive terms. Perhaps a product for which various CAs can offer greater differentiation and value models. I think the right compromise might be to treat the intermediate as in-scope for the policy and that the issuance of the intermediate itself is subject to audit and web trust, but that the down-line activities engaged in with a name constrained intermediate need not be subject to audit, disclosure, or policies beyond those which are already enforced by the technical constraints. As to disclosure of these name constrained intermediates, I should think that if they became popular, even among largish enterprises, there might arise quite a lot of such intermediates. Perhaps rather than in CCADB, these name constrained intermediates should be required as a matter of policy to be submitted to CT logs (to an acceptable number of logs, with an acceptable number of those under separate administrative control). A possibility to strengthen issuance of these types of certificates would be to require submission in pre-certificate form with an effective "publish for opposition" period of a week or two to elapse after CT pre-submission before the signed final certificate is returned to the purchaser. Just my thoughts... Matt On Friday, May 19, 2017 at 8:48:14 AM UTC-5, Gervase Markham wrote: > We need to have a discussion about the appropriate scope for: > > 1) the applicability of Mozilla's root policy > 2) required disclosure in the CCADB > > The two questions are related, with 2) obviously being a subset of 1). > It's also possible we might decide that for some certificates, some > subset of the Mozilla policy applies, but not all of it. > > I'm not even sure how best to frame this discussion, so let's have a go > from this angle, and if it runs into the weeds, we can try again another > way. > > The goal of scoping the Mozilla policy is, to my mind, to have Mozilla > policy sufficiently broadly applicable that it covers all > publicly-trusted certs and also doesn't leave unregulated sufficiently > large number of untrusted certs inside publicly-trusted hierarchies that > it will hold back forward progress on standards and security. > > The goal of CCADB disclosure is to see what's going on inside the WebPKI > in sufficient detail that we don't miss important things. Yes, that's vague. > > Here follow a list of scenarios for certificate issuance. Which of these > situations should be in full Mozilla policy scope, which should be in > partial scope (if any), and which of those should require CCADB > disclosure? Are there scenarios I've missed? > > A) Unconstrained intermediate > AA) EE below > B) Intermediate constrained to id-kp-serverAuth > BB) EE below > C) Intermediate constrained to id-kp-emailProtection > CC) EE below > D) Intermediate constrained to anyEKU > DD) EE below > E) Intermediate usage-constrained some other way > EE) EE below > F) Intermediate name-constrained (dnsName/ipAddress) > FF) EE below > G) Intermediate name-constrained (rfc822Name) > GG) EE below > H) Intermediate name-constrained (srvName) > HH) EE below > I) Intermediate name-constrained some other way > II) EE below > > If a certificate were to only be partially in scope, one could imagine > it being exempt from one or more of the following sections of the > Mozilla policy: > > * BR Compliance (2.3) > * Audit (3.1) and auditors (3.2) > * CP and CPS (3.3) > * CCADB (4) > * Revocation (6) > > It's also further possible that BR Compliance could be split, requiring > compliance to some parts of the BRs but not others. > > So this is a complicated question! > > One reasonable enquiry would be: what is the status quo? I _think_ it's > as follows: > > 1) Applicability (Mozilla Root Store Policy section 1.1): > all except E), EE), I) and II), but only those EE certs with no EKU, > or at least one of serverAuth, emailProtection or anyEKU. > 2) Disclosure (CCADB Common Policy section 4): > A), B), D), possibly H) and I) depending on EKU. > > Is that right? > > Gerv _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
