Re: Guang Dong Certificate Authority (GDCA) root inclusion request
在 2016年11月16日星期三 UTC+8上午1:11:05,Han Yuwei写道: > 在 2016年11月15日星期二 UTC+8下午7:03:07,wangs...@gmail.com写道: > > 在 2016年11月15日星期二 UTC+8上午8:51:25,Kathleen Wilson写道: > > > On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote: > > > > We have uploaded the lastest translantion of CP/CPS. > > > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543 > > > > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545 > > > > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546 > > > > EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547 > > > > > > > > Because of our English level, there maybe some mistakes. If you have > > > > any questions, please contact us. > > > > > > > > > Thanks to all of you who have reviewed and commented on this request from > > > Guangdong Certificate Authority (GDCA) is to include the "GDCA TrustAUTH > > > R5 ROOT" certificate, turn on the Websites trust bit, and enabled EV > > > treatment. > > > > > > There were some recommendations to deny this request due to the > > > versioning problems between the English documents and the original > > > documents. > > > > > > Do you all still feel that is the proper answer to this root inclusion > > > request? > > > > > > Or should we proceed with reviewing these new English translations of the > > > documents, and make our decision based on the new versions? > > > > > > Thanks, > > > Kathleen > > > > Because we misunderstand that we only need to provide the related chapters > > of CP/CPS in English, and non-related sections are not required. We are > > terribly sorry that we misinterpreted your requirement and upload an > > inconsistent CP/CPS in English. Someone inferred that we don’t utilize a > > version control for CP/CPS. In fact, we do have a strict control for master > > version CP/CPS (see section 1.5 in CP/CPS). > > We understand that it is our responsibility to provide accurate English > > versions and ensure consistency and synchronicity between Chinese and > > English versions. Hence, we have decided to strictly implement version > > controlling of English version CP/CPS according to section 1.5 in CP/CPS. > > The auditor is reviewing our complete CP/CPS in English and the new version > > will be published as soon as possible. > > We will keep open mind to process any further issues. > > Ok, this is what I want to see. Maybe next time you could be more specific > about the problems and not just like "translation problem". If you can't > describe your opinion exactly in English you can use Chinese and let others > translate. But it's best for you to hire a professional translator. > Since CPS is very critical, I hope you understand what I said before. I don't > want another Wosign incident happen again. Thanks for proposing many good questions, which push us to utilize version controls for English CP/CPS. We are looking forward to your further comments and suggestions. We plan to attend the CA/B Forum meetings in February next year, If it is lucky to meet you there, we are looking forward to have your consultation and suggestions. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
UI Improvement in Certificate details
Li-Chun CHEN from Chunghwa Telecom would like to push for a UI improvement to properly display subject information in certificate details for FF (and others). In order to assist him, I prepared some text to be included in an improvement bug for Mozilla products and will try sending similar information to Microsoft and other Application Software Suppliers. --- BEGIN quote --- Subject: "UI Improvement in Certificate details" In order for certificate details to be humanly readable, certain OIDs used in Certificate details (such as subject information for OV and EV SSL Certificates), need to be replaced by a proper field description. This topic was discussed during the CA/B Forum F2F meeting 39. [link to the minutes] We kindly ask that the following OIDs are properly displayed in the corresponding Mozilla Certificate details code. 2.5.4.5 --> Serial Number 2.5.4.9 --> Street Address 2.5.4.15 --> Business Category 2.5.4.17 --> Postal Code 1.3.6.1.4.1.311.60.2.1.1 --> Jurisdiction of Incorporation Locality 1.3.6.1.4.1.311.60.2.1.2 --> Jurisdiction of Incorporation State or Province 1.3.6.1.4.1.311.60.2.1.3 --> Jurisdiction of Incorporation Country --- END quote --- I am struggling to find a proper bugzilla category so that the "bug" gets properly addressed. * Is it part of the core? (https://bugzilla.mozilla.org/describecomponents.cgi?product=Core) * Is it part of the nss? (https://bugzilla.mozilla.org/describecomponents.cgi?product=NSS) * Is it part of the firefox? (https://bugzilla.mozilla.org/describecomponents.cgi?product=firefox) * Is there something else more appropriate? And from there, which is the most appropriate sub-category? (so many options to choose from and I am not entirely familiar with the structure). Any help would be appreciated. Thank you, Dimitris Zacharopoulos. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
在 2016年11月16日星期三 UTC+8上午6:35:22,Kathleen Wilson写道: > On Tuesday, November 15, 2016 at 10:41:28 AM UTC-8, Peter Bowen wrote: > > I think Mozilla needs to update its guidance to CAs. The information > > checklist directions > > (https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices) > > says "If the CP/CPS documents are not in English, then the portions of > > those documents pertaining to verification of the certificate > > subscriber must be translated into English." > > Done... > https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices > now says: "If the CP/CPS documents are not in English, then the CP/CPS > documents that are relevant to the root inclusion request must be translated > into English." > > Also updated > https://wiki.mozilla.org/CA:Recommended_Practices#Publicly_Available_CP_and_CPS > to add the second sentence to the 3rd bullet point: > "The CP/CPS should be available in an English version. The non-English > version may be authoritative (as that's the working language of the CA) but > the CA is responsible for ensuring that the translation is not materially > different from the authoritative version of the document." > > Note that this is also on our list of things to add directly to the policy: > https://github.com/mozilla/pkipolicy/issues/6 > > > > > > This makes me think that the expectation is not that the full doc is > > in English and that a one-time translation is acceptable. > > > > I don't think we should hold it against GDCA that Mozilla's > > requirements have apparently changed. > > Fair enough. > > Before asking folks to review the documents again... > > Would a representative of GDCA please confirm that the following translations > are correct to the best of their knowledge? > Please also confirm that these documents match the corresponding version of > the document in Chinese (no material differences). > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543 > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545 > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546 > EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547 > > > Thanks, > Kathleen Now we have a good understanding of the latest policy of Mozilla. We have sent a complete CP/CPS in English to our auditor. They will review the documents to ensure it is consistent with the Chinese version and meets the latest requirements. The CP/CPS in English will be revised and approved in light of Section 1.5 in CP/CPS after receiving feedback from the auditor, and will be published in our website before November 22nd 23:59 (Beijing time). We hope everyone can have a discussion based on the newly published versions. Thanks to all for your understanding and suggestions to GDCA. We will keep an open mind to process any further issues. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Technically Constrained Sub-CAs
On Tue, Nov 15, 2016 at 7:27 AM, Gervase Markham wrote: > I certainly think our view of redaction will be driven by use cases. > AIUI, you are strongly encouraging use cases to be brought to the IETF. > However, if 6962bis is in Last Call, and won't be updated, is the TRANS > group still listening to and accumulating use cases for redaction? (Chrome/Google hat) 6962-bis has completed WGLC. It describes the base mechanism for logging certificates - but makes no statements about the policy (e.g. when it is appropriate to log a certificate). It describes, at present, a single technical mean to avoid logging a certificate. This is covered in https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-20#section-4 The TRANS WG also seems to have rough consensus to continue to discuss https://datatracker.ietf.org/doc/draft-strad-trans-redaction/ on the path to adoption. This draft would define additional methods for redaction, as driven by the use cases, for which you could log a 'certificate' in a way with less information than the methods provided by 6962-bis. So the topic of redaction is by no means closed. Rather, it's being worked on in parallel, with 6962-bis defining the 'base' technology, and the redaction I-D covering more of the nuanced use cases. You might imagine this as the distinction between 'certificates' and 'precertificates' within the existing CT ecosystem. A 'precertificate' has a specific prescribed shape and signalling, and when implemented, is 'as good as' logging the certificate. Similarly, the redaction ID defines a specific shape of how to restrict some information from being logged - without setting any policies on when it may or may not be appropriate to employ that method, versus say 6962-bis full certificate logging, or when 6962-bis' existing defined mechanism may not be sufficient. So the policy is disjoint from the technology (as IETF is awful with policy and tries to avoid it, thankfully); the I-D describing the technical forms to address the use cases is still under active work, but in order to ensure a timely completion, we (Chrome) want to make sure the use cases are fed in as much as possible early in the process, to allow sufficient exploration of a technical solution, and if a technical solution isn't viable, to push towards a policy solution. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Technically Constrained Sub-CAs
On Tuesday, 15 November 2016 09:35:17 UTC, Jakob Bohm wrote: > The HTTPS-everywhere tendency, including the plans of some people to > completely remove unencrypted HTTP from implementations, makes it > necessary for non-public stuff connected to the Internet to get > Internet-compatible TLS certificates. > That happens to be the same as the WebPKI No. You mistake a convenience for a necessity. It is certainly _convenient_ if everything in the world trusts your claim of identity without any action but it's not _necessary_ that it must be so. If you want this convenience, you must pay us the courtesy of being open and honest. If you would rather not, too bad we don't trust you. Let me be more specific: I don't trust you. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Include Symantec-brand Class 1 and Class 2 Root Certs
This request from Symantec is to only enable the Email trust bit for the following 4 root certificates that will eventually replace the VeriSign-brand class 1 and 2 root certs that are currently included in NSS. 1) Symantec Class 1 Public Primary Certification Authority - G6 2) Symantec Class 2 Public Primary Certification Authority - G6 3) Symantec Class 1 Public Primary Certification Authority - G4 4) Symantec Class 2 Public Primary Certification Authority - G4 The G6 root certs are SHA-256, and the G4 root certs are ECC. If there are no objections or concerns about this request, then I will recommend approval in the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=833986 Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Technically Constrained Sub-CAs
On Tue, Nov 15, 2016 at 04:27:09PM +0100, Gervase Markham wrote: > I certainly think our view of redaction will be driven by use cases. > AIUI, you are strongly encouraging use cases to be brought to the IETF. > However, if 6962bis is in Last Call, and won't be updated, is the TRANS > group still listening to and accumulating use cases for redaction? AFAIK, the trans WG isn't shutting down after 6962bis is published. There's a redaction draft that's gotten some support for being worked on, at least, so I'd be surprised if plausible use cases for redaction weren't given an open hearing. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
On Tuesday, November 15, 2016 at 10:41:28 AM UTC-8, Peter Bowen wrote: > I think Mozilla needs to update its guidance to CAs. The information > checklist directions > (https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices) > says "If the CP/CPS documents are not in English, then the portions of > those documents pertaining to verification of the certificate > subscriber must be translated into English." Done... https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices now says: "If the CP/CPS documents are not in English, then the CP/CPS documents that are relevant to the root inclusion request must be translated into English." Also updated https://wiki.mozilla.org/CA:Recommended_Practices#Publicly_Available_CP_and_CPS to add the second sentence to the 3rd bullet point: "The CP/CPS should be available in an English version. The non-English version may be authoritative (as that's the working language of the CA) but the CA is responsible for ensuring that the translation is not materially different from the authoritative version of the document." Note that this is also on our list of things to add directly to the policy: https://github.com/mozilla/pkipolicy/issues/6 > > This makes me think that the expectation is not that the full doc is > in English and that a one-time translation is acceptable. > > I don't think we should hold it against GDCA that Mozilla's > requirements have apparently changed. Fair enough. Before asking folks to review the documents again... Would a representative of GDCA please confirm that the following translations are correct to the best of their knowledge? Please also confirm that these documents match the corresponding version of the document in Chinese (no material differences). CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543 CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545 EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546 EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547 Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Audit Reminder Email Summary
Here's a summary of the audit reminder emails that were sent today. The following is now automatically generated when the audit reminder emails get sent. Forwarded Message Subject: Summary of November 2016 Audit Reminder Emails Date: Tue, 15 Nov 2016 20:00:42 + (GMT) Mozilla: Audit Reminder Root Certificates: ISRG Root X1 Standard Audit: https://cert.webtrust.org/SealFile?seal=1987&file=pdf Audit Statement Date: 2015-12-15 BR Audit: https://cert.webtrust.org/SealFile?seal=1988&file=pdf BR Audit Statement Date: 2015-12-15 CA Comments: null Mozilla: Audit Reminder Root Certificates: EE Certification Centre Root CA Standard Audit: http://www.sk.ee/en/repository/audit/ Audit Statement Date: 2015-10-30 BR Audit: https://www.sk.ee/upload/files/53_Audit%20Attestation%202015.pdf BR Audit Statement Date: 2015-10-30 CA Comments: null Mozilla: Audit Reminder Root Certificates: CA Disig Root R1 CA Disig Root R2 Standard Audit: http://www.disig.eu/_pdf/Audit2015_report.pdf Audit Statement Date: 2015-10-28 BR Audit: http://www.disig.eu/_pdf/Audit2015_report.pdf BR Audit Statement Date: 2015-10-28 CA Comments: null Mozilla: Audit Reminder Root Certificates: ACEDICOM Root Standard Audit: https://cert.webtrust.org/SealFile?seal=1958&file=pdf Audit Statement Date: 2015-11-03 BR Audit: https://cert.webtrust.org/SealFile?seal=1958&file=pdf BR Audit Statement Date: 2015-11-03 CA Comments: null Mozilla: Overdue Audit Statements Root Certificates: Root CA Generalitat Valenciana Standard Audit: https://cert.webtrust.org/SealFile?seal=1908&file=pdf Audit Statement Date: 2015-07-17 BR Audit: https://cert.webtrust.org/SealFile?seal=1908&file=pdf BR Audit Statement Date: 2015-07-17 CA Comments: Per CA request, Root CA Generalitat Valenciana will be removed via https://bugzilla.mozilla.org/show_bug.cgi?id=1272158 Mozilla: Overdue Audit Statements Root Certificates: Class 2 Primary CA Standard Audit: http://www.lsti-certification.fr/images/liste_entreprise/Liste%20PSCe.pdf Audit Statement Date: 2015-04-09 BR Audit: https://bug1025095.bugzilla.mozilla.org/attachment.cgi?id=8590352 BR Audit Statement Date: 2015-04-09 EV Audit: http://www.lsti-certification.fr/images/liste_entreprise/Liste%20PSCe.pdf EV Audit Statement Date: 2015-04-09 CA Comments: https://bugzilla.mozilla.org/show_bug.cgi?id=1297034 Did not find reference to "Class 2 Primary CA" in the 2016 audit statements. Update: Audit of Class 2 Primary CA completed mid-October. Waiting for auditor to write attestation letter. Mozilla: Audit Reminder Root Certificates: Secure Global CA SecureTrust CA XRamp Global Certification Authority Standard Audit: https://cert.webtrust.org/SealFile?seal=1951&file=pdf Audit Statement Date: 2015-11-16 BR Audit: https://cert.webtrust.org/SealFile?seal=1954&file=pdf BR Audit Statement Date: 2015-11-16 EV Audit: https://cert.webtrust.org/SealFile?seal=1952&file=pdf EV Audit Statement Date: 2015-11-16 CA Comments: null Mozilla: Audit Reminder Root Certificates: CFCA EV ROOT Standard Audit: https://cert.webtrust.org/SealFile?seal=1944&file=pdf Audit Statement Date: 2015-10-16 BR Audit: https://cert.webtrust.org/SealFile?seal=1946&file=pdf BR Audit Statement Date: 2015-10-16 EV Audit: https://cert.webtrust.org/SealFile?seal=1945&file=pdf EV Audit Statement Date: 2015-10-16 CA Comments: null ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
On Tue, Nov 15, 2016 at 3:02 AM, wrote: > > Because we misunderstand that we only need to provide the related chapters of > CP/CPS in English, and non-related sections are not required. We are terribly > sorry that we misinterpreted your requirement and upload an inconsistent > CP/CPS in English. Someone inferred that we don’t utilize a version control > for CP/CPS. In fact, we do have a strict control for master version CP/CPS > (see section 1.5 in CP/CPS). > We understand that it is our responsibility to provide accurate English > versions and ensure consistency and synchronicity between Chinese and English > versions. Hence, we have decided to strictly implement version controlling of > English version CP/CPS according to section 1.5 in CP/CPS. The auditor is > reviewing our complete CP/CPS in English and the new version will be > published as soon as possible. > We will keep open mind to process any further issues. I think Mozilla needs to update its guidance to CAs. The information checklist directions (https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices) says "If the CP/CPS documents are not in English, then the portions of those documents pertaining to verification of the certificate subscriber must be translated into English." This makes me think that the expectation is not that the full doc is in English and that a one-time translation is acceptable. I don't think we should hold it against GDCA that Mozilla's requirements have apparently changed. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
On Tuesday, November 15, 2016 at 6:03:07 AM UTC-5, wangs...@gmail.com wrote: > 在 2016年11月15日星期二 UTC+8上午8:51:25,Kathleen Wilson写道: > > On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote: > > > We have uploaded the lastest translantion of CP/CPS. > > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543 > > > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545 > > > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546 > > > EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547 > > > > > > Because of our English level, there maybe some mistakes. If you have any > > > questions, please contact us. > > > > > > Thanks to all of you who have reviewed and commented on this request from > > Guangdong Certificate Authority (GDCA) is to include the "GDCA TrustAUTH R5 > > ROOT" certificate, turn on the Websites trust bit, and enabled EV > > treatment. > > > > There were some recommendations to deny this request due to the versioning > > problems between the English documents and the original documents. > > > > Do you all still feel that is the proper answer to this root inclusion > > request? > > > > Or should we proceed with reviewing these new English translations of the > > documents, and make our decision based on the new versions? > > > > Thanks, > > Kathleen > > Because we misunderstand that we only need to provide the related chapters of > CP/CPS in English, and non-related sections are not required. We are terribly > sorry that we misinterpreted your requirement and upload an inconsistent > CP/CPS in English. Someone inferred that we don’t utilize a version control > for CP/CPS. In fact, we do have a strict control for master version CP/CPS > (see section 1.5 in CP/CPS). > We understand that it is our responsibility to provide accurate English > versions and ensure consistency and synchronicity between Chinese and English > versions. Hence, we have decided to strictly implement version controlling of > English version CP/CPS according to section 1.5 in CP/CPS. The auditor is > reviewing our complete CP/CPS in English and the new version will be > published as soon as possible. > We will keep open mind to process any further issues. Read through this discussion thread, here is my take on this. GDCA has taken action to address the discrepancies between English and Chinese CP/CPS and put in place stricter version control. So we should look at the updated version, if that's deemed good I don't see other reason to reject. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
On 15/11/2016 18:10, Han Yuwei wrote: 在 2016年11月15日星期二 UTC+8下午7:03:07,wangs...@gmail.com写道: 在 2016年11月15日星期二 UTC+8上午8:51:25,Kathleen Wilson写道: On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote: We have uploaded the lastest translantion of CP/CPS. CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543 CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545 EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546 EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547 Because of our English level, there maybe some mistakes. If you have any questions, please contact us. Thanks to all of you who have reviewed and commented on this request from Guangdong Certificate Authority (GDCA) is to include the "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and enabled EV treatment. There were some recommendations to deny this request due to the versioning problems between the English documents and the original documents. Do you all still feel that is the proper answer to this root inclusion request? Or should we proceed with reviewing these new English translations of the documents, and make our decision based on the new versions? Thanks, Kathleen Because we misunderstand that we only need to provide the related chapters of CP/CPS in English, and non-related sections are not required. We are terribly sorry that we misinterpreted your requirement and upload an inconsistent CP/CPS in English. Someone inferred that we don’t utilize a version control for CP/CPS. In fact, we do have a strict control for master version CP/CPS (see section 1.5 in CP/CPS). We understand that it is our responsibility to provide accurate English versions and ensure consistency and synchronicity between Chinese and English versions. Hence, we have decided to strictly implement version controlling of English version CP/CPS according to section 1.5 in CP/CPS. The auditor is reviewing our complete CP/CPS in English and the new version will be published as soon as possible. We will keep open mind to process any further issues. Ok, this is what I want to see. Maybe next time you could be more specific about the problems and not just like "translation problem". If you can't describe your opinion exactly in English you can use Chinese and let others translate. But it's best for you to hire a professional translator. Since CPS is very critical, I hope you understand what I said before. I don't want another Wosign incident happen again. Note that he said most of these things already in his post dated Thu, 27 Oct 2016 03:21:53 -0700 (PDT) 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: Guang Dong Certificate Authority (GDCA) root inclusion request
在 2016年11月15日星期二 UTC+8下午7:03:07,wangs...@gmail.com写道: > 在 2016年11月15日星期二 UTC+8上午8:51:25,Kathleen Wilson写道: > > On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote: > > > We have uploaded the lastest translantion of CP/CPS. > > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543 > > > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545 > > > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546 > > > EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547 > > > > > > Because of our English level, there maybe some mistakes. If you have any > > > questions, please contact us. > > > > > > Thanks to all of you who have reviewed and commented on this request from > > Guangdong Certificate Authority (GDCA) is to include the "GDCA TrustAUTH R5 > > ROOT" certificate, turn on the Websites trust bit, and enabled EV > > treatment. > > > > There were some recommendations to deny this request due to the versioning > > problems between the English documents and the original documents. > > > > Do you all still feel that is the proper answer to this root inclusion > > request? > > > > Or should we proceed with reviewing these new English translations of the > > documents, and make our decision based on the new versions? > > > > Thanks, > > Kathleen > > Because we misunderstand that we only need to provide the related chapters of > CP/CPS in English, and non-related sections are not required. We are terribly > sorry that we misinterpreted your requirement and upload an inconsistent > CP/CPS in English. Someone inferred that we don’t utilize a version control > for CP/CPS. In fact, we do have a strict control for master version CP/CPS > (see section 1.5 in CP/CPS). > We understand that it is our responsibility to provide accurate English > versions and ensure consistency and synchronicity between Chinese and English > versions. Hence, we have decided to strictly implement version controlling of > English version CP/CPS according to section 1.5 in CP/CPS. The auditor is > reviewing our complete CP/CPS in English and the new version will be > published as soon as possible. > We will keep open mind to process any further issues. Ok, this is what I want to see. Maybe next time you could be more specific about the problems and not just like "translation problem". If you can't describe your opinion exactly in English you can use Chinese and let others translate. But it's best for you to hire a professional translator. Since CPS is very critical, I hope you understand what I said before. I don't want another Wosign incident happen again. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 Phase-out
On Tue, Nov 15, 2016 at 7:25 AM, Kurt Roeckx wrote: > > - If it's an enterprise root they need to switch to SHA-2 This is a lot easier said than done for many organizations. Depending on the CA software this might be a small configuration change or might involve a very large software upgrade. I think the key question here is whether Firefox will have an option to do two things: 1) Continue to accept signatures over SHA-1 hashes for end-entity certificates 2) Continue to accept signatures over SHA-1 hashes for CA certificates in the chain While these may seem similar (in fact from a crypto risk perspective #2 is probably worse than #1), they frequently represent different amounts of work required to mitigate for organizations. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Technically Constrained Sub-CAs
On 15/11/16 05:39, Ryan Sleevi wrote: > I think it'd be useful to resolve the questions I asked on this thread > - > https://groups.google.com/d/msg/mozilla.dev.security.policy/ZMUjQ6xHrDA/ySofsF_PAgAJ > - to figure out what Mozilla expects/wants of TCSCs with respect to > the BRs, as that seems like it would significantly affect how you want > CT to play or not play in that role. I think the answer to that question is that in general, TCSCs need to adhere to the BRs but there may be some bits we don't need them to adhere to. We should clarify our policy on this point. https://github.com/mozilla/pkipolicy/issues/36 > As Andrew Ayer points out, currently, CAs are required to ensure TCSCs > comply with the BRs. Non-compliance is misissuance. Does Mozilla share > that view? And is Mozilla willing to surrender the ability to detect > misissuance, in favor of something which clearly doesn't address the > use cases for redaction identified in the CA/Browser Forum and in the > IETF? I certainly think our view of redaction will be driven by use cases. AIUI, you are strongly encouraging use cases to be brought to the IETF. However, if 6962bis is in Last Call, and won't be updated, is the TRANS group still listening to and accumulating use cases for redaction? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 Phase-out
On 2016-11-15 16:19, Gervase Markham wrote: On 15/11/16 12:20, jansomar...@gmail.com wrote: I would step in to your discussion if you don't mind. My question is very similar to the original one but in regards to internal usage of SHA-1 signed certs. We are running large number of network devs devs == devices, rather than developers? acting as a proxy and users need to authenticate in order to access some of the applications. It's an internal closed environment and all the devices are using self-signed certificates. Will something change for us when Mozilla disabled SHA-1 certs? Are you sure you mean self-signed certs? Every time a user accesses a new application, they get a security error they have to override? Or do you mean you have a private enterprise root which you add to web browsers, and which issue all these certs for you? I guess the answer for both cases are: - If it's an enterprise root they need to switch to SHA-2 - If it's self-signed we don't care about the signature algorithm. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 Phase-out
On 15/11/16 12:20, jansomar...@gmail.com wrote: > I would step in to your discussion if you don't mind. My question is > very similar to the original one but in regards to internal usage of > SHA-1 signed certs. We are running large number of network devs devs == devices, rather than developers? > acting as a proxy and users need to authenticate in order to access > some of the applications. It's an internal closed environment and all > the devices are using self-signed certificates. Will something change > for us when Mozilla disabled SHA-1 certs? Are you sure you mean self-signed certs? Every time a user accesses a new application, they get a security error they have to override? Or do you mean you have a private enterprise root which you add to web browsers, and which issue all these certs for you? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
Agree with Gerv & Tony, More patience should be given if they want to improve. And I don’t think “I posted on the solidot (Chinese Slashdot) about this. The majority comments want the application rejected. “is enough to be the reason to reject the request. For many Chinese companies, they do need to learn how to work with global community, they might even have language issues to use English as the working language, for Guang Dong CA case, I can see they are willing to work with the community and we should encourage them to do more. Thanks, Xiaosheng Tan 在 2016/11/15 下午9:08,“dev-security-policy 代表 Tony” 写入: 在 2016年11月15日星期二 UTC+8下午5:53:19,Gervase Markham写道: > On 15/11/16 08:39, Percy wrote: > > I posted on the solidot (Chinese Slashdot) about this. The majority > > comments want the application rejected. > > https://translate.google.com/translate?hl=en&sl=zh-CN&tl=en&u=http%3A%2F%2Fwww.solidot.org%2Fstory%3Fsid%3D50368 > > That fact, by itself, is not useful information. It would help if you > were to summarise why people feel the application should be rejected, > and how those reasons map to Mozilla's policy requirements. > > Gerv Agreed with Gerv, the reasons for rejection/improvements should be listed very clearly in this case, considering the positive actions taken by CA as it will publish the full new version of CP/CPS in English and implement version control on EN CP/CPS. It's common that Chinese company only maintains one master file policy which is in Chinese based on experience. But if they can do one version control on EN policies, even from now on, it should be deemed as a good improvement. Also, guidance for coaching the CA to enhance the internal controls for the future is needed. More patience shall be given. ___ 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: Guang Dong Certificate Authority (GDCA) root inclusion request
在 2016年11月15日星期二 UTC+8下午5:53:19,Gervase Markham写道: > On 15/11/16 08:39, Percy wrote: > > I posted on the solidot (Chinese Slashdot) about this. The majority > > comments want the application rejected. > > https://translate.google.com/translate?hl=en&sl=zh-CN&tl=en&u=http%3A%2F%2Fwww.solidot.org%2Fstory%3Fsid%3D50368 > > That fact, by itself, is not useful information. It would help if you > were to summarise why people feel the application should be rejected, > and how those reasons map to Mozilla's policy requirements. > > Gerv Agreed with Gerv, the reasons for rejection/improvements should be listed very clearly in this case, considering the positive actions taken by CA as it will publish the full new version of CP/CPS in English and implement version control on EN CP/CPS. It's common that Chinese company only maintains one master file policy which is in Chinese based on experience. But if they can do one version control on EN policies, even from now on, it should be deemed as a good improvement. Also, guidance for coaching the CA to enhance the internal controls for the future is needed. More patience shall be given. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 Phase-out
Hello Guys, I would step in to your discussion if you don't mind. My question is very similar to the original one but in regards to internal usage of SHA-1 signed certs. We are running large number of network devs acting as a proxy and users need to authenticate in order to access some of the applications. It's an internal closed environment and all the devices are using self-signed certificates. Will something change for us when Mozilla disabled SHA-1 certs? As far as I could read there is a plan to have an option to override this security feature and access website anyway. Of course enabling SHA-1 in about:config is also an option but we need to prepare our users for that. Thank you very much for any qualified answer. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
在 2016年11月15日星期二 UTC+8上午8:51:25,Kathleen Wilson写道: > On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote: > > We have uploaded the lastest translantion of CP/CPS. > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543 > > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545 > > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546 > > EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547 > > > > Because of our English level, there maybe some mistakes. If you have any > > questions, please contact us. > > > Thanks to all of you who have reviewed and commented on this request from > Guangdong Certificate Authority (GDCA) is to include the "GDCA TrustAUTH R5 > ROOT" certificate, turn on the Websites trust bit, and enabled EV treatment. > > There were some recommendations to deny this request due to the versioning > problems between the English documents and the original documents. > > Do you all still feel that is the proper answer to this root inclusion > request? > > Or should we proceed with reviewing these new English translations of the > documents, and make our decision based on the new versions? > > Thanks, > Kathleen Because we misunderstand that we only need to provide the related chapters of CP/CPS in English, and non-related sections are not required. We are terribly sorry that we misinterpreted your requirement and upload an inconsistent CP/CPS in English. Someone inferred that we don’t utilize a version control for CP/CPS. In fact, we do have a strict control for master version CP/CPS (see section 1.5 in CP/CPS). We understand that it is our responsibility to provide accurate English versions and ensure consistency and synchronicity between Chinese and English versions. Hence, we have decided to strictly implement version controlling of English version CP/CPS according to section 1.5 in CP/CPS. The auditor is reviewing our complete CP/CPS in English and the new version will be published as soon as possible. We will keep open mind to process any further issues. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
On 15/11/16 08:39, Percy wrote: > I posted on the solidot (Chinese Slashdot) about this. The majority > comments want the application rejected. > https://translate.google.com/translate?hl=en&sl=zh-CN&tl=en&u=http%3A%2F%2Fwww.solidot.org%2Fstory%3Fsid%3D50368 That fact, by itself, is not useful information. It would help if you were to summarise why people feel the application should be rejected, and how those reasons map to Mozilla's policy requirements. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Technically Constrained Sub-CAs
On 14/11/2016 21:37, Nick Lamb wrote: On Monday, 14 November 2016 16:57:20 UTC, Jakob Bohm wrote: If this is the only privacy mechanism in 6962bis, I would suggest that everyone not employed by either Google or another mass-monitoring service block its adoption on human rights grounds and on the basis of being a mass-attack on network security. Whereas I would say almost the precise opposite, the Web PKI is a _public_ resource, if you don't want your certificates to be examined by the _public_ then you are in the wrong place and need to look into a private CA. Redaction has no place in public CT logs. If a private CA wants to operate redacted logs in which everything is too murky to make any useful conclusions about anything they're welcome to do just that. Google and the "information wants to be free" crowd want everything connected to the Internet to be declared public and everything to be connected to the Internet. Many others tend to disagree. The HTTPS-everywhere tendency, including the plans of some people to completely remove unencrypted HTTP from implementations, makes it necessary for non-public stuff connected to the Internet to get Internet-compatible TLS certificates. That happens to be the same as the WebPKI, thus the need for an ability to get a WebPKI certificate without announcing your address to every script-kiddie automated mass-attack tool out there. Even from this very limited perspective of protecting a subscriber from themselves, redaction falls down badly as I explained in my posts when Chromium mooted what redaction policies should be accepted earlier this year. Chromium=Google=Peeping Tom. The snooping argument amounts to very little. If you were paying attention to CT logs when greatagain.gov was launched, or if you really stare hard at all the new certificates logged for the .gov TLD you will have discovered what Hillary's transition site would have been called. But amid a media saturated with wall-to-wall with US election news, focusing on even the tiniest slivers of new information, nobody even mentioned it. Not because the White House staff have some elite redaction technology that allowed them keep it off the record but because it's just not that interesting. Maybe because that was just too insignificant to shout about, or maybe because the political journalists are not up to speed on CT yet. 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: Apple's response to the WoSign incidents
On Tuesday, November 15, 2016 at 12:37:56 AM UTC-8, Thijs Alkemade wrote: > On 13 Nov 2016, at 10:08, Percy wrote: > > > > I just found out that Apple doesn't limit "CA 沃通免费SSL证书 G2" intermediate CA > > even though Apple limited "WoSign CA Free SSL Certificate G2" intermediate > > CA. An example of site signed by"CA 沃通免费SSL证书 G2" intermediate CA is > > https://www.chelenet.com/ > > > > Those two intermediate certs are treated by WoSign the same way and the > > translation of "CA 沃通免费SSL证书 G2" is "WoSign CA Free SSL Certificate G2". > > Users can select whether the end cert is signed by "CA 沃通免费SSL证书 G2" or > > "WoSign CA Free SSL Certificate G2". All control measures are the same and > > the only difference is the language for marketing reasons. > > > > Hence, because Apple has chose to blocked "WoSign CA Free SSL Certificate > > G2", it makes sense to apply the same sanction on "CA 沃通免费SSL证书 G2", as > > they're in all senses the same. > > Hi Percy, > > I’ve been following Apple’s security updates to determine when the announced > block becomes active and how it is implemented. Using 10.11.6, with no > updates available, it appears this block is not yet active for me. There are > no errors when I try to visit https://inow.ua in Safari > (https://crt.sh/?id=43120524 appears to be the last certificate issued by > "WoSign CA Free SSL Certificate G2” which is currently still in use). In the > file > /System/Library/Security/Certificates.bundle/Contents/Resources/Allowed.plist > I only see two CINNIC roots listed. > > Could you tell us what OS and version you used to determine that Apple has > limited "WoSign CA Free SSL Certificate G2”? > > Best regards, > Thijs Alkemade You can also check this thread https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/ZFOZCFW4K-s Ryan pointed out that the whitelist has been implemented in the newest version ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Apple's response to the WoSign incidents
On Tuesday, November 15, 2016 at 12:37:56 AM UTC-8, Thijs Alkemade wrote: > On 13 Nov 2016, at 10:08, Percy wrote: > > > > I just found out that Apple doesn't limit "CA 沃通免费SSL证书 G2" intermediate CA > > even though Apple limited "WoSign CA Free SSL Certificate G2" intermediate > > CA. An example of site signed by"CA 沃通免费SSL证书 G2" intermediate CA is > > https://www.chelenet.com/ > > > > Those two intermediate certs are treated by WoSign the same way and the > > translation of "CA 沃通免费SSL证书 G2" is "WoSign CA Free SSL Certificate G2". > > Users can select whether the end cert is signed by "CA 沃通免费SSL证书 G2" or > > "WoSign CA Free SSL Certificate G2". All control measures are the same and > > the only difference is the language for marketing reasons. > > > > Hence, because Apple has chose to blocked "WoSign CA Free SSL Certificate > > G2", it makes sense to apply the same sanction on "CA 沃通免费SSL证书 G2", as > > they're in all senses the same. > > Hi Percy, > > I’ve been following Apple’s security updates to determine when the announced > block becomes active and how it is implemented. Using 10.11.6, with no > updates available, it appears this block is not yet active for me. There are > no errors when I try to visit https://inow.ua in Safari > (https://crt.sh/?id=43120524 appears to be the last certificate issued by > "WoSign CA Free SSL Certificate G2” which is currently still in use). In the > file > /System/Library/Security/Certificates.bundle/Contents/Resources/Allowed.plist > I only see two CINNIC roots listed. > > Could you tell us what OS and version you used to determine that Apple has > limited "WoSign CA Free SSL Certificate G2”? > > Best regards, > Thijs Alkemade Thijs, I'm using MacOS Sierra 10.12.1. FYI, https://inow.ua 's cert is revoked now. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
On Wednesday, August 3, 2016 at 2:45:23 PM UTC-7, Kathleen Wilson wrote: > This request from Guangdong Certificate Authority (GDCA) is to include the > "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and > enabled EV treatment. > > GDCA is a nationally recognized CA that operates under China’s Electronic > Signature Law. GDCA’s customers are business corporations registered in > mainland China, government agencies of China, individuals or mainland China > citizens, servers of business corporations which have been registered in > mainland China, and software developers. > > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1128392 > > And in the pending certificates list: > https://wiki.mozilla.org/CA:PendingCAs > > Summary of Information Gathered and Verified: > https://bugzilla.mozilla.org/attachment.cgi?id=8749437 > > Noteworthy points: > > * Root Certificate Download URL: > https://bugzilla.mozilla.org/attachment.cgi?id=8748933 > https://www.gdca.com.cn/cert/GDCA_TrustAUTH_R5_ROOT.der > > * The primary documents are provided in Chinese. > > CA Document Repository: > https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/ > http://www.gdca.com.cn/cp/cp > http://www.gdca.com.cn/cps/cps > http://www.gdca.com.cn/cp/ev-cp > http://www.gdca.com.cn/cps/ev-cps > > Translations into English: > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346 > CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749 > > * CA Hierarchy: This root certificate has internally-operated subordinate CAs > - GDCA TrustAUTH R4 SSL CA (issues 2048-bit SSL certs) > - GDCA TrustAUTH R4 Generic CA (issues 2048-bit individual certs) > - GDCA TrustAUTH R4 CodeSigning CA (issues 2048-bit CodeSigning certs) > - GDCA TrustAUTH R4 Extended Validation SSL CA (issues 2048-bit EV SSL certs) > - GDCA TrustAUTH R4 Extended Validation Code Signing CA (issues 2048-bit EV > CodeSigning certs) > > * This request is to turn on the Websites trust bit. > > CPS section 3.2.5: For domain verification, GDCA needs to check the written > materials which can be used to prove the ownership of corresponding domain > provided by applicant. Meanwhile, GDCA should ensure the ownership of domain > from corresponding registrant or other authoritative third-party databases. > During the verification, GDCA needs to perform the following procedures: > 1. GDCA should confirm that the domain's owner is certificate applicant based > on the information queried from corresponding domain registrant or > authoritative third-party database and provided by applicant. > 2. GDCA should confirm that the significant information (such as document > information of applicant) in application materials are consistent with the > reply of domain's owner by sending email or making phone call based on the > contact information (such as email, registrar, administrator's email > published at this domain's website, etc.) queried from corresponding domain > registrant or authoritative third-party database. > If necessary, GDCA also need to take other review measures to confirm the > ownership of the domain name. Applicant can't refuse to the request for > providing appropriate assistance. > > > * EV Policy OID: 1.2.156.112559.1.1.6.1 > > * Test Website: https://ev-ssl-test-1.95105813.cn/ > > * CRL URLs: > http://www.gdca.com.cn/crl/GDCA_TrustAUTH_R5_ROOT.crl > http://www.gdca.com.cn/crl/GDCA_TrustAUTH_R4_SSL_CA.crl > http://www.gdca.com.cn/crl/GDCA_TrustAUTH_R4_Extended_Validation_SSL_CA.crl > > * OCSP URL: > http://www.gdca.com.cn/TrustAUTH/ocsp > > * Audit: Annual audits are performed by PricewaterhouseCoopers Zhong Tian LLP > according to the WebTrust criteria. > WebTrust CA: https://cert.webtrust.org/SealFile?seal=2024&file=pdf > WebTrust BR: https://cert.webtrust.org/SealFile?seal=2025&file=pdf > WebTrust EV: https://cert.webtrust.org/SealFile?seal=2026&file=pdf > > * Potentially Problematic Practices: None Noted > (http://wiki.mozilla.org/CA:Problematic_Practices) > > This begins the discussion of the request from Guangdong Certificate > Authority (GDCA) to include the "GDCA TrustAUTH R5 ROOT" certificate, turn on > the Websites trust bit, and enabled EV treatment. At the conclusion of this > discussion I will provide a summary of issues noted and action items. If > there are outstanding issues, then an additional discussion may be needed as > follow-up. If there are no outstanding issues, then I will recommend approval > of this request in the bug. > > Kathleen I posted on the solidot (Chinese Slashdot) about this. The majority comments want the application rejected. https://translate.google.com/translate?hl=en&sl=zh-CN&tl=en&u=http%3A%2F%2Fwww.solidot.org%2Fstory%3Fsid%3D50368 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Apple's response to the WoSign incidents
On 13 Nov 2016, at 10:08, Percy wrote: > > I just found out that Apple doesn't limit "CA 沃通免费SSL证书 G2" intermediate CA > even though Apple limited "WoSign CA Free SSL Certificate G2" intermediate > CA. An example of site signed by"CA 沃通免费SSL证书 G2" intermediate CA is > https://www.chelenet.com/ > > Those two intermediate certs are treated by WoSign the same way and the > translation of "CA 沃通免费SSL证书 G2" is "WoSign CA Free SSL Certificate G2". > Users can select whether the end cert is signed by "CA 沃通免费SSL证书 G2" or > "WoSign CA Free SSL Certificate G2". All control measures are the same and > the only difference is the language for marketing reasons. > > Hence, because Apple has chose to blocked "WoSign CA Free SSL Certificate > G2", it makes sense to apply the same sanction on "CA 沃通免费SSL证书 G2", as > they're in all senses the same. Hi Percy, I’ve been following Apple’s security updates to determine when the announced block becomes active and how it is implemented. Using 10.11.6, with no updates available, it appears this block is not yet active for me. There are no errors when I try to visit https://inow.ua in Safari (https://crt.sh/?id=43120524 appears to be the last certificate issued by "WoSign CA Free SSL Certificate G2” which is currently still in use). In the file /System/Library/Security/Certificates.bundle/Contents/Resources/Allowed.plist I only see two CINNIC roots listed. Could you tell us what OS and version you used to determine that Apple has limited "WoSign CA Free SSL Certificate G2”? Best regards, Thijs Alkemade ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
在 2016年11月15日星期二 UTC+8上午8:51:25,Kathleen Wilson写道: > On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote: > > We have uploaded the lastest translantion of CP/CPS. > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543 > > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545 > > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546 > > EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547 > > > > Because of our English level, there maybe some mistakes. If you have any > > questions, please contact us. > > > Thanks to all of you who have reviewed and commented on this request from > Guangdong Certificate Authority (GDCA) is to include the "GDCA TrustAUTH R5 > ROOT" certificate, turn on the Websites trust bit, and enabled EV treatment. > > There were some recommendations to deny this request due to the versioning > problems between the English documents and the original documents. > > Do you all still feel that is the proper answer to this root inclusion > request? > > Or should we proceed with reviewing these new English translations of the > documents, and make our decision based on the new versions? > > Thanks, > Kathleen If GDCA insists on translation problem, I can't trust it. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy