RE: Mozilla Policy Requirements CA Incidents
Speaking from a personal perspective - This all makes sense, and, to be honest, the spectrum/grade idea isn’t a good or robust. Implementing something like that requires too many judgment questions about whether a CA belongs in box x vs. box y and what is the difference between those two boxes. I also get the frustration with certain issues, especially when the pop up among CAs – especially if the rule is well established. I’ve been looking at the root causes of mis-issuance in detail (stating with DigiCert) and so far I’ve found they divide into a few buckets. 1) Where the CA relied on a third party for something and probably shouldn’t have, 2) where there was an internal engineering issue, 3) a manual process went bad, 4) software the CA relied on had an issue, or 5) the CA simply couldn’t/didn’t act in time. From the incidents I’ve categorized so far (still working on all the incidents for all CAs), the biggest buckets seem like engineering issues followed by manual process issues. For example, at DigiCert proper the engineering issues represent about 35% of the issues. (By DigiCert proper, I exclude the Sub CAs and Quovadis systems – this allows me to look exclusively at our internal operations compared to the operations of somewhat separate systems.) The next biggest issue is our failure to move fast enough (30%) followed by manual process problems (24%). DigiCert proper doesn’t use very much third party software in its CA so that tends to be our smallest bucket. The division between these categories is interesting because some are less in control of the CA than others. For example, if primekey has an issue pretty much everyone has an issue since so many CAs use primekey at some level (DigiCert via Quovadis). The division is also somewhat arbitrary and based solely on the filed incident reports. However, what I’m looking for is whether the issues result from human error, insufficient implementation timelines, engineering issues, or software issues. I’m not ready to make a conclusion industry-wide. The trend I’ve noticed at DigiCert is the percent of issues related to DigiCert manual processes is decreasing while the percent of engineering blips is increasing. This is a good trend as it means we are moving away from manual processes and into better automation. What else is interesting is the number of times we’ve had issues with moving too slow has dropped significantly over the last two year, which means we’ve seen substantial improvement in communication and handling of changes in industry standards. The number of issues increased, but I chalk that up to more transparency and scrutiny by the public (a good thing) than worse systems. The net result is a nice report that we’re using internally (and will share externally) that shows where the biggest improvements have been made. We’re also hoping this data shows where we need to concentrate more. Right now, the data is showing more focus on engineering and unit tests to ensure all systems are updated when a guideline changes. So why do I share this data now before it’s ready? Well, I think looking at this information can maybe help define possible solutions. Long and windy, but… One resulting idea is that maybe you could require a report on improvements from each CA based on their issues? The annual audit could include a report similar to the above where the CA looks at the past year of their own mistakes and the other industry issues and evaluates how well they did compared to previous years. This report can also describe how the CA changed their system to comply with any new Mozilla or CAB Forum requirements. What automated process did they put in place to guarantee compliance? This part of the audit report can be used to reflect on the CA operations and make suggestions to the browsers on where they need to improve and where they need to automate. It can also be used to document one area of improvement they need to focus on. Although this doesn’t cure immediate mis-issuances such does give better transparency into what CAs are doing to improve and exactly how they implemented the changes made to the Mozilla policy. A report like this also shifts the burden of dealing with issues to the community instead of the module owners and emphasizes the CA on fixing their systems and learning from mistakes. With the change to WebTrust audits, there’s an opportunity for more free-form reporting that can include this information. And this information has to be fare more interesting than reading about yet another individual who forgot to check a box in CCADB. This is still more reactive than I’d like and sometimes requires a whole year before a CA gives information about the changes made to systems to reflect changes in policy. The report does get people thinking proactively about what they need to do to improve, which may, by itself, be a force for improvement. This also allows the community
Re: Mozilla Policy Requirements CA Incidents
On Mon, Oct 7, 2019 at 7:06 PM Jeremy Rowley wrote: > Interesting. I can't tell with the Netlock certificate, but the other > three non-EKU intermediates look like replacements for intermediates that > were issued before the policy date and then reissued after the compliance > date. The industry has established that renewal and new issuance are > identical (source?), but we know some CAs treat these as different > instances. Source: Literally every time a CA tries to use it as an excuse? :) My question is how we move past “CAs provide excuses”, and at what point the same excuses fall flat? While that's not an excuse, I can see why a CA could have issues with a > renewal compared to new issuance as changing the profile may break the > underlying CA. That was Quovadis’s explanation, although with no detail to support that it would break something, simply that they don’t review the things they sign. Yes, I’m frustrated that CAs continue to struggle with anything that is not entirely supervised. What’s the point of trusting a CA then? However, there's probably something better than "trust" vs. "distrust" or > "revoke" v "non-revoke", especially when it comes to an intermediate. I > guess the question is what is the primary goal for Mozilla? Protect users? > Enforce compliance? They are not mutually exclusive objectives of course, > but the primary drive may influence how to treat issuing CA non-compliance > vs. end-entity compliance. I think a minimum goal is to ensure the CAs they trust are competent and take their job seriously, fully aware of the risk they pose. I am more concerned about issues like this which CAs like QuoVadis acknowledges they would not cause. The suggestion of a spectrum of responses fundamentally suggests root stores should eat the risk caused by CAs flagrant violations. I want to understand why browsers should continue to be left holding the bag, and why every effort at compliance seems to fall on how much the browsers push. Of the four, only Quovadis has responded to the incident with real > information, and none of them have filed the required format or given > sufficient information. Is it too early to say what happens before there is > more information about what went wrong? Key ceremonies are, unfortunately, > very manual beasts. You can automate a lot of it with scripting tools, but > the process of taking a key out, performing a ceremony, and putting things > a way is not automated due to the off-line root and FIPS 140-3 > requirements. Yes, I think it’s appropriate to defer discussing what should happen to these specific CAs. However, I don’t think it’s too early to begin to try and understand why it continues to be so easy to find massive amounts of misissuance, and why policies that are clearly communicated and require affirmative consent is something CAs are still messing up. It suggests trying to improve things by strengthening requirements isn’t helping as much as needed, and perhaps more consistent distrusting is a better solution. In any event, having CAs share the challenges is how we do better. Understanding how the CAs not affected prevent these issues is equally important. We NEED CAs to be better here, so what’s the missing part about why it’s working for some and failing for others? I know it seems extreme to suggest to start distrusting CAs over this, but every single time, it seems there’s a CA communication, affirmative consent, and then failure. The most recent failure to disclose CAs is equally disappointing and frustrating, and it’s not clear we have CAs adequately prepared to comply with 2.7, no matter how much we try. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Mozilla Policy Requirements CA Incidents
Interesting. I can't tell with the Netlock certificate, but the other three non-EKU intermediates look like replacements for intermediates that were issued before the policy date and then reissued after the compliance date. The industry has established that renewal and new issuance are identical (source?), but we know some CAs treat these as different instances. While that's not an excuse, I can see why a CA could have issues with a renewal compared to new issuance as changing the profile may break the underlying CA. Note that revoking these CAs puts the CA back on issuing from the legacy ICA that was issued before the renewal. Depending on the reason for the reissue, that may be a less desirable outcome. I don't have a good answer on what to do in a circumstance like this (and I'm a bit biased probably since we have a relationship with Quovadis). However, there's probably something better than "trust" vs. "distrust" or "revoke" v "non-revoke", especially when it comes to an intermediate. I guess the question is what is the primary goal for Mozilla? Protect users? Enforce compliance? They are not mutually exclusive objectives of course, but the primary drive may influence how to treat issuing CA non-compliance vs. end-entity compliance. Of the four, only Quovadis has responded to the incident with real information, and none of them have filed the required format or given sufficient information. Is it too early to say what happens before there is more information about what went wrong? Key ceremonies are, unfortunately, very manual beasts. You can automate a lot of it with scripting tools, but the process of taking a key out, performing a ceremony, and putting things a way is not automated due to the off-line root and FIPS 140-3 requirements. BTW, I'm really liking how these issues are raised here in bulk by problem. This is a really nice format and gets the community involved in looking at what to do. I think it also helps identify common causes of problems. Jeremy -Original Message- From: dev-security-policy On Behalf Of Ryan Sleevi via dev-security-policy Sent: Monday, October 7, 2019 12:53 PM To: mozilla-dev-security-policy Subject: Mozilla Policy Requirements CA Incidents In light of Wayne's many planned updates as part of version 2.7 of the Mozilla Root Store Policy, and prompted by some folks looking at adding linters, I recently went through and spot-checked some of the Mozilla Policy-specific requirements to see how well CAs are doing at following these. I discovered five issues, below: # Intermediates that do not comply with the EKU requirements In September 2018 [1], Mozilla sent a CA Communications reminding CAs about the changes in Policy 2.6.1. One specific change, called to attention in ACTION 3, required the presence of EKUs for intermediates, and the separation of e-mail and SSL/TLS from the intermediates. This requirement, while new to Mozilla Policy, was not new to publicly trusted CAs, as it matched an existing requirement from Microsoft's Root Program [2]. This requirement was first introduced by Microsoft in July 2015, with their Version 2.0 of their own policy. It's a reasonable expectation to expect that all CAs in both Microsoft and Mozilla's program would have been conforming to the stricter requirement of Microsoft, which goes above-and-beyond the Baseline Requirements. However, Mozilla still allowed a grandfathering in of existing intermediates, setting the new requirement for their policy at 2019-01-01. Mozilla also set forth certain exclusions to account for cross-signing. Despite that, four CAs have violated this requirement in 2019: * Microsoft: https://bugzilla.mozilla.org/show_bug.cgi?id=1586847 * Actalis: https://bugzilla.mozilla.org/show_bug.cgi?id=1586787 * QuoVadis: https://bugzilla.mozilla.org/show_bug.cgi?id=1586792 * NetLock: https://bugzilla.mozilla.org/show_bug.cgi?id=1586795 # Authority Key Identifier issues RFC 5280, Section 4.2.1.1 [3], defines the Authority Key Identifier extension. Within RFC 5280, it states that (emphasis added) The identification MAY be based on ***either*** the key identifier (the subject key identifier in the issuer's certificate) ***or*** the issuer name and serial number. That is, it provides an either/or requirement for this field. Despite this not being captured in the updated ASN.1 module defined in RFC 5912 [4], Mozilla Root Store Policy has, since Version 1.0 [5], included a requirement that CAs MUST NOT issue certificates that have (emphasis added) "incorrect extensions (e.g., SSL certificates that exclude SSL usage, or ***authority key IDs that include both the key ID and the issuer's issuer name and serial number)***;" In examining issuance, I found that one CA, trusted by Mozilla, regularly violates this requirement: * Camerfirma: https://bugzilla.mozilla.org/show_bug.cgi?id=1586860 # Thoughts While I've opened CA incident issues for
Mozilla Policy Requirements CA Incidents
In light of Wayne's many planned updates as part of version 2.7 of the Mozilla Root Store Policy, and prompted by some folks looking at adding linters, I recently went through and spot-checked some of the Mozilla Policy-specific requirements to see how well CAs are doing at following these. I discovered five issues, below: # Intermediates that do not comply with the EKU requirements In September 2018 [1], Mozilla sent a CA Communications reminding CAs about the changes in Policy 2.6.1. One specific change, called to attention in ACTION 3, required the presence of EKUs for intermediates, and the separation of e-mail and SSL/TLS from the intermediates. This requirement, while new to Mozilla Policy, was not new to publicly trusted CAs, as it matched an existing requirement from Microsoft's Root Program [2]. This requirement was first introduced by Microsoft in July 2015, with their Version 2.0 of their own policy. It's a reasonable expectation to expect that all CAs in both Microsoft and Mozilla's program would have been conforming to the stricter requirement of Microsoft, which goes above-and-beyond the Baseline Requirements. However, Mozilla still allowed a grandfathering in of existing intermediates, setting the new requirement for their policy at 2019-01-01. Mozilla also set forth certain exclusions to account for cross-signing. Despite that, four CAs have violated this requirement in 2019: * Microsoft: https://bugzilla.mozilla.org/show_bug.cgi?id=1586847 * Actalis: https://bugzilla.mozilla.org/show_bug.cgi?id=1586787 * QuoVadis: https://bugzilla.mozilla.org/show_bug.cgi?id=1586792 * NetLock: https://bugzilla.mozilla.org/show_bug.cgi?id=1586795 # Authority Key Identifier issues RFC 5280, Section 4.2.1.1 [3], defines the Authority Key Identifier extension. Within RFC 5280, it states that (emphasis added) The identification MAY be based on ***either*** the key identifier (the subject key identifier in the issuer's certificate) ***or*** the issuer name and serial number. That is, it provides an either/or requirement for this field. Despite this not being captured in the updated ASN.1 module defined in RFC 5912 [4], Mozilla Root Store Policy has, since Version 1.0 [5], included a requirement that CAs MUST NOT issue certificates that have (emphasis added) "incorrect extensions (e.g., SSL certificates that exclude SSL usage, or ***authority key IDs that include both the key ID and the issuer's issuer name and serial number)***;" In examining issuance, I found that one CA, trusted by Mozilla, regularly violates this requirement: * Camerfirma: https://bugzilla.mozilla.org/show_bug.cgi?id=1586860 # Thoughts While I've opened CA incident issues for all five incidents, I am concerned that requirements that have been clearly communicated, and reiterated, are violated like this. The one exception to this is Microsoft, which at the time of issuance was not yet a participant in the Mozilla Root CA Program directly, although admittedly, it's concerning that they might have violated their own Root Program requirements. I'm not sure how we can better prevent such situations, especially when they were clearly communicated and affirmatively acknowledged by the CAs in question. I'd be concerned with any suggestions that only rules placed in the Baseline Requirements should be followed; that would quite literally be placing the cart before the horse, since browsers lead the BRs. I'd love to understand people's thoughts about how to handle such situations, and more generally, what can be done to better prevent such situations going forward. [1] https://wiki.mozilla.org/CA/Communications#September_2018_CA_Communication [2] https://aka.ms/rootcert 4.A.10 [3] https://tools.ietf.org/html/rfc5280#section-4.2.1.1 [4] https://tools.ietf.org/html/rfc5912 [5] https://wiki.mozilla.org/CA:CertificatePolicyV1.0 ___ 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org
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: Entrust Root Certification Authority - G4 Inclusion Request
On Monday, July 29, 2019 at 5:22:19 PM UTC-4, Bruce wrote: > We will update section 4.2 and 9.12.3 in the next release of the CPS. The CPS Has been updated to address the above issues, see https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190930-version-36.pdf. ___ 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
