Re: Google Trust Services roots
On 10/02/2017 05:42, Ryan Sleevi wrote: On Thu, Feb 9, 2017 at 3:39 PM, Jakob Bohm via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Additional issue #2: The information at https://pki.goog/ about how to report misissuance directs visitors to a generic reporting page for code vulnerabilities, which (by their nature) tends to require reaction times measured in days/weeks rather than the 1 day maximum specified in Google's CPS. (To be clear, I am responding only as an individual, neither as Mozilla peer or Google employee, although I recognize you will likely disregard my remarks regardless.) In the past, such comments have generally been seen as offtopic/accusatory, because they are inherently absent of evidence of any malfeasance. Indeed, your very comment seems to suggest that Google is not adhering to its CP/CPS, but without evidence, and such implication comes not based on any action that Google has taken, but based on your view of what 'others' do or the 'class' of bugs. I highlight this because we (the community) see the occasional remark like this; most commonly, it's directed at organizations in particular countries, on the basis that we shouldn't trust "them" because they're in one of "those countries". However, the Mozilla policy is structured to provide objective criteria and assessments of that. In this case, I do not believe you are being accurate or fair to present it as an "issue"; you are implying that Google will not adhere to its CP/CPS, but without evidence. The nature of incident reporting via this method may indeed be risky, but it's neither forbidden nor intrinsically wrong. If you look at many members in the Mozilla program, you will see far less specificity as to a problem report and the acceptable means of reporting this. For clarity, I was pointing out that GTS seems to have chosen a method likely to fail if an when actually needed, due to the typical dynamics of large human organizations. Presumably an organization of such magnitude is likely to have contact points more dedicated to time-sensitive action-required messages than the contact point they chose. So while it's useful for you to draw attention to this, it's without evidence or basis for you to suggest that this is an "issue", per se - that is, it seemingly in no way conflicts with Mozilla policy or industry practice. I find that it is an issue, but not an absolute cause for rejection. 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: Google Trust Services roots
On Thu, Feb 9, 2017 at 9:56 PM, Richard Wang via dev-security-policy wrote: > I can't see this sentence > " I highlight this because we (the community) see the occasional remark like > this; most commonly, it's directed at organizations in particular countries, > on the basis that we shouldn't trust "them" because they're in one of "those > countries". However, the Mozilla policy is structured to provide objective > criteria and assessments of that." > has any relationship with this topic, please advise, thanks. I think the point is that issues raised about CAs need to be grounded in fact. "Universal Trust Services wrote Y in their CPS but did not do Y as demonstrated by Z" is something that can be evaluated factually "UTS wrote Y in their CPS but might not being doing Y" without any evidence is not something that can be evaluated factually. I agree with Ryan; we tend to see the second type of issue come up more often with CAs from certain countries. This sort of non-data driven issue is not appropriate to raise. Instead show what should have happened and what did not. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)
I think Mozilla should have a very clear policy for: (1) If a company that not a public trusted CA acquired a trusted root key, what the company must do? (2) If a company is a public trusted CA that acquired a trusted root key, what the company must do? (3) If a company is a public trusted CA, but distrusted by Mozilla, this company acquired a trusted root key, what the company must do? Thanks. Best Regards, Richard -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On Behalf Of Peter Bowen via dev-security-policy Sent: Friday, February 10, 2017 1:10 PM To: Gervase Markham Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots) On Thu, Feb 9, 2017 at 7:41 AM, Gervase Markham via dev-security-policy wrote: > On 09/02/17 14:32, Gijs Kruitbosch wrote: >> Would Mozilla's root program consider changing this requirement so >> that it *does* require public disclosure, or are there convincing >> reasons not to? At first glance, it seems like 'guiding' CAs towards >> additional transparency in the CA market/industry/... might be >> helpful to people outside Mozilla's root program itself. > > This would require CAs and companies to disclose major product plans > publicly well in advance of the time they would normally disclose them. > I won't dig out the dates myself, or check the emails, but if you look > for the following dates from publicly-available information: > > A) The date Google took control of the GlobalSign roots > B) The date Google publicly announced GTS > > you will see there's quite a big delta. If you assume Google told > Mozilla about event A) before it happened, then you can see the problem. Google says they took control on 11 August 2016. On 19 October 2016, Google publicly stated "Update on the Google PKI: new roots were generated and web trust audits were performed, the report on this is forthcoming," (https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Google) Google didn't file with Mozilla until 22 December 2016, and I suspect that was only because I happened to run across their staged website: https://twitter.com/pzb/status/812103974220222465 I appreciate the business realities of pre-disclosure, but that is not the case here. There is no excuse for having taken control of existing roots and not disclosing such once they disclosed that they are intending to become a root CA. Thanks, Peter ___ 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: Google Trust Services roots
I can't see this sentence " I highlight this because we (the community) see the occasional remark like this; most commonly, it's directed at organizations in particular countries, on the basis that we shouldn't trust "them" because they're in one of "those countries". However, the Mozilla policy is structured to provide objective criteria and assessments of that." has any relationship with this topic, please advise, thanks. Best Regards, Richard -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On Behalf Of Ryan Sleevi via dev-security-policy Sent: Friday, February 10, 2017 12:43 PM To: Jakob Bohm Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Google Trust Services roots On Thu, Feb 9, 2017 at 3:39 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Additional issue #2: The information at https://pki.goog/ about how to > report misissuance directs visitors to a generic reporting page for > code vulnerabilities, which (by their nature) tends to require > reaction times measured in days/weeks rather than the 1 day maximum > specified in Google's CPS. > (To be clear, I am responding only as an individual, neither as Mozilla peer or Google employee, although I recognize you will likely disregard my remarks regardless.) In the past, such comments have generally been seen as offtopic/accusatory, because they are inherently absent of evidence of any malfeasance. Indeed, your very comment seems to suggest that Google is not adhering to its CP/CPS, but without evidence, and such implication comes not based on any action that Google has taken, but based on your view of what 'others' do or the 'class' of bugs. I highlight this because we (the community) see the occasional remark like this; most commonly, it's directed at organizations in particular countries, on the basis that we shouldn't trust "them" because they're in one of "those countries". However, the Mozilla policy is structured to provide objective criteria and assessments of that. In this case, I do not believe you are being accurate or fair to present it as an "issue"; you are implying that Google will not adhere to its CP/CPS, but without evidence. The nature of incident reporting via this method may indeed be risky, but it's neither forbidden nor intrinsically wrong. If you look at many members in the Mozilla program, you will see far less specificity as to a problem report and the acceptable means of reporting this. So while it's useful for you to draw attention to this, it's without evidence or basis for you to suggest that this is an "issue", per se - that is, it seemingly in no way conflicts with Mozilla policy or industry practice. ___ 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: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)
On Thu, Feb 9, 2017 at 7:41 AM, Gervase Markham via dev-security-policy wrote: > On 09/02/17 14:32, Gijs Kruitbosch wrote: >> Would Mozilla's root program consider changing this requirement so that >> it *does* require public disclosure, or are there convincing reasons not >> to? At first glance, it seems like 'guiding' CAs towards additional >> transparency in the CA market/industry/... might be helpful to people >> outside Mozilla's root program itself. > > This would require CAs and companies to disclose major product plans > publicly well in advance of the time they would normally disclose them. > I won't dig out the dates myself, or check the emails, but if you look > for the following dates from publicly-available information: > > A) The date Google took control of the GlobalSign roots > B) The date Google publicly announced GTS > > you will see there's quite a big delta. If you assume Google told > Mozilla about event A) before it happened, then you can see the problem. Google says they took control on 11 August 2016. On 19 October 2016, Google publicly stated "Update on the Google PKI: new roots were generated and web trust audits were performed, the report on this is forthcoming," (https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Google) Google didn't file with Mozilla until 22 December 2016, and I suspect that was only because I happened to run across their staged website: https://twitter.com/pzb/status/812103974220222465 I appreciate the business realities of pre-disclosure, but that is not the case here. There is no excuse for having taken control of existing roots and not disclosing such once they disclosed that they are intending to become a root CA. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On Thu, Feb 9, 2017 at 3:39 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Additional issue #2: The information at https://pki.goog/ about how to > report misissuance directs visitors to a generic reporting page for > code vulnerabilities, which (by their nature) tends to require reaction > times measured in days/weeks rather than the 1 day maximum specified > in Google's CPS. > (To be clear, I am responding only as an individual, neither as Mozilla peer or Google employee, although I recognize you will likely disregard my remarks regardless.) In the past, such comments have generally been seen as offtopic/accusatory, because they are inherently absent of evidence of any malfeasance. Indeed, your very comment seems to suggest that Google is not adhering to its CP/CPS, but without evidence, and such implication comes not based on any action that Google has taken, but based on your view of what 'others' do or the 'class' of bugs. I highlight this because we (the community) see the occasional remark like this; most commonly, it's directed at organizations in particular countries, on the basis that we shouldn't trust "them" because they're in one of "those countries". However, the Mozilla policy is structured to provide objective criteria and assessments of that. In this case, I do not believe you are being accurate or fair to present it as an "issue"; you are implying that Google will not adhere to its CP/CPS, but without evidence. The nature of incident reporting via this method may indeed be risky, but it's neither forbidden nor intrinsically wrong. If you look at many members in the Mozilla program, you will see far less specificity as to a problem report and the acceptable means of reporting this. So while it's useful for you to draw attention to this, it's without evidence or basis for you to suggest that this is an "issue", per se - that is, it seemingly in no way conflicts with Mozilla policy or industry practice. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 09/02/2017 20:55, Ryan Hurst wrote: Peter, Thank you very much for your, as always, thorough review. Let me start by saying I agree there is an opportunity for improving the policies around how key transfers such your recent transfer and Google's are handled. It is my hope we can, through our respective recent experiences performing such transfers, help Mozilla revise their policy to provide better guidance for such cases in the future. As for your specific questions, my responses follow: pzb: First, according to the GTS website, there is no audit using the WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL. However the two roots in the Mozilla CA program currently are EV enabled and at least one subordinate CA under them is issuing EV certificates. rmh: Prior to our final stage of the acquisition we contacted both Mozilla and Microsoft about this particular situation. Additional issue #1: Apparently, GlobalSign has not updated its website with the fact that GlobalSign root R2 is no longer operated by GlobalSign, see for example https://support.globalsign.com/customer/en/portal/articles/1426602-globalsign-root-certificates .. Also looking at the GlobalSign website I saw no obvious press release regarding this transfer, the closest I could find was the following, which seems kind of misleading, as it mentions new EV certs chaining to GlobalSign R3 instead of R2, but not the fact that R2 is no longer a GlobalSign root: https://support.globalsign.com/customer/portal/articles/2580816-ev-ssl-intermediate-and-root-changes Additional issue #2: The information at https://pki.goog/ about how to report misissuance directs visitors to a generic reporting page for code vulnerabilities, which (by their nature) tends to require reaction times measured in days/weeks rather than the 1 day maximum specified in Google's CPS. 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: Taiwan GRCA Root Renewal Request
Kathleen Wilson於 2017年2月3日星期五 UTC+8上午6時36分54秒寫道: > On Tuesday, December 13, 2016 at 2:36:15 PM UTC-8, Kathleen Wilson wrote: > > Thanks to all of you who have reviewed and commented on this request from > > Government of Taiwan, Government Root Certification Authority (GRCA), to > > include their renewed Government Root Certification Authority root > > certificate, and turn on the Websites and Email trust bits. > > > > To summarize this discussion so far, two primary concerns have been raised, > > as follows. > > > > 1) There are several intermediate certificates that are technically capable > > of issuing TLS certificates, but have not been audited according to the > > BRs. This is a show-stopper. > > > > Reference: > > https://wiki.mozilla.org/CA:BaselineRequirements#Whole-Population_Audit_of_Intermediate_Certs > > “BR Audits must always include the whole-population audit of intermediate > > certificates that are capable of issuing SSL certs.” > > > > This means that if the intermediate certificate is not technically > > constrained via EKU (and name constraints) then it must be audited > > according to the BRs. > > > > We have resolved this particular situation in the past by having the CA get > > an audit statement saying that the intermediate certificate has not issued > > TLS certificates during the audit period. And requiring that the CA get > > such an audit statement annually. > > > > The CA has been working with their auditor to get an appropriate audit > statement that covers all of the intermediate certs chaining up to this root. > In accordance with Kathleen's advice, our auditor has provided such a audit statement.(https://bug1065896.bmoattachments.org/attachment.cgi?id=8835815) > > > > 2) The new root certificate has the same exact full distinguished name as > > the old root certificate. I think this is OK. > > > > The CA tested this with Firefox, and provided their test results: > > https://bugzilla.mozilla.org/attachment.cgi?id=8818360 > > > > The new root cert having the same DN as the old root cert appears to work > from a technical standpoint (i.e. mozilla::pkix will find the right path if > all necessary certificates are present). However, the duplicate names have > already caused unnecessary confusion: > https://bugzilla.mozilla.org/show_bug.cgi?id=1304264 > > This "new" root certificate was created in 2012, is included in Microsoft's > program, and has several active intermediate certs. So it might not be > reasonable to ask the CA to generate a new root certificate at this point in > time. However, I urge the CA to take note, and not repeat this with the next > generation of their root certificate. > > Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Thursday, 9 February 2017 03:08:14 UTC, Ryan Sleevi wrote: > 19) Can you confirm that Certsuperior, Certisign, CrossCert, and Certisur > are the only Delegated Third Parties utilized by Symantec, across all > Symantec operated CAs that are trusted by Mozilla products? Maybe Ryan has better information than me, but I had assumed that in practice all the companies identified on their site as Symantec "Affiliates" offering SSL are or have been Delegated Third Parties under the BRs. https://forms.ws.symantec.com/verisign-worldwide/index.html I confess that I reached this supposition by Googling "Symantec Crosscert" and thinking about what I found, rather than through deep knowledge of Symantec's business or direct personal information. Symantec provides the following links for "affiliates" offering SSL https://www.acs.altech.co.za/symantec-pki https://www.egypttrust.com/ http://www.comsign.co.il/ http://www.verisign.co.jp/ http://www.crosscert.com/ http://www.itrus.com.cn/ http://www.msctrustgate.com/ http://www.mysecuresign.com/ http://www.niftetrust.com/ http://www.safescrypt.com/ http://www.adacom.com/ http://www.skyrr.is/ http://www.telefonica.es/ http://www.trustitalia.it/ http://www.certsuperior.com/ http://www.certisign.com.br/ http://www.certisur.com/ http://www.e-sign.cl/ Some of those were on Ryan's list above already, and some are defunct, but despite language barriers I think I was able to determine that some of the others are selling Symantec certificates. I suppose it's possible that they're merely acting as resellers and all validation etc. is done by Symantec, but I wanted to flag it up. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
Ryan, Thank you for the quick reply. My comments and questions are inline. On Thu, Feb 9, 2017 at 11:55 AM, Ryan Hurst via dev-security-policy wrote: > Peter, > > Thank you very much for your, as always, thorough review. > > Let me start by saying I agree there is an opportunity for improving the > policies around how key transfers such your recent transfer and Google's are > handled. > > It is my hope we can, through our respective recent experiences performing > such transfers, help Mozilla revise their policy to provide better guidance > for such cases in the future. Where I see opportunities below, I'm marking them with "Policy Suggestion". > As for your specific questions, my responses follow: > > pzb: First, according to the GTS website, there is no audit using the > WebTrust Principles and Criteria for Certification Authorities – Extended > Validation SSL. However the two roots in the Mozilla CA program currently > are EV enabled and at least one subordinate CA under them is issuing EV > certificates. > > rmh: Prior to our final stage of the acquisition we contacted both Mozilla > and Microsoft about this particular situation. > > At this time, we do not have any interest in the issuance of EV SSL > certificates, however GlobalSign does. Based on our conversations with > representatives from both organizations we were told that since: > - The EV OID associated with this permission is associated with GlobalSign > and not Google and, > - GlobalSign is active member in good standing with the respective root > programs and, > - Google will not be issuing EV SSL certificates, > - Google will operate these roots under their own CP/CPS’s and associated > OIDs, > - Google issuing a certificate with the GlobalSign OIDs would qualify as > miss-issuance. Mozilla recognizes 2.23.140.1.1 as being a valid OID for EV certificates for all EV-enabled roots (https://bugzilla.mozilla.org/show_bug.cgi?id=1243923). 1) Do you consider it mis-issuance for Google to issue a certificate containing the 2.23.140.1.1 OID? Policy Suggestion A) When transferring a root that is EV enabled, it should be clearly stated whether the recipient of the root is also receiving the EV policy OID(s). > That it would be acceptable for us not to undergo a EV SSL audit, and that > GlobalSign could keep the EV right for the associated subordinate CA for the > remaining validity period to facilitate the transition (assuming continued > compliance). > > As a former manager of a root program, this seems an appropriate position to > take. And as one who has been involved in several such root transfers I think > differences in intended use are common enough that they should be explicitly > handled by policy. > > pzb: Second, according to the GTS CPS v1.3, "Between 11 August 2016 and 8 > December 2016, Google Inc. operated these Roots according to Google Inc.’s > Certification Practice Statement." The basic WebTrust for CA and WebTrust BR > audit reports for the period ending September 30, 2016 explicitly state they > are for "subordinate CA under external Root CA" and do not list the roots in > the GTS CPS at all. > > rmh: I believe this will be answered by my responses to your third and fourth > observations. It was not. 2) Will Google be publishing an audit report for a period starting 11 August 2016 that covers the transferred GS roots? If so, can you estimate the end of period date? > pzb: Third, the Google CPS says Google took control of these roots on August > 11, 2016. The Mozilla CA policy explicitly says that a bug report must be > filed to request to be included in the Mozilla CA program. It was not until > December 22, 2016 that Google requested inclusion as a CA in Mozilla's CA > program (https://bugzilla.mozilla.org/show_bug.cgi?id=1325532). This does > not appear to align with Mozilla requirements for public disclosure. > > rmh: As has been mentioned, timing for a transaction like this is very > complicated. The process of identifying candidates that could meet our needs > took many months with several false starts with different organizations. That > said, prior to beginning this process we proactively reached out to both > Microsoft and Mozilla root programs to let them know we were beginning the > process. Once it looked like we would be able to come to an agreement with > GlobalSign we again reached out and notified both programs of our intent to > secure these specific keys. Then once the transaction was signed we again > notified the root programs that the deal was done. > > As you know the process to ensure a secure, audited and well structured key > migration is also non-trivial. Once this migration was performed we again > notified both root programs. > > Our intention was to notify all parties, including the public, shortly after > the transfer but it took some time for our auditors, for reasons unrelated to > our audit, to produce the associated audit letters.
Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban
On 09/02/2017 18:20, Jakob Bohm wrote: On 09/02/2017 10:59, Gervase Markham wrote: On 08/02/17 11:25, Jakob Bohm wrote: My logic is that adding additional entropy to a serial number whose length is fully controlled by CA procedures can increase the mitigations against SHA-1 weaknesses. For example if the existing CA setup uses all bits of the old serial number length for non-random values, then the required 64 random bits can simply be appended or prepended. Requiring randomness in the serial number is only appropriate when some of the certificate contents are attacker-controlled. This is not true for an intermediate issued by a CA. And if the CA is an attacker, restricting them to a serial number of the same length (i.e. not arbitrary) makes it harder for them to engineer a collision. Gerv However as a best practice, a CA may establish internal countermeasures involving adding entropy even for internal requests for intermediary certificates. My proposal was to simply not ban that. For external requests, the issue would be if a specific CA certificate was previously used to sign certificates whose serial number consisted of e.g. a 128 bit internally computed value (such as AES128(fixed key, counter)) and a few bits of fresh entropy (such as 20 bits), then moving to to the higher requirement of 64 fresh CSPRNG bits might be best implemented (for some such CA) by changing to those same 128 bits (for continued uniqueness), plus 64 bits of CSPRNG output. Again my proposal was not to ban that. More generally, there might be a Mozilla policy requirement that the length should be fixed in the (updated) CP/CPS, and the serial number should be mostly generated by the issuing CA (except for cross-certs). Strike that exception, the serial number is not dictated by the requester, even for cross-certs. While such length-growing security improvements might be hampered by the need to support legacy parties with hard limits on serial number length, that would be for each CA to consider and decide. 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: Talk at FOSDEM
Thank you for the link, Gerv. That was a very interesting watch. Curious correlation [post video] between Earnst and Young re:Wosign and Earnst and Young re: CrossCert (although I assume this CrossCert relationship was only forthcoming after your talk). And the gent around the 38 minute mark turning the lights off as you where talking was somewhat amusing (sorry) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
Peter, Thank you very much for your, as always, thorough review. Let me start by saying I agree there is an opportunity for improving the policies around how key transfers such your recent transfer and Google's are handled. It is my hope we can, through our respective recent experiences performing such transfers, help Mozilla revise their policy to provide better guidance for such cases in the future. As for your specific questions, my responses follow: pzb: First, according to the GTS website, there is no audit using the WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL. However the two roots in the Mozilla CA program currently are EV enabled and at least one subordinate CA under them is issuing EV certificates. rmh: Prior to our final stage of the acquisition we contacted both Mozilla and Microsoft about this particular situation. At this time, we do not have any interest in the issuance of EV SSL certificates, however GlobalSign does. Based on our conversations with representatives from both organizations we were told that since: - The EV OID associated with this permission is associated with GlobalSign and not Google and, - GlobalSign is active member in good standing with the respective root programs and, - Google will not be issuing EV SSL certificates, - Google will operate these roots under their own CP/CPS’s and associated OIDs, - Google issuing a certificate with the GlobalSign OIDs would qualify as miss-issuance. That it would be acceptable for us not to undergo a EV SSL audit, and that GlobalSign could keep the EV right for the associated subordinate CA for the remaining validity period to facilitate the transition (assuming continued compliance). As a former manager of a root program, this seems an appropriate position to take. And as one who has been involved in several such root transfers I think differences in intended use are common enough that they should be explicitly handled by policy. pzb: Second, according to the GTS CPS v1.3, "Between 11 August 2016 and 8 December 2016, Google Inc. operated these Roots according to Google Inc.’s Certification Practice Statement." The basic WebTrust for CA and WebTrust BR audit reports for the period ending September 30, 2016 explicitly state they are for "subordinate CA under external Root CA" and do not list the roots in the GTS CPS at all. rmh: I believe this will be answered by my responses to your third and fourth observations. pzb: Third, the Google CPS says Google took control of these roots on August 11, 2016. The Mozilla CA policy explicitly says that a bug report must be filed to request to be included in the Mozilla CA program. It was not until December 22, 2016 that Google requested inclusion as a CA in Mozilla's CA program (https://bugzilla.mozilla.org/show_bug.cgi?id=1325532). This does not appear to align with Mozilla requirements for public disclosure. rmh: As has been mentioned, timing for a transaction like this is very complicated. The process of identifying candidates that could meet our needs took many months with several false starts with different organizations. That said, prior to beginning this process we proactively reached out to both Microsoft and Mozilla root programs to let them know we were beginning the process. Once it looked like we would be able to come to an agreement with GlobalSign we again reached out and notified both programs of our intent to secure these specific keys. Then once the transaction was signed we again notified the root programs that the deal was done. As you know the process to ensure a secure, audited and well structured key migration is also non-trivial. Once this migration was performed we again notified both root programs. Our intention was to notify all parties, including the public, shortly after the transfer but it took some time for our auditors, for reasons unrelated to our audit, to produce the associated audit letters. Once we received said letters, we then filed the bugs. This is, although not our ideal timeline, and based on our understanding, in compliance with the Mozilla root program in that since these roots were already members they did not require us to publicly disclose the above negotiation, contracting, planning, migration and other intermediate steps. pzb: Fourth, the audit reports linked in the bug explicitly set the scope of "subordinate CA operated under external Root CA" and do not include any indication of controls around the issuance of subordinate CA certificates. These audit reports do not have an appropriate scope for a root CA. rmh: Yes, we were also concerned about this topic, especially with the recent scope issues with audits. As such, we discussed this with both our auditors, and the the root programs prior to acquisition of the key material. When looking at this issue it is important to keep in mind Google has operated a WebTrust audit
Re: Google Trust Services roots
Peter, Thank you very much for your, as always, thorough review. Let me start by saying I agree there is an opportunity for improving the policies around how key transfers such your recent transfer and Google's are handled. It is my hope we can, through our respective recent experiences performing such transfers, help Mozilla revise their policy to provide better guidance for such cases in the future. As for your specific questions, my responses follow: pzb: First, according to the GTS website, there is no audit using the WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL. However the two roots in the Mozilla CA program currently are EV enabled and at least one subordinate CA under them is issuing EV certificates. rmh: Prior to our final stage of the acquisition we contacted both Mozilla and Microsoft about this particular situation. At this time, we do not have any interest in the issuance of EV SSL certificates, however GlobalSign does. Based on our conversations with representatives from both organizations we were told that since: - The EV OID associated with this permission is associated with GlobalSign and not Google and, - GlobalSign is active member in good standing with the respective root programs and, - Google will not be issuing EV SSL certificates, - Google will operate these roots under their own CP/CPS’s and associated OIDs, - Google issuing a certificate with the GlobalSign OIDs would qualify as miss-issuance. That it would be acceptable for us not to undergo a EV SSL audit, and that GlobalSign could keep the EV right for the associated subordinate CA for the remaining validity period to facilitate the transition (assuming continued compliance). As a former manager of a root program, this seems an appropriate position to take. And as one who has been involved in several such root transfers I think differences in intended use are common enough that they should be explicitly handled by policy. pzb: Second, according to the GTS CPS v1.3, "Between 11 August 2016 and 8 December 2016, Google Inc. operated these Roots according to Google Inc.’s Certification Practice Statement." The basic WebTrust for CA and WebTrust BR audit reports for the period ending September 30, 2016 explicitly state they are for "subordinate CA under external Root CA" and do not list the roots in the GTS CPS at all. rmh: I believe this will be answered by my responses to your third and fourth observations. pzb: Third, the Google CPS says Google took control of these roots on August 11, 2016. The Mozilla CA policy explicitly says that a bug report must be filed to request to be included in the Mozilla CA program. It was not until December 22, 2016 that Google requested inclusion as a CA in Mozilla's CA program (https://bugzilla.mozilla.org/show_bug.cgi?id=1325532). This does not appear to align with Mozilla requirements for public disclosure. rmh: As has been mentioned, timing for a transaction like this is very complicated. The process of identifying candidates that could meet our needs took many months with several false starts with different organizations. That said, prior to beginning this process we proactively reached out to both Microsoft and Mozilla root programs to let them know we were beginning the process. Once it looked like we would be able to come to an agreement with GlobalSign we again reached out and notified both programs of our intent to secure these specific keys. Then once the transaction was signed we again notified the root programs that the deal was done. As you know the process to ensure a secure, audited and well structured key migration is also non-trivial. Once this migration was performed we again notified both root programs. Our intention was to notify all parties, including the public, shortly after the transfer but it took some time for our auditors, for reasons unrelated to our audit, to produce the associated audit letters. Once we received said letters, we then filed the bugs. This is, although not our ideal timeline, and based on our understanding, in compliance with the Mozilla root program in that since these roots were already members they did not require us to publicly disclose the above negotiation, contracting, planning, migration and other intermediate steps. pzb: Fourth, the audit reports linked in the bug explicitly set the scope of "subordinate CA operated under external Root CA" and do not include any indication of controls around the issuance of subordinate CA certificates. These audit reports do not have an appropriate scope for a root CA. rmh: Yes, we were also concerned about this topic, especially with the recent scope issues with audits. As such, we discussed this with both our auditors, and the the root programs prior to acquisition of the key material. When looking at this issue it is important to keep in mind Google has operated a WebTrust audited subordinat
Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban
On 09/02/2017 10:59, Gervase Markham wrote: On 08/02/17 11:25, Jakob Bohm wrote: My logic is that adding additional entropy to a serial number whose length is fully controlled by CA procedures can increase the mitigations against SHA-1 weaknesses. For example if the existing CA setup uses all bits of the old serial number length for non-random values, then the required 64 random bits can simply be appended or prepended. Requiring randomness in the serial number is only appropriate when some of the certificate contents are attacker-controlled. This is not true for an intermediate issued by a CA. And if the CA is an attacker, restricting them to a serial number of the same length (i.e. not arbitrary) makes it harder for them to engineer a collision. Gerv However as a best practice, a CA may establish internal countermeasures involving adding entropy even for internal requests for intermediary certificates. My proposal was to simply not ban that. For external requests, the issue would be if a specific CA certificate was previously used to sign certificates whose serial number consisted of e.g. a 128 bit internally computed value (such as AES128(fixed key, counter)) and a few bits of fresh entropy (such as 20 bits), then moving to to the higher requirement of 64 fresh CSPRNG bits might be best implemented (for some such CA) by changing to those same 128 bits (for continued uniqueness), plus 64 bits of CSPRNG output. Again my proposal was not to ban that. More generally, there might be a Mozilla policy requirement that the length should be fixed in the (updated) CP/CPS, and the serial number should be mostly generated by the issuing CA (except for cross-certs). While such length-growing security improvements might be hampered by the need to support legacy parties with hard limits on serial number length, that would be for each CA to consider and decide. 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: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)
On 09/02/17 14:32, Gijs Kruitbosch wrote: > Would Mozilla's root program consider changing this requirement so that > it *does* require public disclosure, or are there convincing reasons not > to? At first glance, it seems like 'guiding' CAs towards additional > transparency in the CA market/industry/... might be helpful to people > outside Mozilla's root program itself. This would require CAs and companies to disclose major product plans publicly well in advance of the time they would normally disclose them. I won't dig out the dates myself, or check the emails, but if you look for the following dates from publicly-available information: A) The date Google took control of the GlobalSign roots B) The date Google publicly announced GTS you will see there's quite a big delta. If you assume Google told Mozilla about event A) before it happened, then you can see the problem. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)
On 09/02/2017 10:06, Gervase Markham wrote: > We require disclosure of root ownership transfer, but not _public_ > disclosure. Would Mozilla's root program consider changing this requirement so that it *does* require public disclosure, or are there convincing reasons not to? At first glance, it seems like 'guiding' CAs towards additional transparency in the CA market/industry/... might be helpful to people outside Mozilla's root program itself. ~ Gijs ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 09/02/17 05:31, Peter Bowen wrote: > Third, the Google CPS says Google took control of these roots on > August 11, 2016. The Mozilla CA policy explicitly says that a bug > report must be filed to request to be included in the Mozilla CA > program. But the Mozilla CA policy does not require that the organization on the receiving end of a root transfer must re-apply for inclusion for already-included certificates. > It was not until December 22, 2016 that Google requested > inclusion as a CA in Mozilla's CA program > (https://bugzilla.mozilla.org/show_bug.cgi?id=1325532). This does not > appear to align with Mozilla requirements for public disclosure. We require disclosure of root ownership transfer, but not _public_ disclosure. Kathleen would need to speak regarding dates, but I know Mozilla was made aware of these transfers significantly before the inclusion request was filed. Apart from this, however, it seems at first glance that the other assertions made in Peter's post here in mozilla.dev.security.policy are correct. So CCing Ryan Hurst of GTS for a response. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban
On 08/02/17 11:25, Jakob Bohm wrote: > My logic is that adding additional entropy to a serial number whose > length is fully controlled by CA procedures can increase the > mitigations against SHA-1 weaknesses. For example if the existing CA > setup uses all bits of the old serial number length for non-random > values, then the required 64 random bits can simply be appended or > prepended. Requiring randomness in the serial number is only appropriate when some of the certificate contents are attacker-controlled. This is not true for an intermediate issued by a CA. And if the CA is an attacker, restricting them to a serial number of the same length (i.e. not arbitrary) makes it harder for them to engineer a collision. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On 09/02/17 03:07, Ryan Sleevi wrote: > We appreciate your attention to these questions and will thoughtfully > consider a response to these questions if received no later than 2017-02-13 > 00:00:00 UTC. Mozilla also requests answers to these excellent questions under the same terms and, for the avoidance of doubt, interprets the above as the point in time between Sun 2017-02-12 and Mon 2017-02-13, rather than the point in time between Mon 2017-02-13 and Tue 2017-02-14. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy