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: 

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

[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]

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

Re: Remediation Plan for WoSign and StartCom

[Ryan Hurst]

It is true, that without gossip, CT is dependent on browsers monitoring the log 
ecosystem, this is one reason why in the Chrome policy the one Google log is 
required.

I would argue, with the monitoring Google does and the one Google log policy 
that this risk is mitigated sufficiently, even without gossip.

Gossip is needed, as is Firefox's own implementation of CT verification, which 
is actively in the works, but given the above mitigations I still believe this 
extra requirement is not necessary.

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