
Please remove StartCom Certification Authority root certificate - silsha
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744027
======
chollida1
TL/DR from the Mozilla bugzilla
([https://bugzilla.mozilla.org/show_bug.cgi?id=994033](https://bugzilla.mozilla.org/show_bug.cgi?id=994033))
There doesn't appear to be a definitive argument as to should they or should
they not waive their revocation fee.

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!

~~~
xenophonf
I'm a StartCom user that's affected by Heartbleed. Right now, I am using the
free certificates, so this FAQ entry applies
([https://www.startssl.com/?app=25#72](https://www.startssl.com/?app=25#72)):

" 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.

------
DangerousPie
I don't think that "charging for services you said you would charge for" is
anywhere near reason enough to revoke a root certificate. I would be very
disappointed by Debian if they actually went through with this.

~~~
guan
From the customer’s point of view there’s not much to complain about.

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.

------
mstrem
Disclaimer: I have a number of free StartCom certificates.

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.

~~~
yeukhon
If I remember correctly, [http://gandi.net/](http://gandi.net/) offers 1 year
free SSL cert if you buy a domain. To be honest the difference between an
excellent cert and good-enough cert is what you want to protect. If you think
your data is so sensitive and you accept that we must rely on CA at the
moment, you wouldn't be using StartCom free cert.

------
rschmitty
Seems unlikely to happen based on what was said in the thread.

> 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.

------
BuildTheRobots
Not getting involved in the politics of being charged for revocations/re-
keying, however it's worth pointing out that Google Chrome (linux and windows,
and Chromium) all seem to have the "Check for server certificate revocation"
option disabled by default.

~~~
Karunamon
In my experience, enabling it causes strange behavior with some plugins and
even Chrome itself at some times. If the CRL check fails, related secure
connections will fail _with no notification_.

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....

~~~
BuildTheRobots
Interesting; thank you for the warning -This explains some of the oddness I've
been having this morning after enabling it last night.

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)

------
blazespin
Certificate revocation infrastructure (OSCP or CRL server) is something that
needs to be maintained constantly (versus certificate requests, which are a
one shot deal). In order to maintain that revocation, they have to keep
serving it out for as long as someone might use your cert. It makes perfect
sense to charge for it.

~~~
makomk
The certificate revocation infrastructure is something they're required to
maintain in order for any of the browsers to actually accept their
certificates, though.

------
dfc
Hats off to the Debian developer. I can not believe the report was handled so
politely. This is one of the silliest bug reports I have seen. I can not think
of what the possible thought process was that led to the formation and
submission of this bug report.

    
    
      # dpkg-reconfigure -p low ca-certificates

------
joosters
StartCom customers knew the pricing before they signed up. They should take
the hit. What more is there to it?

~~~
fletchowns
Bingo. If you don't like it, get your cert from somewhere else.

------
chrramirez
So, if StartCom is removed from trusted CAs you will have to buy a new
certificate and spend $$$, something you obviously want to avoid. That's
stupid.

~~~
Karunamon
And worse, the Debian developers would be at fault.

This 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.

~~~
sigzero
I don't think it is dick behavior at all. That has always been their policy.
They have no control of the software originating the problem. It is up to them
to wave or not but not choosing to doesn't make the anything but a business.

~~~
Karunamon
So it's a business. So it's policy. Those are not defenses.

A CA profiting from a vulnerability is a fairly perverse incentive, too.

~~~
lotsofmangos
What else do CAs profit from if it isn't security vulnerabilities?

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.

------
doughj3
There's more discussion on the Mozilla bugzilla, linked from this report:

[https://bugzilla.mozilla.org/show_bug.cgi?id=994033](https://bugzilla.mozilla.org/show_bug.cgi?id=994033)

------
bmelton
Either this request is naive, or I am.

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?

[1] - [http://filippo.io/Heartbleed/](http://filippo.io/Heartbleed/)

~~~
ef4
What that tool says is irrelevant to the question of whether those certs have
been compromised.

The risk is that _before_ the vulnerability was patched, somebody used it to
grab the private keys associated with the certs.

~~~
singlow
But what if the key was never used with openssl or heartbeat?

~~~
andreasvc
Obviously that would be great, but a tool cannot check that.

------
Guvante
> A user comment here says the CVE was cited, and StartSSL waived the
> revocation fee.

Seems like a straightforward solution for them to implement.

------
jl6
Solution 3: cease trusting StartSSL certs issued before 2014-04-07?

This is implied by the request itself but is it possible to implement?

~~~
DoubleMalt
This is actually not enough as you cannot be sure that certificates generated
after that have never been used on a server with a vulnerable OpenSSL
implementation.

~~~
throwaway125
You can't ever guarantee that for any certificate signed by any CA.

------
lazylizard
please remove all CA root certificate becaue they all charge fees for certs
and that discourages spreading TLS and https more broadly?

~~~
derefr
StartCom _almost_ has the right idea with the way they do EV certs: they
charge you _for identity verification_ (the thing that actually requires human
labor to do), and then the EV certs themselves (as many as you like, for as
long as you like) are free.

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.

~~~
drdaeman
> moving the job of identity verification into OpenID identity providers

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.

~~~
derefr
> If you want an identity - generate a keypair. Publish your public key and
> let others sign it to assert this keypair is genuinely yours.

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.

~~~
drdaeman
> You're never the source of your 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.

~~~
maxerickson
I'm in your camp, identity is an intrinsic property of a person. Documents
provide variously worthwhile assertions about that identity (legally
recognized name of depicted individual is...).

One key point in this is that an authentic document can be fraudulent (just
takes a bit of corruption down at the office).

