Hello, On 30/4/19 8:26 μ.μ., Ryan Sleevi via dev-security-policy wrote: > 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?
Definitely, I am just replying to your comment on the increased risk. I do believe that the WebPKI and S/MIME worlds should be separated. We've seen in the past cases where this has lead to many problems (e.g. s/mime certificates with no EKUs that can be used for WebPKI since the CA has no EKU, or includes the serverAuth EKU along with emailProtection). However, this proposal does not "mix" back the two worlds. 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. Of course, it goes without saying that if this PCA has a SubCA with the serverAuth EKU it MUST be audited against all requirements for the WebPKI. 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. > > 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. 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 would be comfortable with allowing PCAs to include both the emailProtection and the serverAuth EKU and prohibit them from not having an EKU if this makes you more comfortable with the change, since it allows us to reach the same goal. Maybe this will address your concerns on CAs misinterpreting the requirement and believing that this CA does not have to be audited against the BRs. > > >>> 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. 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. > > >>>> 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. I believe that I do know many of the risks involved in mixing the WebPKI and the S/MIME worlds, but as I stated before this is not what I am proposing. PCAs are not issuing CAs and they will be audited against all requirements for CAs having the serverAuth EKU. > > >>> 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 Please note that I am not trying the change who carries the burden of proof, I am simply trying to respond to your comment on increased risk. You can see in the beginning of this message why I think that the risk is not increased, and why the community will profit from this change. > 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 This is not what I proposed. In my proposal, all issuing CAs will have EKUs, so I don't think that your example applies in this case. It would apply if I recommended removing the restriction for all CAs and not just PCAs. > 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. I totally agree with you. However, I cannot see why this change in the policy is a bad way to do PKI. If you think that the small analysis in the beginning of the message is wrong, I would be glad to discuss it. > > 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. You are correct that in my previous messages I did not mention the profits from such a change. I hope that this message clarifies it. Best regards, Fotis > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- Fotis Loukos, PhD Director of Security Architecture SSL Corp e: fot...@ssl.com w: https://www.ssl.com _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
