Closed Bug 1204656 Opened 9 years ago Closed 8 years ago

Add ISRG / Let's Encrypt root certificate

Categories

(CA Program :: CA Certificate Root Program, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jaas, Assigned: kwilson)

References

()

Details

(Whiteboard: Included in NSS 3.26, and Firefox 50)

Attachments

(3 files, 1 obsolete file)

CA Details
----------

CA Name: Internet Security Research Group (ISRG)

Website: https://letsencrypt.org/

One Paragraph Summary of CA:
Let’s Encrypt is a service provided by Internet Security Research Group (ISRG). ISRG is a California public benefit corporation, and is recognized by the IRS as a tax-exempt organization under Section 501(c)(3) of the Internal Revenue Code. We will offer server authentication certificates to subscribers around the world. Let’s Encrypt subscribers are the general public.

Audit Type (WebTrust, ETSI etc.): Point in Time Readiness Assessments for WebTrust for CA 2.0, BR 2.0
Auditor: BrightLine
Auditor Website: https://www.brightline.com/
Audit Document URL(s): To be provided at a later date.

Certificate Details
-------------------

Certificate Name: ISRG Root X1
Summary Paragraph:
ISRG Root X1 is a Root CA with an RSA key with a 4096 bit long modulus.  It will be used to issue server authentication certificates via intermediates, as defined in our CP and CPS. Initially there will be two intermediates, “Let's Encrypt Authority X1” and “Let's Encrypt Authority X2”. For more information please see attached diagram.

Certificate download URL (on CA website): https://letsencrypt.org/certs/isrgrootx1.der
Version: X.509 v3
SHA1 Fingerprint: cabd2a79a1076a31f21d253635cb039d4329a5e8
Public key length (for RSA, modulus length) in bits: 4096
Valid From (YYYY-MM-DD): 2015-06-04
Valid To (YYYY-MM-DD): 2035-06-04

CRL HTTP URL: http://crl.root-x1.letsencrypt.org/
CRL issuing frequency for subordinate end-entity certificates: We will not issue CRLs for end-entity certificates.
CRL issuing frequency for subordinate CA certificates: At least once every six months.
OCSP URL: http://ocsp.root-x1.letsencrypt.org/

Class (domain-validated, identity/organizationally-validated or EV): DV
Certificate Policy URL: http://cp.root-x1.letsencrypt.org/
CPS URL: http://cps.root-x1.letsencrypt.org/
Requested Trust Indicators (email and/or SSL and/or code signing): SSL
URL of example website using certificate subordinate to this root (if applying for SSL): http://helloworld.letsencrypt.org/
Status: NEW → ASSIGNED
Whiteboard: Information incomplete
I have entered the information for this request into Salesforce.

Please review the attached document to make sure it is accurate and complete, and comment in this bug to provide corrections and the additional requested information.
Everything looks correct except for:

=====
Re: CA's Response to Recommended Practices

IDN: We do not currently issued for IDN, when we do we'll state how we handle homographic spoofing in our CPS.

Natural Person: We only issued DV certificates which do not include O or OU fields.

Network Security Controls: We comply with recommendations.
=====
Re: CA's Response to Problematic Practices

Distributing generated private keys in PKCS#12 files: No

OCSP Responses signed by a certificate under a different root: No

SHA-1 Certificates: We have not and never will issue SHA-1 certificates.

Generic names for CAs: We use “Internet Security Research Group” and “Let’s Encrypt”.

Lack of Communication With End Users: We offer various email addresses for contact, and operate a support forum

Backdating the notBefore date: Compliant with recommendation/requirement
=====
Re: Externally Operated SubCAs

Confirmed correct.
=====
Technical Constraint on 3rd party Issuer

Confirmed correct.
=====
Re: Verification Policies and Practices

Standard Audit: We have not yet completed our full WebTrust audit, but the PITRA letter is here:

https://letsencrypt.org/documents/LE-PITRA-Results-Sept-8-2015.pdf

Multi-Factor Authentication: Two-factor auth is being used, Client Certificates and/or Hardware Tokens. Is Mozilla saying that we need to include/reference information about this in our CP/CPS?

Network Security: We are in compliance with CA/B Forum Network and Certificate System Security. Is Mozilla saying that we need to include/reference information about this in our CP/CPS?

Re: Link to Publicly Disclosed and Audited subordinate CA Certificates
=====
Re: Publicly Disclosed & Audited subCAs

The sub-CA cert from IdenTrust: http://cert.int-x1.letsencrypt.org/
=====
> Re: Link to Publicly Disclosed and Audited subordinate CA Certificates
> =====
> Re: Publicly Disclosed & Audited subCAs
> 
> The sub-CA cert from IdenTrust: http://cert.int-x1.letsencrypt.org/
> =====

Where is the audit for this subCA? I don't see IdenTrusts WebTrust Audit covering the subCA a public facing CA with different validation scheme. As the auditor is the same as IdenTrust and the audit seems to be not finished yet, where is the allowance to issue public certificates regarding WebTrust/Mozilla requirements?
I followup my recent inquiry about a potential violation of the WebTrust requirements by issuing a subordinate CA to ISRG aka. Let’s Encrypt without a formal audit. The audited certification practice of IdenTrust states

"The External CA will produce and publish a separate CP and CPS that they will be bound to adhere to its terms (each are publicly disclosed and linked to on www.IdenTrust.com) and independently audited with publicly available reports.“ (https://secure.identrust.com/certificates/policy/ts/TrustID_CP_v1.7_20150522.pdf)

I don’t see this formal audit, however, ISRG got an intermediate issued and is already issuing certificates with it, although there is just a readiness assessment, a formal assessment is still outstanding.
Blocks: 1230797
IdenTrust has successfully passed a “WebTrust for Principles and Criteria for Certification Authorities 2.0” and a “WebTrust for Principles and Criteria for Certification Authorities – SSL Baseline with Network Security – Version 2” audits that cover its controls.  The locations for the reports are: https://cert.webtrust.org/ViewSeal?id=1910 and https://cert.webtrust.org/ViewSeal?id=1909 respectively. These audits are period-of-time audits and cover the period from July 1, 2014 to June 30, 2015.  The Let’s Encrypt subordinate CA Certificate was issued by IdenTrust on October 19, 2015.  Therefore, the issuance of that certificate will be included in the next audit cycle.  
 
CAB Forum Baseline Requirements (“BR”) found at https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_3_1.pdf) Section 8.1 states: “If the CA has a currently valid Audit Report indicating compliance with an audit scheme listed in Section 8.1, then no pre-issuance readiness assessment is necessary.”  The joint IdenTrust/Let’s Encrypt interpretation of this statement was that there is no need for an additional audit statement until the end of the audit cycle. 
 
