Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

在 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

[Dimitris Zacharopoulos]

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

[wangsn1206]

在 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

[Ryan Sleevi]

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

[Nick Lamb]

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

[Kathleen Wilson]

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

[Matt Palmer]

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

[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




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Audit Reminder Email Summary

[Kathleen Wilson]

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=pdf
Audit Statement Date: 2015-12-15
BR Audit: https://cert.webtrust.org/SealFile?seal=1988=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=pdf
Audit Statement Date: 2015-11-03
BR Audit: https://cert.webtrust.org/SealFile?seal=1958=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=pdf
Audit Statement Date: 2015-07-17
BR Audit: https://cert.webtrust.org/SealFile?seal=1908=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=pdf
Audit Statement Date: 2015-11-16
BR Audit: https://cert.webtrust.org/SealFile?seal=1954=pdf
BR Audit Statement Date: 2015-11-16
EV Audit: https://cert.webtrust.org/SealFile?seal=1952=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=pdf
Audit Statement Date: 2015-10-16
BR Audit: https://cert.webtrust.org/SealFile?seal=1946=pdf
BR Audit Statement Date: 2015-10-16
EV Audit: https://cert.webtrust.org/SealFile?seal=1945=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

[Peter Bowen]

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

[Kevin]

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

[Jakob Bohm]

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

[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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA-1 Phase-out

[Peter Bowen]

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

[Gervase Markham]

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

[Kurt Roeckx]

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: 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=zh-CN=en=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

[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=zh-CN=en=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

[jansomartin]

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: Apple's response to the WoSign incidents

[Percy]

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: Guang Dong Certificate Authority (GDCA) root inclusion request

[Percy]

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=pdf
> WebTrust BR: https://cert.webtrust.org/SealFile?seal=2025=pdf
> WebTrust EV: https://cert.webtrust.org/SealFile?seal=2026=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=zh-CN=en=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

[Thijs Alkemade]

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

[Han Yuwei]

在 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