On Thu, May 2, 2019 at 9:14 AM Fotis Loukos <fot...@ssl.com> wrote: > The PCA (I am calling it PCA even if it does not follow all the design > and architecture of RFC5288 PCAs for simplicity's sake) has the > technical ability to issue both TLS and S/MIME end-entity certs but is > constrained to issue only SubCAs by policy. The same rule applies to > Root CAs for example, which have the technical ability to issue > end-entity certificates, but they are restricted by policy (once again, > for simplicity's sake let's not get into the different rules and > different validations that are stated in RFC5280 for trust anchors > because if we want to be technically correct with everything, EKUs on > intermediates have no meaning). I do not see any reason that the risk to > the ecosystem is increased from this CA. No end-entity certificates are > issued, and thus there is no place for misconduct. >
I don't think it's fair to say there's no place for misconduct. I think this may be a distinction in how we approach technical controls versus procedural controls. The number of failures of procedural controls in the CA incident dashboard is staggering, and many of them could have been addressed via technical controls. Obviously, as a tech guy, I'm going to be biased to technically verifiable controls over "Trust us", especially when the "trust" involves both the CA and the Auditor/CAB. I do not see any reason how the ecosystem is *helped* by this model, and I think that's the thing. It might be comparable to consider the notion of self-issued key rollover. While defined in RFC 5280, and thus 'legal' in a sense, it causes unnecessary complexity and risk compared to alternative designs and solutions. As much as possible, I think we want to keep the PKIs that are trusted on the 'happy' path. > All intermediates underneath that CA will be restricted by EKU (unless > they are PCAs themselves, so the afforementioned analysis applies to > them too). This is what the Mozilla Root Store Policy already uses, and > I think we both agree that this is safe. > > So I can't identify how we the risk is increased. > As I just stated above, you're fundamentally relying on a policy-level control, which means increasing the reliance on audits, and creating significantly greater risk of a policy-control failure, whether due to misunderstanding, malice, or incompetence. We can and should work to improve the systems so we have greater technical verifiability - whether that's through EKU constraints or more ecosystem-wide things such as pre-issuance linting and Certificate Transparency-based post-issuance linting. Hopefully that more clearly spells out the fundamental philosophical difference in approaches, and why it's important to highlight what the benefits are of the policy based solution, for browsers and end users, since they bear the risk. As it stands, it seems CAs are the only ones that benefit, as you've presented, but even then, it's not clear that that's actually true. > > I just want to highlight that there's a difference between whether or not > > you see the risk and whether or not others see the benefit. I think it'd > be > > helpful if you highlight the benefit. For example, you highlighted > > infrastructure certificates - but those aren't applicable (e.g. an OCSP > > certificate) > > There are organizations who would like to issue both TLS and S/MIME > publicly trusted certificates for their uses. With the current model, > the "least common denominator" CA is the Root CA. Yes. That is the intentional goal. > However, having a > single CA for this organization underneath which all certificates are > issued by other SubCAs makes it way more easier in management. I don't > think that I need to elaborate more on why this is much easier, I > consider it pretty evident. > I think you do need to elaborate on this, because it's also non-obvious that it reduces the number of the CAs. I tried to show the math for you in comparing the difference of designs, but perhaps you want to explicitly expand on how you see a possible joint TLS/S/MIME PKI being designed, under the 'ideal' world, so that it might be more clearly discussed. > I totally agree with the latest sentence, but I think that the > discussion is not on changing the audit requirements themselves, but > changing which requirements apply to which CAs. And as I stated before, > all CAs that chain to a TLS end-entity certificate will be audited > against the same requirements they are audited today, no matter if they > are issuing CAs, CAs with the serverAuth EKU, or PCAs. Having said that, > I don't think that there are changes to the trust model that is > currently in effect. > It introduces unneeded complexity which has been a point of misunderstanding and misapplication in the past. This changes the model from being one of technically inspecting the certificates and comparing the audits to one of divining policy, as to whether a given certificate is a PCA, and potentially ineffable elements (to anyone but the CA or auditor), such as whether the PCA has actually *been* a PCA and not issued any end-entity certificates. That is a significant change in the risk model - something which can be technically verified no longer is. It could be that we're entirely missing eachother's perspectives, and I think that clarifying both what you see the existing 'required' PKI is, and how the alternative PKI under your proposal would look, may help clarify any confusion or misunderstanding. From there, we can then discuss about the risk factors - for users, browsers, and CAs - and the possible benefits. Does that sound like a reasonable next step? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
