On Tue, Apr 30, 2019 at 1:10 PM Fotis Loukos <fot...@ssl.com> wrote: > I am just arguing that there is no risk involved in having a single > certificate. I do agree that the model you proposed with the two > certificates is a model that can be used right now, but I do not see any > additional risks by having a single certificate. >
As the one proposing relaxing the policy, shouldn't the burden of evidence and discussion be on you to establish why and how there is no risk? 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) > > Among other things, the Root CA is permitted to be offline, but the EV > > intermediate is not. > > This is a difference at the specific requirements for the particular > CAs, and not a difference on the policies the CAs are audited against. I > thought that your point is that that model creates a significant risk to > the users because it is subject to the union of policies and needs to be > audited under both policies. The fact that a CA is audited against a > single or multiple policies is semantically different to the content of > the policies themselves. > I don't believe it's reasonable to treat those as separable. For example, by the same logic being applied here, one could argue that there is no difference between a root certificate and a leaf certificate, since they're audited against the same policies - but, obviously, with different requirements. The requirements - and capabilities - of the certificates are an intrinsic part of the discussion and risk. > >> Or how is it different from auditing a Sub CA issued before 2019/01/01 > >> under both policies? > > > > > > It is this previously-permitted, now forbidden, aspect of policy that was > > the intentional specification of policy. Folks would argue that the EV > > intermediate - capable of issuing TLS certificates - wasn't "intended" to > > be used as such, and thus would exclude it from audits or complying with > > the BRs, or any other number of divergent, non-compliant behaviours. > > Well, I totally agree that this interpretation is really, REALLY, bad, > and I would never support something like this. I really don't think that > any auditors would actually agree with this since it creates a huge risk > to the ecosystem and as far as I'm concerned, it is clear that such CAs > are in scope. However, I wouldn't object to adding that such SubCAs are > subject to both policies, if that would address your concerns. > I feel that, as the proposer to the change, it would be beneficial if you look through the past discussions of CA certificate disclosures, to see that such interpretations have been met. From an auditor perspective, it's not an interpretative matter, if that's how the scope was contracted. I don't think it's beneficial to try and incrementally piecemeal bandaids on, without first understanding how and why the policy came to be, and the risks it's trying to prevent, and then discussing the benefits to the community and to users that outweigh those risks. It's also not unreasonable to reject the proposal if risks are overlooked, or if the risks outweigh the benefits, or if the benefits are not clearly articulated. > > The current policy ensures that there's technical restrictions on this, > and > > defines them in such a way that the permitted hierarchy is the desired > > hierarchy, not only for matters of assessing compliance, but of reducing > > risk to users. > > You are mentioning the risk to the users, and in your previous email you > mentioned that there were issues in the past. I would appreciate it if > you could please point me to a single occasion where a SubCA not issuing > end entity certificates, but having EKU constrained intermediates led to > an issue. > Beyond attempting to change the burden of evidence - which is a rather entirely unreasonable and problematic approach, especially as the advocate for the change - simply look through my past CP/CPS reviews in this Forum. You can see, for example, that one of the routine issues I would flag would be the conflation of e-mail certificates for use as TLS certificates, through poorly specified certificate profiles. For example, an intermediate - with EKUs for both - may be used as a policy intermediate. TLS and S/MIME intermediates would be constructed, but without EKU restrictions - merely operational. The S/MIME leaves would lack EKUs, the TLS intermediate would have TLS-server-auth. However, certificates issued by the S/MIME intermediate would fully be usable for TLS, particularly if the user's or organization's legal name was a domain-shaped thing. There are many ways to do PKI. Many of them are bad. Part of the policy is to constrain and restrain the badness, and reduce ambiguity and options. This is already practiced by many more mature standards groups - one can see this prominent example in the design of TLS 1.3 and its reform of the ciphersuite selection process. As the person advocating the change, the only reason captured so far is that it would allow to do something different - but that different carries with it a number of risks, both technical and interpretative. At a high level, perhaps you can demonstrate why this 'different' would be beneficial and worth the complexity and the risk. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
