Re: Remediation Plan for WoSign and StartCom

[Kathleen Wilson]

On Wednesday, October 19, 2016 at 3:13:50 PM UTC-7, okaphone.e...@gmail.com 
wrote:
> Perhaps "haste" is not what you want here. How about "urgency"?
> 

Yep. Changed in the wiki page.

Thanks,
Kathleen

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

Re: Remediation Plan for WoSign and StartCom

[okaphone . elektronika]

Perhaps "haste" is not what you want here. How about "urgency"?

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

Re: Remediation Plan for WoSign and StartCom

[Kathleen Wilson]

On Wednesday, October 19, 2016 at 11:50:55 AM UTC-7, Gervase Markham wrote:
> 
> Today at the CAB Forum I outlined some of Mozilla's thinking on how we
> rate the severity of incidents. It might be helpful to reproduce that
> here. This is what I said:
> 

Thanks, Gerv!

I added that text to the wiki page:
https://wiki.mozilla.org/CA:MaintenanceAndEnforcement#Potential_Problems.2C_Prevention.2C_Response

Kathleen
___
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

[Andrew R. Whalley]

Hello,

Thank you for the links.  I note, however, that there's at least one
difference between the native language version and the English translation:

http://www.gdca.com.cn/cps/cps version 4.3 has a section 4.2.4 covering
CAA.
https://bug1128392.bmoattachments.org/attachment.cgi?id=8795091 version 4.3
in English has no such section.

The fact there's a discrepancy is rather worrying.  Could you please check
and let me know if there are any other substantive differences between the
Chinese and English versions?

Cheers,

Andrew

On Mon, Sep 26, 2016 at 7:17 PM,  wrote:

> 在 2016年9月27日星期二 UTC+8上午4:15:00，Andrew R. Whalley写道：
> > Hello,
> >
> > I have completed a read through of the English translations of the CP
> > (v1.2) and CPS (v4.1). Before I post my comments I wanted to see if there
> > were any more recent translations?  It looks like the local language
> > versions are 1.4 and 4.3 respectively.
> >
> > Many thanks,
> >
> > Andrew
> >
> > On Wed, Aug 3, 2016 at 2:45 PM, 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 PricewaterhouseCoo

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 19/10/16 11:35, longol...@gmail.com wrote:
> Hey Kathleen, hey list,
> 
> I really don't get why Mozilla is pushing so hard on the Chinese and
> at the same time let others get away. For example the Comodo case
> from today. Isn't that a much worse incident than what has happened
> here. 

Today at the CAB Forum I outlined some of Mozilla's thinking on how we
rate the severity of incidents. It might be helpful to reproduce that
here. This is what I said:


Many CAs may have been looking at Mozilla’s actions a little nervously,
conscious that they have had an issue or two in the past, and wondering
where the tipping point is which might lead to the production of a
WoSign-style “issue list”, and if they will ever hit it. It might
therefore be worth noting that while CA incidents have differing levels
of seriousness, there are some components which every CA should be able
to avoid which are red flags for Mozilla in terms of a continued trust
relationship, and which would lead to an investigation. They are:

* Deliberate violation of Mozilla or other applicable policy
* Lying or deception

Mozilla will also assess how concerned we are about an issue in part
based on how the CA reacts to that issue, and previous ones. In incident
response, Mozilla is looking for the following factors:

* A CA takes responsibility for their own actions.
* Incidents are taken with an appropriate level of seriousness.
* Incidents are handled with haste.
* Root cause analysis is performed.
* Any questions posed, by anyone, are answered quickly and in detail.
* A reasonably-detailed report is made public on what happened, why,
  and how things have changed to make sure it won’t happen again.

The recent issue experienced by Comodo was a good (albeit small) example
of this being done.

If people have further questions about this, they should feel free to
ask, either now or privately.


> People were able to issue certs for other people domains. When
> I read the WoSign answer to the current case
> (https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf)
> I personally felt, that they completely understood the seriousness of
> the situation. 

If you compare WoSign's responses over the entire period of
investigation to the criteria above, I hope you can see how the two
incidents are not comparable. In particular, they engaged in deliberate
violations of Mozilla policy and lied to cover it up.

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

Re: Remediation Plan for WoSign and StartCom

[longolius]

Hey Kathleen,
hey list,

I really don't get why Mozilla is pushing so hard on the Chinese and at the 
same time let others get away.
For example the Comodo case from today. Isn't that a much worse incident than 
what has happened here. People were able to issue certs for other people 
domains.
When I read the WoSign answer to the current case 
(https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf) I 
personally felt, that they completely understood the seriousness of the 
situation.
I doubt we'll see a professional answer like this in the current Comodo case. 
But then - of cause - Comodos headquarter is in the United States and not in 
China.

I feel like Mozilla is misusing its market power in a beginning trade war and 
this is not a good thing for the Mozilla Foundation. We all trust Mozilla to 
fight for a free web and not to choose sides in a trade war.

Best,
Nikolai

Am Donnerstag, 13. Oktober 2016 18:50:02 UTC+2 schrieb Kathleen Wilson:
> All,
> 
> Thanks again to all of you who have put in so much time and effort to 
> determine what happened with WoSign and StartCom and discuss what to do about 
> it.
> 
> Based on the information that I have seen regarding WoSign, I believe that 
> WoSign intentionally bent the rules in order to continue issuing SHA-1 SSL 
> certs, when they knew full well that was no longer allowed. I also believe 
> that the deception continued even after Mozilla directly asked WoSign about 
> this. WoSign has lost my confidence in their ability and intention to follow 
> Mozilla's policies. Therefore, I think we should respond similarly to WoSign 
> as we did to CNNIC [1][2]. Unfortunately, the number of certificates and the 
> timescales involved are such that we prefer not to create a list of the 
> domains for which previously-issued certs that chain up to the Affected Roots 
> may continue to be trusted, so our approach will be a little different, as 
> Gerv previously described[3].
> 
> Within this message, the term “Affected Roots” applies to the following 7 
> root certificates.
> 
> 1) Subject: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
> Certificate Serial Number: 50706bcdd813fc1b4e3b3372d211488d
> SHA-1 Fingerprint   
> 16:32:47:8D:89:F9:21:3A:92:00:85:63:F5:A4:A7:D3:12:40:8A:D6
> SHA-256 Fingerprint   
> D6:F0:34:BD:94:AA:23:3F:02:97:EC:A4:24:5B:28:39:73:E4:47:AA:59:0F:31:0C:77:F4:8F:DF:83:11:22:54
> 
> 2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA 
> Limited, C=CN
> Certificate Serial Number: 5e68d61171946350560068f33ec9c591
> SHA-1 Fingerprint   
> B9:42:94:BF:91:EA:8F:B6:4B:E6:10:97:C7:FB:00:13:59:B6:76:CB
> SHA-256 Fingerprint   
> 4B:22:D5:A6:AE:C9:9F:3C:DB:79:AA:5E:C0:68:38:47:9C:D5:EC:BA:71:64:F7:F2:2D:C1:D6:5F:63:D8:57:08
> 
> 3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA 
> Limited, C=CN
> Certificate Serial Number: 6b25da8a889d7cbc0f05b3b17a614544
> SHA-1 Fingerprint   
> FB:ED:DC:90:65:B7:27:20:37:BC:55:0C:9C:56:DE:BB:F2:78:94:E1
> SHA-256 Fingerprint   
> D4:87:A5:6F:83:B0:74:82:E8:5E:96:33:94:C1:EC:C2:C9:E5:1D:09:03:EE:94:6B:02:C3:01:58:1E:D9:9E:16
> 
> 4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
> Certificate Serial Number: 684a5870806bf08f02faf6dee8b09090
> SHA-1 Fingerprint   
> D2:7A:D2:BE:ED:94:C0:A1:3C:C7:25:21:EA:5D:71:BE:81:19:F3:2B
> SHA-256 Fingerprint   
> 8B:45:DA:1C:06:F7:91:EB:0C:AB:F2:6B:E5:88:F5:FB:23:16:5C:2E:61:4B:F8:85:56:2D:0D:CE:50:B2:9B:02
> 
> 5) Subject: CN=StartCom Certification Authority, OU=Secure Digital 
> Certificate Signing, O=StartCom Ltd., C=IL
> Certificate Serial Number: 01
> SHA-1 Fingerprint   
> 3E:2B:F7:F2:03:1B:96:F3:8C:E6:C4:D8:A8:5D:3E:2D:58:47:6A:0F
> SHA-256 Fingerprint   
> C7:66:A9:BE:F2:D4:07:1C:86:3A:31:AA:49:20:E8:13:B2:D1:98:60:8C:B7:B7:CF:E2:11:43:B8:36:DF:09:EA
> 
> 6) Subject: CN=StartCom Certification Authority, OU=Secure Digital 
> Certificate Signing, O=StartCom Ltd., C=IL
> Certificate Serial Number: 2d
> SHA-1 Fingerprint   
> A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0
> SHA-256 Fingerprint   
> E1:78:90:EE:09:A3:FB:F4:F4:8B:9C:41:4A:17:D6:37:B7:A5:06:47:E9:BC:75:23:22:72:7F:CC:17:42:A9:11
> 
> 7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., 
> C=IL
> Certificate Serial Number: 3b
> SHA-1 Fingerprint   
> 31:F1:FD:68:22:63:20:EE:C6:3B:3F:9D:EA:4A:3E:53:7C:7C:39:17
> SHA-256 Fingerprint   
> C7:BA:65:67:DE:93:A7:98:AE:1F:AA:79:1E:71:2D:37:8F:AE:1F:93:C4:39:7F:EA:44:1B:B7:CB:E6:FD:59:95
> 
> I intend to move forward as follows, unless further information or input 
> causes me to rethink this plan. Therefore, I will continue to appreciate your 
> input, and this discussion is still open.
> 
> Mozilla will perform the following 4 actions. I have filed Bugzilla Bug 
> #1309707 to track the engineering work for this. Please keep discussion here 
> in mozilla.dev.security.policy, and not in the bug.
> 
> 1) Distrust certificates chaining up to Affected R

