Re: Nation State MITM CA's ?

[RS Tyler Schroder via dev-security-policy]

News reports[1][2] are now showing that the certificate has been "cancelled". I 
do not have a way to verify that it has been revoked independently at this time.

Sources:
[1] https://tsarka.org/post/national-certificate-cancelled
[2] 
https://www.reuters.com/article/us-kazakhstan-internet-surveillance/kazakhstan-halts-introduction-of-internet-surveillance-system-idUSKCN1UX0VD
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT]Unretrievable CPS documents listed in CCADB

[(RS) Tyler Schroder via dev-security-policy]

Hi Corey,

FWIW, at least one of those CAs are no longer active, such as 5388 WoSign: 
https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/
 - do old CAs get removed from CCADB or marked inactive in that system?

I do like the idea of linking the specific document over the general repo page.

Regards,

Tyler

-Original Message-
From: dev-security-policy  On 
Behalf Of Corey Bonnell via dev-security-policy
Sent: Thursday, May 2, 2019 9:54 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: [EXT]Unretrievable CPS documents listed in CCADB

Hello,
Section 4 of Mozilla Root Store Policy states that CAs are bound by the latest 
Common CCADB Policy (http://ccadb.org/policy). Section 5 of the Common CCADB 
Policy specifies the requirements for CAs regarding providing URLs to various 
documents, such as the CP, CPS, and audit reports. In particular, “the URLs to 
such CPs, CPSes and audits, and any metadata about them such as the name of the 
auditor or the date of the audit, need to be updated as new information become 
available.”

The current AllCertificateRecordsReport.csv was downloaded and the CPS URLs for 
all unrevoked intermediate and root certificates were extracted. Each extracted 
CPS URL was then requested via HTTP GET using cURL and the HTTP response status 
code recorded. Below is a list of all CPS URLs which return a HTTP status code 
of 400 or greater:

"Row number", "CA Owner", "Certificate Name", "CPS URL", "HTTP status code"
7, "AC Camerfirma, S.A.", "Chambers of Commerce Root", 
http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_eidas_EN_v_1_2_3.pdf,
 404
191, Atos, "Atos TrustedRoot 2011", 
https://pki.atos.net/Download/AtosTrustedCACPSv1.9.0.pdf, 404
258, "Autoridad de Certificacion Firmaprofesional", "SIGNE Autoridad de 
Certificacion", 
http://www.signe.es/wp-content/uploads/2018/08/DPC_SIGNE_2.1-180731.pdf, 404
262, Buypass, "Buypass Class 2 CA 1", 
http://www.buypass.com/home/support/ca-documentation-legal, 404
466, "Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)", "S-TRUST 
Authentication and Encryption Root CA 2005:PN", 
http://www.s-trust.de/stn-cps/stn_cps.pdf, 404
468, "Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)", "TC TrustCenter 
Class 3 CA II", https://www.s-trust.de/stn-cps, 404
594, DigiCert, "ADACOM CA for EU Qualified e-Seals", 
https://pki.adacom.com/repository/en/CPS/files/Certification_Practice_Statement_for_EU_Qualified_certificates_v3.pdf,
 404
634, DigiCert, "Allgeier IT Solutions CA", 
https://www.s-trust.de/ablage_download_dokumente/ablage_pdf/S-TRUST_STN_CPS_V3_87.pdf,
 404
741, DigiCert, "Belgium Root CA2", 
https://stage-pki.belgium.be/resources/PKI-BelgiumRootCA-CPS-v1.2.pdf, 404
1394, DigiCert, "Government AA", 
https://stage-pki.belgium.be/resources/Government-CA-Certification-Practice-Statement-v1.0.pdf,
 404
1546, DigiCert, "Microsoft IT SSL CA 1", 
https://www.microsoft.com/pki/mscorp/cps/Microsoft%20IT%20PKI%20CP-CPS%20for%20SSL%20Ver%201%203%20January%202015.htm,
 404
1551, DigiCert, "Microsoft IT SSL SHA2", 
http://www.microsoft.com/pki/mscorp/cps/Microsoft%20IT%20PKI%20CP-CPS%20for%20SSL%20Ver%201%203%20January%202015.htm,
 404
2494, "Financijska agencija (Fina)", "Fina Root CA", 
http://rdc.fina.hr/QTSA2017/FinaQTSA, 404
2815, "Government of France (ANSSI, DCSSI)", IGC/A, 
http://www.ssi.gouv.fr/site_article15.html, 404
2991, "Government of Tunisia, Agence National de Certification Electronique / 
National Digital Certification Agency (ANCE/NDCA)", "Tunisian Root Certificate 
Authority - TunRootCA2", 
http://www.tuntrust.tn/sites/default/files/documents/PolitiqueSERVEURS-PTC-BR-08.pdf,
 404
3209, "Microsec Ltd.", "e-Szigno Class2 CA 2017", 
https://static.e-szigno.hu/docs/szsz--fok--sea--EN--v2.8.pdf, 404
3211, "Microsec Ltd.", "e-Szigno Class3 CA 2017", 
https://static.e-szigno.hu/docs/szsz--fok--sig--EN--v2.8.pdf, 404
3216, "Microsec Ltd.", "e-Szigno Qualified CA 2017", 
https://static.e-szigno.hu/docs/szsz--min--sig--EN--v2.8.pdf, 404
3217, "Microsec Ltd.", "e-Szigno Qualified Organization CA 2017", 
https://static.e-szigno.hu/docs/szsz--min--sea--EN--v2.8.pdf, 404
3308, "Pos Digicert Sdn. Bhd (Malaysia)", "PosDigicert Class 2 Root CA G2", 
https://www.posdigicert.com.my/public/uploads/files/CPS-Rev-60.pdf, 404
3442, "SECOM Trust Systems CO., LTD.", http://www.valicert.com/, 
https://repository.secomtrust.net/rootrepository/CPSen.pdf, 404
3445, "SECOM Trust Systems CO., LTD.", "Security Communication EV RootCA1", 
https://repository.secomtrust.net/EV-Root1/index.html, 404
4526, "T-Systems International GmbH (Deutsche Telekom)", "Deutsche Telekom AG 
Issuing CA 01", http://corporate-pki.telekom.de/cps/cps.htm, 403
4528, "T-Systems International GmbH (Deutsche Telekom)", "Deutsche Telekom AG 
Issuing CA 01", http://corporate-pki1.telekom.de/cps/cps.htm, 403
5242, "Telia Company (formerly TeliaSonera)", "Sonera Class1 CA", 

Re: Comodo Rebrand to Sectigo

[(RS) Tyler Schroder via dev-security-policy]

Thanks for the clarification! That makes much more sense.


-Tyler


On 11/7/2018 6:28 AM, Rob Stradling via dev-security-policy wrote:
> CAUTION: This message was sent from outside the company.
>
>
> On 07/11/2018 01:36, RS Tyler Schroder via dev-security-policy wrote:
>> Based on a recent visit to crt.sh , Comodo has rebranded to Sectigo 
>> <https://sectigo.com/>
>>
>> (Talked with Wayne off-list to confirm there's no announcement required 
>> under BR Sec. 8, so just posting it for general awareness / discussion)
> Hi Tyler.  Thanks for posting this.  However, I think your
> (unfortunately inaccurate) statement - "Comodo has rebranded to Sectigo"
> - demonstrates perfectly the confusion between two distinct
> organizations that necessitated this rebrand!
>
> Comodo (https://www.comodo.com/) has not rebranded.  Comodo, which
> continues to offer various cybersecurity products and services, ceased
> being a CA when it sold a majority share in its "Comodo CA" business
> unit to Francisco Partners just over a year ago.
>
> Sectigo (https://sectigo.com/) is the new name for "Comodo CA".
>
> https://sectigo.com/newsroom/comodo-ca-rebrands-as-sectigo
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@sectigo.com
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy




smime.p7s
Description: S/MIME Cryptographic Signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Comodo Rebrand to Sectigo

[RS Tyler Schroder via dev-security-policy]

Based on a recent visit to crt.sh , Comodo has rebranded to Sectigo 


(Talked with Wayne off-list to confirm there's no announcement required under 
BR Sec. 8, so just posting it for general awareness / discussion)


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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[(RS) Tyler Schroder via dev-security-policy]

The legal definition that I came acrosss is " In United States 
law, a stipulation is a formal 
legal acknowledgment and agreement made between opposing parties before a 
pending hearing or 
trial. For example, both parties 
might stipulate to certain facts and so not have to argue them in court. After 
the stipulation is entered into, it is presented to the judge." [1]


On 10/9/2018 12:48 PM, Kathleen Wilson via dev-security-policy wrote:

CAUTION: This message was sent from outside the company.


All,

I would like to create some written rules about using "No Stipulation"
in CP and CPS documents; e.g. what it means, and when it is OK to be used.

First, I will appreciate your thoughts about what the term "No
Stipulation" means. e.g. does it mean one or all of the following?
 "No rules defined for this section"
 "This section is not applicable"
 "This section is not allowed"
 "This section is not used"

Can "No Stipulation" mean different things based on the context of the
section?
For example
"1.3.5 Other Participants
No stipulation."
Does that mean “no other participants are allowed”?

Here is what RFC 3647 says about the term:
""
While many topics are identified, it is not necessary for a CP or a
   CPS to include a concrete statement for every such topic.  Rather, a
   particular CP or CPS may state "no stipulation" for a component,
   subcomponent, or element on which the particular CP or CPS imposes no
   requirements or makes no disclosure.  In this sense, the list of
   topics can be considered a checklist of topics for consideration by
   the CP or CPS writer.

   It is recommended that each and every component and subcomponent be
   included in a CP or CPS, even if there is "no stipulation"; this will
   indicate to the reader that a conscious decision was made to include
   or exclude a provision concerning that topic.  This drafting style
   protects against inadvertent omission of a topic, while facilitating
   comparison of different certificate policies or CPSs, e.g., when
   making policy mapping decisions.
""

It seems a little ambiguous to me, so I would like to have a written
statement about what "No Stipulation" means within CP and CPS documents,
especially in regards to SSL certificate issuance.

Here are two examples that I've seen recently.

== Example 1 ==
In this situation, the CA has one CP that covers different types of
roots, so the CPS for the different roots has the details. There is no
further detailed public documentation beyond the CPS.

In the CA's CP:
3.1.2 Need for Names to be Meaningful
No Stipulation
3.1.5 Uniqueness of Names
No Stipulation
3.2.2.1 Identity
No Stipulation
3.2.2.2 DBA/Tradename
No Stipulation
3.2.2.3 Verification of Country
No Stipulation
3.2.2.4 Validation of Domain Authorization or Control
No Stipulation
3.2.2.4.1 Validating the Applicant as a Domain Contact
No Stipulation
3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
No Stipulation
3.2.2.4.3 Phone Contact with Domain Contact
No Stipulation
3.2.2.4.4 Constructed Email to Domain Contact
No Stipulation
3.2.2.4.5 Domain Authorization Document
No Stipulation
3.2.2.4.6 Agreed-Upon Change to Website
No Stipulation
3.2.2.4.7 DNS Change
No Stipulation
3.2.2.4.8 IP Address
No Stipulation
3.2.2.4.9 Test Certificate
No Stipulation
3.2.2.4.10 TLS Using a Random Number
No Stipulation
3.2.2.4.11 Any Other Method
This method has been retired and MUST NOT be used.
3.2.2.4.12 Validating Applicant as a Domain Contact
No Stipulation
3.2.2.5 Authentication for an IP Address
No Stipulation
3.2.2.6 Wildcard Domain Validation
No Stipulation
3.2.2.7 Data Source Accuracy
No Stipulation
3.2.2.8 CAA Records
No Stipulation
3.2.3 Authentication of Individual Identity
No Stipulation
3.2.4 Non-Verified Subscriber Information
No Stipulation
4.7.4 Notification of New Certificate Issuance to Subscriber
No stipulation
4.9.7 CRL Issuance Frequency
No Stipulation.
4.9.10 On-Line Revocation Checking Requirements
No Stipulation
5.4.6 Audit Log Accumulation System (Internal vs. External)
No Stipulation
6.1.5 Key Sizes
No Stipulation
6.2.3 Private Key Escrow
No Stipulation
6.2.5 Private Key Archival
No Stipulation
6.2.6 Private Key Transfer into or from a Cryptographic Module
No Stipulation
6.2.9 Deactivating Private Keys
No Stipulation
6.3.2 Certificate Operational Periods and Key Pair Usage Periods
No Stipulation
6.7 NETWORK SECURITY CONTROLS
No stipulation

The relevant CPS has the following sections with No Stipulation:
3.1.5 Uniqueness of Names
No Stipulation
3.2.2.5 Authentication for an IP Address
No Stipulation
3.2.2.6 Wildcard Domain Validation
No Stipulation
4.7.4 Notification of New Certificate Issuance to Subscriber
No Stipulation
5.4.6 Audit Log Accumulation System (Internal vs. External)
No Stipulation
6.2.3 Private Key Escrow
No Stipulation
6.2.5 Private Key Archival

Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)

[RS Tyler Schroder via dev-security-policy]

> The unqualified mention of "September 8" confused me at first, but it 
> obviously refers to the "CAA Mandatory BR" taking effect on "September 
> 8, 2017", thus the single misissuance probably happened between 
> September 8, 2017 and when they changed the policy on August 31, 2018. 
>
> However I cannot tell, because I can't find the serial number on crt.sh. 


This appears to be the cert in question: https://crt.sh/?id=596401403=ocsp

Dates show they were revoked on the same day of the CPS update, so that 
explanation checks out for now
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)

[RS Tyler Schroder via dev-security-policy]

On Tuesday, September 11, 2018 at 3:34:45 AM UTC-4, josselin@gmail.com 
wrote:
> The audit of our previous CAA check practices ensured that the CA/B Forum 
> requirements were met except for a single certificate for which the CA was 
> not authorized to issue according to the DNS CAA record.
> 
> This failure is related to our old practices that led to a control of the DNS 
> CAA records with automatic alerts for the Registration Officers, but the 
> blocking of the certificate request was not automatic unlike today. It was 
> found that the request had been approved despite this alert, and in 
> particular because of the provision of additional supporting documents by the 
> applicant such as a request for a certificate signed by the legal 
> representative of the entity accompanied by a photocopy of his identity 
> document, which attest to the consent to issue.
> 
> We checked the logs of the controls carried out and re-rolled these controls 
> on all the SSL certificates issued since September 8th and confirm that only 
> this certificate was the object of a failure.
> 
> This certificate, which has not yet been deployed and used by the customer, 
> has been identified and revoked by the CA and is now included in the CRL with 
> the following serial number: 476abeb2bc78d588ef4b8f27dbd25f6a (see 
> http://crl.certigna.fr/servicesca.crl).
> 
> Note that this incident will not be able to happen again by means of our new 
> practices that automatically block any certificate request for which the DNS 
> CAA record controls induce that the CA is not allowed to issue, without 
> possible bypass by the RA. These practices are described in the latest 
> updated versions of our CP/CPS. 
> 
> We remain at your disposal if you want further information.

Adding Q24/25

24. Your CPS for the Root and Wild CPSs as of 8/31/2018 note in section 4.2.1 
that a certificate issue that did not comply with RFC6844 would be 
automatically blocked. Your note in the first post says that "our new practices 
that automatically block any certificate request for which the DNS CAA record 
controls induce that the CA is not allowed to issue, without possible bypass by 
the RA". Was this blocking process not fully automated as described prior 
(going off of Q23 from Jakob)? 

25. What exactly prompted the manual override for CAA Checking? A request from 
the origin certificate requestor, the RA on their own...


Relevant section:
> The following cases do not allow the CA to authorize the issuance of the 
> certificate:
> - The CAA DNS field is present, it contains an "issue" or "issuewild" tag and 
> does not list
> Certigna as an authorized Certificate Authority;
> - The CAA DNS field is present, it is designated as "critical" and the tag 
> used is not supported
> by the CA (it is not an "issue" or "issuewild" tag);
> - The zone is validly DNSSEC-signed and our DNS query times out.
> If any of these cases are encountered, the certificate request is 
> automatically blocked and the
> applicant is notified by email of the need to update the associated DNS 
> records.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[RS Tyler Schroder via dev-security-policy]

On Thursday, March 1, 2018 at 2:43:05 PM UTC-5, Tom wrote:
> > Therefore, it is not unreasonable to assume that this key has been
>  > compromised.
> 
> 
> So it means that any private keys generated on that website could be 
> compromised:
> - If any third-party JS were compromised (and we know how insecure 
> js-based ads are - last time it was a crypto miner on youtube)
> - If they were stored on the compromised server
> - If a trojan were installed on the compromised server
> - If somebody MitM the server
> 
> Or am I missing something ?

That seems rather comprehensive. Any number of vectors could have caused a key 
leak.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[RS Tyler Schroder via dev-security-policy]

On Thursday, March 1, 2018 at 12:59:17 PM UTC-5, Matthew Hardeman wrote:
> By this point, one would imagine that reputational risks would prevent any
> CA from working with Trustico.
> 
> On Thu, Mar 1, 2018 at 11:56 AM, Hector Martin 'marcan' via
> dev-security-policy  wrote:
> 
> > On 2018-03-02 00:28, Hanno Böck via dev-security-policy wrote:
> > > Hi,
> > >
> > > On twitter there are currently some people poking Trustico's web
> > > interface and found trivial script injections:
> > > https://twitter.com/svblxyz/status/969220402768736258
> > >
> > > Which seem to run as root:
> > > https://twitter.com/cujanovic/status/969229397508153350
> > >
> > > I haven't tried to reproduce it, but it sounds legit.
> >
> > Unsurprisingly, the entire server is now down. If Trustico are lucky,
> > someone just `rm -rf /`ed the whole thing. If they aren't, they now have
> > a bunch of persistent backdoors in their network.
> >
> > Now the interesting question is whether this vector could've been used
> > to recover any/all archived private keys.
> >
> > As I understand it, Trustico is in the process of terminating their
> > relationship with Digicert and switching to Comodo for issuance. I have
> > a question for Digicert, Comodo, and other CAs: do you do any vetting of
> > resellers for best practices? While clearly most of the security burden
> > rests with the CA, this example shows that resellers with poor security
> > practices (archiving subscriber public keys, e-mailing them to trigger
> > revocation, trivial command injection vulnerabilities, running a PHP
> > frontend directly as root) can have a significant impact on the security
> > of the WebPKI for a large number of certificate holders. Are there any
> > concerns that the reputability of a CA might be impacted if they
> > willingly choose to partner with resellers which have demonstrated such
> > problems?
> >
> > --
> > Hector Martin "marcan" (x...@x.st)
> > Public Key: https://mrcn.st/pub
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >

I posted about this issue in the other thread on Trustico's debacle after 
seeing the twitter explosion over here: 
https://groups.google.com/d/msg/mozilla.dev.security.policy/wxX4Yv0E3Mk/q6P8oE3pAQAJ

Agreeing with Hector, I think that would be reasonable grounds to assume 
compromise.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy