Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement
On Tue, Apr 30, 2019 at 1:10 PM Fotis Loukos 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
Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement
Hello, On 30/4/19 6:59 μ.μ., Ryan Sleevi via dev-security-policy wrote: > On Tue, Apr 30, 2019 at 11:49 AM Fotis Loukos wrote: > >> On 30/4/19 6:34 μ.μ., Ryan Sleevi via dev-security-policy wrote: >>> On Tue, Apr 30, 2019 at 8:51 AM Fotis Loukos wrote: >>> Hello Ryan, On 29/4/19 5:20 μ.μ., Ryan Sleevi via dev-security-policy wrote: > On Fri, Apr 26, 2019 at 7:02 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> In version 2.6 of our Root Store Policy, we added the requirement to >> section 5.3 that intermediate certificates contain an EKU and separate >> serverAuth and emailProtection uses. Version 2.6.1 updated the requirement >> to exclude cross certificates [1]. Last month, an issue [2] was filed >> requesting that we add "Policy Certification Authorities" (PCAs) as another >> exception. >> >> PCAs are described in RFC 5280 as a CA certificate that is only used >> to >> issue other CA certificates, so excluding PCAs from this requirement would >> not in theory weaken it. However, I'm not aware of any way to technically >> enforce that PCAs not issue end-entity certificates, and allowing more >> exceptions would seem to make this policy more difficult to enforce. >> In >> addition, RFC 5280 section 3.2 appears to reference PCAs as an example of >> an architecture that should be abandoned in favor of x509v3 >> certificate >> extensions: >> >>With X.509 v3, most of the requirements addressed by RFC 1422 can >> be >>addressed using certificate extensions, without a need to restrict >>the CA structures used. In particular, the certificate extensions >>relating to certificate policies obviate the need for PCAs... >> >> This is https://github.com/mozilla/pkipolicy/issues/172 >> >> I will appreciate everyone's input on this proposal. >> > > TL;DR: I do not support this change. > > This appears to highlight a tension between Mozilla Policy and >> (possible) > ways to design a PKI. > > Consider the example of a CA that produces EV, OV, and DV certificates, for > use in both TLS and S/MIME. > > One hierarchy would have (Root, no policies/any policy) -> (EV, OV, DV > PCAs, using the Certificate Policies extension to constrain the >> policies) > -> (TLS, S/MIME issuing intermediates, using EKU) -> Leaf > Another hierarchy would be (Root, no policies/any policy) -> (TLS, >> S/MIME > "policy" intermediates, using EKU) -> (EV, OV, DV TLS issuing intermdiates, > EV, OV, DV S/MIME issuing intermediates, using the Certificate Policies to > constrain the policies) I would be glad to implement the second model you are proposing, but AFAICT this is prohibited by the Root Store Policy using a single SubCA. More precisely, section 5.3 of the Root Store Policy mentions: Intermediate certificates created after January 1, 2019, with the exception of cross-certificates that share a private key with a corresponding root certificate: MUST contain an EKU extension; and, MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and, * MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate. >>> >>> Can you explain to me why you believe this is prohibited? The second >> model >>> is the model that is permitted - the first model is, as you note, >> expressly >>> forbidden by policy. >> >> As I said, this is prohibited by the Root Store Policy using a single >> SubCA. If that SubCA was to issue a TLS and an S/MIME intermediate, it >> would need to either: >> - Not include an EKU extension -> prohibited by the clause "MUST contain >> an EKU extension" >> - Include the anyExtendedKeyUsage KeyPurposeId -> prohibited by the >> clause "MUST NOT include the anyExtendedKeyUsage KeyPurposeId" >> - Include both the id-kp-serverAuth and id-kp-emailProtection >> KeyPurposeIds -> prohibited by the clause "MUST NOT include both the >> id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same >> certificate." >> >> I don't know of any other possible configurations that would allow this. >> Please let me know if this can be solved in some other way. >> > > I'm afraid we're saying the same thing, so I'm not sure where the confusion > is. > > It would appear you're interpreting "(TLS, S/MIME "policy" intermediates, > using EKU)" as referring to a single certificate, wheras I'm trying to > clearly specify (as later provided) that this is not, and is in fact two > different certificates, each constrained by EKU to a singular, specific > purpose. > > This is desirable. > 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
Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement
On Tue, Apr 30, 2019 at 11:49 AM Fotis Loukos wrote: > On 30/4/19 6:34 μ.μ., Ryan Sleevi via dev-security-policy wrote: > > On Tue, Apr 30, 2019 at 8:51 AM Fotis Loukos wrote: > > > >> Hello Ryan, > >> > >> On 29/4/19 5:20 μ.μ., Ryan Sleevi via dev-security-policy wrote: > >>> On Fri, Apr 26, 2019 at 7:02 PM Wayne Thayer via dev-security-policy < > >>> dev-security-policy@lists.mozilla.org> wrote: > >>> > In version 2.6 of our Root Store Policy, we added the requirement to > section 5.3 that intermediate certificates contain an EKU and separate > serverAuth and emailProtection uses. Version 2.6.1 updated the > >> requirement > to exclude cross certificates [1]. Last month, an issue [2] was filed > requesting that we add "Policy Certification Authorities" (PCAs) as > >> another > exception. > > PCAs are described in RFC 5280 as a CA certificate that is only used > to > issue other CA certificates, so excluding PCAs from this requirement > >> would > not in theory weaken it. However, I'm not aware of any way to > >> technically > enforce that PCAs not issue end-entity certificates, and allowing more > exceptions would seem to make this policy more difficult to enforce. > In > addition, RFC 5280 section 3.2 appears to reference PCAs as an example > >> of > an architecture that should be abandoned in favor of x509v3 > certificate > extensions: > > With X.509 v3, most of the requirements addressed by RFC 1422 can > be > addressed using certificate extensions, without a need to restrict > the CA structures used. In particular, the certificate extensions > relating to certificate policies obviate the need for PCAs... > > This is https://github.com/mozilla/pkipolicy/issues/172 > > I will appreciate everyone's input on this proposal. > > >>> > >>> TL;DR: I do not support this change. > >>> > >>> This appears to highlight a tension between Mozilla Policy and > (possible) > >>> ways to design a PKI. > >>> > >>> Consider the example of a CA that produces EV, OV, and DV certificates, > >> for > >>> use in both TLS and S/MIME. > >>> > >>> One hierarchy would have (Root, no policies/any policy) -> (EV, OV, DV > >>> PCAs, using the Certificate Policies extension to constrain the > policies) > >>> -> (TLS, S/MIME issuing intermediates, using EKU) -> Leaf > >>> Another hierarchy would be (Root, no policies/any policy) -> (TLS, > S/MIME > >>> "policy" intermediates, using EKU) -> (EV, OV, DV TLS issuing > >> intermdiates, > >>> EV, OV, DV S/MIME issuing intermediates, using the Certificate Policies > >> to > >>> constrain the policies) > >> > >> I would be glad to implement the second model you are proposing, but > >> AFAICT this is prohibited by the Root Store Policy using a single SubCA. > >> More precisely, section 5.3 of the Root Store Policy mentions: > >> > >> Intermediate certificates created after January 1, 2019, with the > >> exception of cross-certificates that share a private key with a > >> corresponding root certificate: MUST contain an EKU extension; and, MUST > >> NOT include the anyExtendedKeyUsage KeyPurposeId; and, * MUST NOT > >> include both the id-kp-serverAuth and id-kp-emailProtection > >> KeyPurposeIds in the same certificate. > >> > > > > Can you explain to me why you believe this is prohibited? The second > model > > is the model that is permitted - the first model is, as you note, > expressly > > forbidden by policy. > > As I said, this is prohibited by the Root Store Policy using a single > SubCA. If that SubCA was to issue a TLS and an S/MIME intermediate, it > would need to either: > - Not include an EKU extension -> prohibited by the clause "MUST contain > an EKU extension" > - Include the anyExtendedKeyUsage KeyPurposeId -> prohibited by the > clause "MUST NOT include the anyExtendedKeyUsage KeyPurposeId" > - Include both the id-kp-serverAuth and id-kp-emailProtection > KeyPurposeIds -> prohibited by the clause "MUST NOT include both the > id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same > certificate." > > I don't know of any other possible configurations that would allow this. > Please let me know if this can be solved in some other way. > I'm afraid we're saying the same thing, so I'm not sure where the confusion is. It would appear you're interpreting "(TLS, S/MIME "policy" intermediates, using EKU)" as referring to a single certificate, wheras I'm trying to clearly specify (as later provided) that this is not, and is in fact two different certificates, each constrained by EKU to a singular, specific purpose. This is desirable. > > I suppose it wasn't clear that the , was separating out a list of > > intermediates. That is, in the 'second' model, you'd construct the > > following: > > (Root, no policies / any policy) -> (TLS intermediate) -> (EV > intermediate) > > -> (EV TLS Leaf) > > (Root, no policies / any policy) ->
Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement
On 30/4/19 6:34 μ.μ., Ryan Sleevi via dev-security-policy wrote: > On Tue, Apr 30, 2019 at 8:51 AM Fotis Loukos wrote: > >> Hello Ryan, >> >> On 29/4/19 5:20 μ.μ., Ryan Sleevi via dev-security-policy wrote: >>> On Fri, Apr 26, 2019 at 7:02 PM Wayne Thayer via dev-security-policy < >>> dev-security-policy@lists.mozilla.org> wrote: >>> In version 2.6 of our Root Store Policy, we added the requirement to section 5.3 that intermediate certificates contain an EKU and separate serverAuth and emailProtection uses. Version 2.6.1 updated the >> requirement to exclude cross certificates [1]. Last month, an issue [2] was filed requesting that we add "Policy Certification Authorities" (PCAs) as >> another exception. PCAs are described in RFC 5280 as a CA certificate that is only used to issue other CA certificates, so excluding PCAs from this requirement >> would not in theory weaken it. However, I'm not aware of any way to >> technically enforce that PCAs not issue end-entity certificates, and allowing more exceptions would seem to make this policy more difficult to enforce. In addition, RFC 5280 section 3.2 appears to reference PCAs as an example >> of an architecture that should be abandoned in favor of x509v3 certificate extensions: With X.509 v3, most of the requirements addressed by RFC 1422 can be addressed using certificate extensions, without a need to restrict the CA structures used. In particular, the certificate extensions relating to certificate policies obviate the need for PCAs... This is https://github.com/mozilla/pkipolicy/issues/172 I will appreciate everyone's input on this proposal. >>> >>> TL;DR: I do not support this change. >>> >>> This appears to highlight a tension between Mozilla Policy and (possible) >>> ways to design a PKI. >>> >>> Consider the example of a CA that produces EV, OV, and DV certificates, >> for >>> use in both TLS and S/MIME. >>> >>> One hierarchy would have (Root, no policies/any policy) -> (EV, OV, DV >>> PCAs, using the Certificate Policies extension to constrain the policies) >>> -> (TLS, S/MIME issuing intermediates, using EKU) -> Leaf >>> Another hierarchy would be (Root, no policies/any policy) -> (TLS, S/MIME >>> "policy" intermediates, using EKU) -> (EV, OV, DV TLS issuing >> intermdiates, >>> EV, OV, DV S/MIME issuing intermediates, using the Certificate Policies >> to >>> constrain the policies) >> >> I would be glad to implement the second model you are proposing, but >> AFAICT this is prohibited by the Root Store Policy using a single SubCA. >> More precisely, section 5.3 of the Root Store Policy mentions: >> >> Intermediate certificates created after January 1, 2019, with the >> exception of cross-certificates that share a private key with a >> corresponding root certificate: MUST contain an EKU extension; and, MUST >> NOT include the anyExtendedKeyUsage KeyPurposeId; and, * MUST NOT >> include both the id-kp-serverAuth and id-kp-emailProtection >> KeyPurposeIds in the same certificate. >> > > Can you explain to me why you believe this is prohibited? The second model > is the model that is permitted - the first model is, as you note, expressly > forbidden by policy. As I said, this is prohibited by the Root Store Policy using a single SubCA. If that SubCA was to issue a TLS and an S/MIME intermediate, it would need to either: - Not include an EKU extension -> prohibited by the clause "MUST contain an EKU extension" - Include the anyExtendedKeyUsage KeyPurposeId -> prohibited by the clause "MUST NOT include the anyExtendedKeyUsage KeyPurposeId" - Include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds -> prohibited by the clause "MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate." I don't know of any other possible configurations that would allow this. Please let me know if this can be solved in some other way. > > I suppose it wasn't clear that the , was separating out a list of > intermediates. That is, in the 'second' model, you'd construct the > following: > (Root, no policies / any policy) -> (TLS intermediate) -> (EV intermediate) > -> (EV TLS Leaf) > (Root, no policies / any policy) -> (TLS intermediate) -> (OV intermediate) > -> (OV TLS leaf) > (Root, no policies / any policy) -> (TLS intermediate) -> (DV intermediate) > -> (DV TLS leaf) > (Root, no policies / any policy) -> (S/MIME intermediate) -> (EV > intermediate) -> (EV S/MIME leaf) > ... etc > > This is *highly* desirable and strongly beneficial to security than a model > which is expressly forbidden in the current policy, which is > (Root, no policies / any policy) -> (EV intermediate) -> (TLS intermediate) > -> (EV TLS leaf) > (Root, no policies / any policy) -> (EV intermediate) -> (S/MIME > intermediate) -> (EV S/MIME leaf) > > That model creates significant risk to users,
Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement
On Tue, Apr 30, 2019 at 8:51 AM Fotis Loukos wrote: > Hello Ryan, > > On 29/4/19 5:20 μ.μ., Ryan Sleevi via dev-security-policy wrote: > > On Fri, Apr 26, 2019 at 7:02 PM Wayne Thayer via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> In version 2.6 of our Root Store Policy, we added the requirement to > >> section 5.3 that intermediate certificates contain an EKU and separate > >> serverAuth and emailProtection uses. Version 2.6.1 updated the > requirement > >> to exclude cross certificates [1]. Last month, an issue [2] was filed > >> requesting that we add "Policy Certification Authorities" (PCAs) as > another > >> exception. > >> > >> PCAs are described in RFC 5280 as a CA certificate that is only used to > >> issue other CA certificates, so excluding PCAs from this requirement > would > >> not in theory weaken it. However, I'm not aware of any way to > technically > >> enforce that PCAs not issue end-entity certificates, and allowing more > >> exceptions would seem to make this policy more difficult to enforce. In > >> addition, RFC 5280 section 3.2 appears to reference PCAs as an example > of > >> an architecture that should be abandoned in favor of x509v3 certificate > >> extensions: > >> > >>With X.509 v3, most of the requirements addressed by RFC 1422 can be > >>addressed using certificate extensions, without a need to restrict > >>the CA structures used. In particular, the certificate extensions > >>relating to certificate policies obviate the need for PCAs... > >> > >> This is https://github.com/mozilla/pkipolicy/issues/172 > >> > >> I will appreciate everyone's input on this proposal. > >> > > > > TL;DR: I do not support this change. > > > > This appears to highlight a tension between Mozilla Policy and (possible) > > ways to design a PKI. > > > > Consider the example of a CA that produces EV, OV, and DV certificates, > for > > use in both TLS and S/MIME. > > > > One hierarchy would have (Root, no policies/any policy) -> (EV, OV, DV > > PCAs, using the Certificate Policies extension to constrain the policies) > > -> (TLS, S/MIME issuing intermediates, using EKU) -> Leaf > > Another hierarchy would be (Root, no policies/any policy) -> (TLS, S/MIME > > "policy" intermediates, using EKU) -> (EV, OV, DV TLS issuing > intermdiates, > > EV, OV, DV S/MIME issuing intermediates, using the Certificate Policies > to > > constrain the policies) > > I would be glad to implement the second model you are proposing, but > AFAICT this is prohibited by the Root Store Policy using a single SubCA. > More precisely, section 5.3 of the Root Store Policy mentions: > > Intermediate certificates created after January 1, 2019, with the > exception of cross-certificates that share a private key with a > corresponding root certificate: MUST contain an EKU extension; and, MUST > NOT include the anyExtendedKeyUsage KeyPurposeId; and, * MUST NOT > include both the id-kp-serverAuth and id-kp-emailProtection > KeyPurposeIds in the same certificate. > Can you explain to me why you believe this is prohibited? The second model is the model that is permitted - the first model is, as you note, expressly forbidden by policy. I suppose it wasn't clear that the , was separating out a list of intermediates. That is, in the 'second' model, you'd construct the following: (Root, no policies / any policy) -> (TLS intermediate) -> (EV intermediate) -> (EV TLS Leaf) (Root, no policies / any policy) -> (TLS intermediate) -> (OV intermediate) -> (OV TLS leaf) (Root, no policies / any policy) -> (TLS intermediate) -> (DV intermediate) -> (DV TLS leaf) (Root, no policies / any policy) -> (S/MIME intermediate) -> (EV intermediate) -> (EV S/MIME leaf) ... etc This is *highly* desirable and strongly beneficial to security than a model which is expressly forbidden in the current policy, which is (Root, no policies / any policy) -> (EV intermediate) -> (TLS intermediate) -> (EV TLS leaf) (Root, no policies / any policy) -> (EV intermediate) -> (S/MIME intermediate) -> (EV S/MIME leaf) That model creates significant risk to users, because that EV intermediate is capable of issuing both, subject to the union of policies, needs to be audited under both policies, and regularly we see issues with CA's thinking that their requirements on S/MIME don't apply to TLS. > > In your example, the TLS, S/MIME "policy" intermediates have to be > different since they cannot include both the id-kp-serverAuth and > id-kp-emailProtection EKUs. I do not think that having a single CA for > this will introduce any risks. > > To summarize, I agree with the second model you are proposing, but I do > not think that a single SubCA under the Root will introduce any > additional risks compared to different SubCAs depending on the usage. > I disagree with this conclusion. I believe it demonstrably introduces more risk to have intermediates that are jointly capable of issuing for multiple purposes, as has been shown
RE: AT SSL certificates without the AIA extension
Hi Nick, That's a good idea if we were going to continue with supporting customers like this; however, we're in the final stages of terminating all customers running on-premise SSL CAs. Given the timing, setting up private CT logs wouldn't help because that would undoubtedly take longer than our termination date in about 4 months. Doug -Original Message- From: Nick Lamb Sent: Tuesday, April 30, 2019 3:51 AM To: dev-security-policy@lists.mozilla.org Cc: Doug Beattie Subject: Re: AT SSL certificates without the AIA extension On Mon, 29 Apr 2019 12:41:07 + Doug Beattie via dev-security-policy wrote: > It should be noted that these certificates are not posted to CT logs > nor are they accessed via browsers as they are used within closed > networks, but we'll get more details on their exact usage shortly. Hi Doug, Thanks for reporting this problem, I appreciate that this subCA doesn't see a proportionate reward to logging these certs in the existing well known public logs and so it makes sense that they wouldn't write to them. I'm also glad to hear that a 100% sample policy was in place with, it sounds like, a monthly audit period, given the volumes involved (from what I can see publicly in e.g. Censys) that seems like a good idea. Still, in terms of your audit oversight role it could make sense, as software is replaced/ upgraded, to switch to private CT logging as a substitute for a human role of uploading certs for audit. >From your description it sounds as though GlobalSign reasonably trusts that the assigned AT Employee will provide them with an accurate set of certs, the thing we're protecting against here is accident or mistake, not a malevolent subCA operator which would be very hard to detect this way. Unfortunately this employee (and perhaps one or more deputies) were on leave. If that assessment is correct then software which uses RFC6962 methods to write certs on issuance to a log operated by GlobalSign would satisfy this requirement automatically without a human action. With the log not publicly trusted it could operate a much relaxed policy (e.g. MMD 7 days or even not defined, not publicly accessible) but it would avoid this dependency on a specific person at AT doing a manual step periodically in order for GlobalSign to have sight of issued certificates. With the relative popularity of RFC6962 logging, this becomes an off-the-shelf hook that can be used to support audit roles easily without either manual steps to export the certificates or special modifications to the issuance software. You mentioned EJBCA specifically in this post, and so I verified that as expected EJBCA does provide a means for CA operators to configure a log without also then embedding SCTs in certificates (which might not be desirable for AT's application) Nick. smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement
Hello Ryan, On 29/4/19 5:20 μ.μ., Ryan Sleevi via dev-security-policy wrote: > On Fri, Apr 26, 2019 at 7:02 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> In version 2.6 of our Root Store Policy, we added the requirement to >> section 5.3 that intermediate certificates contain an EKU and separate >> serverAuth and emailProtection uses. Version 2.6.1 updated the requirement >> to exclude cross certificates [1]. Last month, an issue [2] was filed >> requesting that we add "Policy Certification Authorities" (PCAs) as another >> exception. >> >> PCAs are described in RFC 5280 as a CA certificate that is only used to >> issue other CA certificates, so excluding PCAs from this requirement would >> not in theory weaken it. However, I'm not aware of any way to technically >> enforce that PCAs not issue end-entity certificates, and allowing more >> exceptions would seem to make this policy more difficult to enforce. In >> addition, RFC 5280 section 3.2 appears to reference PCAs as an example of >> an architecture that should be abandoned in favor of x509v3 certificate >> extensions: >> >>With X.509 v3, most of the requirements addressed by RFC 1422 can be >>addressed using certificate extensions, without a need to restrict >>the CA structures used. In particular, the certificate extensions >>relating to certificate policies obviate the need for PCAs... >> >> This is https://github.com/mozilla/pkipolicy/issues/172 >> >> I will appreciate everyone's input on this proposal. >> > > TL;DR: I do not support this change. > > This appears to highlight a tension between Mozilla Policy and (possible) > ways to design a PKI. > > Consider the example of a CA that produces EV, OV, and DV certificates, for > use in both TLS and S/MIME. > > One hierarchy would have (Root, no policies/any policy) -> (EV, OV, DV > PCAs, using the Certificate Policies extension to constrain the policies) > -> (TLS, S/MIME issuing intermediates, using EKU) -> Leaf > Another hierarchy would be (Root, no policies/any policy) -> (TLS, S/MIME > "policy" intermediates, using EKU) -> (EV, OV, DV TLS issuing intermdiates, > EV, OV, DV S/MIME issuing intermediates, using the Certificate Policies to > constrain the policies) I would be glad to implement the second model you are proposing, but AFAICT this is prohibited by the Root Store Policy using a single SubCA. More precisely, section 5.3 of the Root Store Policy mentions: Intermediate certificates created after January 1, 2019, with the exception of cross-certificates that share a private key with a corresponding root certificate: MUST contain an EKU extension; and, MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and, * MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate. In your example, the TLS, S/MIME "policy" intermediates have to be different since they cannot include both the id-kp-serverAuth and id-kp-emailProtection EKUs. I do not think that having a single CA for this will introduce any risks. To summarize, I agree with the second model you are proposing, but I do not think that a single SubCA under the Root will introduce any additional risks compared to different SubCAs depending on the usage. Regards, Fotis > > It's unclear to me the benefit of the former design over the latter, for > either the CA or for relying parties. On the other hand, the benefits are > clearer for the latter - in which the S/MIME vs TLS split happens as early > as possible. This approach reduces the scope of audits: in the former > design, the PCAs need to be covered by both TLS and S/MIME applicable > audits, while the latter allows cleaving the S/MIME CAs from the scope of > the TLS audits. Similarly, this latter approach, reflected in the current > language, also reduces the scope of risk - if an EV PCA issues an > inappropriate S/MIME issuing intermediate, revoking that EV PCA would also > revoke all EV TLS certificates under the PCA model, while under the current > model, the technical constraints of the TLS "policy" intermediate reduce > the risk of misissuing an S/MIME intermediate under that hierarchy. > > As it's unclear to me the benefit of accommodating the PCAs, because as you > note, it's more complexity to the policy, and because it seems to be > systemically more riskier for end-users and more expensive for CAs, I don't > think we should support modifying the policy. > ___ > 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
Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement
Hello, On 27/4/19 2:02 π.μ., Wayne Thayer via dev-security-policy wrote: > In version 2.6 of our Root Store Policy, we added the requirement to > section 5.3 that intermediate certificates contain an EKU and separate > serverAuth and emailProtection uses. Version 2.6.1 updated the requirement > to exclude cross certificates [1]. Last month, an issue [2] was filed > requesting that we add "Policy Certification Authorities" (PCAs) as another > exception. > > PCAs are described in RFC 5280 as a CA certificate that is only used to > issue other CA certificates, so excluding PCAs from this requirement would > not in theory weaken it. However, I'm not aware of any way to technically Just to clarify, when opening the ticket by Policy CAs I was describing CAs issuing only SubCAs, or other "infrastructure" certificates such as OCSP certificates, and not end-entity certificates. The full model described in RFC5280 includes many more architectural requirements. > enforce that PCAs not issue end-entity certificates, and allowing more > exceptions would seem to make this policy more difficult to enforce. In I think that many, if not most, of the requirements imposed by the Mozilla Root Store Policy are difficult to enforce. This specific requirement is easy to monitor thanks to CT. Crt.sh already provides this information in a single webpage for every CA, and I think that a single database query will return non-compliant SubCAs directly. Other requirements, such as CAA monitoring which is part of the Mozilla Root Store Policy by virtue of CA/B Forum BRs, are way more difficult to enforce, and cannot be monitored directly using some service like CT. > addition, RFC 5280 section 3.2 appears to reference PCAs as an example of > an architecture that should be abandoned in favor of x509v3 certificate > extensions: > >With X.509 v3, most of the requirements addressed by RFC 1422 can be >addressed using certificate extensions, without a need to restrict >the CA structures used. In particular, the certificate extensions >relating to certificate policies obviate the need for PCAs... It is my understanding that this applies to the full PCA model. As I described before, I am simply talking about SubCAs that are issuing only other SubCAs. Unfortunately, I don't think there is a single term to describe these Subs. Regards, Fotis > > This is https://github.com/mozilla/pkipolicy/issues/172 > > I will appreciate everyone's input on this proposal. > > - Wayne > > [1] > https://github.com/mozilla/pkipolicy/commit/a8353e12db6128d9a01de7ab94949180115a2d92 > [2] https://github.com/mozilla/pkipolicy/issues/172 > ___ > 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
Re: AT SSL certificates without the AIA extension
On Mon, 29 Apr 2019 12:41:07 + Doug Beattie via dev-security-policy wrote: > It should be noted that these certificates are not posted to CT logs > nor are they accessed via browsers as they are used within closed > networks, but we'll get more details on their exact usage shortly. Hi Doug, Thanks for reporting this problem, I appreciate that this subCA doesn't see a proportionate reward to logging these certs in the existing well known public logs and so it makes sense that they wouldn't write to them. I'm also glad to hear that a 100% sample policy was in place with, it sounds like, a monthly audit period, given the volumes involved (from what I can see publicly in e.g. Censys) that seems like a good idea. Still, in terms of your audit oversight role it could make sense, as software is replaced/ upgraded, to switch to private CT logging as a substitute for a human role of uploading certs for audit. >From your description it sounds as though GlobalSign reasonably trusts that the assigned AT Employee will provide them with an accurate set of certs, the thing we're protecting against here is accident or mistake, not a malevolent subCA operator which would be very hard to detect this way. Unfortunately this employee (and perhaps one or more deputies) were on leave. If that assessment is correct then software which uses RFC6962 methods to write certs on issuance to a log operated by GlobalSign would satisfy this requirement automatically without a human action. With the log not publicly trusted it could operate a much relaxed policy (e.g. MMD 7 days or even not defined, not publicly accessible) but it would avoid this dependency on a specific person at AT doing a manual step periodically in order for GlobalSign to have sight of issued certificates. With the relative popularity of RFC6962 logging, this becomes an off-the-shelf hook that can be used to support audit roles easily without either manual steps to export the certificates or special modifications to the issuance software. You mentioned EJBCA specifically in this post, and so I verified that as expected EJBCA does provide a means for CA operators to configure a log without also then embedding SCTs in certificates (which might not be desirable for AT's application) Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
