Re: CAs cross-signing roots whose subjects don't comply with the BRs
On Tue, Oct 8, 2019 at 10:04 AM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Unless I found a root that Ryan isn’t referring to, Mozilla Policy 2.1 ( > https://wiki.mozilla.org/CA:CertificatePolicyV2.1) would have been in > force when the root was first issued, so BR compliance would be mandatory > from a Mozilla policy standpoint. Correct. It sounds like you've identified the same (recently added) root, which was issued during Policy 2.1. That is, the BR-violating self-signed version was created 2014-12, added to Mozilla in 2018-10, and the BR-violating cross-signs created 2019-02 and 2019-06. As it sounds like there's at least a consistent view that this is BR violating, I left a comment on the Inclusion Bug, https://bugzilla.mozilla.org/show_bug.cgi?id=1390803#c27 , to ask Wayne and Kathleen how they'd like to proceed. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAs cross-signing roots whose subjects don't comply with the BRs
On 08/10/2019 13:41, Corey Bonnell wrote: On Monday, October 7, 2019 at 10:52:36 AM UTC-4, Ryan Sleevi wrote: I'm curious how folks feel about the following practice: Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). They create this Root Certificate after the effective date of the Baseline Requirements, but prior to Root Programs consistently requiring compliance with the Baseline Requirements (i.e. between 2012 and 2014). This Root Certificate does not comply with the BRs' rules on Subject: namely, it omits the Country field. ... > ... Given that there is discussion about mandating the use of ISO3166 or other databases for location information, the profile of the subjectDN may change such that future cross-signs cannot be done without running afoul of policy. With this issue and Ryan’s scenario in mind, I think there may need to be some sort of grandfathering allowed for roots so that cross-signs can be issued without running afoul of policy. What I’m less certain on, is to what extent this grandfathering clause would allow for non-compliance of the current policies, as that is a very slippery slope and hinders progress in creating a saner webPKI certificate profile. For the CA that Ryan brings up, I’m less inclined to allow for a “grandfathering” as the root certificate in question was originally mis-issued. But for a root certificate that was issued in compliance with the policy at the time but now no longer has a compliant subjectDN, perhaps a carve-out in Mozilla Policy to allow for a cross-sign (using the now non-compliant subjectDN) is warranted. Please note the situation explained in the first paragraph of Ryan's scenario: The (hypothetical) Root 1 without a C element may have been issued before Vrowser Policy made BR compliance mandatory. In other words, BR non-compliance may not have been actual non-compliance at that time. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAs cross-signing roots whose subjects don't comply with the BRs
On Monday, October 7, 2019 at 10:52:36 AM UTC-4, Ryan Sleevi wrote: > I'm curious how folks feel about the following practice: > > Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). They > create this Root Certificate after the effective date of the Baseline > Requirements, but prior to Root Programs consistently requiring compliance > with the Baseline Requirements (i.e. between 2012 and 2014). This Root > Certificate does not comply with the BRs' rules on Subject: namely, it > omits the Country field. > > Later, in 2019, Foo takes their existing Root Certificate ("Root 2"), > included within Mozilla products, and cross-signs the Subject. This now > creates a cross-signed certificate, "Root 1 signed-by Root 2", which has a > Subject field that does not comport with the Baseline Requirements. > > To me, this seems like a clear-cut violation of the Baseline Requirements, > and "Foo" could have pursued an alternative hierarchy to avoid needing to > cross-sign. However, I thought it interesting to solicit others' feedback > on this situation, before opening the CA incident for Foo. It appears there was a few months’ time in between versions 1.0 and 1.1 of the BRs that apparently allowed for omitting the C RDN even if the O was included in the Subject. Having spent some time in Censys.io, it appears that this root in question was not issued during this period so the root certificate in question was mis-issued. However, I think there’s an additional issue that’s worth discussing along with the current topic: how to treat cross-signs for roots that, when originally issued, were compliant with the BRs and Mozilla Policy but now can no longer have their subjectDN embedded in cross-signs due to changes in policy. Given that there is discussion about mandating the use of ISO3166 or other databases for location information, the profile of the subjectDN may change such that future cross-signs cannot be done without running afoul of policy. With this issue and Ryan’s scenario in mind, I think there may need to be some sort of grandfathering allowed for roots so that cross-signs can be issued without running afoul of policy. What I’m less certain on, is to what extent this grandfathering clause would allow for non-compliance of the current policies, as that is a very slippery slope and hinders progress in creating a saner webPKI certificate profile. For the CA that Ryan brings up, I’m less inclined to allow for a “grandfathering” as the root certificate in question was originally mis-issued. But for a root certificate that was issued in compliance with the policy at the time but now no longer has a compliant subjectDN, perhaps a carve-out in Mozilla Policy to allow for a cross-sign (using the now non-compliant subjectDN) is warranted. Thanks, Corey ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAs cross-signing roots whose subjects don't comply with the BRs
On Mon, Oct 7, 2019 at 12:20 PM Jeremy Rowley wrote: > For example, suppose a root was created before a rule went into place and > the root needs to be renewed for some reason. If the root was compliant > before creation and modifying the profile would break something with the > root, then there's a good argument that you shouldn't modify the root > during the resign. That assumes the reasons are discussed here and > alternatives are explored fully. This should then be documented (including > the reasons) in an incident report and the subsequent audit. > For sure. Note that because Root 1's Subject was non-conforming (and pre-BR enforcement, even though post-BR), there's nothing to work around with on that Subject. It, more or less, needs to be retired. It's unfortunate this was missed during the inclusion request, as I think it would have dramatically altered the request: CAs have been rejected for failing to conform to the profile, so it's unfortunate that during the whole process, no one spotted this. However, it "should" have come up during the review prior to cross-signing, which is ostensibly why there's an incident with that CA. The solutions all involve retiring that root (since it can't be cross-signed), or creating a new root, and cross-signing it by two different parents (i.e. it prohibits a linear history). > > Tl;dr - No, CAs shouldn't sign things that violate the BRs, even roots. > But I could see there being reasons for the CA to do so. > > (And I haven't scanned CT to discover if it is us. Crossing my fingers > it's not 😊. If I don't scan, it's like a terrible version of Christmas.) > It's not DigiCert (or its many aquisitions) To your follow-up question: - At least within mozilla::pkix (relevant to Mozilla) and Chrome's handling of CRLSets, revocation is integrated as part of the path building algorithm, allowing alternative paths to be found. However, that's not necessarily the case for other certificate path building and verification libraries, and revocation could have impact. That is, of course, all the more reason that CAs should be extremely diligent in their cross-signs, to avoid creating issues, and to rotate names early and often. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: CAs cross-signing roots whose subjects don't comply with the BRs
For this particular incident, I would like to know why the CA didn’t review the profile before signing the root. It seems like a flaw in the process in the key ceremony process not to go through a checklist with the profile and ensure each field complies with the current version of BRs. Question on browser behavior - will revocation of the cross essentially result in revocation of root 2 since the date is newer? Anyone distributing that cross, will basically see the root as revoked unless they have the root embedded by then, right? -Original Message- From: dev-security-policy On Behalf Of Jeremy Rowley via dev-security-policy Sent: Monday, October 7, 2019 10:21 AM To: r...@sleevi.com Cc: mozilla-dev-security-policy Subject: RE: CAs cross-signing roots whose subjects don't comply with the BRs Yeah - I like the visibility here since I know I often forget to post the incident to the Mozilla list as well as post the bug. IMO - it's up to the CA to decide if they want to sign something in violation of the BRs and then it's up the browsers on what the action taken in response is. I acknowledge this is somewhat a non-answer, but I think if the CA discloses why they are signing something, works with the community to decide the action taken is better than the alternative, accepts the risk to the audit, then they should do it, assuming the risk. The BRs are pretty rigid so there may be circumstances that merit violation of the requirements, but that violation should only be done with as much transparency as possible and considering all the positions. For example, suppose a root was created before a rule went into place and the root needs to be renewed for some reason. If the root was compliant before creation and modifying the profile would break something with the root, then there's a good argument that you shouldn't modify the root during the resign. That assumes the reasons are discussed here and alternatives are explored fully. This should then be documented (including the reasons) in an incident report and the subsequent audit. Tl;dr - No, CAs shouldn't sign things that violate the BRs, even roots. But I could see there being reasons for the CA to do so. (And I haven't scanned CT to discover if it is us. Crossing my fingers it's not 😊. If I don't scan, it's like a terrible version of Christmas.) -Original Message- From: dev-security-policy On Behalf Of Ryan Sleevi via dev-security-policy Sent: Monday, October 7, 2019 10:07 AM To: Jeremy Rowley Cc: mozilla-dev-security-policy Subject: Re: CAs cross-signing roots whose subjects don't comply with the BRs On Mon, Oct 7, 2019 at 11:54 AM Jeremy Rowley wrote: > Are both roots trusted in the Mozilla root store? If so, could you say > that Mozilla has approved of the root not-withstanding the non-compliance? > If root 2 did go through the public review process and had the public > look at the certificate and still got embedded, then Mozilla perhaps > signed off on the root. > Good question! Yes, it turns out that a version of this cross-sign is included, and while there was a public discussion phase, this non-compliance was not detected during the inclusion request nor part of the discussion. In fact, there were zero comments during the public discussion phase. > That said, I don't personally see the harm in incident reports (other > than the fact that they can be used for negative marketing). They are > there for documenting issues and making the public aware of issues. > Like qualified audits, they don't necessarily mean something terrible > since they represent a disclosure/record of some kind. Even if the > incident report is open, discussed, and closed pretty quickly, then > you end up with an a record that can be pointed to. Filing more > incident report (as long as they are different issues) is a good thing > as it gives extra transparency in the CA's operations that is easily > discoverable and catalogable. Makes data analytics easier and you can > go back through the incidents to see how things are changing with the CA. > Well, the reason I raised it here, rather than as an incident, was to try and nail down the expectations here. For example, would it be better to have that discussion on the incident, with "Foo" arguing "You approved it, ergo it's not a violation to cross-sign it"? Or would it be better to have visibility here, perhaps in the abstract (even if it is trivial to scan CT and figure out which CA I'm talking about), if only to get folks expectations here on whether or not new certificates should be signed that violate the BRs? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___
RE: CAs cross-signing roots whose subjects don't comply with the BRs
Yeah - I like the visibility here since I know I often forget to post the incident to the Mozilla list as well as post the bug. IMO - it's up to the CA to decide if they want to sign something in violation of the BRs and then it's up the browsers on what the action taken in response is. I acknowledge this is somewhat a non-answer, but I think if the CA discloses why they are signing something, works with the community to decide the action taken is better than the alternative, accepts the risk to the audit, then they should do it, assuming the risk. The BRs are pretty rigid so there may be circumstances that merit violation of the requirements, but that violation should only be done with as much transparency as possible and considering all the positions. For example, suppose a root was created before a rule went into place and the root needs to be renewed for some reason. If the root was compliant before creation and modifying the profile would break something with the root, then there's a good argument that you shouldn't modify the root during the resign. That assumes the reasons are discussed here and alternatives are explored fully. This should then be documented (including the reasons) in an incident report and the subsequent audit. Tl;dr - No, CAs shouldn't sign things that violate the BRs, even roots. But I could see there being reasons for the CA to do so. (And I haven't scanned CT to discover if it is us. Crossing my fingers it's not 😊. If I don't scan, it's like a terrible version of Christmas.) -Original Message- From: dev-security-policy On Behalf Of Ryan Sleevi via dev-security-policy Sent: Monday, October 7, 2019 10:07 AM To: Jeremy Rowley Cc: mozilla-dev-security-policy Subject: Re: CAs cross-signing roots whose subjects don't comply with the BRs On Mon, Oct 7, 2019 at 11:54 AM Jeremy Rowley wrote: > Are both roots trusted in the Mozilla root store? If so, could you say > that Mozilla has approved of the root not-withstanding the non-compliance? > If root 2 did go through the public review process and had the public > look at the certificate and still got embedded, then Mozilla perhaps > signed off on the root. > Good question! Yes, it turns out that a version of this cross-sign is included, and while there was a public discussion phase, this non-compliance was not detected during the inclusion request nor part of the discussion. In fact, there were zero comments during the public discussion phase. > That said, I don't personally see the harm in incident reports (other > than the fact that they can be used for negative marketing). They are > there for documenting issues and making the public aware of issues. > Like qualified audits, they don't necessarily mean something terrible > since they represent a disclosure/record of some kind. Even if the > incident report is open, discussed, and closed pretty quickly, then > you end up with an a record that can be pointed to. Filing more > incident report (as long as they are different issues) is a good thing > as it gives extra transparency in the CA's operations that is easily > discoverable and catalogable. Makes data analytics easier and you can > go back through the incidents to see how things are changing with the CA. > Well, the reason I raised it here, rather than as an incident, was to try and nail down the expectations here. For example, would it be better to have that discussion on the incident, with "Foo" arguing "You approved it, ergo it's not a violation to cross-sign it"? Or would it be better to have visibility here, perhaps in the abstract (even if it is trivial to scan CT and figure out which CA I'm talking about), if only to get folks expectations here on whether or not new certificates should be signed that violate the BRs? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAs cross-signing roots whose subjects don't comply with the BRs
On 07/10/2019 17:35, Ryan Sleevi wrote: > On Mon, Oct 7, 2019 at 11:26 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 07/10/2019 16:52, Ryan Sleevi wrote: >>> I'm curious how folks feel about the following practice: >>> >>> Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). They >>> create this Root Certificate after the effective date of the Baseline >>> Requirements, but prior to Root Programs consistently requiring >> compliance >>> with the Baseline Requirements (i.e. between 2012 and 2014). This Root >>> Certificate does not comply with the BRs' rules on Subject: namely, it >>> omits the Country field. >> >> Clarification needed: Does it omit Country from the DN of the root 1 >> itself, from the DN of intermediary CA certs and/or from the DN of End >> Entity certs? >> > > It's as I stated: The Subject of the Root Certificate omits the Country > field. You were unclear if Root 1 omitted the C element from it's own name (a BR requirement for new roots), or from various aspects of the issuance from root 1 (also BR requirements). It is now clear that the potential BR violation is only in the DN of Root 1 itself, and for the purpose of this hypothetical, we can assume that all other aspects of Root 1 operation are BR compliant. > > >>> >>> Later, in 2019, Foo takes their existing Root Certificate ("Root 2"), >>> included within Mozilla products, and cross-signs the Subject. This now >>> creates a cross-signed certificate, "Root 1 signed-by Root 2", which has >> a >>> Subject field that does not comport with the Baseline Requirements. >> >> Nit: Signs the Subject => Signs Root 1 >> > > Perhaps it would be helpful if you were clearer about what you believe you > were correcting. > An minor typo (nit) in your original post. You wrote -"signs the Subject" instead of -"signs Root 1". > I thought I was very precise here, so it's useful to understand your > confusion: > > Root 2, a root included in Mozilla products, cross-signs Root 1, a root > which omits the Country field from the Subject. > > This creates a certificate, whose issuer is Root 2 (a Root included in > Mozilla Products), and whose Subject is Root 1. The Subject of Root 1 does > not meet the BRs requirements on Subjects for intermediate/root > certificates: namely, the certificate issued by Root 2 omits the C, because > Root 1 omits the C. > This is now clear after the clarification that C was only omitted in the DN of Root 1 itself. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAs cross-signing roots whose subjects don't comply with the BRs
On Mon, Oct 7, 2019 at 11:54 AM Jeremy Rowley wrote: > Are both roots trusted in the Mozilla root store? If so, could you say > that Mozilla has approved of the root not-withstanding the non-compliance? > If root 2 did go through the public review process and had the public look > at the certificate and still got embedded, then Mozilla perhaps signed off > on the root. > Good question! Yes, it turns out that a version of this cross-sign is included, and while there was a public discussion phase, this non-compliance was not detected during the inclusion request nor part of the discussion. In fact, there were zero comments during the public discussion phase. > That said, I don't personally see the harm in incident reports (other than > the fact that they can be used for negative marketing). They are there for > documenting issues and making the public aware of issues. Like qualified > audits, they don't necessarily mean something terrible since they represent > a disclosure/record of some kind. Even if the incident report is open, > discussed, and closed pretty quickly, then you end up with an a record that > can be pointed to. Filing more incident report (as long as they are > different issues) is a good thing as it gives extra transparency in the > CA's operations that is easily discoverable and catalogable. Makes data > analytics easier and you can go back through the incidents to see how > things are changing with the CA. > Well, the reason I raised it here, rather than as an incident, was to try and nail down the expectations here. For example, would it be better to have that discussion on the incident, with "Foo" arguing "You approved it, ergo it's not a violation to cross-sign it"? Or would it be better to have visibility here, perhaps in the abstract (even if it is trivial to scan CT and figure out which CA I'm talking about), if only to get folks expectations here on whether or not new certificates should be signed that violate the BRs? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: CAs cross-signing roots whose subjects don't comply with the BRs
Are both roots trusted in the Mozilla root store? If so, could you say that Mozilla has approved of the root not-withstanding the non-compliance? If root 2 did go through the public review process and had the public look at the certificate and still got embedded, then Mozilla perhaps signed off on the root. That said, I don't personally see the harm in incident reports (other than the fact that they can be used for negative marketing). They are there for documenting issues and making the public aware of issues. Like qualified audits, they don't necessarily mean something terrible since they represent a disclosure/record of some kind. Even if the incident report is open, discussed, and closed pretty quickly, then you end up with an a record that can be pointed to. Filing more incident report (as long as they are different issues) is a good thing as it gives extra transparency in the CA's operations that is easily discoverable and catalogable. Makes data analytics easier and you can go back through the incidents to see how things are changing with the CA. -Original Message- From: dev-security-policy On Behalf Of Ryan Sleevi via dev-security-policy Sent: Monday, October 7, 2019 9:35 AM To: Jakob Bohm Cc: mozilla-dev-security-policy Subject: Re: CAs cross-signing roots whose subjects don't comply with the BRs On Mon, Oct 7, 2019 at 11:26 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 07/10/2019 16:52, Ryan Sleevi wrote: > > I'm curious how folks feel about the following practice: > > > > Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). > > They create this Root Certificate after the effective date of the > > Baseline Requirements, but prior to Root Programs consistently > > requiring > compliance > > with the Baseline Requirements (i.e. between 2012 and 2014). This > > Root Certificate does not comply with the BRs' rules on Subject: > > namely, it omits the Country field. > > Clarification needed: Does it omit Country from the DN of the root 1 > itself, from the DN of intermediary CA certs and/or from the DN of End > Entity certs? > It's as I stated: The Subject of the Root Certificate omits the Country field. > > > > Later, in 2019, Foo takes their existing Root Certificate ("Root > > 2"), included within Mozilla products, and cross-signs the Subject. > > This now creates a cross-signed certificate, "Root 1 signed-by Root > > 2", which has > a > > Subject field that does not comport with the Baseline Requirements. > > Nit: Signs the Subject => Signs Root 1 > Perhaps it would be helpful if you were clearer about what you believe you were correcting. I thought I was very precise here, so it's useful to understand your confusion: Root 2, a root included in Mozilla products, cross-signs Root 1, a root which omits the Country field from the Subject. This creates a certificate, whose issuer is Root 2 (a Root included in Mozilla Products), and whose Subject is Root 1. The Subject of Root 1 does not meet the BRs requirements on Subjects for intermediate/root certificates: namely, the certificate issued by Root 2 omits the C, because Root 1 omits the C. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAs cross-signing roots whose subjects don't comply with the BRs
On Mon, Oct 7, 2019 at 11:26 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 07/10/2019 16:52, Ryan Sleevi wrote: > > I'm curious how folks feel about the following practice: > > > > Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). They > > create this Root Certificate after the effective date of the Baseline > > Requirements, but prior to Root Programs consistently requiring > compliance > > with the Baseline Requirements (i.e. between 2012 and 2014). This Root > > Certificate does not comply with the BRs' rules on Subject: namely, it > > omits the Country field. > > Clarification needed: Does it omit Country from the DN of the root 1 > itself, from the DN of intermediary CA certs and/or from the DN of End > Entity certs? > It's as I stated: The Subject of the Root Certificate omits the Country field. > > > > Later, in 2019, Foo takes their existing Root Certificate ("Root 2"), > > included within Mozilla products, and cross-signs the Subject. This now > > creates a cross-signed certificate, "Root 1 signed-by Root 2", which has > a > > Subject field that does not comport with the Baseline Requirements. > > Nit: Signs the Subject => Signs Root 1 > Perhaps it would be helpful if you were clearer about what you believe you were correcting. I thought I was very precise here, so it's useful to understand your confusion: Root 2, a root included in Mozilla products, cross-signs Root 1, a root which omits the Country field from the Subject. This creates a certificate, whose issuer is Root 2 (a Root included in Mozilla Products), and whose Subject is Root 1. The Subject of Root 1 does not meet the BRs requirements on Subjects for intermediate/root certificates: namely, the certificate issued by Root 2 omits the C, because Root 1 omits the C. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAs cross-signing roots whose subjects don't comply with the BRs
On 07/10/2019 16:52, Ryan Sleevi wrote: I'm curious how folks feel about the following practice: Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). They create this Root Certificate after the effective date of the Baseline Requirements, but prior to Root Programs consistently requiring compliance with the Baseline Requirements (i.e. between 2012 and 2014). This Root Certificate does not comply with the BRs' rules on Subject: namely, it omits the Country field. Clarification needed: Does it omit Country from the DN of the root 1 itself, from the DN of intermediary CA certs and/or from the DN of End Entity certs? Also is the omission limited to historic certs issued before some date, or also in new certs issued in 2019 (not counting the cross cert below). Later, in 2019, Foo takes their existing Root Certificate ("Root 2"), included within Mozilla products, and cross-signs the Subject. This now creates a cross-signed certificate, "Root 1 signed-by Root 2", which has a Subject field that does not comport with the Baseline Requirements. Nit: Signs the Subject => Signs Root 1 To me, this seems like a clear-cut violation of the Baseline Requirements, and "Foo" could have pursued an alternative hierarchy to avoid needing to cross-sign. However, I thought it interesting to solicit others' feedback on this situation, before opening the CA incident for Foo. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
CAs cross-signing roots whose subjects don't comply with the BRs
I'm curious how folks feel about the following practice: Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). They create this Root Certificate after the effective date of the Baseline Requirements, but prior to Root Programs consistently requiring compliance with the Baseline Requirements (i.e. between 2012 and 2014). This Root Certificate does not comply with the BRs' rules on Subject: namely, it omits the Country field. Later, in 2019, Foo takes their existing Root Certificate ("Root 2"), included within Mozilla products, and cross-signs the Subject. This now creates a cross-signed certificate, "Root 1 signed-by Root 2", which has a Subject field that does not comport with the Baseline Requirements. To me, this seems like a clear-cut violation of the Baseline Requirements, and "Foo" could have pursued an alternative hierarchy to avoid needing to cross-sign. However, I thought it interesting to solicit others' feedback on this situation, before opening the CA incident for Foo. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy