Re: DigiCert-Symantec Announcement
I think the plan at the root level makes sense and is reasonable, at least as far as I think I understand it. (A diagram would be nice.) At the intermediate level, however, I think more detail is needed. I'm especially interested in learning how resilient the cert hierarchy will be should it become necessary to alter the hierarchy in response to an adversarial act or management mishap or PKI community sanction or perhaps even future standards work.I also wonder about the plan to allocate the "economically critical" customer base across the various intermediates. For example, should soda companies, banks, shipping companies, and media sites all be given the same consideration? What about main web sites vs static content servers (CDNs)? What about sites that are important to the economy but aren't necessarily the most popular?My hope is that there will be enough fault tolerance, redundancy, resiliency--call it whatever you like--built in to the system so that we know we have options available should we need them. The extent to which DigiCert can flesh out some of these details will be of benefit to the whole community.From: Jeremy Rowley via dev-security-policySent: Monday, August 21, 2017 12:48 AMTo: mozilla-dev-security-policyReply To: Jeremy RowleySubject: RE: DigiCert-Symantec AnnouncementHi everyone, We’re still progressing towards close and transition. One of the items we are heavily evaluating is the root structure and cross-signings post close. Although the plan is still being finalized, I wanted to provide a community update on the current proposal.Right now, Mozilla post stated that they plan to deprecate Symantec roots for TLS by the end of 2018. We continue to work on a plan to transition all customers using the roots for TLS to another root, likely the DigiCert High Assurance root. We will not cross-sign any Symantec roots, however we will continue using those roots for code signing and client/email certs post close (non-TLS use cases). We also plan on using Symantec roots to cross-sign some of the DigiCert roots to provide ubiquity in non-Mozilla systems and processes. However, this sign will only provide one-way trust, with the ultimate chain in Mozilla being EE-> Issuing CA -> DigiCert root in all cases.DigiCert currently has four operational roots in the Mozilla trust store: Baltimore, Global, Assured ID, and High Assurance. The other roots are some permutation of these four roots that were established for future use cases/rollover (ECC vs. RSA). We already separate operations by Sub CA, with TLS, email, and code signing using different issuing CAs. As mentioned in my previous post, we plan on using multiple Sub CAs chained to the DigiCert roots to further control the population trusted by each Sub CA but have not decided on exact numbers. OV and EV will be limited by Alexa distribution and/or number of customers. DV isn’t readily identifiable by customer and will use a common sub CA.Root separation proves a difficult, yet achievable, task as there are only four operational roots: Baltimore, High Assurance, Global, and Assured ID. Global and High Assurance issue mostly OV/EV certs but do include code signing and client certificates. High Assurance is our EV root and used for both EV code signing certificates and TLS certs. Baltimore is our cross-signed root and used primarily by older Verizon customers. Assured ID is used mostly for code signing and client. However, Assured ID is also our FBCA root, meaning government-issued TLS certificates chain to it. Of course, all TLS certs are issued in accordance with the BRs regardless of root. Looking at the current customer base, our current plan is to issue EV (code and TLS) from High Assurance, OV (code and TLS) from Global. Assured ID will continue as our client certificate and government root. We plan to continue using Symantec roots for code signing and client. We’re still looking into this though. We’d love to separate out the roots more than this, but that’s not likely possible given the current root architecture. If there is a non-cross-signed Symantec root that the browsers are not planning to remove, we’d like to continue using the root to issue high volume DV and device certificates. If this is not possible and Mozilla is still planning on distrusting all Symantec roots, we’ll likely migrate DV certs to a Sub
Re: Draft Security Blog about v2.5 of Root Store Policy
On Thursday, September 7, 2017 at 1:23:17 AM UTC-7, Buschart, Rufus wrote: > I have a question regarding the meaning of: > > > * The latest versions of the WebTrust and ETSI audit criteria are now > > required, and auditors are required to be appropriately qualified. I will delete that sentence in the blog post, because I don't think it's really necessary. > > Will you still accept ETSI TS 102 042 audits or does it mean, you will only > accept ETSI EN 319 411-1 audits? Both are acceptable according to BRG 8.4. mozilla.org/listinfo/dev-security-policy ETSI TS 102 042 audits are still allowed as per https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#audit-criteria Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Idea for a stricter name constraint interpretation
On Thu, Sep 7, 2017 at 5:22 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 07/09/2017 21:00, Ryan Sleevi wrote: > Then there is your suggestion of requiring technically constrained >> >>> SubCAs (that were constrained under a previous set of relevant name >>> types) could survive by subjecting themselves to the massive overhead of >>> satisfying the requirements for an unconstrained SubCA (audits, dual >>> user authentication, specially secured server facilities, geographic >>> redundancy, etc.), where as a constrained SubCA they could operate under >>> normal enterprise internal security rules. >>> >>> >> Yup. >> >> > What do you mean "Yup"? > This is a correct statement about what is currently required of CAs, and is a technically viable and workable solution, albeit one with tradeoffs, and does not require any breaking of compatibility. > The goalposts have not moved at all. > > When you failed to understand the goals outlined in the first two and > last paragraphs of my initial short post, I listed the two purposes > explicitly in my post dated 2017-09-01 06:07 UTC (As "primary problem" > and "secondary problem"). > Respectfully, you are changing the goals as solutions are produced. For example, your notation of primary/secondary fails to consider (or explicitly ignores) the repeated attempts to highlight the principle in https://www.mozilla.org/en-US/about/manifesto/#principle-06 outlined to you. As I highlighted, your proposal (and all variations of it that you've offered so far) fail to meet that. I offered you a variety of suggestions that meet that principle - some of which do not achieve what you value, but do achieve what Mozilla has explicitly valued. At this point, I feel like there's not much productive communication to be made here. I understand your goals. They are ignoring publicly-stated goals and principles, and present compatibility issues, but I wish you the best of luck in demonstrating how your solution can meet those goals. I don't believe you realize you're setting value-based criteria and those values are not shared, nor reasonable, but in any event, you have a solution you believe works, I've offered you several solutions that balance for other values, and it seems profoundly unlikely that you can be convinced that interoperability and standards-compliance is more important in the concrete than an abstract perception of cost that doesn't actually manifestly exist. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PROCERT issues
On Thu, Sep 7, 2017 at 11:17 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Mozilla has decided that there is sufficient concern about the > activities and operations of the CA "PROCERT" to collect together our > list of current concerns. That list can be found here: > https://wiki.mozilla.org/CA:PROCERT_Issues > > Note that this list may expand or reduce over time as issues are > investigated further, with information either from our or our > community's investigations or from PROCERT. > > We expect PROCERT to engage in a public discussion of these issues and > give their comments and viewpoint. We also hope that our community will > make comments, and perhaps provide additional information based on their > own investigations. > > When commenting on these issues, please clearly state which issue you > are addressing on each occasion. The issues have been given identifying > letters to help with this. > > At the end of a public discussion period between Mozilla, our community > and PROCERT, which we hope will be no longer than a couple of weeks, > Mozilla will move to make a decision about the continued trust of > PROCERT, based on the picture which has then emerged. > (Unless stated, wearing a personal hat) Hi Gerv, Do you have an anticipated time period for discussion? That is, what represents a time for which PROCERT may submit feedback to have it considered, and at what point you will consider discussion closed? Based on the information provided, Issue K represents an unconditional security issue, in as much as names such as "autodiscover" and "owaserver" are widely-used domains for Outlook Web Access. Many clients attempt to access resources at this (unqualified) domain, relying on the combination of DNS suffix search and locally-trusted certificates to ensure proper resolution. By issuing a publicly trusted certificate for this name - and then failing to revoke it - represents a critical security risk and arguably a dereliction of responsibility. Combined with Issue D and Issue G, it is questionable as to how it was ever validated, and suggest serious failings over the most critical security control of a CA - which is validation of a domain. Combined with Issue L, Issue Q, Issue R, Issue X, and Issue W, serious questions are raised about the oversight and technical ability of the staff, as these are indicative of serious control failures. Outside of Issue K, I would suggest that Issue O and Issue S show a lack of awareness of developments in the CA ecosystem, as both of these controls were direct responses to widely reported CA security issues. The failure to take appropriate steps - or to appreciate the reasons behind such steps - are indicative of a systematic misunderstanding of the security function of a CA. On the basis of the sum of these issues, it would seem that the criteria in Section 7.3 of Mozilla policy - https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ - is met: "Mozilla will disable or remove a certificate if the CA demonstrates ongoing or egregious practices that do not maintain the expected level of service or that do not comply with the requirements of this policy." ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Idea for a stricter name constraint interpretation
On 07/09/2017 21:00, Ryan Sleevi wrote: On Thu, Sep 7, 2017 at 1:20 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: All but one of your suggestions would require the revocation of existing SubCA certificates, essentially invalidating all existing uses of certificates issued by those SubCAs (Each certificate holder would need to obtain and install at least a new SubCA cert, possibly a complete new end cert). This is not at all an accurate representation of what it would require, but I'm not sure it's worth pointing out the code to you, since I think the broader conversation is whether or not that's a bad thing. While you're presupposing it's objectively bad, you haven't demonstrated that it's an unreasonable requirement. What "code" are you talking about? Surely not computer code, because then there must be something buried in your posts that I haven't spotted. Then there is your suggestion of requiring technically constrained SubCAs (that were constrained under a previous set of relevant name types) could survive by subjecting themselves to the massive overhead of satisfying the requirements for an unconstrained SubCA (audits, dual user authentication, specially secured server facilities, geographic redundancy, etc.), where as a constrained SubCA they could operate under normal enterprise internal security rules. Yup. What do you mean "Yup"? Could you suggest an alternative solution that does not impose such significant costs? Why? You're moving a goalpost as it suits, and that's not a productive line of discussion. To the point that there are multiple ways to address this problem is established. That there are paths forward that avoid radically breaking backwards compatibility is also established. The goalposts have not moved at all. When you failed to understand the goals outlined in the first two and last paragraphs of my initial short post, I listed the two purposes explicitly in my post dated 2017-09-01 06:07 UTC (As "primary problem" and "secondary problem"). For clarity, I consider redistributing a modified SubCA certificate to existing certificate holders in order to meet new compliance rules as an additional compliance requirement. What you haven't stated, but which is clear from your replies, is you view these costs to exceed the cost of breaking backwards compatibility. That's certainly a viewpoint you can take, and I respect your view, but you haven't advanced any arguments to support that, and merely stated it as factual. I hope we can agree there are multiple ways to address the introduction of new nametypes. These different approaches have different tradeoffs for them - revocation, auditing, new functionality, breaking old functionality - and I've presented this multitude in the hopes of demonstrating to you that jumping to a solution which notably runs counter to Mozilla's Principles isn't necessary - there are alternatives. You have failed to list any (non-accidental) old functionality broken by my original suggestion (with appropriate bug fixes such as the one for the Subject distinguished name). So far I have seen you suggest the following approaches: - Revoke existing, previously accepted, SubCA certificates. - Replace and reissue existing SubCA certificates with new ones with a changed value of the name constraints extension, revoking the previous SubCA certificate. - Introduce a new extension that would have to be added to previously issued SubCA certificates, requiring replace, reissue and revoke, but only once rather than each time the requirements change within the SubCA lifetime. - Convert existing, previously accepted, SubCA operations to much higher standards not applicable to their intended use, only to their (unintentional) acceptance as valid for a different name type. My suggestion was a 5th way: - Applications that add new names types (or resurrect old forgotten ones) should consider name constrained SubCAs that don't mention the new name type as not trusted for the new name type. Ditto for root programs that adjust their TCSC definitions to encompass new name types. There is also a 6th way, which I considered too dangerous: - Root programs could grandfather as TCSC existing SubCAs (issued before a cutoff date) that met an older definition of TCSC, without actually making the associated certificate validation code check for the resulting loophole. You may still wish to view a solution that breaks backwards compatibility favorably, and it's unlikely I can convince you otherwise. But I can highlight for those on the list that alternatives do exist, and your solution has notable costs - costs that, in many cases, are deemed unacceptably high. I explicitly stated in my first post that the changed design would need to be checked against the corpus of known public CAs to make sure nothing actually in use is broken. Perhaps the design should also be
Re: Idea for a stricter name constraint interpretation
On Thu, Sep 7, 2017 at 1:20 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All but one of your suggestions would require the revocation of existing > SubCA certificates, essentially invalidating all existing uses of > certificates issued by those SubCAs (Each certificate holder would need > to obtain and install at least a new SubCA cert, possibly a complete new > end cert). > This is not at all an accurate representation of what it would require, but I'm not sure it's worth pointing out the code to you, since I think the broader conversation is whether or not that's a bad thing. While you're presupposing it's objectively bad, you haven't demonstrated that it's an unreasonable requirement. Then there is your suggestion of requiring technically constrained > SubCAs (that were constrained under a previous set of relevant name > types) could survive by subjecting themselves to the massive overhead of > satisfying the requirements for an unconstrained SubCA (audits, dual > user authentication, specially secured server facilities, geographic > redundancy, etc.), where as a constrained SubCA they could operate under > normal enterprise internal security rules. > Yup. > Could you suggest an alternative solution that does not impose such > significant costs? > Why? You're moving a goalpost as it suits, and that's not a productive line of discussion. To the point that there are multiple ways to address this problem is established. That there are paths forward that avoid radically breaking backwards compatibility is also established. What you haven't stated, but which is clear from your replies, is you view these costs to exceed the cost of breaking backwards compatibility. That's certainly a viewpoint you can take, and I respect your view, but you haven't advanced any arguments to support that, and merely stated it as factual. I hope we can agree there are multiple ways to address the introduction of new nametypes. These different approaches have different tradeoffs for them - revocation, auditing, new functionality, breaking old functionality - and I've presented this multitude in the hopes of demonstrating to you that jumping to a solution which notably runs counter to Mozilla's Principles isn't necessary - there are alternatives. You may still wish to view a solution that breaks backwards compatibility favorably, and it's unlikely I can convince you otherwise. But I can highlight for those on the list that alternatives do exist, and your solution has notable costs - costs that, in many cases, are deemed unacceptably high. > You seem to be ignoring my actual arguments and arguing only against > specific words and phrases. Hopefully, you can see from above that I haven't done so at all, but in fact been explaining to you why your proposal is unacceptably costly. It may be simply you disagree. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Idea for a stricter name constraint interpretation
On 01/09/2017 20:07, Ryan Sleevi wrote: On Fri, Sep 1, 2017 at 2:07 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: ... So, from the get-go with the standards, it was possible to name constrain DNS. Unless you were referencing certificates prior to them being bound to domain names, but I can't see how that would be relevant, since the context is about DNS names. Point was that RFC2818 (and RFC2459 which it references for SAN usage) changed the established interpretation of WebPKI certificates from the established Mozilla standard. And that this is an obvious precedent to making such changes. I'm sorry, this is simply factually false. That depends on how you interpret the deprecation of matching against CN only, as was the case at least up to and including Netscape 4.x Browsers (according to old Netscape documentation listing supported standard and Netscape cert extensions). However this whole discussion of the SAN introduction by PKIX was only intended as an example of how such changes (may) have happened in the past. It was prolonged by your repeated use of anachronistic references such as RFC2818. The primary problem is the need to not weaken security for code that starts looking at new (or previously unused) name types after existing PKI restricted CAs have (obviously) not mentioned the "new" type(s) as "deny all" entries in their name restrictions. The secondary problem is not to burden such restricted CAs with additional audit or other compliance requirements when such "new" name types are added to standards such as the CAB/F BRs and the Mozilla root program polices. I gave multiple suggestions on how to avoid both of those. All but one of your suggestions would require the revocation of existing SubCA certificates, essentially invalidating all existing uses of certificates issued by those SubCAs (Each certificate holder would need to obtain and install at least a new SubCA cert, possibly a complete new end cert). Then there is your suggestion of requiring technically constrained SubCAs (that were constrained under a previous set of relevant name types) could survive by subjecting themselves to the massive overhead of satisfying the requirements for an unconstrained SubCA (audits, dual user authentication, specially secured server facilities, geographic redundancy, etc.), where as a constrained SubCA they could operate under normal enterprise internal security rules. Could you suggest an alternative solution that does not impose such significant costs? Indeed, I am just trying to see those very requirements from the perspective of the already deployed PKI and its subscribers being the "existing users" for which interop needs to be ensured. Unfortunately, I do not believe you are succeeding in doing so through proposing semantic changes. You seem to be ignoring my actual arguments and arguing only against specific words and phrases. 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
PROCERT issues
Mozilla has decided that there is sufficient concern about the activities and operations of the CA "PROCERT" to collect together our list of current concerns. That list can be found here: https://wiki.mozilla.org/CA:PROCERT_Issues Note that this list may expand or reduce over time as issues are investigated further, with information either from our or our community's investigations or from PROCERT. We expect PROCERT to engage in a public discussion of these issues and give their comments and viewpoint. We also hope that our community will make comments, and perhaps provide additional information based on their own investigations. When commenting on these issues, please clearly state which issue you are addressing on each occasion. The issues have been given identifying letters to help with this. At the end of a public discussion period between Mozilla, our community and PROCERT, which we hope will be no longer than a couple of weeks, Mozilla will move to make a decision about the continued trust of PROCERT, based on the picture which has then emerged. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Draft Security Blog about v2.5 of Root Store Policy
Hello Kathleen! Thank you for sharing your draft version. I have a question regarding the meaning of: > * The latest versions of the WebTrust and ETSI audit criteria are now > required, and auditors are required to be appropriately qualified. Will you still accept ETSI TS 102 042 audits or does it mean, you will only accept ETSI EN 319 411-1 audits? Both are acceptable according to BRG 8.4. With best regards, Rufus Buschart Siemens AG Information Technology Human Resources PKI / Trustcenter GS IT HR 7 4 Hugo-Junkers-Str. 9 90411 Nuernberg, Germany Tel.: +49 1522 2894134 mailto:rufus.busch...@siemens.com www.siemens.com/ingenuityforlife -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+rufus.buschart=siemens@lists.mozilla.org] On Behalf Of Kathleen Wilson via dev-security-policy Sent: Mittwoch, 6. September 2017 20:23 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Draft Security Blog about v2.5 of Root Store Policy All, Here is a draft of a security blog about version 2.5 of Mozilla's Root Store Policy. I will greatly appreciate constructive feedback about it. Thanks, Kathleen == Mozilla Releases Version 2.5 of Root Store Policy == Recently, Mozilla released version 2.5 of our Root Store Policy, which continues our efforts to improve standards and reinforce public trust in the security of the Web. We are grateful to all those in the security and Certificate Authority (CA) communities who contributed constructively to the discussions surrounding the new provisions. The changes of greatest note in version 2.5 of our Root Store Policy are as follows: * CAs are required to follow industry best practice for securing their networks, for example by conforming to the CA/Browser Forum’s Network Security Guidelines or a successor document. * CAs are required to use only those methods of domain ownership validation which are specifically documented in the CA/Browser Forum’s Baseline Requirements 1.4.1. * Additional requirements were added for intermediate certificates that are used to sign certificates for S/MIME. In particular, such intermediate certificates must be name constrained in order to be considered technically-constrained and exempt from being audited and disclosed on the Common CA Database. * Clarified that point-in-time audit statements do not replace the required period-of-time assessments. Mozilla continues to require full-surveillance period-of-time audits that must be conducted annually, and successive audit periods must be contiguous. * Clarified the information that must be provided in each audit statement, including the distinguished name and SHA-256 fingerprint for each root and intermediate certificate in scope of the audit. * CAs are required to follow and be aware of discussions in the mozilla.dev.security.policy forum, where Mozilla's root program is coordinated, although they are not required to participate. * The latest versions of the WebTrust and ETSI audit criteria are now required, and auditors are required to be appropriately qualified. * CAs are required at all times to operate in accordance with the applicable Certificate Policy (CP) and Certificate Practice Statement (CPS) documents, which must be reviewed and updated at least once every year. * Our policy on root certificates being transferred from one organization or location to another has been updated and included in the main policy. Trust is not transferable; Mozilla will not automatically trust the purchaser of a root certificate to the level it trusted the previous owner. The differences between versions 2.5 and 2.4.1 may be viewed on Github. (Version 2.4.1 contained exactly the same normative requirements as version 2.4 but was completely reorganized.) As always, we re-iterate that participation in Mozilla’s CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Mozilla Security Team == ___ 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
