I've heard it from three different sources: Certificate Authorities will make verification more painful, more costly, and more difficult - but only if they're mandated industry-wide. They can't add overhead their competitors can skip on. The CAs and Browsers have been working together in the CA/Browser Forum to come up with new requirements for Certificate Authorities. The Public Comment period on the draft of these requirements is ongoing until the end of May, and takes place on mozilla.dev.security.policy. I read through the draft, and I didn't have many actual comments (aside from one question I posted to the SSL Observatory list and one clarification I requested) - but I wanted to highlight a few points from it.

The requirements are "a subset of the requirements that a Certification Authority must meet in order for its Certificates to be Publicly Trusted." They apply only to SSL/TLS Certificates: "Similar requirements for code signing, S/MIME, time-stamping, VoIP, IM, Web services, etc. may be covered in future versions."

It talks a lot about verification requirements to ensure the applicant is who she says she is in the event the cert will contain Subject Identity Information, but more importantly talks about how the domain and/or IP addresses will be verified:

If the CA uses the Internet mail system to confirm that the Applicant has authorization from the Domain Name Registrant to obtain a Certificate for the requested Fully-Qualified Domain Name, the CA MUST use a mail system address formed in one of the following ways:

1. Supplied by the Domain Name Registrar
2. Taken from the Domain Name Registrant's .registrant., .technical., or .administrative. contact information, as it appears in the Domain's WHOIS record
3. By prepending a local part to a Domain Name as follows:
   1. Local part - One of the following: "admin", "administrator", "webmaster", "hostmaster", or "postmaster"
   2. Domain Name . Formed by pruning zero or more components from the Registered Domain Name or the requested Fully-Qualified Domain Name.

So the old trick of registering one of these reserved email addresses might just work depending on the domain. And if the domain uses Anonymous Whois (Proxy Registration), that organization must be contacted to confirm the application is legit (so you could target those guys).

What is interesting though, is the wording in that section, emphasis mine: "If the CA relies on a confirmation of the right to use or control the Registered Domain Name(s) from a Domain Name Registrar", "If the CA uses the Internet mail system to confirm", "If the Domain Name Registrant has used a private, anonymous, or proxy registration service". It's a bunch of If's. There's no MUST or SHOULD stating that one of these methods are the only allowed.

Which lead me to ask about it - are these the only methods? Is this vagueness intentional? I gave the example of another verification method being via telephone from the WHOIS information. The responses are coming in privately and will be posted shortly I'm sure - but it does seem to be intentional. As Ian G says "the high level document should state the high level requirement, and leave implementation to the CA". He goes on to say that the audit process intended to ensure that the implementation is valid. (I'll talk about that below.) And Stephen Davidson mentions "There are a number of US patents covering aspects of domain validation for SSL certificates. The BR has to tread a fine line between laying out good practice and requiring CAs to follow a process that might intrude on a patented process." Sheesh. Patents on how to check someone's ID. /grumble

Edit:It seems this topic may have been accidently double posted (I submitted it first under a topic and a couple days later after it never showed up as a reply). The two threads are BR11.1 Authorization by Domain Name Registrant and BR11 -Validation Practices. A proposal to have methods listed in a wiki page referenced by the requirements has seen support, to ensure the methods are acceptable. There's definetly some questions about how that would work (can methods be removed? what's the approval process?) - but it's a step forwards and what I wanted to point out.

This next bit about audits is notable:

