Please remove StartCom Certification Authority root certificate
bugs.debian.org
bugs.debian.org
On the side of StartCom an extremly resonable point as to why they should not waive their fee:
> Every other certificate provider requires payment for certificates. StartCom is the one provider offering free certificates, which goes a long way to spreading TLS and https more broadly, and the complaint here is that they're daring to charge a fee to maintain their revocation list? Removing them over that would do more harm than good to security.
And the also very reasonable counter point:
> The problem is that thanks to Heartbleed we now have potentially leaked private keys (leaked due to circumstances outside of the control of anyone) and thus insecure sites. Now with StartSSL charging for every single revoked certificate they are encouraging people to "eh, the chance my key got leaked is so low, I'll just stay with my old certificate" thinking and behaviour. This is actively compromising the security of SSL and consumers (no one I know checks the SSL vendor on certificates of sites they visit if there's the lock icon and it says it is trustworthy). Therefor customers and site users expose themselves to potential security risks while the browser ensures them they are communicating securely with the website.
At the very least its refreshing to see that people aren't just jumping on the rage bandwagon of, "OMG you mean I have to pay for something that you said I'd have to pay for. You are evil".
It's nice to see some even handed analysis of the situation!
" Revocations carry a handling fee of currently US$ 24.90. Class 1 subscribers may use a different sub domain in order to create additional certificates without the need to revoke a previously created certificate. Alternatively it's possible to upgrade to Class 2 level which allows to create the same set of certificates once again (besides all the other benefits), because different levels are issued by different issuers, making revocation unnecessary."
I understand where Mozilla's coming from here, but I also see it from StartCom's side. StartCom requires manual verification for certain sensitive CA operations, so they've set up their (quite reasonable) fee schedule accordingly. Likewise, I'm sure that the terms and conditions of other CAs states that in the case of a key compromise, sure, they'll revoke the certificate for free, but the user must buy a new certificate to replace the compromised one - which is basically the same thing as StartCom charging for revocation.
If you’re maintaining a CA trust store, it might be a little different. The CA can adopt any pricing structure they want, but the one they’ve chosen will lead some customers to not revoke their certificates, resulting in potentially compromised certificates being used in a way that could have been avoided.
This could definitely factor into your judgment of whether it’s a good idea to trust certificates signed by that CA.
However, even though I own some certs with StartCom, I personally think this comment has literally no basis.
Looking at the CA market - if anything - we should be happy that a CA like StartCom exists. It is a very small team lead by Eddy Nigg (he is very helpful by the way) and given that they are the ONLY ones (as far as I am aware) offering free certs - we should applaud them. Besides, the fee for revoking is very small.
I also was very much aware that revoking a cert had a charge before I signed up for one - I think it is pretty clear - so not a problem for me at all. Of course if I had to revoke a cert because of StartCom's mistake that would be a different story.
Bare in mind these are only domain validated certificates - perfect for small website owners who wish to offer their site over httpS without paying any extra fee.
Your customer relation to StartCom is irrelevant, this is about everybody else implicitly trusting them.
> Whatever you and I think of this pricing structure, people free to chose any provider of certificates that matches their pricing interest and that people are knowingly or should be knowlingly buying a product that has a certain price structure when they get the certificates in the first place.
> Revoking a certificate is generally primarily in the interest of the owner of said certificate so there is incentive to actually pay this fee.
> I do not believe it is Debian's place to pass judgement on which pricing scheme people should prefer, even if you and I personally rather pay up front and have no costs on revocation.
This led to a bit of problem with a proxy server at work. A filter update blocked the CRL link, and suddenly nobody in my office could sign into their Chrome browsers. You'd hit "log in", it would appear to work, but nothing happens. An error saying that CRL checks were at fault would have saved a great deal of time....
I went an checked firefox too which does check CRLs as default but doesn't silently fail if it can't check them (it's a separate tickbox)
# dpkg-reconfigure -p low ca-certificatesThis is a sticky situation, really. On one hand, StartCom's pricing structure is fairly upfront. On the other hand, extracting $25 from every customer because of a bug they have no control over is dick behavior of the highest order.
Ideally they'd put out a notice saying that they will offer a one-time rekey for free. Without getting into ethics, it's an entirely automated process and costs Startcom absolutely nothing.
A CA profiting from a vulnerability is a fairly perverse incentive, too.
Their whole purpose is to help with the authentication side of security. They didn't force anyone to use buggy code written by a third party and it is not their fault that many of their customers have gone and done so.
It costs money to maintain a CRL.
Maybe they could revoke their intermediate certificate and reissue certificates to everyone. That would take time to coordinate, and every month that goes by 1/12 of the bad certs expire anyway.
That's not the issue though. Most people are not StartCom customers and couldn't care less.
They still care about what that padlock icon signifies and that's why it's pertinent of large vendors to consider the CA status of StartCom in a situation like this.
You mean "Real Life" if I buy an item from manufacturer X, and it breaks due to a product from manufacturer Y (which almost everyone uses with the product I bought since it's complementary), it would be nice if manufacturer X would replace the item for free, but it's not sketchy or a dick move if they don't.
If the certificate is not revoked when compromised, the party harmed may not be the StartCom customer, but anyone still trusting certificates issued by them.
When this is happening on a large scale, considering the CA status of StartCom is certainly due dilligence.
As I understand it, not all StartCom certificates are necessarily vulnerable. I have a number of StartSSL certificates issued before 4/7 that, according to the HeartBleed checker here[1] are not vulnerable.
Is it wrong for me to assume that the tool is correct, or is it wrong to assume that all StartCom certificates are necessarily vulnerable?
The risk is that before the vulnerability was patched, somebody used it to grab the private keys associated with the certs.
They aren't claiming all StartCom certificates are vulnerable, they are saying some StartCom certificates may be vulnerable because they impose a fee on revocation.
Seems like a straightforward solution for them to implement.
This is implied by the request itself but is it possible to implement?
I think the optimal thing would be moving the job of identity verification into OpenID identity providers. So you could create a plain OpenID identity, or pay for a verified OpenID identity. Then, CAs would just be infrastructure to issue free certs to whichever verified identity obviously owns them.
In fact, if identity verification came before domain registration et al., the certificate-issuance part could even be done proactively: you'd buy a domain, put your verified OpenID in the SOA record, and then some CA-bot would notice, prompt your identity provider to generate a CSR using the private key the identity provider has on file, and then send back a signed cert.
Please, don't. This idea is horrible.
With OpenID (and xAuth and Persona and whatever) your identity is provided, not asserted. This is very important distinction. I believe, any sane person wants to be a source of their identity (that's asserted by others), not to lease their very identity from a third party.
If you want an identity - generate a keypair. Publish your public key and let others sign it to assert this keypair is genuinely yours. It's that easy. (Although, sadly, X.509 doesn't support multiple signatures, so one can't do a proper web-of-trust with them.)
If you want automated domain ownership verification and completely automated certificate signing (and whois-pointed email ownership check is not to your taste) - well, how about putting a CSR right in TXT record of the domain? CA-bot would see those and sign them. No need for identity providers except for a domain registrar.
You're hiding an unbounded amount of work under the word "publish" there. The important part of an identity is the part where people trust that someone using the identity is you. Just posting "hey, this is the public key for John Smith" on a website does nothing to prove that fact. (Key-signing parties prove that fact, but people don't do those.)
What does prove that fact is the background-check a CA does. But they only do it to create a private notion of your identity for themselves, which means that every CA has to do its own redundant background check, which is why certs cost money.
All I'm suggesting, here, is that the "background checking to create an ID number that maps to a specific person" part could be split off into its own business model, and the resulting ID number (in the form of an OpenID, or whatever else) reused by any-and-all organizations that wish to map tokens to real people.
Also:
> I believe, any sane person wants to be a source of their identity (that's asserted by others), not to lease their very identity from a third party.
You're never the source of your identity. For example, your name is only your name because the government you were born under has a law creating an identity, by mapping birth certificates to people, and your name is one aspect of that identity. Change citizenship from the US to China? Suddenly what you were considering "your name" is no more, and your new name is spelled in ideographs. You can certainly get people to call you by your old, alphabetic name--but that is a person-to-token mapping. In any token-to-person mapping--a phonebook, for example--you'll be found by your new government-created identity.
I guess you're (or I'm, that's well possible too) mistaking identity with something other.
In my understanding, identities are what we - or part of us, as one could have multiple identities - are, not how we're called or what we look like. And names, personal or domain ones, are not identities but their properties. Others could assert your identity by confirming those properties (like when state issues a birth certificate with one's name in) or even associate their own information with person's identity (like assigning a trust level to a signature or limiting signature's timespan or, say, adding contract ID to a signature).
This is why OpenID and other attempts to shift identities from being owned (like one owns a certificate or password) to being merely leased doesn't look fancy to me.
One key point in this is that an authentic document can be fraudulent (just takes a bit of corruption down at the office).