Let’s Encrypt completed a point-in-time readiness assessment per BR Section 8.1, and will be fulfilling this complete audit requirement within the proper time frame.
(In reply to roots from comment #7)
> Let’s Encrypt completed a point-in-time readiness assessment per BR Section
> 8.1, and will be fulfilling this complete audit requirement within the
> proper time frame.

I believe the requirement is set as followed in section 8.1:

If the CA does not have a currently valid Audit Report indicating compliance with one of the audit schemes listed in Section 8.1, then, before issuing Publicly-Trusted Certificates, the CA SHALL successfully complete a point-in-time readiness assessment performed in accordance with applicable standards under one of the audit schemes listed in Section 8.1. The point-in-time readiness assessment SHALL be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and SHALL be followed by a complete audit under such scheme *within ninety (90) days* of issuing the first Publicly-Trusted Certificate.

My interpretation is that the CA MUST provide a complete audit WITHIN 90 days after issuing the first certificate.
well the first open cert that was issued was for https://helloworld.letsencrypt.org/ and conveniently they are valid for 90 days, which is the time to complete the full audit, and the cert expires on friday dec 12, 20:22:00 GMT so they still have some days to finish their audit, even though I doubt it will be finished until then.
A period-of-time audit generally has three dates:

- Start of Period
- End of Period
- Issuance of report by the auditor

Then there is the date on which the report is provided to Mozilla.

As I interpret 8.1, the end of period date must be within 90 days of issuing the first publicly trusted certificate.  Additionally, the rules for WebTrust audits state that the minimum period duration (the time between Start of Period and End of Period) is 60 days.

Mozilla currently puts to limit on how long it can take an auditor to issue the report after the end of period.  Based on reports on other CAs, this can be as little as four weeks or as long as 7.5 months.  

Once the CA has the report, they have 30 days to submit the report to Mozilla. (item #7 in the CA maintenance policy)

Given that Mozilla currently has no requirement on the duration between end of period and report issuance, there is no deadline by which one should expect to see ISRG/Let's Encrypt upload their report here.
(In reply to Peter Bowen from comment #10)
> Mozilla currently puts to limit on how long it can take an auditor to issue
> the report after the end of period.  Based on reports on other CAs, this can
> be as little as four weeks or as long as 7.5 months.  

Since the advent of EV and Baseline Requirements auditors have 3 month for the submission of the yearly report after expiration of the previous report or must issue a statement if the report is delayed with reasons for the delay. 
E.g. if the previous report was for the period 1.1.13 - 31.12.13, the next report must be issued by 31.3.14

However for audits covering the period the CA operated with a readiness audit, the requirement calls for within 90 days.
BTW. maybe this is something Mozilla can take to the CAB forum for clarification.
(In reply to roots from comment #7)

> Let’s Encrypt completed a point-in-time readiness assessment per BR Section
> 8.1, and will be fulfilling this complete audit requirement within the
> proper time frame.

Point in Time audit reports for ISRG / Let's Encrypt can be found on our website:

https://letsencrypt.org/repository/
Yes copy paste problem :-(
Attached file 1204656-CAInformation-Complete.pdf (obsolete) —
This request has been added to the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
I will update this bug when I start the discussion.
Whiteboard: Information incomplete → Ready for Public Discussion
According to <http://www.csoonline.com/article/3019991/security/malvertising-campaign-used-a-free-certificate-from-lets-encrypt.html>, Let's Encrypt issued a subscriber certificate that was used for distributing malware and, when informed, Let's Encrypt declined to revoke the certificate.  The subscriber certificate at issue was an integral part of a criminal attack to install banking malware on computers.  If this it is true that Let's Encrypt does not revoke such certificates, this request should not be approved.
(In reply to David E. Ross from comment #19)
> According to
> <http://www.csoonline.com/article/3019991/security/malvertising-campaign-
> used-a-free-certificate-from-lets-encrypt.html>, Let's Encrypt issued a
> subscriber certificate that was used for distributing malware

I think it's probably important to be precise in our language. This was not a code signing certificate. So what you mean is that the news article reports that "Let's Encrypt issued a subscriber certificate for a domain, and the domain was subsequently used for distributing malware."

> and, when
> informed, Let's Encrypt declined to revoke the certificate.  

You clearly think this is a bad thing. Are you asking Mozilla whether we require that CAs act as content filters for the sites that they provide certificates for? The answer to that question is No, we do not.

> The subscriber
> certificate at issue was an integral part of a criminal attack to install
> banking malware on computers.

You say "an integral part"; why would the attack have entirely failed if the website had not been SSL?

Gerv
(In reply to Gervase Markham [:gerv] from comment #20)
> > The subscriber
> > certificate at issue was an integral part of a criminal attack to install
> > banking malware on computers.
> 
> You say "an integral part"; why would the attack have entirely failed if the
> website had not been SSL?

Let's assume the following is true: Today, some people think that what they are doing on the web is completely safe if there is a lock sign next to the address bar. If this is what people think, then it is a very good thing that letsencrypt issuing certificates to everybody will change these peoples minds.
Hi Gervase Markham i put the topic into the LE restricted discussion board.
Even it is correct that LE policy is not to take care about webPage content
in this case if the news are correct the subdomain was illegal gained without
the domain owners permission and so it can not be considered as DV.
Interesting analysis of the Trend Micro article:
https://unmitigatedrisk.com/?p=552
I think the main problem with Let's Encrypt is the combination of the following:

1) Automated issuance
2) 1-factor verification (the server requesting the certificate doesn't need any interaction from any other person or device to get the certificate)
3) Refusal to revoke certificates when abuse is reported

Even with the short 90-day lifespan of LE certificates, this causes an issue. If a server is compromised, for example, it can be used for malware distribution for up to 90 days without the CA or anyone else being able to do anything about it.

The reality is also that malware distribution is normally done from new domains, not existing ones. Google's safebrowsing will have no record of new domains that have just been registered and have no reputation, so this check will never block these domains getting a cert.

I also strongly believe that it *is* the CA's responsibility to respond accordingly to reported abuse and illegal use of a certificate that was issued by them, and revoking it ASAP. Otherwise they are not fulfilling their role as an *authority*, IMHO.

All in all, I wouldn't give them a trusted root position, given the above.

Just my $0.02 -- do with it what you will.
well point 3 does hurt, but 1 and 2 is nothing special. most DV certs are automatic, or else they cant really be so quick.

but I wonder a bit that when Mozilla is one of the main Players of LE why the cert was not in Firefox from their beginning...
Technically, point 3 doesn't really matter.

Attackers can always obtain an OCSP staple signed by the CA before it starts doing somgthing. The revocation would only actually take effect after the signing expires, which could be several days. And within that duration, safe browsing mechanism could have already kicked in. So revoking certificates is neither efficient enough nor necessary for defending this kind of abuse.
and with this all 3 points mentioned by Mark are debunked as useless.
I think the certs should still be revoked, since it doesnt really hurt because it isnt a crl but an OCSP which has to sign responses for good and bad certs
(and in my opinion a revoked response should not need to be resigned every some days because certs arent meant to become "unrevoked" so it should be made so that OCSP accepts and recommends not constantly resigning revoked OCSPs which would also drop load from the CA.
Very quick to dismiss... I feel a bit more clarification is required to my $0.02 here:

OCSP stapled responses never have a long TTL (unless LE is using too long TTLs for that too; anyone have any data on that?), so if you'd actually check for stapled responses and not ignore expired ones (bug #1070752) then the scenario for using those is N/A and revocation would take effect very quickly. Even if it were a day or so, that's still better than 90 days and reliant only on the authority that issued the certificates (= the correct party).

My1: Point 1 may be commonplace as far as the actual issuance is concerned, but there's an important difference to keep in mind, which point 2 touched on in combination: It will still require a third party action (usually verification by registrar-listed e-mail). LE doesn't do this: the server ITSELF can (by design) request, verify and retrieve the certificate with no outside interaction, as opposed to verification that is normally required by a person. That is a potentially dangerous setup for CA-signing, even if it's "just" DV. So point 2 is most definitely something special and something to keep in mind, so please don't dismiss it.

Also, Xidorn, think outside of the box: you're assuming that every user of a client that encounters this CA's certs has available and has enabled a service check for phishing/malware sites on every request to catch bad domains that are otherwise not being flagged by the authority. And that those services are always available and always accurate or complete. In this case distribution most definitely can happen up to the expiration date of the cert if no revocation takes place by the CA.
That's not realistic or IMHO acceptable -- evaluation of a CA should never include assumption of specific unrelated services being in use by clients.
@Mark
well it does make sense in some way that you can verify it right with the server because the server is associated with the domain.

well whois email or DNS might be better for some but the concept of letting the server verify has it's own good points, for example you can HTTPS your dyndns domain.

also I think to bring back the gray lock and try to differentiate between DV, OV (if somehow possible) and EV.
espeically on mobile there is NO way to differentiate even between normal and EV certs on first sight since all the locks are green now.
earlier EV was green, rest was gray, simple enough.
Regarding points 1 and 2: While certificate issuance normally involves a human interaction, it would be fairly simple for a malware author to automate issuance of certificates even with existing providers. Each domain could be registered with a different email address, and a service like https://www.mailgun.com/inbound-routing could be used to receive the emails. I could probably automate certificate issuance with an existing provider in less than 24 hrs.

The only difference with Let's Encrypt is that the automation is already implemented.

Point 3 is still something to consider though.
@Mark : this is a thread about LE in Mozilla, not LE in general. So, when you say:

> you're assuming that every user of a client that encounters this CA's certs has available and has enabled a service check for phishing/malware sites on every request to catch bad domains that are otherwise not being flagged by the authority.

"a client" == "Up to date versions of Firefox that would include this cert".

In four days, there won't be any in-support browsers that don't check a safety list, anyway.

That said, I don't think point 3 is an issue -- I'm not sure I agree with the idea that it's the post-hoc responsibility of a CA to revoke a cert. Beyond that, OCSP/CRL isn't reliably checked by all browsers, right? I seem to recall that being a headline discussion an while back. 

If a machine on a trusted domain is compromised enough for this attack to work, then, if anything, the whole domain's certs should be revoked (which could be, but not necessarily is, LE's responsibility)
"In four days, there won't be any in-support browsers that don't check a safety list, anyway."
what happens in 4 days?
(In reply to My1 from comment #32)
> "In four days, there won't be any in-support browsers that don't check a
> safety list, anyway."
> what happens in 4 days?

MS ends support for all IE versions older than the latest/last (11). There we be no more versions of IE going forward, as it has been deprecated for MS Edge.

http://arstechnica.com/information-technology/2016/01/microsoft-readies-kill-switch-for-internet-explorer-8-9-and-10/

http://www.independent.co.uk/life-style/gadgets-and-tech/news/microsoft-ends-support-internet-explorer-version-8-9-10-a6800881.html

https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support
let me guess IE11 checks those lists?

but that means that Vista has no supported IE version (IE10 doesnt do vista and IE11 probably too), LOL, that might actually be a slightly bad move, especially considering that Vista extended (security) Support runs till somewhere 2017.

this is so bad it actually makes me laugh...
(In reply to tigerhawkvok from comment #31)
> @Mark : this is a thread about LE in Mozilla, not LE in general.

I get that. But you're also assuming everyone will just use Firefox as-set out-of-the-box. Quite a few users I know don't want to use Google's SafeBrowsing because of the inherent privacy issues. On top, you're still relying on it being always available (which it isn't) and always accurate (which it most certainly isn't).
Unless of course you're going to make this use of SafeBrowsing mandatory...

And this is inherently about LE in general because for inclusion of a root cert (which is no small deal), LE's practices and way of working are important. Including a root cert indicates that you explicitly trust the CA and all of the certs it issues; and I think the latter is problematic as has already been shown.

> I'm not sure I agree with the idea that it's the post-hoc responsibility of a CA to revoke a cert.

Whose responsibility would it be, then? If not the CA, who else is going to (or even can) revoke a cert for domains that cause net-abuse?
Or are you planning to have a dedicated team constantly update the Mozilla cert blocklist on a daily basis? And how complete will that list be at the end of the day? Because I think that will be required for LE root inclusion if the recent issues are any indication.

Sorry for going on and apologies if this discussion is rather seen on some Google groups mailing list (that is likely not going to do anything but have the point die off) but I do think these issues are relevant here because I say it'd be a WONTFIX, especially if you can keep a measure of control through cross-signing of LE certs by a different, trusted, CA as is the case now.
well one of the problems is that HTTPS revocation checks arent enforced for anything but EVs so it's kinda useless for many certs to be revoked in the fist place isnt it?
This discussion of CA policy should probably move to the dev-security-policy list:

https://lists.mozilla.org/listinfo/dev-security-policy
(In reply to tigerhawkvok from comment #31)
> I'm not sure I agree with the idea that it's the post-hoc responsibility of a CA to revoke a cert.

It's for sure their responsibility, see BR 4.9.1.1.
(In reply to Chris Peterson [:cpeterson] from comment #37)
> This discussion of CA policy should probably move to the dev-security-policy
> list:
> 
> https://lists.mozilla.org/listinfo/dev-security-policy

It's somehow no discussion of CA policy but discussion on following the BR, which is a requirement for inclusion to the root store, isn't it?
What else needs to be done in order for LE to be included to the Mozilla Trusted CA store?
Flags: needinfo?(kwilson)
well this probably needs to be discussed and is in queue for that.
(In reply to Jason Milionis from comment #40)
> What else needs to be done in order for LE to be included to the Mozilla
> Trusted CA store?

Mozilla's process is described here: https://wiki.mozilla.org/CA
Comment #18 in this bug completed step 4.
Flags: needinfo?(kwilson)
looks like quite a long process...
Full operational WebTrust audits (Sept 15 - Dec 15 2015) are available here:

https://letsencrypt.org/repository/
Attachment #8698640 - Attachment is obsolete: true
I am now opening the public discussion period for this request from Internet Security Research Group (ISRG) to include the "ISRG Root X1" root certificate, and turn on the Websites trust bit. 

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called "ISRG Root Inclusion Request".

Please actively review, respond, and contribute to the discussion.

A representative of this CA must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: Ready for Public Discussion → In public discussion
* Test Website: https://helloworld.letsencrypt.org/

I thought I had tested it, but now I'm not sure...

When I import the "ISRG Root X1" root certificate and turn on the Websites trust bit for it; and turn off the Websites trust bit for the "DST Root CA X3" root certificate; and clear my browsing history, then try to browse to the test website, I get the "Your connection is not secure" error.

Are you able to connect to the test website in a way that uses the ISRG root and not the DST root?
I see. But I need a test website whose SSL cert chains up to the root cert to be included. The CA can resolve this by updating the server to include the other issuer cert too.
https://helloworld.letsencrypt.org/
now chains up to the "ISRG Root X1" root certificate, and I was able to successfully test it.
Hi Kathleen, you wrote in the m.d.s.p thread for this inclusion that "I plan to close this discussion and recommend approval in the bug."

And then, you don't seem to have done either of those things, but neither did you comment any further in the thread itself. So, what is the status of this work?
Flags: needinfo?(kwilson)
(In reply to allizom40 from comment #51)
> Hi Kathleen, you wrote in the m.d.s.p thread for this inclusion that "I plan
> to close this discussion and recommend approval in the bug."

More people commented in the discussion, so I think the discussion is not yet ready to be closed. The CA needs to drive the Q&A in the discussion to closure, by responding to the questions and concerns that are raised.
Flags: needinfo?(kwilson)
The public comment period for this request is now over.

This request has been evaluated as per Mozilla’s CA Certificate Inclusion Policy at

https://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

Inclusion Policy Section 4 [Technical].
I am not aware of instances where Internet Security Research Group (ISRG) has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug.

Inclusion Policy Section 6 [Relevance and Policy].
ISRG appears to provide a service relevant to Mozilla users. It offers server authentication certificates to the general public around the world.

Root Certificate Name: ISRG Root X1
O From Issuer Field: Internet Security Research Group
Trust Bits: Websites
EV Policy OID: Not EV
Root Certificate Download URL: https://letsencrypt.org/certificates/

CA Document Repository: 	https://letsencrypt.org/repository/
CP: https://letsencrypt.org/documents/ISRG-CP-May-5-2016.pdf
CPS: https://letsencrypt.org/documents/ISRG-CPS-May-5-2016.pdf
Subscriber Agreement: https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf

Certificate Revocation
CRL URL: http://crl.root-x1.letsencrypt.org/
CRL issuing frequency for subordinate end-entity certificates: We will not issue CRLs for end-entity certificates.
CRL issuing frequency for subordinate CA certificates: At least once every six months.
OCSP URL: http://ocsp.root-x1.letsencrypt.org/
CP section 4.10.2: OCSP responses from this service must have a maximum expiration time of 10 days.

Inclusion Policy Section 7 [Validation]. 
ISRG appears to meet the minimum requirements for subscriber verification, as follows:

* SSL Verification Procedures: As per the CP, For each Name listed in a DV-SSL Certificate, the CA shall confirm that, as of the date the Certificate was issued, the Applicant either is the Domain Name Registrant or has control over the FQDN by following the procedures listed in section 3.2.2.2.

* EV SSL Verification Procedures: Not requesting EV treatment
* Email Verification Procedures: Not requesting the Email trust bit.
* Code Signing Subscriber Verification Procedure: Not requesting the Code Signing trust bit.

Inclusion Policy Sections 11-14 [Audit]. 
Annual audits are performed by Schellman & Company, Inc., according to the WebTrust criteria.
Standard Audit: https://cert.webtrust.org/SealFile?seal=1987&file=pdf
BR Audit: https://cert.webtrust.org/SealFile?seal=1988&file=pdf

Inclusion Policy Section 18 [Certificate Hierarchy]
CA Hierarchy: https://letsencrypt.org/certificates/
This root currently signs internally-operated intermediate certificates which sign DV SSL certificates.
* Externally Operated SubCAs: There may be externally-operated subCAs in the future, but the CP/CPS requires that they be audited annually according to the CA/Browser Forum Baseline Requirements.
* Cross Signing: Cross-signing with "DST Root CA X3" root that is owned by IdenTrust and included in NSS.
	
Based on this assessment I intend to approve this request from ISRG to include the "ISRG Root X1" root certificate, and turn on the Websites trust bit.
Whiteboard: In public discussion → Pending Approval
As per the summary in Comment #53, and on behalf of Mozilla I approve this request from Internet Security Research Group (ISRG) to include the following root certificate:

** "ISRG Root X1" (websites)

I will file the NSS bug for the approved change.
Whiteboard: Pending Approval → Approved, Pending NSS Changes
Depends on: 1289889
I have filed bug #1289889 against NSS for the actual change.
Do we want to add that in the fx release notes?
(In reply to Sylvestre Ledru [:sylvestre] from comment #56)
> Do we want to add that in the fx release notes?

As far as I'm aware, we don't usually add CA root cert additions/removals to the fx release notes.
We do mention them in the NSS release notes, e.g.
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.25_release_notes
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.26_release_notes  (addition of this root)
FWIW, I think it would be reasonable to treat this one specially... Let's Encrypt's work to improve the ecosystem and available to anyone seems especially well-aligned with Mozilla's mission, so it's worth more than a yet-another-CA footnote.
Let's Encrypt is hitting rules with feet and has been added although (late audit with curious dates, reject to treat with high risk certs, reject to revoke well known malicious certs) and meanwhile Mozilla checks steps against WoSign (for sure, the incidents are harder here, but also incidents exist with Let's Encrypt) nothing happens here but the CA has been added and should also now be celebrated?! Honestly it does not proof the independence of this approval process from the sponsorship in Let's Encrypt and hits the rule, that the auditor and the owner shouldn't be the same.

Additionally, making a up to nothing low level validation level the standard is nothing, which improves the ecosystem, as long as other validation levels are not distinquished expextable, it's exactly the opposite. The concept to add a certification validation to establish the encryption channel had a sense and what's not given by design and is the big challenge in the internet is trust, however the default is now encryption only. Maybe it's a good idea to encrypt everything although because of bad internet in many regions and information, which is public and not interesting for any investigation party, I do not see the need, but trust is also important, more important for a well running e-commerce, for e-government etc. So if encryption only is the new standard, it's fine but it should be distinguished from trust and what's the problem e.g. with extended validation is, that's not expectable, that there will be additional information for trust. Needs some kind of signal, additional icon, color handling, everyone learned (red, yellow, green), some kinds of scores (A-F), ...

In short: I do not see anything to celebrate, doing so would also proof lack of independence. Additionally I see important work for the security UI handling not to result in a desaster for the ecosystem as education on "check for https" may be damaged sustainable.
@#59 while I dont know much about the malicious certs except for one case I am pretty sure that iirc while LE wasnt early with the audits they also werent after the deadline back in november or whenever it was.
also for revoking I can see your point when they are not revoking that it is clearly against the rules but then again that person who got github certs from wosign did revoke his cert and it still worked in chrome since it didnt even care to check. revocation in the CA system is a mess to be short.

I personally think we should push for a system where not anyone can sign for anything like dane/TLSA as quick as possible and abolish the CA model for domain validation in the long run. for domain validation TLSA is better anyway because putting a file somewhere on the webserver just proves you have access to the webserver, not the domain itself, and since the whole DNS and DNSSec (as we know DANE/TLSA doesnt work without DNSSec) thing has to go over the registrar and registry making it hard for anyone but the domain owner get a valid DNSSec Running therefore also no DANE/TLSA for others.

while the DNSSec root KSK is a Single point of failure, as from what I read on the internet it is VERY well protected and just for resigning the new ZSKs every few months that you need seven people at once.

I dont know how hard the CA infrasture is saved but for CAs you have many points (each CA itself is one) of failure where any single one is enough to kick the whole system quite hard for anyone not using HPKP (which can be pretty risky so I userstand prople not using it) also some CAs may be in places with questionable law practices (e.g. the gov can force them to sign certs) which makes it worse. while this can happen for the registries as well the registry keys only work for their domains making it impossible for for example china to sign a DNSSec for a .de domain or whatever.

we have 174 (source:  different CAs and I personally dont think that ANY of them has ANY constraints no matter whether it's on the path length (intermediates usually get a pathlength but not a root cert) nor on the domain names. (I dont know it'ss just what I think. feel free to prove me right or wrong here)

and the problem is that any CA without constraints can instantly give out certs for ANY website bei it google, github or even mozilla unless it uses HPKP AND the browser in question supports HPKP as well.
Gentlemen,

This bug is not the place for a discussion of perceived flaws in the CA system.

Gerv
@#60 It's just a bit curious, reports which have been claimed, they don't exist come up lateron with a date in the past. So why have they been negated before? However, agree on your addons.

@61 For sure, it isn't, just responded on why it's no good idea to hype the integration and change in announcement procedures. Didn't started this hype discussion.
Limiting the comments on this bug now. I just asked a simple question, I didn't meant to start a discussion. Sorry about that.
Restrict Comments: true
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Whiteboard: Approved, Pending NSS Changes → Included in NSS 3.26, and Firefox 50
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.