At least once every eleven to thirteen months following the previous independent audit (in order to accommodate an auditor's schedule), the CA MUST be independently examined for compliance with the requirements of one of the eligible audit schemes listed in Section 16.1.

...

The audit report MUST be made publicly available. For both government and commercial CAs, the CA SHOULD make its audit report publicly available no later than three months after the end of the audit period. In the event of a delay greater than three months, and if so requested by an Application Software Supplier, the CA MUST provide an explanatory letter signed by its auditor.

An "Application Software Supplier" is one of Apple, Google, KDE, Microsoft, Opera, RIM, and Mozilla. More interesting are the "eligible audit schemes" listed:

• WebTrust for Certification Authorities v1.0 or later
• ETSI TS 101 456 v1.2.1 or later
• ETSI TS 102 042 V1.1.1 or later
• ISO 21188:2006, completed by either a licensed WebTrust for CAs auditor, or an audit authority operating according to the laws and policies for assessors in the jurisdiction of the CA
• If a Government CA is legally required to use a different internal audit scheme, it may use such scheme provided that: (a) the audit encompasses all requirements of one of the above schemes, and (b) the audit is performed by an Appropriate Internal Supervisory Government Auditing Agency, separate from the CA, that meets the requirements of Section 16.4.

Since the people who read audit schemes and the people who read this blog are wholly orthogonal - here's some light details. First off, these are audits, not penetration tests or code review. And if we learned something from the Comodo debacle (assuming you believe the posted code) - it's that poor code and mediocre defenses do exist even in critical endpoints. The types of issues that exist in the nitty-gritty (hardcoded passwords, exposed administrative interfaces, password-based authentication instead of client certificates, and conceivably whatever bug enabled the Iranian to get the DLL in the first place) - should have been identified by a pen test. But an audit is more likely to gloss over the details.

But, putting aside my feelings of an audit compared to a penetration test (or an 'Advanced Persistent Test' if you're AR), it is encouraging that the audit report is required to be make available.

There's this small bit:

The CA and its RAs SHALL NOT archive the Subscriber Private Key.

If the CA, or any of its designated RAs were to generate a Private Key on behalf of the Subscriber, then the CA MUST encrypt the Private Key for transport to the Subscriber.

If the CA, or any of its designated RAs were to become aware that a Subscriber's Private Key had been communicated to any person or organization not affiliated with the Subscriber, then the CA MUST revoke any certificates that include the Public Key corresponding to the Private Key that has been communicated.

I don't see SHALL used too often, but it is a synonym for MUST, to save you the time of looking it up.

Now, for the paranoid crowd: what about collusion between a CA and the government? If it was proven that a CA had issued a cert for government interception, that CA would pretty quickly be untrusted by users, and probably browsers as well. It's incentive for a CA not to do so, since such an action puts its business at risk. But let's check the relevant sections of the doc:

8.1 Compliance

The CA MUST at all times: Comply with all law applicable to its business and the Certificates it issues in each jurisdiction where it operates

Could a judge order a CA to do the government's bidding and sign a CSR for law enforcement? Well, practically speaking I'm not qualified to answer this. There's not a lot of people who are. I credit Dino Dai Zovi when I say: "The people who are qualified to speak about the topic won't and can't, so by definition the only people speaking are people unqualified." I'll just note that by stretching parts of the Requirements (stretching "right to use, or had control of, the Domain Name and IP address") and emphasizing compliance with applicable law - they'd have somewhat of a defense from an industry sanction. Not from the people on the internet of course.

Now what about law enforcement trying force a CA to revoke a cert? This was a wondering I had that I posted to the SSL Observatory list. It came about from the following segments:

10.3.2 Agreement Requirements

The Subscriber Agreement MUST contain provisions imposing on the Applicant itself (or made by the Applicant on behalf of its principal or agent under a subcontractor or hosting service relationship) the following obligations and warranties:

4. Use of Certificate: An obligation and warranty to install the Certificate only on servers that are accessible at the subjectAltName(s) listed in the Certificate, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement

...

12.2.3 Investigation

The CA MUST begin investigation of a Certificate Problem Report within twenty-four hours of receipt, and decide whether revocation or other appropriate action is warranted based on at least the following criteria:

1. The nature of the alleged problem
2. The number of Certificate Problem Reports received about a particular Certificate or Subscriber
3. The type of the complainants (for example, a complaint from a law enforcement official that a Web site is engaged in illegal activities should carry more weight than a complaint from a consumer alleging that she didn't receive the goods she ordered)
4. Relevant legislation.

The certificate recipient must abide by "applicable laws" - but those laws may differ from the Certificate Authority's. Then a specific scenario of law enforcement complaining to a CA is given. When you couple that with the DOJ's over-reaching domain name seizures - well, personally I think it's a matter of when, not if, the government uses this tactic to harass sites extra-jurisdictionally.

if 1 * 2 < 3:
    print "hello, world!"