New Standard For Issuance of SSL/TLS Certificates

wiredmikey writes "In light of the many security breaches and incidents that have undermined the faith the IT industry has in Certificate Authorities (CAs) and their wares, the CA/Browser Forum, an organization of leading CAs and other software vendors, has released the 'Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates,' an industry-wide baseline standard for the operation of CAs issuing SSL/TLS digital certificates natively trusted by the browser. The CA/Browser Forum is requesting Web browser and operating system vendors adopt the requirements (PDF) as part of their conditions to distribute CA root certificates in their software. According to the forum, the Baseline Requirements are based on best practices from across the SSL/TLS sector and touch on a number of subjects, such as the verification of identity, certificate content and profiles, CA security and revocation mechanisms. The requirements become effective July 1, 2012, and will continue to evolve to address new risks and threats."

Or

[Spad]

In other news: Certificate Authorities who were already half-assing their verification processes, hiding their security breaches and not bothering to secure their internet-facing phpmyadmin installs will continue to do exactly that under the new regime right up to the point that they get caught, just like now.

Money, time and effort

[jdastrup]

I remember the days when SSL certs where at least $200 USD/year, required faxes and forms, including one notarized. It was a pain in the butt to get a legit SSL cert that worked in most browsers. Looks like we may be going back to that.

SubjectAltName and internal names / reserved IPs

[nullchar]

It's great the CA/Browser Forum, made up of the most prominent Certificate Authorities, is taking steps to standardize their rules for certificates. Many rules in the PDF are technical and exact, which will help with software enforcement.

However, even this necessary step of not issuing public certs for non-FQDN hostnames and reserved IP addresses won't take effect until late 2016!

As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName
extension or Subject commonName field containing a Reserved IP Address or Internal Server Name, the CA
SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and
that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a
certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject
commonName field containing a Reserved IP Address or Internal Server Name. Effective 1 October 2016, CAs
SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field
contains a Reserved IP Address or Internal Server Name.

If we're going to spend time and resources updating our browsers and operating systems to enforce some of these requirements and properly query certificate revocation lists, we may as well throw out the entrenched CA model and try something else [convergence.io].

Not just that.

[khasim]

Then people wanted certs cheap and now, not something high levels of integrity checking really allow for, so what agreement did exist simply went up in smoke as vendors pandered to customers over and above common sense.

Not just that. Certs are also now MARKETED as a means of verifying the web site you're connecting to.

The process you mention is one means of attempting to fill that role.

But certs were not designed as a means of verifying a web site. They're just for encryption. And for encryption they work pretty good.

The question now is how do you verify that the site at a.b.c.d is REALLY the site you think it is. Here's a hint: you cannot rely upon the certificate to validate it.

Don't baby security companies

[thegarbz]

These are companies in which we should place our full trust. There shouldn't be standards, codes of practices, or anything else which could let an idiot with a computer become a root CA.

Instead the requirements should open them up to vigorous external audits. The auditors should be security experts and should be able to look at every part of the internal and external infrastructure owned by the CA. Any CA that fails should be kicked off the list.

Maybe then we'd weed out the incompetents from the companies with which we trust our security.

Re:Interesting.

[Anonymous Coward]

It appears that you fail basic understanding of the concepts of public key cryptography and certification authorities. OF COURSE the CA does not generate the private key because this would break the security concept. There is nothing wrong with having the CA only sign the public key. Your musings about the private key are total nonsense, using a private key which does not belong to the public key will simply not work.

Really, get yourself educated before posting such rubbish.