Re: Remediation Plan for WoSign and StartCom

[Tom Ritter]

On Oct 19, 2016 11:51 AM, "Ryan Hurst"  wrote:
>
> > Because we're talking about a CA which used their private keys to get
> > around baseline requirements/prohibitions by backdating, I would not
> > be comfortable trusting them with operating a log where they could do
> > the same thing. The addition of the Google log prevents this to some
> > degree. So I would prefer the requirement either be 'one google and
> > one non-google/non-self-operated log' or just 'one google log'.
> >
> > -tom
>
> Since you would be OK with one google log, it seems it would be harmless
for them to log to their log also. As such treating them consistently as
the Google EV policy (one google, one other) seems acceptable.
>

It would be harmless, but if the only option for them to get to two logs is
to run their own, I don't see the point in requiring them to if we're not
going to really regard it as trusted. (Which at least I wouldn't. I'd
regard it as "A log I expect to be manipulated as soon as it is financially
expedient to do so.")

Unless we're proverbially doing it to give them more rope to hang
themselves with, so they get punished worse if they manipulate their log
like their CA issuance. But I'm not keen on that idea since we're
retroactively finding them putting users at risk, and this would be even
moreso.

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

Re: Incident Report - OCR

[Daniel McCarney]

Hi Robin,


> Comodo is performing a thorough review of all server certificates issued by
> Comodo between those dates for domains on the .be and .eu TLDs which used
> the domain control validation method described in 3.2.2.4.2 of the BRs.


Can you elaborate on how this review is being performed?
Does it include human cross-reference of the source images used as input to
the
OCR system and the produced email address used during domain validation?

Thanks!


On Wed, Oct 19, 2016 at 10:59 AM, Robin Alden  wrote:

> SUMMARY:
>
> Comodo was informed by security researchers Florian Heinz and Martin Kluge
> that on 23rd September 2016 they had been able to obtain a server
> authentication certificate [1] from Comodo for a domain which they did not
> own or control.
>
> The researchers shared their discovery with Comodo and this assisted Comodo
> to ensure that no further such certificates were issued.
>
>
>
> DOMAIN CONTROL VALIDATION
>
> One of the methods that Comodo uses to validate that a certificate
> applicant
> owns or controls a domain to be included in the subjectAlternativeName of a
> server authentication certificate is set out in the CA/B Forum's Baseline
> Requirements document [2] at section 3.2.2.4.2.
>
> That method may be summarized as the sending of an email to an email
> address
> (and obtaining a confirming response) where the email is identified as
> belonging to the Domain Name Registrant, technical contact, or
> administrative contract as listed in the WHOIS record of the domain.
>
>
>
> For the TLDs .eu and .be the registries offer only a redacted port 43 WHOIS
> service which does not include the contact email addresses.
>
> They also offer a web-based WHOIS service which presents the contact email
> addresses, but which does so in the form of a graphical image in a page
> instead of text.
>
> For these TLDs (.eu and .be) we were using an OCR system to read the
> contact
> email addresses.
>
>
>
> The researchers disclosed to Comodo that, while obtaining a certificate
> from
> Comodo for a domain that they did control, Comodo's certificate application
> process presented them with an email address which was not the same as they
> had registered in WHOIS but which was substantially similar.  They inferred
> from the nature of the difference between the email addresses that the
> difference was due to an error in reading the email address, most likely by
> OCR (Optical Character Recognition).
>
> They verified that the error in transcribing the email address led to a
> vulnerability in the certificate application process by identifying a
> domain
> name which was also subject to the OCR transcription error and, by
> registering a domain with the name produced by the transcription error,
> were
> able to obtain a certificate from Comodo for the domain name which was
> subject to the transcription error despite them not controlling it.
>
>
>
> The domain that they used for their proof of concept was
>
> a1-telekom.eu
>
> The registrant email address in the WHOIS entry was
>
> domain.bill...@a1telekom.at 
>
> which was misread by OCR as
>
>   domain.bill...@altelekom.at
>   (the "1" in a1telekom.at was
> detected
> as a lower case 'L')
>
>
>
> IMMEDIATE RESPONSE
>
> Comodo's immediate response to the disclosure was to revoke the identified
> certificate and to disable the use of OCR in the interpretation of WHOIS
> responses for the validation new certificate requests.
>
>
>
> INVESTIGATION OF SCOPE
>
> Comodo used an OCR system to interpret WHOIS information from 2 TLDs.  The
> TLDs were .be and .eu .
>
> Comodo used OCR for the WHOIS on these two domains between 27-JUL-2016 and
> 28-SEP-2016.
>
> Comodo is performing a thorough review of all server certificates issued by
> Comodo between those dates for domains on the .be and .eu TLDs which used
> the domain control validation method described in 3.2.2.4.2 of the BRs.
>
> The review is ongoing but no other examples have been found of certificates
> issued as a consequence of OCR mis-reads.
>
>
>
> WHOIS
>
> Comodo notes that the port 43 WHOIS service provided by most registries is
> a
> valuable source of information for CAs and for other parties who have a
> legitimate need to contact domain name registrants.
>
> Some domain registrars provide registrants with a means to effectively
> opt-out of having their contact details made public through the port 43
> WHOIS server, or otherwise, by providing a 'privacy' or 'anonymization'
> service whose details appear in the WHOIS results for the domain instead of
> those of the registrant.
>
> Comodo understands that some registrants will not want to be identified and
> supports their right to a choice as to whether they should be identified in
> WHOIS.
>
> Comodo understands that some registries do not offer a port 43 WHOIS
> service
> because they are not able to do so.  There are some registries for small or
> p

Re: Remediation Plan for WoSign and StartCom

[Ryan Hurst]

> Because we're talking about a CA which used their private keys to get
> around baseline requirements/prohibitions by backdating, I would not
> be comfortable trusting them with operating a log where they could do
> the same thing. The addition of the Google log prevents this to some
> degree. So I would prefer the requirement either be 'one google and
> one non-google/non-self-operated log' or just 'one google log'.
> 
> -tom

Since you would be OK with one google log, it seems it would be harmless for 
them to log to their log also. As such treating them consistently as the Google 
EV policy (one google, one other) seems acceptable.

Ryan

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

Re: Remediation Plan for WoSign and StartCom

[Ryan Hurst]

On Wednesday, October 19, 2016 at 12:58:49 AM UTC-7, Kurt Roeckx wrote:
> I at least have some concerns about the current gossip draft and talked 
> a little to dkg about this. I should probably bring this up on the trans 
> list.
> 

Please do, we would like to see this brought to closure soon and we want to 
make sure all feedback is considered.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Incident Report - OCR

[Robin Alden]

SUMMARY:

Comodo was informed by security researchers Florian Heinz and Martin Kluge
that on 23rd September 2016 they had been able to obtain a server
authentication certificate [1] from Comodo for a domain which they did not
own or control.

The researchers shared their discovery with Comodo and this assisted Comodo
to ensure that no further such certificates were issued.

 

DOMAIN CONTROL VALIDATION

One of the methods that Comodo uses to validate that a certificate applicant
owns or controls a domain to be included in the subjectAlternativeName of a
server authentication certificate is set out in the CA/B Forum's Baseline
Requirements document [2] at section 3.2.2.4.2.  

That method may be summarized as the sending of an email to an email address
(and obtaining a confirming response) where the email is identified as
belonging to the Domain Name Registrant, technical contact, or
administrative contract as listed in the WHOIS record of the domain.

 

For the TLDs .eu and .be the registries offer only a redacted port 43 WHOIS
service which does not include the contact email addresses.  

They also offer a web-based WHOIS service which presents the contact email
addresses, but which does so in the form of a graphical image in a page
instead of text.  

For these TLDs (.eu and .be) we were using an OCR system to read the contact
email addresses.

 

The researchers disclosed to Comodo that, while obtaining a certificate from
Comodo for a domain that they did control, Comodo's certificate application
process presented them with an email address which was not the same as they
had registered in WHOIS but which was substantially similar.  They inferred
from the nature of the difference between the email addresses that the
difference was due to an error in reading the email address, most likely by
OCR (Optical Character Recognition).

They verified that the error in transcribing the email address led to a
vulnerability in the certificate application process by identifying a domain
name which was also subject to the OCR transcription error and, by
registering a domain with the name produced by the transcription error, were
able to obtain a certificate from Comodo for the domain name which was
subject to the transcription error despite them not controlling it.

 

The domain that they used for their proof of concept was 

a1-telekom.eu

The registrant email address in the WHOIS entry was

domain.bill...@a1telekom.at  

which was misread by OCR as

  domain.bill...@altelekom.at
  (the "1" in a1telekom.at was detected
as a lower case 'L')

 

IMMEDIATE RESPONSE

Comodo's immediate response to the disclosure was to revoke the identified
certificate and to disable the use of OCR in the interpretation of WHOIS
responses for the validation new certificate requests.

 

INVESTIGATION OF SCOPE

Comodo used an OCR system to interpret WHOIS information from 2 TLDs.  The
TLDs were .be and .eu .

Comodo used OCR for the WHOIS on these two domains between 27-JUL-2016 and
28-SEP-2016.

Comodo is performing a thorough review of all server certificates issued by
Comodo between those dates for domains on the .be and .eu TLDs which used
the domain control validation method described in 3.2.2.4.2 of the BRs.

The review is ongoing but no other examples have been found of certificates
issued as a consequence of OCR mis-reads.

 

WHOIS

Comodo notes that the port 43 WHOIS service provided by most registries is a
valuable source of information for CAs and for other parties who have a
legitimate need to contact domain name registrants.

Some domain registrars provide registrants with a means to effectively
opt-out of having their contact details made public through the port 43
WHOIS server, or otherwise, by providing a 'privacy' or 'anonymization'
service whose details appear in the WHOIS results for the domain instead of
those of the registrant.

Comodo understands that some registrants will not want to be identified and
supports their right to a choice as to whether they should be identified in
WHOIS.

Comodo understands that some registries do not offer a port 43 WHOIS service
because they are not able to do so.  There are some registries for small or
poor regions where we cannot expect technical excellence.

Comodo finds it regrettable that some registries choose to offer a port 43
WHOIS service which redacts information for all registrants which even the
registry themselves would normally consider to be public.  We find it even
more regrettable that a sub-set of those registries refuse to consider
offering unredacted access to that information even when contractual and/or
commercial terms (including binding restrictions on the use of that
information) are offered.  

 

Robin Alden

Comodo CA Ltd.

 

[1] https://crt.sh/?id=47045653

[2] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

[3]
http://www.heise.de/newsticker/meld

Re: Remediation Plan for WoSign and StartCom

[Tom Ritter]

On 19 October 2016 at 02:58, Kurt Roeckx  wrote:
> On 2016-10-19 01:37, Rob Stradling wrote:
>>
>> On 18/10/16 23:49, Gervase Markham wrote:
>>>
>>> On 18/10/16 15:42, Ryan Hurst wrote:

 I do not understand the desire to require StartCom / WoSign to not
 utilize their own logs as part of the associated quorum policy.
>>>
>>>
>>> My original logic was that it could be seen that the log owner is
>>> trustworthy. However, you are right that CT does not require this.
>>
>>
>> A log operator could offer a split view of their log, and this might go
>> undetected.  That's why we need CT gossip to exist.
>
>
> I at least have some concerns about the current gossip draft and talked a
> little to dkg about this. I should probably bring this up on the trans list.


Please do!  For those not aware, the CT Gossip draft is in 'pre-final
review' in the sense that (we think) we're pretty much done but need
people to finally read it now.  Draft is at:
https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/


Because we're talking about a CA which used their private keys to get
around baseline requirements/prohibitions by backdating, I would not
be comfortable trusting them with operating a log where they could do
the same thing. The addition of the Google log prevents this to some
degree. So I would prefer the requirement either be 'one google and
one non-google/non-self-operated log' or just 'one google log'.

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

Re: StartCom & Qihoo Incidents

[Michael Ströder]

Peter Gutmann wrote:
> Ryan Sleevi  writes:
> 
>> What is the goal of the root program? Should there be a higher bar for
>> removing CAs than adding them? Does trust increase or decrease over time?
> 
> Another thing I'd like to bring up is the absolute silence of the CAB forum
> over all this.  Apple have quietly unilaterally distrusted, Mozilla have
> debated at length (three months now) and are taking action, but the regulatory
> body that should be taking charge, the CAB forum, has (apparently) taken
> absolutely no action.
> 
> Does anyone know the position among other browser vendors, Chrome, IE, Opera,
> Konqueror, Chromium, Midori, the dozen or more forks of various bigger
> browsers, the dozens(?) of mobile browsers, and so on.

Most Linux distributions ship a package like "ca-certificates-mozilla" which
simply copies the Mozilla trusted CA cert set and converts it into several trust
store formats.
So the impact is much broader besides web browsers even affecting e.g. MTA-MTA
SMTP communication.

(Yes, I fully understand that Mozilla refuses to take responsibility for that.)

Ciao, Michael.

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

Re: Remediation Plan for WoSign and StartCom

[Kurt Roeckx]

On 2016-10-19 01:37, Rob Stradling wrote:

On 18/10/16 23:49, Gervase Markham wrote:

On 18/10/16 15:42, Ryan Hurst wrote:

I do not understand the desire to require StartCom / WoSign to not
utilize their own logs as part of the associated quorum policy.


My original logic was that it could be seen that the log owner is
trustworthy. However, you are right that CT does not require this.


A log operator could offer a split view of their log, and this might go
undetected.  That's why we need CT gossip to exist.


I at least have some concerns about the current gossip draft and talked 
a little to dkg about this. I should probably bring this up on the trans 
list.



Kurt

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