Closed Bug 647959 Opened 14 years ago Closed 14 years ago

Add Honest Achmed's root certificate

Categories

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

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: honest.achmed, Assigned: kathleen.a.wilson)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16 Build Identifier: This is a request to add the CA root certificate for Honest Achmed's Used Cars and Certificates. The requested information as per the CA information checklist is as follows: 1. Name Honest Achmed's Used Cars and Certificates 2. Website URL www.honestachmed.dyndns.org 3. Organizational type Individual (Achmed, and possibly his cousin Mustafa, who knows a bit about computers). 4. Primary market / customer base Absolutely anyone who'll give us money. 5. Impact to Mozilla Users Achmed's business plan is to sell a sufficiently large number of certificates as quickly as possible in order to become too big to fail (see "regulatory capture"), at which point most of the rest of this application will become irrelevant. 6. CA Contact Information achmed@honestachmed.dyndns.org Technical information about each root certificate 1. Certificate Name Honest Achmed's Used Cars and Certificates 2. Certificate Issuer Field Honest Achmed's Used Cars and Certificates 3. Certificate Summary The purpose of this certificate is to allow Honest Achmed to sell bucketloads of other certificates and make a lot of money. 4. Root Certificate URL www.honestachmed.dyndns.org/cert.der 5. SHA1 fingerprint to 10. Signing key parameters See the certificates. 11. Test website URL - 14. OCSP (OCSP is required for EV enablement) https://www.honestachmed.dyndns.org / www.honestachmed.dyndns.org/chain.p7s / www.honestachmed.dyndns.org/crl.der / www.honestachmed.dyndns.org/ocsp.asp 15. Requested Trust Bits All of them of course. The more trust bits we get, the more certificates we can sell. 16. SSL Validation Type All of them. The more types, the more certificates we can sell. CA Hierarchy information for each root certificate 1. CA Hierarchy Honest Achmed plans to authorise certificate issuance by at least, but not limited to, his cousin Osman, his uncles Mehmet and Iskender, and possibly his cousin's friend Emin. 2. Sub CAs Operated by 3rd Parties Honest Achmed's uncles may invite some of their friends to issue certificates as well, in particular their cousins Refik and Abdi or "RA" as they're known. Honest Achmed's uncles assure us that their RA can be trusted, apart from that one time when they lent them the keys to the car, but that was a one-off that won't happen again. Verification Policies and Practices 1. Documentation: CP, CPS, and Relying Party Agreements Honest Achmed promises to studiously verify that payment from anyone requesting a certificate clears before issuing it (except for his uncles, who are good for credit). Achmed guarantees that no certificate will be issued without payment having been received, as per the old latin proverb "nil certificati sine lucre". 2. Audits Achmed's uncles all vouch for the fact that he's honest. In any case by the time he's issued enough certificates he'll be regarded as too big to fail by the browser vendors, so an expensive audit doesn't really matter. 3. SSL Verification Procedures 4. Email Address Verification Procedures 5. Code Signing Subscriber Verification Procedures See (1). Response to Mozilla's CA Recommended Practices Honest Achmed promises to abide by these practices. If he's found not to abide by them, he'll claim it was a one-off slip-up in procedures and that policies have been changed to ensure that it doesn't happen again. If it does happen again, he'll blame it on one of his uncles or maybe his cousin, who still owes him some money for getting the car fixed. Reproducible: Always
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Honest Achmed is at least more honest than Comodo.
Is this really regulatory capture, or just TB2F? The CAs aren't exerting any pressure on the browser vendors (they don't have to because the browser vendors aren't acting as regulators), it seems more like plain TB2F to me.
He seems very honest, we should grant him to be a CA. (LOL).
Resolved invalid? What's the difference between Honest Achmed and the other CAs? Just an audit report? The community should chip in!
This guy seems pretty legit. I know his third cousin seven times removed Asya, she works at my local breakfast place. We can have a key signing party there or something. Signing the keys of people you don't know, but your friend has a friend who has a sister who knows them, is recommended industry practice these days right? Plus, I hear he gives discounts when you buy identities in bulk.
Is this really "resolved invalid"?
I am sure Achmed could help getting the issue resolved timely by hooking up his revenue stream to the bug assignee?
This sounds like a dup of bug 239484.
I don't see how this is RESOLVED INVALID! Honest Achmed is my bedrooms 2^nd largest CA and if you fail to add the root certificate to firefox I have real problems when accessing my notebook while it is stationed there! Please reopen!
I have reopened this ticket due to the honest nature of the request. Trust the man's certificate. You trust everyone else's.
According to http://www.mozilla.org/projects/security/certs/policy/ and https://wiki.mozilla.org/CA:Information_checklist apparently fails to comply to the audit requirements amongst other things at the moment. Should a valid audit statement be published and confirmed by an authorized auditor, I guess Mozilla could consider a discussion to include this CA.
Given that the audit requirements will become irrelevant once Achmed has issued enough certificates to become TB2F, it seems a little redundant to require an audit. Perhaps Achmed could simply donate the cost of the audit to charity, where it'll at least do some good, and cut out the middleman? (BenB: Nice comment :-).
There is nothing new under the sun; this is actually a duplicate of bug 233458. Inclusion policy is here: http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Honest Achmed's application fails to meet criteria: 6, bullet 3 6, bullet 6 and therefore also sections 9, 10 and 11 7 Gerv
I note that there is a sizeable portion of Thunderbird's userbase which would benefit from having Honest Achmed's certificate included: the members of the many and varied fandoms, interest groups, and self-organizing groups which have a penchant for pseudonyms which cannot be verified with any public registrar. I vote to reopen the bug.
Considering the problems at DigiNotar I vote for giving Honest Achmed a second chance!
Given Diginotar's recent performance, would it have helped my case if I'd applied as Dishonest Achmed? My other cousin Coskun has many hacker friends in Iran, and they've assured him they wouldn't engage in their national sport of using foreign CAs to issue them Google certificates if I was accepted as a CA.
You have only a chance of getting approved if you install an anti-virus scanner because the absence of such in the Diginotar case is what Fox-IT thought was worth mentioning in their report. And since we all know that anti-virus scanners are fuelled by magic and able to detect the intent of the programmer of a certain piece of code this is all the protection you need.
(In reply to Ben Bucksch (:BenB) from comment #8) > This sounds like a dup of bug 239484. Not bug 380635 and bug 433845?
FWIW, I think Baboo is referring to TÜRKTRUST "issuing two SSL intermediary certificates that could be [and were] used to issue certificates for arbitrary domains" <http://www.h-online.com/security/news/item/Fatal-error-leads-TURKTRUST-to-issue-dangerous-SSL-certificates-1777291.html>
Restrict Comments: true
Product: mozilla.org → NSS
QA Contact: kwilson
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.