Re: Concerns with Dun & Bradstreet as a QIIS
Forgive my ignorance, but could you please explain what was your ultimate goal, as "an attacker", what were you hoping to gain and how could you use this against Relying Parties? I read your email several times but I could not easily find a case where your fake address creates any serious concern for Relying Parties. Even if you used the same street address as CloudFlare, the CA would check against the database and would find two company records that share the same address. That would obviously block the process and additional checks would take place. Now, as a way to delay certificate issuance for CloudFlare, I find it interesting but it certainly doesn't seem to affect Relying Parties. And to take this one step further, I believe there are several GISs that also accept whatever address you tell them because: 1. They have no reason to believe that you will lie to them (they know who you are and in some Jurisdictions you might be prosecuted for lying to the government) 2. No foreseeable harm to others could be done if you misrepresent your own address. Since we are discussing about Data/Information Sources, the BRs define how CAs should evaluate a Data Source and declaring it "Reliable". "3.2.2.7 Data Source Accuracy Prior to using any data source as a Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification. The CA SHOULD consider the following during its evaluation: 1. The age of the information provided, 2. The frequency of updates to the information source, 3. The data provider and purpose of the data collection, 4. The public accessibility of the data availability, and 5. The relative difficulty in falsifying or altering the data. Databases maintained by the CA, its owner, or its affiliated companies do not qualify as a Reliable Data Source if the primary purpose of the database is to collect information for the purpose of fulfilling the validation requirements under this Section 3.2." The EVGs also describe how to evaluate and declare the "Qualified" status: "11.11.5. Qualified Independent Information Source A Qualified Independent Information Source (QIIS) is a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that: (1) Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and (2) The database provider updates its data on at least an annual basis. The CA SHALL use a documented process to check the accuracy of the database and ensure its data is acceptable, including reviewing the database provider's terms of use. The CA SHALL NOT use any data in a QIIS that the CA knows is (i) self-reported and (ii) not verified by the QIIS as accurate. Databases in which the CA or its owners or affiliated companies maintain a controlling interest, or in which any Registration Authorities or subcontractors to whom the CA has outsourced any portion of the vetting process (or their owners or affiliated companies) maintain any ownership or beneficial interest, do not qualify as a QIIS." In my understanding, this is the process each CA must perform to evaluate every Data Source before granting them the "Reliable" or "Qualified" status. Self-reported information without any supporting evidence is clearly not acceptable. I have not evaluated this database that you mention but if they accept self-reporting for "Street Address" and don't perform any additional verification (like asking you for a utility bill or cross-referencing it with a government database), then the "Street Address" information is unreliable and the CA's evaluation process should catch that. That doesn't mean that the rest of the information is also unreliable. For example, an Information Source might describe in their documentation practices how they verify each piece of information, for example: * the Jurisdicion of Incorporation (they check official government records), * registry number (they check official government records), * the name of legal representative (they check official government records), * the official name of the legal entity (they check official government records), * street address (they check the address of a utility bill issued under the name of the legal entity), * telephone numbers (self-reported), * color of the building (self-reported), and the CA, during evaluation, might decide to accept only the first 5 as Reliable/Qualified Information as they have higher level of assurance. That would be the right thing to do. For the rest of the information, the CA should probably request additional validation information from the Applicant. Sorry for the long email, quoting requirements always does that :) Dimitris. On 27/9/2018 2:52 πμ, Ian
Re: Concerns with Dun & Bradstreet as a QIIS
On Thu, Sep 27, 2018 at 10:39 PM Tim Hollebeek wrote: > I'm glad you added the smiley, because in my experience CAs have rarely, > if ever, have had any discretion in such matters. That does not match reports from multiple former employees of various CAs. Nor do we (DigiCert) particularly want to, to be honest. I prefer clear, > open, and transparent validation rules that other CAs can't play games with. > > Whitelisting and disclosure of validation sources was an active topic of > discussion at the Redmond F2F, if I'm remembering my meetings correctly. > I'm surprised that more small CAs didn't support me in that effort at my > previous employer, as they generally have not taken as much time or effort > to find the correct sources, and instead rely upon inferior sources. > > If that's the direction people want to move, I'd echo Matt's concern that > it will be a complex and difficult process. It's best to recall we spent a > year or three trying to reach consensus about what localities existed in > Taiwan and how companies could be identified there, and failed. I think that’s conflating bad proposals with difficulty. I'm always willing to work with people on improving the baseline > requirements, but there needs to be a recognition up front that this is not > going to be an easy problem to solve, and people need to be willing to > volunteer and roll up their sleeves and do their part in we're going to > undertake such a time consuming effort. Indeed. I look forward to CAs with the day to day expertise to suggest QGIS to be added. I’m sure any CA of considerable size and scale will no doubt have a readily available list of QGIS as appropriate for their validation efforts, as part of ensuring a consistent application of their own validation policies. I can’t imagine any CA but the very smallest not already having guidance for their validation staff as to what serves as an appropriate and reliable source, as they surely wouldn’t be making it up on the fly. > > -Tim > > > -Original Message- > > From: dev-security-policy > On > > Behalf Of Ryan Sleevi via dev-security-policy > > Sent: Thursday, September 27, 2018 4:18 PM > > To: Matthew Hardeman > > Cc: mozilla-dev-security-policy < > mozilla-dev-security-pol...@lists.mozilla.org>; > > Ian Carroll > > Subject: Re: Concerns with Dun & Bradstreet as a QIIS > > > > Yes, it would be work, but would result in consistent and reliable > information, > > and already reflective of the fact that an EV certificate needs to > identify the > > jurisdictionOfIncorporation and it's incorporating documents. Or are we > saying > > that OV doesn't need to make sure it's actually a valid and legal > entity, and can > > just display whatever information the CA feels is appropriate? ;) > > > > > > On Thu, Sep 27, 2018 at 6:48 PM Matthew Hardeman via dev-security-policy > < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > A whitelist of QGIS sounds fairly difficult. And how long would it > > > take to adopt a new one? > > > > > > In some states you're going to have an authority per county. It'd be > > > a big list. > > > > > > On Thu, Sep 27, 2018 at 5:35 PM, Ian Carroll via dev-security-policy < > > > dev-security-policy@lists.mozilla.org> wrote: > > > > > > > On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi > > wrote: > > > > > Thanks for raising this, Ian. > > > > > > > > > > The question and concern about QIIS is extremely reasonable. As > > > discussed > > > > > in past CA/Browser Forum activities, some CAs have extended the > > > > definition > > > > > to treat Google Maps as a QIIS (it is not), as well as third-party > > > WHOIS > > > > > services (they’re not; that’s using a DTP). > > > > > > > > > > In the discussions, I proposed a comprehensive set of reforms that > > > would > > > > > wholly remedy this issue. Given that the objective of OV and EV > > > > > certificates is nominally to establish a legal identity, and the > > > > > legal identity is derived from State power of recognition, I > > > > > proposed that > > > only > > > > > QGIS be recognized for such information. This wholly resolves > > > differences > > > > > in interpretation on suitable QIIS. > > > > > > > > > > However, to ensure there do not also emerge conflicting > > > > > understandings > > > of > > > > > appropriate QGIS - and in particular, since the BRs and EVGs > > > > > recognize > > > a > > > > > variety of QGIS’s with variable levels of assurance relative to > > > > > the information included - I further suggested that the > > > > > determination of a > > > > QGIS > > > > > for a jurisdictional boundary should be maintained as a normative > > > > whitelist > > > > > that can be interoperably used and assessed against. If a given > > > > > jurisdiction is not included within that whitelist, or the QGIS is > > > > > not > > > on > > > > > it, it cannot be used. Additions to that whitelist can be > > > > > maintained by > > > > the > > > >
RE: Concerns with Dun & Bradstreet as a QIIS
I'm glad you added the smiley, because in my experience CAs have rarely, if ever, have had any discretion in such matters. Nor do we (DigiCert) particularly want to, to be honest. I prefer clear, open, and transparent validation rules that other CAs can't play games with. Whitelisting and disclosure of validation sources was an active topic of discussion at the Redmond F2F, if I'm remembering my meetings correctly. I'm surprised that more small CAs didn't support me in that effort at my previous employer, as they generally have not taken as much time or effort to find the correct sources, and instead rely upon inferior sources. If that's the direction people want to move, I'd echo Matt's concern that it will be a complex and difficult process. It's best to recall we spent a year or three trying to reach consensus about what localities existed in Taiwan and how companies could be identified there, and failed. I'm always willing to work with people on improving the baseline requirements, but there needs to be a recognition up front that this is not going to be an easy problem to solve, and people need to be willing to volunteer and roll up their sleeves and do their part in we're going to undertake such a time consuming effort. -Tim > -Original Message- > From: dev-security-policy On > Behalf Of Ryan Sleevi via dev-security-policy > Sent: Thursday, September 27, 2018 4:18 PM > To: Matthew Hardeman > Cc: mozilla-dev-security-policy > ; > Ian Carroll > Subject: Re: Concerns with Dun & Bradstreet as a QIIS > > Yes, it would be work, but would result in consistent and reliable > information, > and already reflective of the fact that an EV certificate needs to identify > the > jurisdictionOfIncorporation and it's incorporating documents. Or are we saying > that OV doesn't need to make sure it's actually a valid and legal entity, and > can > just display whatever information the CA feels is appropriate? ;) > > > On Thu, Sep 27, 2018 at 6:48 PM Matthew Hardeman via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > A whitelist of QGIS sounds fairly difficult. And how long would it > > take to adopt a new one? > > > > In some states you're going to have an authority per county. It'd be > > a big list. > > > > On Thu, Sep 27, 2018 at 5:35 PM, Ian Carroll via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi > wrote: > > > > Thanks for raising this, Ian. > > > > > > > > The question and concern about QIIS is extremely reasonable. As > > discussed > > > > in past CA/Browser Forum activities, some CAs have extended the > > > definition > > > > to treat Google Maps as a QIIS (it is not), as well as third-party > > WHOIS > > > > services (they’re not; that’s using a DTP). > > > > > > > > In the discussions, I proposed a comprehensive set of reforms that > > would > > > > wholly remedy this issue. Given that the objective of OV and EV > > > > certificates is nominally to establish a legal identity, and the > > > > legal identity is derived from State power of recognition, I > > > > proposed that > > only > > > > QGIS be recognized for such information. This wholly resolves > > differences > > > > in interpretation on suitable QIIS. > > > > > > > > However, to ensure there do not also emerge conflicting > > > > understandings > > of > > > > appropriate QGIS - and in particular, since the BRs and EVGs > > > > recognize > > a > > > > variety of QGIS’s with variable levels of assurance relative to > > > > the information included - I further suggested that the > > > > determination of a > > > QGIS > > > > for a jurisdictional boundary should be maintained as a normative > > > whitelist > > > > that can be interoperably used and assessed against. If a given > > > > jurisdiction is not included within that whitelist, or the QGIS is > > > > not > > on > > > > it, it cannot be used. Additions to that whitelist can be > > > > maintained by > > > the > > > > Forum, based on an evaluation of the suitability of that QGIS for > > > purpose, > > > > and a consensus for adoption. > > > > > > > > This would significantly reduce the risk, while also further > > > > reducing ambiguities that have arisen from some CAs attempting to > > > > argue that non-employees of the CA or QGIS, but which act as > > > > intermediaries on > > > behalf > > > > of the CA to the QGIS, are not functionally and formally DTPs and > > > > this subject to the assessment requirements of DTPs. This > > > > ambiguity is being exploited in ways that can allow a CA to > > > > nominally say it checked a > > QGIS, > > > > but is relying on the word of a third-party, and with no assurance > > > > of > > the > > > > system security of that third party. > > > > > > > > Do you think such a proposal would wholly address your concern? > > > > > > I think I'll always agree with removing intermediaries from the >
RE: SHA-1 exception history
> On Thu, 27 Sep 2018 14:52:27 + > Tim Hollebeek via dev-security-policy > wrote: > > > My personal impression is that by the time they are brought up here, > > far too many issues have easily predicted and pre-determined outcomes. > > It is probably true that many issues have predictable outcomes but I think > predictability is on the whole desirable. Are there in fact CA representatives > who'd rather they had no idea how Mozilla would react when there's an issue? Asserting that the only alternative to pre-determined outcomes is "no idea" is a straw man. If there is a lack of predictability because I can't predict the results of an open and honest deliberation among a diverse community, then yes, I want that. I would actually love to see more widespread participation by community members. Different perspectives are useful. > > I know most of the security and key management people for the payment > > industry very well [1], and they're good people. > > I mean this not sarcastically at all, but almost everybody is "good people". > That's just not enough. I would like to think that I'm "good people" and yet it > certainly would not be a good idea for the Mozilla CA root trust programme to > trust some CA root I have on this PC. Almost everyone is certainly not "good people" in the sense that I meant. Security is a difficult subject, and people who understand it well are rare. It unfortunately also tends to attract the personality type that is keen on finding faults and inherently suspicious of the motivations of others. I have a great deal of respect for many of the people I've met who have both a profound understanding of technical issues and the ability to make sound decisions. If you read the entire long historical list of SHA-1 exchanges, you'll find a profound lack of respect for the opinions of others in many places. That tends to cause people to not participate, in much the same way as it caused me to slowly back away from the conversation at the time. > > I attempted to speak up a few times in various fora but it was pretty > > clear that anything that wasn't security posturing wasn't going to be > > listened to, and finding a practical solution was not on the agenda. > > It was pretty clear sitting in the room that certain persons had > > already made up their minds before they even understood what a payment > > terminal was, how they are managed, and what the costs and risks were > > for each potential alternative. > > If we're being frank, my impression is that First Data lied in their submission to > us and if it came solely to my discretion that would be enough to have justified > telling them "No" on its own the first time. Honestly, First Data is not my favorite company. I tend to disagree with their representatives more often than not. And I'm not asserting they or others should have gotten what they wanted, only that the level of discourse was not where it should have been. This is perhaps less obvious to those who only followed the discussions on the list, and did not participate on the calls and in person. I actually think the tone on m.d.s-p has improved quite a bit in the last year or two. It's one of the reasons I participate here from time to time, where previously I rarely if ever did. I would like to see it continue moving in the right direction. > As to understanding what a payment terminal is, how about "The cheapest > possible device that passes the bare minimum of tests to scrape through" ? Is > that a good characterisation? It is not. Such extreme cynicism is generally a symptom of a lack of objectivity. -Tim smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Concerns with Dun & Bradstreet as a QIIS
Yes, it would be work, but would result in consistent and reliable information, and already reflective of the fact that an EV certificate needs to identify the jurisdictionOfIncorporation and it's incorporating documents. Or are we saying that OV doesn't need to make sure it's actually a valid and legal entity, and can just display whatever information the CA feels is appropriate? ;) On Thu, Sep 27, 2018 at 6:48 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > A whitelist of QGIS sounds fairly difficult. And how long would it take to > adopt a new one? > > In some states you're going to have an authority per county. It'd be a big > list. > > On Thu, Sep 27, 2018 at 5:35 PM, Ian Carroll via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi wrote: > > > Thanks for raising this, Ian. > > > > > > The question and concern about QIIS is extremely reasonable. As > discussed > > > in past CA/Browser Forum activities, some CAs have extended the > > definition > > > to treat Google Maps as a QIIS (it is not), as well as third-party > WHOIS > > > services (they’re not; that’s using a DTP). > > > > > > In the discussions, I proposed a comprehensive set of reforms that > would > > > wholly remedy this issue. Given that the objective of OV and EV > > > certificates is nominally to establish a legal identity, and the legal > > > identity is derived from State power of recognition, I proposed that > only > > > QGIS be recognized for such information. This wholly resolves > differences > > > in interpretation on suitable QIIS. > > > > > > However, to ensure there do not also emerge conflicting understandings > of > > > appropriate QGIS - and in particular, since the BRs and EVGs recognize > a > > > variety of QGIS’s with variable levels of assurance relative to the > > > information included - I further suggested that the determination of a > > QGIS > > > for a jurisdictional boundary should be maintained as a normative > > whitelist > > > that can be interoperably used and assessed against. If a given > > > jurisdiction is not included within that whitelist, or the QGIS is not > on > > > it, it cannot be used. Additions to that whitelist can be maintained by > > the > > > Forum, based on an evaluation of the suitability of that QGIS for > > purpose, > > > and a consensus for adoption. > > > > > > This would significantly reduce the risk, while also further reducing > > > ambiguities that have arisen from some CAs attempting to argue that > > > non-employees of the CA or QGIS, but which act as intermediaries on > > behalf > > > of the CA to the QGIS, are not functionally and formally DTPs and this > > > subject to the assessment requirements of DTPs. This ambiguity is being > > > exploited in ways that can allow a CA to nominally say it checked a > QGIS, > > > but is relying on the word of a third-party, and with no assurance of > the > > > system security of that third party. > > > > > > Do you think such a proposal would wholly address your concern? > > > > I think I'll always agree with removing intermediaries from the > validation > > process. Outside of practical concerns, a whitelist of QGIS entities > sounds > > like a good idea. > > > > I would wonder what the replacement for D is in the United States. You > > can normally get an address for a company from a QGIS but not (from the > > states I've seen) a phone number for callback verification. > > ___ > > 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 > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Concerns with Dun & Bradstreet as a QIIS
A whitelist of QGIS sounds fairly difficult. And how long would it take to adopt a new one? In some states you're going to have an authority per county. It'd be a big list. On Thu, Sep 27, 2018 at 5:35 PM, Ian Carroll via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi wrote: > > Thanks for raising this, Ian. > > > > The question and concern about QIIS is extremely reasonable. As discussed > > in past CA/Browser Forum activities, some CAs have extended the > definition > > to treat Google Maps as a QIIS (it is not), as well as third-party WHOIS > > services (they’re not; that’s using a DTP). > > > > In the discussions, I proposed a comprehensive set of reforms that would > > wholly remedy this issue. Given that the objective of OV and EV > > certificates is nominally to establish a legal identity, and the legal > > identity is derived from State power of recognition, I proposed that only > > QGIS be recognized for such information. This wholly resolves differences > > in interpretation on suitable QIIS. > > > > However, to ensure there do not also emerge conflicting understandings of > > appropriate QGIS - and in particular, since the BRs and EVGs recognize a > > variety of QGIS’s with variable levels of assurance relative to the > > information included - I further suggested that the determination of a > QGIS > > for a jurisdictional boundary should be maintained as a normative > whitelist > > that can be interoperably used and assessed against. If a given > > jurisdiction is not included within that whitelist, or the QGIS is not on > > it, it cannot be used. Additions to that whitelist can be maintained by > the > > Forum, based on an evaluation of the suitability of that QGIS for > purpose, > > and a consensus for adoption. > > > > This would significantly reduce the risk, while also further reducing > > ambiguities that have arisen from some CAs attempting to argue that > > non-employees of the CA or QGIS, but which act as intermediaries on > behalf > > of the CA to the QGIS, are not functionally and formally DTPs and this > > subject to the assessment requirements of DTPs. This ambiguity is being > > exploited in ways that can allow a CA to nominally say it checked a QGIS, > > but is relying on the word of a third-party, and with no assurance of the > > system security of that third party. > > > > Do you think such a proposal would wholly address your concern? > > I think I'll always agree with removing intermediaries from the validation > process. Outside of practical concerns, a whitelist of QGIS entities sounds > like a good idea. > > I would wonder what the replacement for D is in the United States. You > can normally get an address for a company from a QGIS but not (from the > states I've seen) a phone number for callback verification. > ___ > 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: Concerns with Dun & Bradstreet as a QIIS
On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi wrote: > Thanks for raising this, Ian. > > The question and concern about QIIS is extremely reasonable. As discussed > in past CA/Browser Forum activities, some CAs have extended the definition > to treat Google Maps as a QIIS (it is not), as well as third-party WHOIS > services (they’re not; that’s using a DTP). > > In the discussions, I proposed a comprehensive set of reforms that would > wholly remedy this issue. Given that the objective of OV and EV > certificates is nominally to establish a legal identity, and the legal > identity is derived from State power of recognition, I proposed that only > QGIS be recognized for such information. This wholly resolves differences > in interpretation on suitable QIIS. > > However, to ensure there do not also emerge conflicting understandings of > appropriate QGIS - and in particular, since the BRs and EVGs recognize a > variety of QGIS’s with variable levels of assurance relative to the > information included - I further suggested that the determination of a QGIS > for a jurisdictional boundary should be maintained as a normative whitelist > that can be interoperably used and assessed against. If a given > jurisdiction is not included within that whitelist, or the QGIS is not on > it, it cannot be used. Additions to that whitelist can be maintained by the > Forum, based on an evaluation of the suitability of that QGIS for purpose, > and a consensus for adoption. > > This would significantly reduce the risk, while also further reducing > ambiguities that have arisen from some CAs attempting to argue that > non-employees of the CA or QGIS, but which act as intermediaries on behalf > of the CA to the QGIS, are not functionally and formally DTPs and this > subject to the assessment requirements of DTPs. This ambiguity is being > exploited in ways that can allow a CA to nominally say it checked a QGIS, > but is relying on the word of a third-party, and with no assurance of the > system security of that third party. > > Do you think such a proposal would wholly address your concern? I think I'll always agree with removing intermediaries from the validation process. Outside of practical concerns, a whitelist of QGIS entities sounds like a good idea. I would wonder what the replacement for D is in the United States. You can normally get an address for a company from a QGIS but not (from the states I've seen) a phone number for callback verification. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 exception history
On Thu, 27 Sep 2018 14:52:27 + Tim Hollebeek via dev-security-policy wrote: > My personal impression is that by the time they are brought up here, > far too many issues have easily predicted and pre-determined outcomes. It is probably true that many issues have predictable outcomes but I think predictability is on the whole desirable. Are there in fact CA representatives who'd rather they had no idea how Mozilla would react when there's an issue? > I know most of the security and key management people for the payment > industry very well [1], and they're good people. I mean this not sarcastically at all, but almost everybody is "good people". That's just not enough. I would like to think that I'm "good people" and yet it certainly would not be a good idea for the Mozilla CA root trust programme to trust some CA root I have on this PC. > I attempted to speak up a few times in various fora but it was pretty > clear that anything that wasn't security posturing wasn't going to be > listened to, and finding a practical solution was not on the agenda. > It was pretty clear sitting in the room that certain persons had > already made up their minds before they even understood what a > payment terminal was, how they are managed, and what the costs and > risks were for each potential alternative. If we're being frank, my impression is that First Data lied in their submission to us and if it came solely to my discretion that would be enough to have justified telling them "No" on its own the first time. Here's what they wrote to us: "In Nov. 2014 Datawire added SHA-2 certificates to our staging and support environments." And here's what they'd told their customers about one of those staging environments as late as September 2015: "Datawire will update to SHA-256 support on March 9, 2016 on the following url: stg.dw.us.fdcnet.biz (staging)" and yet when Symantec did create a SHA-256 certificate for stg.dw.us.fdcnet.biz it wasn't in November 2014, or on March 9, 2016, it was dated 10 June 2016. OK, well, maybe it was just stg.dw.us.fdcnet.biz right? Let's try one of their support sites, support.datawire.net. That finally received a SHA-256 certificate in September 2016 almost two years after Datawire told us it had happened, in fact, it was just barely before Symantec forwarded us their request for an exception. Rather than almost two _years_ their customers actually had two _days_ for this change before First Data put an onion in their pocket and came to tell us about how hard they'd tried... [support.datawire.net still exists at time of writing but is scheduled to expire in the next few hours] As to understanding what a payment terminal is, how about "The cheapest possible device that passes the bare minimum of tests to scrape through" ? Is that a good characterisation? Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Visa Issues
Visa has filed a bug [1] requesting removal of the eCommerce root from the Mozilla root store. Visa has also responded to the information requested in the qualified audits bug [2], but it's unclear if or when they will respond to the issues list presented in this thread. Two weeks have passed since I posted the issues list, and I see no reason to delay the complete distrust of Visa's eCommerce root. That is likely to happen in Firefox 64 [3] via removal of the root from NSS version 3.40 . Visa is still welcome to respond to the issues list, but I think the removal of Visa's only included root, and thus Visa, from the Mozilla CA Certificate Program implies that this discussion has reached a conclusion. - Wayne [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1493822 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1485851#c2 [3] https://wiki.mozilla.org/Release_Management/Calendar On Sun, Sep 23, 2018 at 1:15 PM Ryan Sleevi wrote: > > > On Thu, Sep 13, 2018 at 3:26 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Visa recently delivered new qualified audit reports for their eCommerce >> Root that is included in the Mozilla program. I opened a bug [1] and >> requested an incident report from Visa. >> >> Visa was also the subject of a thread [2] earlier this year in which I >> stated that I would look into some of the concerns that were raised. I've >> done that and have compiled the following issues list: >> >> https://wiki.mozilla.org/CA:Visa_Issues >> >> While I have attempted to make this list as complete, accurate, and >> factual >> as possible, it may be updated as more information is received from Visa >> and the community. >> >> I would like to request that a representative from Visa engage in this >> discussion and provide responses to these issues. >> >> - Wayne >> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1485851 >> [2] >> >> https://groups.google.com/d/msg/mozilla.dev.security.policy/NNV3zvX43vE/ns8UUwp8BgAJ > > > I've not seen Visa engage in this discussion. The silence is rather > deafening, and arguably unacceptably so. > > With respect to the Qualified Audit, Visa's response as to the substance > of the issue is particularly unsettling. > https://bugzilla.mozilla.org/show_bug.cgi?id=1485851#c3 demonstrates that > they've not actually remediated the qualification, that they've further > failed to meet the BRs requirements on revocations by any reasonable > perspective, and they don't even have a plan yet to remedy this issue. > > Examining the bug itself is fairly disturbing, and the responses likely > reveal further BR violations. For example, the inability to obtain evidence > of domain validation information reveals that there are further issues with > 2-7.3 - namely, maintaining those logs for 7 years. The response to 2-7.3 > suggests that there are likely more endemic issues around the issuance. > > Given the past issues, the recently identified issues (that appear to have > been longstanding), and the new issues that Visa's PKI Policy team is > actively engaging in, I believe it would be appropriate and necessary to > consider removing trust in this CA. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services Root Inclusion Request
A few additional points: First off, thank you Rob and James for calling out unacceptable list behavior. Personal attacks will not be tolerated from anyone on this list. On Thu, Sep 27, 2018 at 10:26 AM Ryan Sleevi wrote: > > On Thu, Sep 27, 2018 at 11:17 AM Jeremy Rowley > wrote: > >> Oh – I totally agree with you on the Google inclusion issue. Google meets >> the requirements for inclusion in Mozilla’s root policy so there’s no >> reason to exclude them. They have an audited CPS, support a community >> broader with certs than just Google, and have operated a CA without >> problems in the past. The discussion on Mozilla’s independence is important >> IMO where a) a Mozilla competitor as a module peer and b) having that same >> person also belong to a CA. There are legit concerns. Has any other CA >> served as a module owner? If not, why? I know Tim Hollebeek would be >> interested in being a peer. If he’s not permitted to be a peer, why not? >> > > Again, I don't think there is or should be a ban on module peers being employed by a CA. > I think this again conflates peership with ownership, and it's good to > revisit what policies are actually specified by how it works. > > I disagree with you as to the independence discussion being valuable, > because that conclusion rests on a misunderstanding about module ownership > and peership. Again, > https://www.mozilla.org/en-US/about/governance/policies/module-ownership/ > addresses these concerns. It also is conflating MoCo and MoFo, which I know > was a topic that Gerv was particularly sensitive to. > > To your second part, the selection of peers, > https://wiki.mozilla.org/Modules addresses this - "A peer is a person > whom the owner has appointed to help them." and "Owners may add and remove > peers from their modules as they wish, without reference to anyone else" > > My observation is that peers are appointed in recognition of the level of work they've done for the module. Peer appointments are announced on the Mozilla governance list, and I believe that a search of recent peer announcements [1] supports my observation. If members of this list think there is someone whose contributions should be recognized by making them a peer, please let Kathleen and me know. Employees of CAs often have the knowledge needed to make meaningful contributions here, and we welcome their contributions. [1] https://groups.google.com/forum/#!searchin/mozilla.governance/peer%7Csort:date To be fair, separating out Ryan as a Google browser representative and Ryan >> as a module peer is…hard. Perhaps, he specifically is seen as more >> influential (from my point of view) than others simply because of his dual >> role. >> > > What is difficult separating out? You're intimating at some degree of > influence that is not transparent, but that's not supported by any > evidence. You're also intimating influence over Mozilla somehow, but that > seems like the separation would be easy. > > >> As I said before, Ryan’s a good module peer so I don’t disagree with your >> conclusion or any decision to keep him in that spot. But I think openness >> should include respectful conversation on the impact of influences, >> perceived or real, on the Mozilla direction. What might help alleviate >> concerns is to describe how you (as a module owner) are going to ensure >> that if Ryan is reviewing and approving code or CA policies, they won’t be >> unfairly biased towards google or against its competitors? Maybe that’s a >> bad question, but I’m spit-balling on how we can move past speculation to >> address concerns raised. >> > > Considering that all of this happens in the open, on m.d.s.p., what are > you using to support your thinking that there's some undue influence? Do > you believe that if the title peer is removed, the relationship changes? > Between questions asked and concerns raised? You're not just spit-balling, > you're intimating that the speculation has a reasonable foundation that > requires redress, but you're not actually addressing why that speculation > is seen as reasonable. That things happen here, transparently, should > itself serve to demonstrate the speculation as unfounded. Further, the > influence or lack of influence is based on the discussions that happen > here, and that regardless of any influence that may be perceived, the > community discussion that Wayne facilitates as Module Owner provides ample > opportunity to explore or influence in any other preferable direction. > > Just want to point out that Kathleen is currently still the CA Certificate Policy Module Owner. But let's humour the specious reasoning here, and imagine there was some > undue influence on the peership > - One scenario is that such influence is exercised, and that there isn't a > public review or discussion phase to 'undo' that influence, and that's bad. > That's not a failure of peership though, that's a failure of Module > Ownership > - Another scenario is that such influence is
Re: Google Trust Services Root Inclusion Request
On Thu, Sep 27, 2018 at 11:17 AM Jeremy Rowley wrote: > Oh – I totally agree with you on the Google inclusion issue. Google meets > the requirements for inclusion in Mozilla’s root policy so there’s no > reason to exclude them. They have an audited CPS, support a community > broader with certs than just Google, and have operated a CA without > problems in the past. The discussion on Mozilla’s independence is important > IMO where a) a Mozilla competitor as a module peer and b) having that same > person also belong to a CA. There are legit concerns. Has any other CA > served as a module owner? If not, why? I know Tim Hollebeek would be > interested in being a peer. If he’s not permitted to be a peer, why not? > I think this again conflates peership with ownership, and it's good to revisit what policies are actually specified by how it works. I disagree with you as to the independence discussion being valuable, because that conclusion rests on a misunderstanding about module ownership and peership. Again, https://www.mozilla.org/en-US/about/governance/policies/module-ownership/ addresses these concerns. It also is conflating MoCo and MoFo, which I know was a topic that Gerv was particularly sensitive to. To your second part, the selection of peers, https://wiki.mozilla.org/Modules addresses this - "A peer is a person whom the owner has appointed to help them." and "Owners may add and remove peers from their modules as they wish, without reference to anyone else" > To be fair, separating out Ryan as a Google browser representative and > Ryan as a module peer is…hard. Perhaps, he specifically is seen as more > influential (from my point of view) than others simply because of his dual > role. > What is difficult separating out? You're intimating at some degree of influence that is not transparent, but that's not supported by any evidence. You're also intimating influence over Mozilla somehow, but that seems like the separation would be easy. > As I said before, Ryan’s a good module peer so I don’t disagree with your > conclusion or any decision to keep him in that spot. But I think openness > should include respectful conversation on the impact of influences, > perceived or real, on the Mozilla direction. What might help alleviate > concerns is to describe how you (as a module owner) are going to ensure > that if Ryan is reviewing and approving code or CA policies, they won’t be > unfairly biased towards google or against its competitors? Maybe that’s a > bad question, but I’m spit-balling on how we can move past speculation to > address concerns raised. > Considering that all of this happens in the open, on m.d.s.p., what are you using to support your thinking that there's some undue influence? Do you believe that if the title peer is removed, the relationship changes? Between questions asked and concerns raised? You're not just spit-balling, you're intimating that the speculation has a reasonable foundation that requires redress, but you're not actually addressing why that speculation is seen as reasonable. That things happen here, transparently, should itself serve to demonstrate the speculation as unfounded. Further, the influence or lack of influence is based on the discussions that happen here, and that regardless of any influence that may be perceived, the community discussion that Wayne facilitates as Module Owner provides ample opportunity to explore or influence in any other preferable direction. But let's humour the specious reasoning here, and imagine there was some undue influence on the peership - One scenario is that such influence is exercised, and that there isn't a public review or discussion phase to 'undo' that influence, and that's bad. That's not a failure of peership though, that's a failure of Module Ownership - Another scenario is that such influence is exercised, and there is a public review and discussion phase. If the result produced by that influence is the same as the community expectation, then there's nothing improper here. If the result produced by that influence is different from the community expectation, then that can be corrected and identified during the review and discussion phase, and such 'influence' is actually either non-existent or equivalent to the same influence practiced by all participating members of the community - Another scenario is that there is no such influence, and the participation and peership is identical to that of what the community expects and concurs with. It's almost as if influence is being conflated with consistency - that is, if I'm expressing views that the community agrees with, I'm seen as influential, while ignoring the fact that if I express views the community disagrees with, they are just as influential as to call that out. Do you see the logical flaws here? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org
RE: Google Trust Services Root Inclusion Request
Maybe Jake’s opinion is not being discarded as readily as I supposed. However, Jake’s last message left me disturbed that he didn’t feel listened to. Apologies if I’m overblowing the issue, which are definitely hypothetical at this point. I did want Jake to feel like his input is an important part of this discussion board. Not saying anyone made him feel otherwise intentionally of course, but his last message seemed frustrated. From: Ryan Sleevi Sent: Wednesday, September 26, 2018 10:49 AM To: Jeremy Rowley Cc: Ryan Sleevi ; mozilla-dev-security-policy Subject: Re: Google Trust Services Root Inclusion Request On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote: I also should also emphasize that I’m speaking as Jeremy Rowley, not as DigiCert. Note that I didn’t say Google controlled the policy. However, as a module peer, Google does have significant influence over the policy and what CAs are trusted by Mozilla. Although everyone can participate in Mozilla discussions publicly, it’s a fallacy to state that a general participant has similar sway or authority to a module peer. That’s the whole point of having a separate class for peers compared to us general public. With Google acting as a CA and module peer, you now have one CA heavily influencing who its competitors are, how its competitors operate, and what its competitors can do. Although I personally find that you never misuse your power as a module peer, I can see how Jake has concerns that Google (as a CA) has very heavy influence over the platform that has historically been the CA watchdog (Mozilla). Jeremy, I think this again deserves calling out, because this is misrepresenting what module peership does, as well as the CA relationship. I linked you to the definition of Module Ownership, which highlights and emphasizes that the module peer is simply a recognized helper. To the extent there is any influence, it is through the public discussions here. If your concern is that the title confers some special advantage, that's to misread what module peer is. If your concern is that the participation - which provides solid technical arguments as well as the policy alternatives - is influential, then what you're arguing against is public participation. You're presenting these as factual, and that's misleading, so I'd like to highlight what is actually entailed. The circumstances are different between the scenarios you describe with respect to the other browsers, as is market share. If Microsoft wants to change CAs (and they already use multiple), they can without impacting public perception. If Apple wants to use another CA, they can without people commenting how odd it is that Apple doesn’t use the Apple CA. With Google controlling the CA and the Google browser, all incentive to eliminate any misbehaving Google CA disappears for financial reasons, public perception, and because Google can control the messaging (through marketshare and influence over Mozilla policy). Note that there is historical precedent for Google treating Google special – i.e. the exclusion for Google in the Symantec distrust plan. Thus, I think Jake’s concerns should not be discarded so readily. I can understand and appreciate why you have this perspective. I disagree that it's an accurate representation, and as shown by the previous message, it does not have factual basis. I think it's misleading to suggest that the concerns are being discarded, much like yours - they're being responded to with supporting evidence and careful analysis. However, they do not hold water, and while it would be ideal to convince you of this as well, it's equally important to be transparent about it. Your argument above seems to boil down to "People would notice if Google changed CAs, but not if Microsoft" - yet that's not supported (see, example, the usage of Let's Encrypt by Google, or the former usage of WoSign by Microsoft). Your argument about incentives entirely ignores the incentives I just described to you previously - which look at public perception, internet security, and ecosystem stability. Your argument about influence over Mozilla policy has already been demonstrated as false and misleading, but it seems you won't be convinced by that. And your suggestion of special treatment ignores the facts of the situation (the validation issues, the scoping of audits, that Apple and 2 other CAs were also included in the exclusion), ignores the more significant special treatment granted by other vendors (e.g. Apple's exclusion of a host of mismanaged Symantec sub-CAs now under DigiCert's operational control), the past precedent (e.g. the gradual distrust of WoSign/StartCom through whitelists, of CNNIC through whitelists), and the public discussion involved so entirely that it's entirely unfounded. So I think your continued suggestion that it's being discarded so
RE: Google Trust Services Root Inclusion Request
Oh – I totally agree with you on the Google inclusion issue. Google meets the requirements for inclusion in Mozilla’s root policy so there’s no reason to exclude them. They have an audited CPS, support a community broader with certs than just Google, and have operated a CA without problems in the past. The discussion on Mozilla’s independence is important IMO where a) a Mozilla competitor as a module peer and b) having that same person also belong to a CA. There are legit concerns. Has any other CA served as a module owner? If not, why? I know Tim Hollebeek would be interested in being a peer. If he’s not permitted to be a peer, why not? To be fair, separating out Ryan as a Google browser representative and Ryan as a module peer is…hard. Perhaps, he specifically is seen as more influential (from my point of view) than others simply because of his dual role. As I said before, Ryan’s a good module peer so I don’t disagree with your conclusion or any decision to keep him in that spot. But I think openness should include respectful conversation on the impact of influences, perceived or real, on the Mozilla direction. What might help alleviate concerns is to describe how you (as a module owner) are going to ensure that if Ryan is reviewing and approving code or CA policies, they won’t be unfairly biased towards google or against its competitors? Maybe that’s a bad question, but I’m spit-balling on how we can move past speculation to address concerns raised. From: Wayne Thayer Sent: Wednesday, September 26, 2018 3:39 PM To: Ryan Sleevi Cc: Jeremy Rowley ; mozilla-dev-security-policy Subject: Re: Google Trust Services Root Inclusion Request I'm disputing the conclusion that is being drawn from Jake's concerns, rather than the concerns themselves. Primarily, I disagree with the conclusion that because Google owns a browser with dominant market share and - due to the substantial contributions they make here - because Google has considerable influence in this community, they should not be allowed to participate in our root program as a CA. Secondarily, I disagree that a Google employee should not be a peer of this module due to the potential for a conflict of interest. Unpacking this conclusion in terms of policy it implies, I think the argument being made is that any root store operator should be excluded from membership in the Mozilla program as a CA, and any employee of a CA should be prohibited from being a module peer. The argument is that this will protect us from future conflicts of interest (there seems to be agreement that the concern is hypothetical at this point). My conclusion is that rather than creating somewhat arbitrary, exclusionary rules, we can and should instead rely on the openness and inclusiveness of our process to protect us from conflicts of interest. If Google attempts to gain preferential treatment for their CA from Mozilla, our community can and will identify it, reject it, and hold Mozilla accountable for acting in their best interest. On Wed, Sep 26, 2018 at 9:49 AM Ryan Sleevi via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote: > I also should also emphasize that I’m speaking as Jeremy Rowley, not as > DigiCert. > > > > Note that I didn’t say Google controlled the policy. However, as a module > peer, Google does have significant influence over the policy and what CAs > are trusted by Mozilla. Although everyone can participate in Mozilla > discussions publicly, it’s a fallacy to state that a general participant > has similar sway or authority to a module peer. That’s the whole point of > having a separate class for peers compared to us general public. With > Google acting as a CA and module peer, you now have one CA heavily > influencing who its competitors are, how its competitors operate, and what > its competitors can do. Although I personally find that you never misuse > your power as a module peer, I can see how Jake has concerns that Google > (as a CA) has very heavy influence over the platform that has historically > been the CA watchdog (Mozilla). > Jeremy, I think this again deserves calling out, because this is misrepresenting what module peership does, as well as the CA relationship. I linked you to the definition of Module Ownership, which highlights and emphasizes that the module peer is simply a recognized helper. To the extent there is any influence, it is through the public discussions here. If your concern is that the title confers some special advantage, that's to misread what module peer is. If your concern is that the participation - which provides solid technical arguments as well as the policy alternatives - is influential, then what you're arguing against is public participation. You're presenting these as factual, and that's misleading, so I'd like to highlight what is
RE: Concerns with Dun & Bradstreet as a QIIS
> The question and concern about QIIS is extremely reasonable. As discussed in > past CA/Browser Forum activities, some CAs have extended the definition to > treat Google Maps as a QIIS (it is not), as well as third-party WHOIS services > (they’re not; that’s using a DTP). It's worth noting that the BRs currently say "WHOIS: Information retrieved directly from the Domain Name Registrar or registry operator ..." so I'm not sure using a DTP is actually permitted. Though I don't think we've discussed that point since the language was added. > In the discussions, I proposed a comprehensive set of reforms that would > wholly remedy this issue. Given that the objective of OV and EV certificates > is > nominally to establish a legal identity, and the legal identity is derived > from > State power of recognition, I proposed that only QGIS be recognized for such > information. This wholly resolves differences in interpretation on suitable > QIIS. We agree with this. -Tim smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 exception history
Speaking for myself ... My personal impression is that by the time they are brought up here, far too many issues have easily predicted and pre-determined outcomes. I know most of the security and key management people for the payment industry very well [1], and they're good people. The discussions are generally one or two orders of magnitude more sophisticated (and far more polite) than what happens in the web ecosystem. Yes, there's a lot of silliness in payments, but that's what happens when you try to run and manage a low cost/high volume payment system with complex interconnected audit requirements from multiple SDOs, implemented by hundreds of companies with their own unique perspectives at global scale. They did not deserve the treatment they received. Perhaps things would have gone better if Symantec wasn't involved, but I was shocked at how the situation was handled. I attempted to speak up a few times in various fora but it was pretty clear that anything that wasn't security posturing wasn't going to be listened to, and finding a practical solution was not on the agenda. It was pretty clear sitting in the room that certain persons had already made up their minds before they even understood what a payment terminal was, how they are managed, and what the costs and risks were for each potential alternative. -Tim [1] whenever you swipe a payment card, the card number is likely encrypted with keys from an algorithm that I was first to implement: https://x9.org/x9news/asc-x9-releases-standard-ensuring-security-symmetric-k ey-management-retail-financial-transactions-aes-dukpt-algorithm/ https://x9.org/wp-content/uploads/2018/03/X9.24-3-2017-Python-Source-2018012 9-1.pdf > -Original Message- > From: dev-security-policy On > Behalf Of Nick Lamb via dev-security-policy > Sent: Thursday, September 27, 2018 5:34 AM > To: dev-security-policy@lists.mozilla.org > Cc: Nick Lamb > Subject: Re: Google Trust Services Root Inclusion Request > > On Wed, 26 Sep 2018 23:02:45 +0100 > Nick Lamb via dev-security-policy > wrote: > > Thinking back to, for example, TSYS, my impression was that my post on > > the Moral Hazard from granting this exception had at least as much > > impact as you could expect for any participant. Mozilla declined to > > authorise the (inevitable, to such an extent I pointed out that it > > would happen months before it did) request for yet another exception > > when TSYS asked again. > > Correction: The incident I'm thinking of is First Data, not TSYS, a different SHA- > 1 exception. > > Nick. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/FEUDWpqLnNV5UXAkVPLzsHo_VYc5BQ > WHYUSdSzjAW5Q=?d=LmNFimUxfoPxKiRYG3qhoRqwu2zE3CPQipLjtaTDkdRpP > KDL2JS8yPFFNKYTcWKtHyZ4rfj1O0ZZS5x3vkArKDCzRP3ZCC07l- > SNhD8B4TkkcnDmXJPFlTmuf9Jbc_AGZOos_RYIwD_0TM7s5q9yJyB2Xw6t5iggY1 > qYMgWdJXSo_R6PJYrWiQCv3l_B3q3HEhjoTqZLi0nRxnuoK_Q5ROt-Zy0xZpG- > sj5lFU44sFfHxhQZR6NBUP6c04vZz2FSHrPV6tFf4x3Sa_hEAhK45l3xKbycZO3xCai > M4pZCF2dAtJ2mTfuGBl9_FgLu3Btz2-siKIw39AtkuiKptp6JWNszrsiDBQb66B- > GVQX7M4F7fgMvyaalslF6KHHg5RFi-uOgM8PlilUBCygn0pZylNrU2thPuy- > Nn9jC=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Re: Google Trust Services Root Inclusion Request
Richard, Unfortunately Gerv is no longer with us, so he cannot respond to this accusation. Having been involved in many discussions on m.d.s.p and with Gerv directly, I am very sure Gerv deeply owned the decisions on StartCom and WoSign. It was by no means Ryan telling Gerv or Mozilla what to do. Gerv put many hours into researching the issues and is the one who wrote the wiki and summary docs. Please give Gerv credit where credit is due. Thanks, Peter On Wed, Sep 26, 2018 at 11:55 PM Richard Wang via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Sorry, I don't agree with this point. Ryan Sleevi is the Mozilla Module > Peer that gave too many pressures to the M.D.S.P community to misleading > the Community and to let Mozilla make the decision that Google want. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services Root Inclusion Request
It is unfair that somebody attacked me in the WoSign sanction discussion, but no body say any word for this! Why? Due to Ryan is famous person and I am nobody? Best Regards, Richard Wang On Sep 27, 2018, at 18:24, James Burton mailto:j...@0.me.uk>> wrote: Richard, Your conduct is totally unacceptable and won’t be tolerated. You must read the forum rules regarding etiquette. Also I suggest you apologise to Ryan. James On Thu, 27 Sep 2018 at 10:33, Rob Stradling via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Richard, You might like to familiarize yourself with the Mozilla Forum Etiquette Ground Rules: https://www.mozilla.org/en-US/about/forums/etiquette/ Note this in particular: "Be civil. No personal attacks. Do not feel compelled to defend your honor in public. Posts containing personal attacks may be removed from the news server." On 27/09/2018 07:59, Richard Wang via dev-security-policy wrote: > Sorry, I don't agree with this point. Ryan Sleevi is the Mozilla Module Peer > that gave too many pressures to the M.D.S.P community to misleading the > Community and to let Mozilla make the decision that Google want. > > There are two facts to support my opinion: > > (1) For StartCom sanction, Mozilla agreed in Oct 2nd 2016 London meeting that > if we separate StartCom completely from WoSign, then Mozilla don't sanction > StartCom that still trust StartCom root. But Google as peer of Mozilla Module > don't agree this, and Ryan even found many very very old problems of StartCom > to be a "fact" that must be distrusted. Google changed the Mozilla decision! > > (2) For Symantec sanction, everyone can see the argues in M.D.S.P discussion > from Ryan Sleevi that Google changed the Mozilla initial decision, this also > is the fact. > > So, we can see Ryan not just a Mozilla Module Peer, he represents Google > browser that affect Mozilla to make the right decision. > > Ryan, don't feel too good about yourself. Peoples patiently look at your long > emails at M.D.S.P and listen to your bala bala speaking at the CABF meeting, > this is because you represent Google Chrome, and Google Chrome seriously > affects Mozilla that have the power to kill any CAs. If you leave Google, you > will be nothing, no one will care about your existence, and no one will care > what you say. So, please don't declare that you don't represent Google before > you speak next time, nonsense! > > Your myopic has brought global Internet security to the ditch. Chrome display > "Secure" for a website just it has SSL(https). Many fake banking websites and > fake PayPal websites have Lets Encrypt certificates, and Google Chrome say it > is "Secure", this completely misleads global Internet users, resulting in > many users are deceived and lost property. Encryption is not equal to secure. > Secure means not only encryption, but also need to tell user the website's > true identity. Does a fake bank website encryption mean anything? nothing and > more worse. > > Ryan, 别自我感觉太好，别人耐心看你在M.D.S.P的长篇大论和听你在CABF meeting上说过没完 > ，是因为你代表谷歌浏览器，而谷歌浏览器严重影响Mozilla对所有CA有生杀大权。如果你离开谷歌，你将什么也不是，没有人会理会你的存在，也没有人会在意你说的话。所以下次不要在发言之前就声明不代表谷歌，废话哦！ > > 你的短视把全球互联网安全带到了沟里，认为有SSL证书(https)就安全，许多假冒银行网站、假冒PayPal 网站都有Lets > Encrypt证书，谷歌浏览器显示为安全，完全误导了全球互联网用户，导致许多用户上当受骗和财产损失。已加密并不等于安全，安全不仅意味着需要加密，而且还需要告知用户此网站的真实身份，一个假冒银行网站加密有任何意义吗？没有并且更糟糕。 > > > Best Regards, > > Richard Wang > > Original Message > From: Ryan Sleevi via dev-security-policy > Received: Thursday, 27 September 2018 00:53 > To: Jeremy Rowley > Cc: Ryan Sleevi ; mozilla-dev-security-policy > Subject: Re: Google Trust Services Root Inclusion Request > > > On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley > mailto:jeremy.row...@digicert.com>> > wrote: > >> I also should also emphasize that I’m speaking as Jeremy Rowley, not as >> DigiCert. >> >> >> >> Note that I didn’t say Google controlled the policy. However, as a module >> peer, Google does have significant influence over the policy and what CAs >> are trusted by Mozilla. Although everyone can participate in Mozilla >> discussions publicly, it’s a fallacy to state that a general participant >> has similar sway or authority to a module peer. That’s the whole point of >> having a separate class for peers compared to us general public. With >> Google acting as a CA and module peer, you now have one CA heavily >> influencing who its competitors are, how its competitors operate, and what >> its competitors can do. Although I personally find that you never misuse >> your power as a module peer, I can see how Jake has concerns that Google >> (as a CA) has very heavy influence over the platform that has historically >> been the CA watchdog (Mozilla). >> > > Jeremy, I think this again deserves calling out, because this is > misrepresenting what module peership does, as well as the CA relationship. > > I linked you to the definition of Module Ownership, which highlights and > emphasizes that the
Re: Google Trust Services Root Inclusion Request
On Wed, 26 Sep 2018 23:02:45 +0100 Nick Lamb via dev-security-policy wrote: > Thinking back to, for example, TSYS, my impression was that my post on > the Moral Hazard from granting this exception had at least as much > impact as you could expect for any participant. Mozilla declined to > authorise the (inevitable, to such an extent I pointed out that it > would happen months before it did) request for yet another exception > when TSYS asked again. Correction: The incident I'm thinking of is First Data, not TSYS, a different SHA-1 exception. Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services Root Inclusion Request
Richard, Your conduct is totally unacceptable and won’t be tolerated. You must read the forum rules regarding etiquette. Also I suggest you apologise to Ryan. James On Thu, 27 Sep 2018 at 10:33, Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Richard, > > You might like to familiarize yourself with the Mozilla Forum Etiquette > Ground Rules: > https://www.mozilla.org/en-US/about/forums/etiquette/ > > Note this in particular: > "Be civil. > No personal attacks. Do not feel compelled to defend your honor in > public. Posts containing personal attacks may be removed from the news > server." > > On 27/09/2018 07:59, Richard Wang via dev-security-policy wrote: > > Sorry, I don't agree with this point. Ryan Sleevi is the Mozilla Module > Peer that gave too many pressures to the M.D.S.P community to misleading > the Community and to let Mozilla make the decision that Google want. > > > > There are two facts to support my opinion: > > > > (1) For StartCom sanction, Mozilla agreed in Oct 2nd 2016 London meeting > that if we separate StartCom completely from WoSign, then Mozilla don't > sanction StartCom that still trust StartCom root. But Google as peer of > Mozilla Module don't agree this, and Ryan even found many very very old > problems of StartCom to be a "fact" that must be distrusted. Google changed > the Mozilla decision! > > > > (2) For Symantec sanction, everyone can see the argues in M.D.S.P > discussion from Ryan Sleevi that Google changed the Mozilla initial > decision, this also is the fact. > > > > So, we can see Ryan not just a Mozilla Module Peer, he represents Google > browser that affect Mozilla to make the right decision. > > > > Ryan, don't feel too good about yourself. Peoples patiently look at your > long emails at M.D.S.P and listen to your bala bala speaking at the CABF > meeting, this is because you represent Google Chrome, and Google Chrome > seriously affects Mozilla that have the power to kill any CAs. If you leave > Google, you will be nothing, no one will care about your existence, and no > one will care what you say. So, please don't declare that you don't > represent Google before you speak next time, nonsense! > > > > Your myopic has brought global Internet security to the ditch. Chrome > display "Secure" for a website just it has SSL(https). Many fake banking > websites and fake PayPal websites have Lets Encrypt certificates, and > Google Chrome say it is "Secure", this completely misleads global Internet > users, resulting in many users are deceived and lost property. Encryption > is not equal to secure. Secure means not only encryption, but also need to > tell user the website's true identity. Does a fake bank website encryption > mean anything? nothing and more worse. > > > > Ryan, 别自我感觉太好，别人耐心看你在M.D.S.P的长篇大论和听你在CABF meeting上说过没完 > ，是因为你代表谷歌浏览器，而谷歌浏览器严重影响Mozilla对所有CA有生杀大权。如果你离开谷歌，你将什么也不是，没有人会理会你的存在，也没有人会在意你说的话。所以下次不要在发言之前就声明不代表谷歌，废话哦！ > > > > 你的短视把全球互联网安全带到了沟里，认为有SSL证书(https)就安全，许多假冒银行网站、假冒PayPal 网站都有Lets > Encrypt证书，谷歌浏览器显示为安全，完全误导了全球互联网用户，导致许多用户上当受骗和财产损失。已加密并不等于安全，安全不仅意味着需要加密，而且还需要告知用户此网站的真实身份，一个假冒银行网站加密有任何意义吗？没有并且更糟糕。 > > > > > > Best Regards, > > > > Richard Wang > > > > Original Message > > From: Ryan Sleevi via dev-security-policy > > Received: Thursday, 27 September 2018 00:53 > > To: Jeremy Rowley > > Cc: Ryan Sleevi ; mozilla-dev-security-policy > > Subject: Re: Google Trust Services Root Inclusion Request > > > > > > On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley < > jeremy.row...@digicert.com> > > wrote: > > > >> I also should also emphasize that I’m speaking as Jeremy Rowley, not as > >> DigiCert. > >> > >> > >> > >> Note that I didn’t say Google controlled the policy. However, as a > module > >> peer, Google does have significant influence over the policy and what > CAs > >> are trusted by Mozilla. Although everyone can participate in Mozilla > >> discussions publicly, it’s a fallacy to state that a general participant > >> has similar sway or authority to a module peer. That’s the whole point > of > >> having a separate class for peers compared to us general public. With > >> Google acting as a CA and module peer, you now have one CA heavily > >> influencing who its competitors are, how its competitors operate, and > what > >> its competitors can do. Although I personally find that you never > misuse > >> your power as a module peer, I can see how Jake has concerns that Google > >> (as a CA) has very heavy influence over the platform that has > historically > >> been the CA watchdog (Mozilla). > >> > > > > Jeremy, I think this again deserves calling out, because this is > > misrepresenting what module peership does, as well as the CA > relationship. > > > > I linked you to the definition of Module Ownership, which highlights and > > emphasizes that the module peer is simply a recognized helper. To the > > extent there is any influence, it is through the public discussions here. > > If your concern
Re: Google Trust Services Root Inclusion Request
Richard, You might like to familiarize yourself with the Mozilla Forum Etiquette Ground Rules: https://www.mozilla.org/en-US/about/forums/etiquette/ Note this in particular: "Be civil. No personal attacks. Do not feel compelled to defend your honor in public. Posts containing personal attacks may be removed from the news server." On 27/09/2018 07:59, Richard Wang via dev-security-policy wrote: > Sorry, I don't agree with this point. Ryan Sleevi is the Mozilla Module Peer > that gave too many pressures to the M.D.S.P community to misleading the > Community and to let Mozilla make the decision that Google want. > > There are two facts to support my opinion: > > (1) For StartCom sanction, Mozilla agreed in Oct 2nd 2016 London meeting that > if we separate StartCom completely from WoSign, then Mozilla don't sanction > StartCom that still trust StartCom root. But Google as peer of Mozilla Module > don't agree this, and Ryan even found many very very old problems of StartCom > to be a "fact" that must be distrusted. Google changed the Mozilla decision! > > (2) For Symantec sanction, everyone can see the argues in M.D.S.P discussion > from Ryan Sleevi that Google changed the Mozilla initial decision, this also > is the fact. > > So, we can see Ryan not just a Mozilla Module Peer, he represents Google > browser that affect Mozilla to make the right decision. > > Ryan, don't feel too good about yourself. Peoples patiently look at your long > emails at M.D.S.P and listen to your bala bala speaking at the CABF meeting, > this is because you represent Google Chrome, and Google Chrome seriously > affects Mozilla that have the power to kill any CAs. If you leave Google, you > will be nothing, no one will care about your existence, and no one will care > what you say. So, please don't declare that you don't represent Google before > you speak next time, nonsense! > > Your myopic has brought global Internet security to the ditch. Chrome display > "Secure" for a website just it has SSL(https). Many fake banking websites and > fake PayPal websites have Lets Encrypt certificates, and Google Chrome say it > is "Secure", this completely misleads global Internet users, resulting in > many users are deceived and lost property. Encryption is not equal to secure. > Secure means not only encryption, but also need to tell user the website's > true identity. Does a fake bank website encryption mean anything? nothing and > more worse. > > Ryan, 别自我感觉太好，别人耐心看你在M.D.S.P的长篇大论和听你在CABF meeting上说过没完 > ，是因为你代表谷歌浏览器，而谷歌浏览器严重影响Mozilla对所有CA有生杀大权。如果你离开谷歌，你将什么也不是，没有人会理会你的存在，也没有人会在意你说的话。所以下次不要在发言之前就声明不代表谷歌，废话哦！ > > 你的短视把全球互联网安全带到了沟里，认为有SSL证书(https)就安全，许多假冒银行网站、假冒PayPal 网站都有Lets > Encrypt证书，谷歌浏览器显示为安全，完全误导了全球互联网用户，导致许多用户上当受骗和财产损失。已加密并不等于安全，安全不仅意味着需要加密，而且还需要告知用户此网站的真实身份，一个假冒银行网站加密有任何意义吗？没有并且更糟糕。 > > > Best Regards, > > Richard Wang > > Original Message > From: Ryan Sleevi via dev-security-policy > Received: Thursday, 27 September 2018 00:53 > To: Jeremy Rowley > Cc: Ryan Sleevi ; mozilla-dev-security-policy > Subject: Re: Google Trust Services Root Inclusion Request > > > On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley > wrote: > >> I also should also emphasize that I’m speaking as Jeremy Rowley, not as >> DigiCert. >> >> >> >> Note that I didn’t say Google controlled the policy. However, as a module >> peer, Google does have significant influence over the policy and what CAs >> are trusted by Mozilla. Although everyone can participate in Mozilla >> discussions publicly, it’s a fallacy to state that a general participant >> has similar sway or authority to a module peer. That’s the whole point of >> having a separate class for peers compared to us general public. With >> Google acting as a CA and module peer, you now have one CA heavily >> influencing who its competitors are, how its competitors operate, and what >> its competitors can do. Although I personally find that you never misuse >> your power as a module peer, I can see how Jake has concerns that Google >> (as a CA) has very heavy influence over the platform that has historically >> been the CA watchdog (Mozilla). >> > > Jeremy, I think this again deserves calling out, because this is > misrepresenting what module peership does, as well as the CA relationship. > > I linked you to the definition of Module Ownership, which highlights and > emphasizes that the module peer is simply a recognized helper. To the > extent there is any influence, it is through the public discussions here. > If your concern is that the title confers some special advantage, that's to > misread what module peer is. If your concern is that the participation - > which provides solid technical arguments as well as the policy alternatives > - is influential, then what you're arguing against is public participation. > > You're presenting these as factual, and that's misleading, so I'd like to > highlight what is actually entailed. > > >> The
RE: AC Camerfirma's CP & CPS disclosure
Hi Wayne All problems have already been resolved from our side and we wait for the PIT audit planned for the next week. We will be able to provide the PIT before October 31th. Best regards Ramiro Muñoz Muñoz AC Camerfirma SA. CTO, Exploitation Manager, CISA. +34 619 746 291 · rami...@camerfirma.com. https://www.linkedin.com/in/ramirom. Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener información CONFIDENCIAL, siendo para uso exclusivo del destinatario, quedando prohibida su divulgación copia o distribución a terceros. Si Vd. ha recibido este mensaje erróneamente, se ruega lo notifique al remitente y proceda a su borrado. De conformidad con lo establecido en el Reglamento UE 2016/679 de 27 de abril de 2016 General de Protección de Datos, se le informa que la empresa AC CAMERFIRMA, S.A. tratará la información que nos facilita con el exclusivo fin de cumplir con las obligaciones derivadas de la relación comercial o contractual adquirida con usted y que sus datos no podrán ser objeto de otro tratamiento ni de cesión a terceros salvo en los casos en que exista una obligación legal. Usted tiene derecho a obtener confirmación acerca del tratamiento de sus datos personales, y a ejercer sus derechos de acceso, rectificación, supresión, limitación y portabilidad en el tratamiento, dirigiéndose a AC CAMERFIRMA, S.A., mediante comunicación escrita remitida a la dirección C/ Ribera del Loira 12 (28042) Madrid, o a la dirección electrónica jurid...@camerfirma.com o a través de la web de incidencias disponible en la página web http://webcrm.camerfirma.com/incidencias/incidencias.php [EN] This message, and if applicable, any file attached to it, may contain CONFIDENTIAL information for the exclusive use of the recipient, being prohibited its disclosure copy or distribution to third parties. If you have received this message incorrectly, please notify the sender and proceed with its deletion. In accordance with the provisions of the EU Regulation 2016/679 of April 27, 2016 General Data Protection, you are informed that the company AC CAMERFIRMA, S.A. will treat the information you provide us with the sole purpose of complying with the obligations derived from the commercial or contractual relationship acquired with you and that your data will not be subject to another treatment or assignment to third parties except in cases where there is an legal obligation. You have the right to obtain confirmation about your personal data treatement, and to exercise your rights of access, rectification, deletion, limitation and portability, contacting AC CAMERFIRMA, SA, by written communication sent to the address C / Ribera del Loira 12 (28042) Madrid, or to the legal address jurid...@camerfirma.com or through the website http://webcrm.camerfirma.com/incidencias/incidencias.php -Mensaje original- De: dev-security-policy [mailto:dev-security-policy-boun...@lists.mozilla.org] En nombre de Wayne Thayer via dev-security-policy Enviado el: jueves, 27 de septiembre de 2018 0:38 Para: Ramiro Muñoz Muñoz CC: mozilla-dev-security-policy Asunto: Re: AC Camerfirma's CP & CPS disclosure Hello Ramiro, On Tue, Sep 4, 2018 at 3:13 PM Wayne Thayer wrote: > Thank you for this response Ramiro. I have copied this to the bug [1] > and have described Mozilla's expectations for point-in-time audits > that confirm that these issues have been resolved. > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1478933 > > On Tue, Sep 4, 2018 at 5:47 AM ramirommunoz--- via dev-security-policy > < dev-security-policy@lists.mozilla.org> wrote: > >> >> 7- List of steps your CA is taking to resolve the situation and >> ensure such issuance will not be repeated in the future, accompanied >> with a timeline of when your CA expects to accomplish these things. >> >> AC Camerfirma has made changes in the CP/CPS to fix the >> inconsistences found by the auditor and will disseminate the >> documents and the new procedures to avoid news problems in a future. >> AC Camerfirma is working on correcting the imbalances detected and >> the effective processes to ensure that the information offered by the >> OCSP and the CRL is the same. >> 2018-07-14 -> Qualified Audit Report >> 2018-09-17 -> CPS & CP's new versions will be disclosed New >> procedures and CPS/CP versions will be distributed among all affected >> people in other to avoid new differences between CP/CPS New >> procedures for self-assessment include full revision of OV >> certificates. >> Best control over changes in the BR version and modifications in AC >> Camerfirma CP/CPS. >> 2018-09-17 -> Finish a full review of the OCSP DDBB and >> synchronization with the PKI DDBB. >> 2018-09-24 -> fixed all inconsistences found. We've reviewed the >> complete databases and checked the correct OCSP/PKI/CRL alignment, >> correcting the problems found. >> 2018-10-01 -> Technical control to avoid inconsistences. We've >>
RE: Re: Google Trust Services Root Inclusion Request
Sorry, I don't agree with this point. Ryan Sleevi is the Mozilla Module Peer that gave too many pressures to the M.D.S.P community to misleading the Community and to let Mozilla make the decision that Google want. There are two facts to support my opinion: (1) For StartCom sanction, Mozilla agreed in Oct 2nd 2016 London meeting that if we separate StartCom completely from WoSign, then Mozilla don't sanction StartCom that still trust StartCom root. But Google as peer of Mozilla Module don't agree this, and Ryan even found many very very old problems of StartCom to be a "fact" that must be distrusted. Google changed the Mozilla decision! (2) For Symantec sanction, everyone can see the argues in M.D.S.P discussion from Ryan Sleevi that Google changed the Mozilla initial decision, this also is the fact. So, we can see Ryan not just a Mozilla Module Peer, he represents Google browser that affect Mozilla to make the right decision. Ryan, don't feel too good about yourself. Peoples patiently look at your long emails at M.D.S.P and listen to your bala bala speaking at the CABF meeting, this is because you represent Google Chrome, and Google Chrome seriously affects Mozilla that have the power to kill any CAs. If you leave Google, you will be nothing, no one will care about your existence, and no one will care what you say. So, please don't declare that you don't represent Google before you speak next time, nonsense! Your myopic has brought global Internet security to the ditch. Chrome display "Secure" for a website just it has SSL(https). Many fake banking websites and fake PayPal websites have Lets Encrypt certificates, and Google Chrome say it is "Secure", this completely misleads global Internet users, resulting in many users are deceived and lost property. Encryption is not equal to secure. Secure means not only encryption, but also need to tell user the website's true identity. Does a fake bank website encryption mean anything? nothing and more worse. Ryan, 别自我感觉太好，别人耐心看你在M.D.S.P的长篇大论和听你在CABF meeting上说过没完 ，是因为你代表谷歌浏览器，而谷歌浏览器严重影响Mozilla对所有CA有生杀大权。如果你离开谷歌，你将什么也不是，没有人会理会你的存在，也没有人会在意你说的话。所以下次不要在发言之前就声明不代表谷歌，废话哦！ 你的短视把全球互联网安全带到了沟里，认为有SSL证书(https)就安全，许多假冒银行网站、假冒PayPal 网站都有Lets Encrypt证书，谷歌浏览器显示为安全，完全误导了全球互联网用户，导致许多用户上当受骗和财产损失。已加密并不等于安全，安全不仅意味着需要加密，而且还需要告知用户此网站的真实身份，一个假冒银行网站加密有任何意义吗？没有并且更糟糕。 Best Regards, Richard Wang Original Message From: Ryan Sleevi via dev-security-policy Received: Thursday, 27 September 2018 00:53 To: Jeremy Rowley Cc: Ryan Sleevi ; mozilla-dev-security-policy Subject: Re: Google Trust Services Root Inclusion Request On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley wrote: > I also should also emphasize that I’m speaking as Jeremy Rowley, not as > DigiCert. > > > > Note that I didn’t say Google controlled the policy. However, as a module > peer, Google does have significant influence over the policy and what CAs > are trusted by Mozilla. Although everyone can participate in Mozilla > discussions publicly, it’s a fallacy to state that a general participant > has similar sway or authority to a module peer. That’s the whole point of > having a separate class for peers compared to us general public. With > Google acting as a CA and module peer, you now have one CA heavily > influencing who its competitors are, how its competitors operate, and what > its competitors can do. Although I personally find that you never misuse > your power as a module peer, I can see how Jake has concerns that Google > (as a CA) has very heavy influence over the platform that has historically > been the CA watchdog (Mozilla). > Jeremy, I think this again deserves calling out, because this is misrepresenting what module peership does, as well as the CA relationship. I linked you to the definition of Module Ownership, which highlights and emphasizes that the module peer is simply a recognized helper. To the extent there is any influence, it is through the public discussions here. If your concern is that the title confers some special advantage, that's to misread what module peer is. If your concern is that the participation - which provides solid technical arguments as well as the policy alternatives - is influential, then what you're arguing against is public participation. You're presenting these as factual, and that's misleading, so I'd like to highlight what is actually entailed. > The circumstances are different between the scenarios you describe with > respect to the other browsers, as is market share. If Microsoft wants to > change CAs (and they already use multiple), they can without impacting > public perception. If Apple wants to use another CA, they can without > people commenting how odd it is that Apple doesn’t use the Apple CA. With > Google controlling the CA and the Google browser, all incentive to > eliminate any misbehaving Google CA disappears for financial reasons, > public perception, and because Google can control the messaging
RE: Re: Re: Google Trust Services Root Inclusion Request
Hi Ryan, Thanks for your point out the link "https://wiki.mozilla.org/CA:WoSign_Issues'. I think I need to say more words about "misleading" and "lie". I like to expose some FACTs to show the public, to let public know who is misleading and lie. For the initiate WoSign issues email in M.D.S.P in Aug 24, 2016 -- Issue 0 (a.k.a. Issue L: Any Port (Jan - Apr 2015), Mozilla wrote: "This problem was reported to Google, and thence to WoSign and resolved. Mozilla only became aware of it recently.” The FACT is Google Ryan Sleevi sent email to Richard Wang at April 4th 2015 to point out the problems (see below original email), NOT WoSign reported to Google, this is the first misleading and lie. The second "lie" is Ryan Sleevi is the Mozilla Module Peer, this mean Mozilla know this case, why someone say “Mozilla only became aware of it recently."(August 24, 2016)? This is second misleading and lie. - Original Message From: Ryan Sleevi Received: Saturday, 04 April 2015 09:25 To: Richard Wang Subject: WoSign Irregularities Hi Richard, It's come to our attention that WoSign may be issuing certificates that are not conforming to your CPS and not conforming to the Baseline Requirements. While we're still investigating the nature and scope, I was hoping you could take the opportunity and ensure that the certificates you're issuing are consistent with the Baseline Requirements and consistent to your CPS. Among other things, I've noted irregularities in: - Subject Information - Extensions - Certificate Policies - Issuer Alternative Name Could you please examine your certificates and let me know of any irregularities that you have detected and what steps have been taken (per Section 8.2 of your CPS) Also, can you please provide your most recent audit? The most recent BR audit available was for the period of 1 January 2013 through 31 December 2013, completed on 28 March 2014. I see you've already completed Seals 1843 (Principles & Practices) and 1842 (EV). When do you expect an audit for the period of 1 January 2014 through 31 December 2014 to be made available? --- Best Regards, Richard Wang Original Message From: Ryan Sleevi via dev-security-policy Received: Thursday, 27 September 2018 00:44 To: Richard Wang Cc: Ryan Sleevi ; mozilla-dev-security-policy ; Jeremy Rowley Subject: Re: Re: Google Trust Services Root Inclusion Request Hi Richard, A few corrections: On Wed, Sep 26, 2018 at 11:36 AM Richard Wang via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Ryan mentioned WoSign/StartCom and 360, so I like to say some words. > > First, I think your idea is not a proper metaphor because 360 browser > can't compare to Google browser, Google browser have absolutely strong > market share to say YES/NO to all CAs, but I am sure not to Google CA. > That wasn't the comparison. I was more highlighting how you actively mislead (lied?) to the community about the relationship between the entities, by trying to argue as separate entities. While Google Trust Services is a separate legal entity, which is about ensuring there is a firewall between these organizations, my concern about bringing it up was because of how you actively mislead the community. > Third, your comparison of Apple and Microsoft is also not correct, they > use its own CA system for their own system use only, not for public, not to > be a global public CA like Google. > I'm afraid this also misunderstands things. Microsoft does issue certificates for end-users using its services (like Google). To the point of the discussion, however, it was about the assumption and implication that you cannot distrust an entity that operates a large web presence and also a CA, or that browsers would play special favors to the CAs of their properties, whether in-house or external. Both of these apply to all browsers - arguably, even Mozilla (which uses certs from DigiCert as well, either through the Amazon-branded sub-CA that DigiCert operates or directly through DigiCert) > Ryan, thank you for still remembering WoSign. > I think it will be very hard for the community to ever forget https://wiki.mozilla.org/CA:WoSign_Issues ___ 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
