Re: Chunghwa Telecom eCA Root Inclusion Request

2018-06-05 Thread lcchen.cissp--- via dev-security-policy
lcchen...@gmail.com於 2018年6月5日星期二 UTC+8下午5時22分40秒寫道:

> 
> 1. We plan to modify the format of this type of certificate. The new 
> certificate format will contain an EKU that excludes anyPolicy, 
> emailProtection and serverAuth; besides, there will be no SubjectAltName 
> anymore. In other words, neither DNSName nor IPAddress will be included in 
> this type of certificate.

We mean that the new certificate format will contain an EKU that doesn’t 
include anyPolicy, emailProtection or serverAuth in it. Thanks.

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


Re: Chunghwa Telecom eCA Root Inclusion Request

2018-06-05 Thread lcchen.cissp--- via dev-security-policy
Wayne Thayer於 2018年5月19日星期六 UTC+8上午8時13分15秒寫道:
> This request is for inclusion of the Chunghwa Telecom eCA as documented in
> the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1341604



 
> ==Bad==
> * A large number of certificates have been misissued from the “Public
> Certification Authority - G2” intermediate [4] (recent example: [2]). Many
> of these certificates remain valid. Chunghwa Telecom has published a
> response to these errors [3] in the inclusion bug. My main concern with the
> response is the assertion that some of these are not SSL certificates bound
> to follow the BRs because they do not contain the CAB Forum OV OID in the
> certificate policies extension. This assertion contradicts section 1.1 of
> Mozilla policy.
> 
> This begins the 3-week comment period for this request [4].
> 
> I will greatly appreciate your thoughtful and constructive feedback on the
> acceptance of this root into the Mozilla CA program.
> 
> - Wayne
> 
> [1]
> https://crt.sh/?CAID=1770=cablint,zlint,x509lint=2015-01-01
> [2] https://crt.sh/?id=290793483=zlint,cablint,x509lint
> [3] https://bug1341604.bmoattachments.org/attachment.cgi?id=8974418
> [4] https://wiki.mozilla.org/CA/Application_Process

Dear Wayne,

   We have already paused the issuance of this type of certificate in argue, 
i.e., dedicated server application software certificate.

   There are 10 such type of certificates that are still valid, as listed in 
https://bugzilla.mozilla.org/attachment.cgi?id=898.

   By the way, the certificate of 
綠金石平台(https://crt.sh/?id=290793483=zlint,cablint,x509lint) that Mozilla 
mentioned in Ref [2] of Comment 55 of 
https://bugzilla.mozilla.org/show_bug.cgi?id=1341604 was revoked on May 21th 
this year, and hence not listed in this attached file.

   All these 10 certificates are used by the systems owned by our company, 
i.e., Chunghwa Telecom Co., Ltd..

   Although these 10 certificates have a SubjectAltnativeName that includes 
DNSName, they are never used as SSL certificates. Here are our solutions for 
handling these 10 certificates.

1. We plan to modify the format of this type of certificate. The new 
certificate format will contain an EKU that excludes anyPolicy, emailProtection 
and serverAuth; besides, there will be no SubjectAltName anymore. In other 
words, neither DNSName nor IPAddress will be included in this type of 
certificate.

2. We plan to notify the owners of the 10 certificates to make an application 
for revoking their original certificates and re-issuing a new one according to 
the new format.
 
   After discussing with the owners of the 10 dedicated server application 
software certificates, they are all willing to re-issue these certificates with 
the new format and revoke the old ones. However, before that we still have some 
work to do, such as system modification, electronic process, and so on.

   We plan to finish the re-issuing and revocation processes of all these 10 
certificates before early July.  Of course we will also report immediately if 
we finish that in advance. 

   Thank you.

Sincerely Yours,

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


Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

2018-06-05 Thread Ryan Sleevi via dev-security-policy
Hi Pedro,

I think the previous replies tried to indicate that I will not be available
to review your feedback at all this week.

On Mon, Jun 4, 2018 at 9:18 AM, Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Kind reminder.
> Thanks!
>
> ___
> 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: Namecheap refused to revoke certificate despite domain owner changed

2018-06-05 Thread Richard S. Leung via dev-security-policy
Howdy,

Thank you all for the discussions around this topic, just a quick update on the 
situation.

Following Jakob's advice, I have notified both Comodo and Namecheap that under 
BR, they needed to revoke that specific certificate I brought up.

So far, Comodo's SSL Abuse Dept. ( ssl_abuse#comodo.com ) had automatic replied 
that the person in charge is currently out of the office and will be back June 
13.

Namecheap's "Risk Management Team" has no response.

Will update after June 13 I suppose.

Thank you.

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