New Standard For Issuance of SSL/TLS Certificates 62
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."
Re:Or (Score:4, Informative)
Re:What? (Score:5, Informative)
There was an agreement, way back when, which involved multiple levels of certs and a general understanding of what level of integrity each level of cert offered. It wasn't hard-and-fast, certainly no standard, but it was generally accepted and generally used. 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.
Interesting. (Score:3, Informative)
Seems like Go Daddy and a number of other CAs don't do much beyond check your Who Is entry in the way of integrity checking, don't actually generate a full key pair (they just sign the public key, which means they don't know who actually generated it, and no signature is placed on the private key which they never see, so the installer of the private key can't know that the private key is the key corresponding to the public key they're offering).
That's really, really, really bad design. Especially if you remember the problems with NULLs being added to strings, the ability to add arbitrary data to files without altering the MD5 hash, etc. I would never trust a signed cert if no individual in the chain could actually certify that one end-point matched the other. That's asking for a MITM.
Re:Interesting. (Score:4, Informative)
You can't trust GoDaddy or any one else to generate your private key! Thus it would no longer be private. Granted, more checking besides Whois data should happen for the ridiculous prices the CAs demand. Also, the owner of the private key obviously knows the public key, and when they install the CA generated certificate along with the keypair, the cert must match the public key.
This is a step forward (Score:5, Informative)
This is a step forward. Not a huge step, but a step. There's a standard, and although it's weak, it's at least there. And, importantly, there's a list of who's signed onto complying with it. The CA Browser Forum says that 94% of the issued certificates were issued by their members, and there's a list of all 40 members. All root certs from non-Forum members should be removed from browsers. Some browsers now recognize as many as 200 CAs. A purge is in order.
There's now a way to check whether a CA claims to comply with these rules. If the cert contains OID 2.23.140.1.2.2, the identity of the business behind the cert has supposedly been validated. If the cert contains OID 2.23.140.1.2.1, only the domain behind the cert has been validated. If it doesn't contain either of those, after July 2012, it's worthless. Browsers should be adjusted accordingly. Note that, for the first time, there's an actual verification process for business identity for non-EV certs. This is a big step forward.
I'm very interested in the validation process for business name information, as described in section 11.2.1 of the specification [cabforum.org]. We use that info in SiteTruth [sitetruth.com], and we'll be tightening up our cert validation, now that there are standards.
It's not clear how this will interact with Akamai's practice of issuing secondary certs for their customers, so that Akamai's caching servers can present SSL certs from companies Akamai represents. Akamai isn't a CA itself, and isn't a member of the CA/Browser forum.
Re:Why so complicated? (Score:5, Informative)
Why aren't SSL certs only to encrypt the transmission so data can't be packet sniffed? Why must the cert also certify that foo.com's owners paid $X for a cert?
SSL uses PKI(public key infrastructure). PKI provides two things, authentication and encryption. Authentication is critical because it proves the encrypted message is going the the recipient and there is nobody in the middle.
Why must the cert also certify that foo.com's owners paid $X for a cert?
It only certify that foo.com owns the certificate, it says nothing about how much the certificate costs.A certificate is a signed public key.
If I connect to mybank.com, can't I clearly tell from the URL that I'm going to where I think I'm going?
If you type "mybank.com" on your browser, your browser will make DNS request to get "mybank.com" IP address. Somebody could high jack the DNS request and return "iownyou.com" IP address and all of your data will send there instead of "mybank.com". Here is the part where the authenticity of the connection comes in.
In contrast, when I ssh between computers, I don't need any certs for that. Assuming I typed the host's name correctly, I'm going to where I think I'm going. Right?
When you ssh to a new computer, you will be presented with the other computer signature and asked if you trust the connection is coming from where you think its coming from and it is your responsibility to authenticate the connection. The CA system puts the responsibility on somebody else. The way ssh works is equivalent to self signed keys online. They will give you encryption but not authenticity. If you go to "mybank.com" and they say "we are mybank.com, trust us,we are who we say we are, here is an encrypted connection, use it to send your bank info", would you proceed? i hope you wont.