Re: Revocation Policy

[Zack Weinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/29/2014 07:09 AM, Gervase Markham wrote:
> 
> Let's imagine StartCom said to you: "OK, we will perform free 
> revocations for all Heartbleed-affected certificates, as you 
> request. And we are changing our business model to charge up-front 
> for certs like all the other CAs, so we don't get hit with a big 
> cost like this again. No more free-of-charge 1-year-valid certs on 
> the Internet."
> 
> Would you consider that a good trade-off, in terms of improving
> the general security of the Internet?

I had to think about this for quite a while, and my answer winds up
being "it depends".

First off, I want to say that estimate the risk of leaving certificates
unrevoked post-Heartbleed fairly low, *despite* evidence that it could
be exploited to capture private keys, because no one has credibly
demonstrated that it was being exploited prior to disclosure (if I'm
wrong about this please tell me!)  Therefore, as long as the affected
server was patched promptly, the odds of a key compromise are low.  (At
this point, though, there are weaponized exploits circulating, so CAs in
general really ought to to crawl their subscriber database and
unilaterally revoke certificates that are on servers that are *still*
vulnerable.)

Because of that, the things we are trading off are (as I see it):
marginal probability that someone starting up a new website will make it
an HTTPS website, versus aggregate probability that, in response to
*similar future* catastrophic events, everyone who should have revoked
their certificate does so.

I think the main thing that swings this tradeoff is how much that
upfront charge is.  If you are considering the acquisition of a
certificate, you are already paying for a domain registration; domain
names cost order of (US)$15 a year, which is peanuts compared to the
cost of the server / hosting provider.  So a charge on the order of $15
per certificate per year is, I think, not that likely to deter people
from making their site HTTPS.  Conversely, we know from this very
discussion that lots of people considered revoking their free StartCom
cert and didn't, precisely because it *wasn't* free.  Relatedly, people
are generally more comfortable with costs that are predictable than with
costs that are unexpected, even if they wind up spending more money in
total with the predictable costs.

On the other hand, if the cost has to go up to $50 or more, that starts
sounding like people who have concrete, not-just-in-principle reasons to
make their site HTTPS *will* be deterred, which would be bad.

Pulling in something you said in response to Jan:
> That sounds to me like: "I'd like to live in a world where
> whatever costs there are for having a certificate system are not
> borne by me under any circumstances."

- -- I keep coming back to my earlier observation that this sort of
low-probability, high-cost event is what insurance is for.  Eddy said
that he had "never heard of" insurance against losses incurred because
of catastrophic failure of software that the business relies on, but
given that the state of play in the software industry is to disclaim all
warranties at all times while shipping code riddled with bugs, I cannot
bring myself to believe that such insurance is unobtainable.  It seems
like something lots of businesses should want.

zw
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTY9eOAAoJEJH8wytnaapkKjUP/ApOkFHdvk6DhXQuhYt2X5Ot
L5or2YprV+I1wRlGWAX2CZLngQWEq0KGGe0Sv59//C4Yq87JlGWjg6uFl8ioE40W
H3tI71lGm7W5QneZsg9Acb6jSHGk/ufNNTkTpxQuQCZK6BGRTMXBssV7ucK9dZWc
P9VGORKjnSFf8RfBAkRH6OaYrh3f7X3J/AmGI8lYIqKrowV89BiKV89d8KR+7sRa
ixfR+1TbOs3D8sAoZoKZZ6ZjBOYhhFFuFnoUu237Sl89AKcVLFjKY/ahv7LMKu+h
pRAlczrOwGZY5RHUXuTb0Yg9IZebp6/VqScRzeuugqQ9cFNgEU/5T1F3JMjmOSSS
Ae1w6X8O8KhcQjRKcGC4sjG0qDNmF6zFKAC55iglV42QeNvTNAh0b6ZG/ygPw8yN
fTN/GxI4JEX4IVAGnM35We3Cmg4KlLwFDhRx6YXrVtfnWyTRHJXAWl8Zbc7z/t6d
5m74F/ZXlHTfLEua/hwnPwk/jTJ50pgnHVVjr/Bl/Sf5URkbNdN7ybpZg/SK2e2J
jH3DUwNwqFtUyz6RRlfc4Kr7tP7deyE9Mr+l1cVthPQfTVN918sXZHr2FcaUTZ01
CM9AyZTJzDgFiUqV4sJoXsi4pQOdqhtm0WFnC2iZBczW36B5hdIHbW3oJxQ8vEbM
VMN7BHGKew4f0LufVk9n
=Lesr
-END PGP SIGNATURE-
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Jan Lühr]

Hello,

Am 30.04.2014 um 12:54 schrieb Gervase Markham :

> On 29/04/14 15:31, Jan Lühr wrote:
>> I'd like to live in a world, were revocation is without any hassle an
>> Community Driven CAs like CAcert are providing security for sites to be
>> interested in.
> 
> That sounds to me like: "I'd like to live in a world where whatever
> costs there are for having a certificate system are not borne by me
> under any circumstances."

No - I’m just dreaming of do-it-yourself communities.
But this is off-topic here - plz contact in person if you’re up to discussing 
this.

Regards, Jan



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Gervase Markham]

On 29/04/14 15:31, Jan Lühr wrote:
> I'd like to live in a world, were revocation is without any hassle an
> Community Driven CAs like CAcert are providing security for sites to be
> interested in.

That sounds to me like: "I'd like to live in a world where whatever
costs there are for having a certificate system are not borne by me
under any circumstances."

Gerv


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Jan Lühr]

Hello,


Am 04/29/2014 11:48 PM, schrieb Eddy Nigg:
> On 04/29/2014 05:31 PM, Jan Lühr wrote:
>> - By advertising certs to be "non-free" and putting the actual price tag
>> on it, alternate CAs like CAcert might get a boost in popularity,
>> emphasizing their importance for global internet security. At the
>> moment, many people skip CAcert in favor of StartSSL, cuase they just
>> can get a "free" certificates in major browsers.
>>
>> I'd like to live in a world, were revocation is without any hassle an
>> Community Driven CAs like CAcert are providing security for sites to be
>> interested in.
> 
> And lets assume CAcert would gain that popularity - how do you expect
> that to be financed exactly? 

I expect (as in expected value) CAcert to die soon. They hardly(?)
sponsors - their own folks consider CAcert to be dead and leave [1]. I
It wouldn't surprise me, if they run out of money soon and vanish.

Do you really believe this could be sustained with ideology?

Nope. I'm just painting a picture of my ideal world. It clashes with
reality far too often :-/.

> I suspected that there are a few CAcert groupies around here with this
> discussion ;-)
> 
> But I tell you a little unknown secret, the first time I heard about
> charging for revocations it was exactly from the folks like Duane and
> later Ian. You can ask them and they might even confirm it, because they
> too were looking for solutions to a problem.
> 

Interesting side node ;-)

[1] https://lists.cacert.org/wws/arc/cacert/2014-03/msg00024.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Eddy Nigg]

On 04/29/2014 05:31 PM, Jan Lühr wrote:

- By advertising certs to be "non-free" and putting the actual price tag
on it, alternate CAs like CAcert might get a boost in popularity,
emphasizing their importance for global internet security. At the
moment, many people skip CAcert in favor of StartSSL, cuase they just
can get a "free" certificates in major browsers.

I'd like to live in a world, were revocation is without any hassle an
Community Driven CAs like CAcert are providing security for sites to be
interested in.


And lets assume CAcert would gain that popularity - how do you expect 
that to be financed exactly? Do you really believe this could be 
sustained with ideology?


I suspected that there are a few CAcert groupies around here with this 
discussion ;-)


But I tell you a little unknown secret, the first time I heard about 
charging for revocations it was exactly from the folks like Duane and 
later Ian. You can ask them and they might even confirm it, because they 
too were looking for solutions to a problem.


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. 
XMPP:   start...@startcom.org 
Blog:   Join the Revolution! 
Twitter:Follow Me 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Jan Lühr]

Hello,

Am 04/29/2014 01:09 PM, schrieb Gervase Markham:
> On 26/04/14 16:45, Zack Weinberg wrote:
>> If a business chooses to give some or even all of its services away
>> free, those who benefit from those services are still customers and
>> still in the same ethical relationship with the business as people who
>> paid for services (perhaps the same service, perhaps not).
>>
>> In particular, the business may *not* duck out of ethical obligations
>> incurred by circumstances beyond any customer's control (e.g.
>> catastrophic bugs in software everyone relies on ;-) just because some
>> of its customers are not *paying* customers.
> 
> Hi Zack,
> 
> Let's imagine StartCom said to you: "OK, we will perform free
> revocations for all Heartbleed-affected certificates, as you request.
> And we are changing our business model to charge up-front for certs like
> all the other CAs, so we don't get hit with a big cost like this again.
> No more free-of-charge 1-year-valid certs on the Internet."
> 
> Would you consider that a good trade-off, in terms of improving the
> general security of the Internet?

Side note - since we're discussing of sth. else: I vote for "yes".
Reasons:

- At the moment, StartSSLcertificates are not free. They are advertised
as free. But the fee for revocation make 'em non-free due to a certain
probability. Free in 85% (or sth. %) of all cases is not free in general.

- I think, revocation of assumed-to-be compromised certs is important
for Internet security. There should be no tempting argument for not
doing so in any situation. Laziness, costs are tempting arguments imho.

- By advertising certs to be "non-free" and putting the actual price tag
on it, alternate CAs like CAcert might get a boost in popularity,
emphasizing their importance for global internet security. At the
moment, many people skip CAcert in favor of StartSSL, cuase they just
can get a "free" certificates in major browsers.

I'd like to live in a world, were revocation is without any hassle an
Community Driven CAs like CAcert are providing security for sites to be
interested in.

Greetz, Jan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Gervase Markham]

On 26/04/14 16:45, Zack Weinberg wrote:
> If a business chooses to give some or even all of its services away
> free, those who benefit from those services are still customers and
> still in the same ethical relationship with the business as people who
> paid for services (perhaps the same service, perhaps not).
> 
> In particular, the business may *not* duck out of ethical obligations
> incurred by circumstances beyond any customer's control (e.g.
> catastrophic bugs in software everyone relies on ;-) just because some
> of its customers are not *paying* customers.

Hi Zack,

Let's imagine StartCom said to you: "OK, we will perform free
revocations for all Heartbleed-affected certificates, as you request.
And we are changing our business model to charge up-front for certs like
all the other CAs, so we don't get hit with a big cost like this again.
No more free-of-charge 1-year-valid certs on the Internet."

Would you consider that a good trade-off, in terms of improving the
general security of the Internet?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Gervase Markham]

On 29/04/14 00:16, Kathleen Wilson wrote:
> My personal opinion…

And mine:

Free-at-the-point-of-issuance certs have been a great thing for the
Internet, and I would be very sad to see them go away. I also think in
general that the charging structures of (non-insurance :-) business
models are best when they reflect the cost structure incurred in
providing the service. Otherwise, one set of customers is subsidising
the other ones. (At the moment, for the other CAs,
non-Heartbleed-vulnerable customers are subsidising the costs incurred
by Heartbleed-vulnerable ones.)

I do not understand the logic of "There is now an unexpected expense
associated with doing the right thing. Despite the fact that my
subscriber agreement says that I should bear that expense, I refuse to
do the right thing until the CA bears the expense for me." That seems
entirely wrong to me.

A contract is a contract. If you don't like contracts which say that the
subscriber should pay for revocations, don't sign one, and encourage
others not to do so also. And if you signed one, you should meet your
obligations. "Let your Yes be Yes, and your No be No." (Jesus).

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Jürgen Brauckmann]

Jan Lühr schrieb:
> I'm more and more depressed about the state of PKIs and TLS / SSL out
> there :-(

Well, did you look into BGP or DNS security recently?

In contrast to public opinion, PKI and TLS security is constantly
*improving* since 6 or 7 years, because nowadays people actually care.
Such "minor" stuff as the Apple "goto fail" bug wouldn't have made it
into the mainstream media ten years ago.

Due to the effort of e.g. Mozillas CA programm, Microsofts CA programm,
the CA/B-Forum and all those people that write "TLS is broken" papers,
things are actually getting better. The only question is whether the
speed of improvement is fast enough.

Its an error to think that technical stuff is secure and sound if nobody
talks about it, and its also an error to think that the area where all
people are crying foul is the worst with regard to security (or safety).

Juergen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Jan Lühr]

Hello,

thanks you for your statement! I appreciate this a lot.

Am 04/29/2014 01:16 AM, schrieb Kathleen Wilson:

>> assumed to be compromised? (Compromised, due to heartbleed, not
>> revoked, because of non-paying subscribers?)
>> 
> 
> 
> In regards to policy…
> 
> In general, Mozilla’s CA Policy does not tell CAs how to structure
> the finances of their business.
> 
> According to Mozilla’s CA Maintenance Policy, a CA has to revoke a
> cert when “the CA obtains reasonable evidence that the subscriber’s
> private key … has been compromised or is suspected of compromise”.
> Does showing that the subscriber was running a bad version of
> OpenSSL count? Many sites that were vulnerable to heartbleed were
> not provably compromised. Mozilla’s CA Maintenance policy does not
> say that a CA has to revoke a cert if the software on the server
> had a bug in it.

> If the subscriber shows evidence (logs, etc) that their private key
> was accessed or compromised, then the CA is required to revoke the 
> certificate. But Mozilla’s CA Policy does *not* say that a CA has
> to issue a replacement cert.

Ok - I take this as a "StartSSL is not violating Mozilla's policies" -
I think that by the nature of heartbleed hardly anybody is able to
provide this evidence.

I think, the debate is settled now and will leave it.
Thanks to you all for your helpful input!

> 
> My personal opinion…
> 
> I have personally benefited from "free" certs, and would be sad to
> see such services go away. However, I understand that in light of
> recent events CAs who have previously offered free certs might
> consider adding an up-front fee or shrinking the certificate
> validity period for free certs.

I benefited from free services, too. But - personally - the risk of
being fooled by assumed-to-be compromised certs is more important to
me. By that decision, I removed StartSSL from my truststore.
But - as said - this is a personal decision and I don't see any reason
for arguing about that.

> The heartbleed bug caught many of us by surprise, and has caused
> many of us to reconsider our policies and practices regarding
> revocation.

100% agree - sadly :-/

> A positive side effect is that more attention will be put on
> revocation. (more about this later)

Being positive here is a nice thing. :-)
I'm more and more depressed about the state of PKIs and TLS / SSL out
there :-(

Greetz, Jan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Kathleen Wilson]

On 4/28/14, 2:05 PM, Jan Lühr wrote:



Does StartSSL violate Mozilla's policies by not revoking certificates
assumed to be compromised?
(Compromised, due to heartbleed, not revoked, because of non-paying
subscribers?)




In regards to policy…

In general, Mozilla’s CA Policy does not tell CAs how to structure the 
finances of their business.


According to Mozilla’s CA Maintenance Policy, a CA has to revoke a cert 
when “the CA obtains reasonable evidence that the subscriber’s private 
key … has been compromised or is suspected of compromise”.  Does showing 
that the subscriber was running a bad version of OpenSSL count? Many 
sites that were vulnerable to heartbleed were not provably compromised. 
Mozilla’s CA Maintenance policy does not say that a CA has to revoke a 
cert if the software on the server had a bug in it.


If the subscriber shows evidence (logs, etc) that their private key was 
accessed or compromised, then the CA is required to revoke the 
certificate. But Mozilla’s CA Policy does *not* say that a CA has to 
issue a replacement cert.



My personal opinion…

I have personally benefited from "free" certs, and would be sad to see 
such services go away. However, I understand that in light of recent 
events CAs who have previously offered free certs might consider adding 
an up-front fee or shrinking the certificate validity period for free 
certs.


The heartbleed bug caught many of us by surprise, and has caused many of 
us to reconsider our policies and practices regarding revocation. A 
positive side effect is that more attention will be put on revocation. 
(more about this later)


Kathleen


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Eddy Nigg]

On 04/29/2014 12:05 AM, Jan Lühr wrote:

Does StartSSL violate Mozilla's policies by not revoking certificates
assumed to be compromised?
(Compromised, due to heartbleed, not revoked, because of non-paying
subscribers?)


/Assumed/ it perhaps a good description since it's rather difficult to 
confirm an actual compromise and if the certificate/key was supposedly 
hosted at an affected server during its life-time.


We believe it's the responsibility of the subscriber to make the correct 
assessment and do whatever is necessary to get the certificate revoked 
(or not).


I don't want to speak for other CAs (as we are currently taking the 
burnt on this one), but I'm pretty sure that other CAs have their limits 
as well what revocations concerns and certificates are not endlessly 
revoked. Netcraft reports about many reissued certificates, but 
relatively few revocations: 
http://news.netcraft.com/archives/2014/04/25/heartbleed-why-arent-certificates-being-revoked.html


So this can't be just an issue of StartCom, but perhaps easier to hit 
because there is a charge involved. Our CRLs can be measured and I 
believe we've done a fairly good job during those hectic days when the 
bug was disclosed.


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. 
XMPP:   start...@startcom.org 
Blog:   Join the Revolution! 
Twitter:Follow Me 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Jan Lühr]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

Am 04/28/2014 09:20 PM, schrieb Eddy Nigg:
> On 04/28/2014 05:53 AM, Eric Mill wrote:
>> I appreciate how diligent you're being about responding to
>> everyone. And, as I've said elsewhere, I haven't believed that
>> there's an ethical problem with offering free certs with paid
>> revocations as a general business practice.
> 
> OK
> 
>> Resist generalizing: would offering a one-time free revocation
>> for any domain whose owner says the word "Heartbleed" be feasible
>> *right now* for Startcom? Could Startcom get through it okay?
> 
> I don't think so, not without a financial loss, which we would have
> to cover from somewhere else. A change to the business model
[...]

well... sadly, I don't think that were actually making any progress in
this discussion. The positions seem to be fixed and there hardly any
new arguments provided. Thus I vote for a resolution.

@certifica...@mozilla.org - I _really_ think that we need an qualified
/ official statement by Mozilla. Please provide it asap - or - give an
estimation on a certain time frame:

Does StartSSL violate Mozilla's policies by not revoking certificates
assumed to be compromised?
(Compromised, due to heartbleed, not revoked, because of non-paying
subscribers?)

If yes: Is StartSSL still considered to be trustworthy, aka shipped
the truststore?

(This is why I CC'ed certifica...@mozilla.org)

Thanks in advance, Jan Luehr
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTXsJ/AAoJEBbh0SAKTJyukM0QAJRZyplHDmeXwsJanL2WTXSJ
WyxEWPiuFrPeVuwExX/Suh+nnWW6Iy6rAOszKK4J7DO87zJ4XypFwPbPZE+Yi7G0
auvyVYt8ZN9WOjs8r97ikfRTZVFtsDQlmhEgZqa0n6bxn7KblxyrHki/3DZli21e
X4udPCeJPuBZFy60IjSaoJoD5/cADxIDyFOhWGKBACRp4kPXsrDOv6znS248iBDV
Be7ygi45RnnKbX+mQN4I7qM0aMOxA8YRVASgA4DD2/nMBCSMMsaAN9bZw83Lre9N
dRfsvfnioMwdS/y4WWZzPS7KrbTG+SoWjz2FRRrNiMSNi6SW9NwZVK8jWD44eQSm
X3nfvnp3pPMDFfgd5gwZVk9VL2M84E7rOoQyj6XE5qWRozGLhs3K84tO3gHj80NP
cuPz8Qiktt0q+RpnS6ecZlre/0MiWO7ljcBI26cLadQMGKQJRnV1161gZLQd8oEf
GOsaKunetgvq6O10hHmaSRq9ARWmoHl1Mgd6rNwcOrn9bRxTiCNHq3vbAjPkm8RD
Ju4d26GdOLjXtEX6yYIlrOgtZUydhK1wOVq6w1gKxxgxJgwKJA9u+grpQHG1v8lP
fHW1mHWBs6bRPeHqT55k30Obz+o9diDA8WV8qdGB/VOX+OEY0i1I+XSpR6S3PH79
e58C/Am59x9UP5Gr/2/m
=LIfE
-END PGP SIGNATURE-
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Eddy Nigg]

On 04/28/2014 10:11 AM, Jeremy Brookman wrote:

If we take the StartSSL principle that subscribers need to pay a fee to
request revocation even in the case of key compromise where there is no
malpractice, but then combine it with the subscriber obligation to request
revocation in the case of (confirmed?) key compromise, then in receiving a
signed class 1 certificate, subscribers accept a financial liability in
circumstances outside their control.


That's probably true, it's not a negligence on part of the subscriber, 
in this case it's probably simply bad luck (a different software could 
have had a bug with similar result at a different time). We've seen it 
in the past that it can happen (weak keys).



Can this product therefore really be described as "100% Free"?


That's of course a question of interpretation and probably also of 
simplicity. Not all services are free of charge of course and our FAQ 
tries to explain that like this:


https://www.startssl.com/?app=25#90 (item 90)


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. 
XMPP:   start...@startcom.org 
Blog:   Join the Revolution! 
Twitter:Follow Me 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Eddy Nigg]

On 04/28/2014 05:53 AM, Eric Mill wrote:

I appreciate how diligent you're being about responding to everyone.
And, as I've said elsewhere, I haven't believed that there's an
ethical problem with offering free certs with paid revocations as a
general business practice.


OK


Resist generalizing: would offering a one-time free revocation for any
domain whose owner says the word "Heartbleed" be feasible *right now*
for Startcom? Could Startcom get through it okay?


I don't think so, not without a financial loss, which we would have to 
cover from somewhere else. A change to the business model would be more 
likely in the future, which I however wouldn't really like to see, but 
there are different options and considerations on the table.


All in all the actual result is rather positive with most subscribers 
complying to the requirement and pay their fees, with the exception of a 
rather noisy minority - which in turn I can understand too and maybe was 
to be expected.



Presumably, your CRL lists have already expanded and your bandwidth
costs increased. If the number of vulnerable certificates is small
enough that you haven't felt guilt-ridden about charging them for
revocation, it should also be small enough that the additional
marginal cost of waiving the fees for them shouldn't cost you that
much.


I think the question about guilt isn't appropriate - I don't feel 
guilt-ridden. We follow a policy and business model we decided long time 
ago which is implemented. As any competitor can charge whatever they 
want for whatever they want, they don't have to feel guilty either, they 
are running a business.


Our CRLs doubled or more since the bug, our OCSP infrastructure isn't 
exactly cheap either and those that receive the benefits from it are 
charged a fee as we disclosed and implemented.



Part of having a
sustainable business is having enough of a buffer so that you can
weather an occasional tornado without having to lock your neighbors
out of the shelter.


I believe that's exactly the point, sustainability is important and we 
took care that the operation will be sustained even in case of a tornado 
(see also other reply to the list regarding insurance). The subscriber 
has obligations too and if it happens, the subscriber has to carry some 
of the costs (maybe never, maybe only once or maybe more than once, 
that's the risk/benefit).


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. 
XMPP:   start...@startcom.org 
Blog:   Join the Revolution! 
Twitter:Follow Me 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Eddy Nigg]

On 04/28/2014 08:53 PM, Zack Weinberg wrote:
I find this both surprising and disturbing. Are you saying that you 
tried to obtain insurance against the possibility of this sort of 
catastrophe (keys compromised due to bug in software maintained by 
third parties) but could not, because no insurer would write the policy?


The typical insurance is protection against claims by third parties due 
to a failure by the CA. Those are fairly expensive but possible, whereas 
the sort of catastrophe you mentioned I haven't heard of so far.


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. 
XMPP:   start...@startcom.org 
Blog:   Join the Revolution! 
Twitter:Follow Me 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Zack Weinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/27/2014 06:07 PM, Eddy Nigg wrote:
> On 04/26/2014 06:45 PM, Zack Weinberg wrote:
>> 
>> CAs should be carrying insurance to cover exactly this sort of 
>> low-probability-but-still-foreseeable, high-cost event.
> 
> Interestingly CAs can insure themselves for mistakes made at their
> end (errors and omission, but not for mistakes of others. That's
> exactly the reason why those costs can't be turned onto the insurer
> (otherwise we'd have done exactly that).

I find this both surprising and disturbing.  Are you saying that you
tried to obtain insurance against the possibility of this sort of
catastrophe (keys compromised due to bug in software maintained by
third parties) but could not, because no insurer would write the
policy?  Or are you saying that there is some rule that forbids you to
seek such insurance in the first place?  Or some third possibility I
am not thinking of?

Whichever way, this seems like a major problem that needs to be
corrected before the *next* time one of these bugs turns up.

zw

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTXpWwAAoJEJH8wytnaapkW8IP/2BS5qiF/U2C4XI52o9qkgVl
hCyZAgyeO9L+rinYOYS/p1KqBjbAyN3sMJM/4WTf06e9p3XXpSoyv6cqXiR5AvNj
sjSrHwA0mEsP8hIMmI1idM3KWMCOyc2giGIG7NgZ1EtK+rLULpp5NFgKbYVVYbw3
q39gAhM2czV4SrXOYv67mE7ux8e/cLejOZx7bjkz570JG4myzOU9skNEcqq5crh5
0YIWTDA7jzx0LGPmVcWcX+8w6MMkZxduq+465k/4kdJEPLkpube0APnTLl8zZfIl
A/WIQQUgmCkwRRqJpktfwmuHMLdUbH8FPV08mkxlw9gYmn8stdH/HOf7jH9VNb8s
Xn+aIEuDBUubWMo23WptSAFZdWSLpD5IYN9IiEqBsxXZj29DxKbhSdbD5Uafxu4j
tLMnijky5SDUXx2tt6vVDpx14j+2lVkFfvXWnojKPN48aORrmotaK8eVlOY0RKY8
W8XaawZMbEJ4U0m9cJWECcf28bb5myK390ZRIRF/OfwnLKn4n6+dqDtLgo3xEiCo
xGWGtWF1DOhEzqbC3e+BTqIF64mWT7Ndh/4YJ6LZuSWvuczynVqKz32+1xUrDyS6
vhweBPMSwpnnqheFPAgX3qaGnFRyR6ipR8qHmggTw7UMSHhb8KlcTGJ+gu7ZxdIG
iejUpsSBUSVMm8onVBsj
=xwf2
-END PGP SIGNATURE-
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Bruce]

Although certificate revocation is funded by the certificate subscriber, 
revocation is for the billions of relying parties. These are the parties that 
don't know anything about Heartbleed or any other threat that could jeopardize 
a certificate or a website.

In the CP and/or CPS, the CAs generally have a relying party agreement which 
says don't trust the certificate unless you have checked the certificate status 
(i.e. CRL or OCSP). How can the relying party effectively meet this obligation, 
if the correct certificate status is not responded?

Bruce.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Jeremy Brookman]

On 28 April 2014 08:48, Jürgen Brauckmann  wrote:

> Jeremy Brookman schrieb:
> >
> > We're all stilling lessons from heartbleed.  One lesson is that charging
> > for revocation has wider practical implications than earlier thought;
>
> Which practical implications do you refer to?
>

Sorry, that was poorly expressed.  I meant that needing revocation because
of key compromise resulting from security bugs seemed to be a more
theoretical than practical consideration; now it's become more real (for me
at least; others with more experience might have been more aware already).
 In particular, for private servers it seemed unlikely.  I could imagine
needing to revoke a certificate because, say, I'd made a mistake somewhere
and needed the certificate reissuing (maybe losing the key or something, or
even ), but not otherwise; it seemed to be more a consideration for larger
organizations where more people had access to the private key, and there
was more likely to be a breach of trust.

Live and learn!

Jeremy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Jürgen Brauckmann]

Jeremy Brookman schrieb:
>
> We're all stilling lessons from heartbleed.  One lesson is that charging
> for revocation has wider practical implications than earlier thought; 

Which practical implications do you refer to?

Eddy wrote:

"Currently the facts show that StartCom's revocation numbers are not
lower, in fact a bit above average. "

So, if this turns out to be true in the long run, then the implication
is clearly that all CAs should charge for revocation to drive up their
revocation stats, right?

Juergen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Jeremy Brookman]

On 27 April 2014 23:07, Eddy Nigg  wrote:

> On 04/25/2014 08:50 PM, Jan Lühr wrote:
>
>> What's your argument here? Is "crying foul" "Unjustified", because
>> nobody "cried foul" the moment you published your policies?
>>
>
> It's unjustified if as a subscriber you are not willing to accept the
> terms and conditions of that service, e.g. you want to accept the
> convenient part of it but not commit to your obligations.


Since you bring up the question of subscriber obligations (and this is a
slightly tangential issue)...

If we take the StartSSL principle that subscribers need to pay a fee to
request revocation even in the case of key compromise where there is no
malpractice, but then combine it with the subscriber obligation to request
revocation in the case of (confirmed?) key compromise, then in receiving a
signed class 1 certificate, subscribers accept a financial liability in
circumstances outside their control.

Can this product therefore really be described as "100% Free"? In the
heartbleed case most people only have suspected key compromise and not
proven key compromise, so it can be argued that this problem hasn't kicked
in. But given the year TLS has had so far, who's to know what'll happen
next week?

We're all stilling lessons from heartbleed.  One lesson is that charging
for revocation has wider practical implications than earlier thought; so
revocation can't be decoupled from issuance, and therefore that to keep the
blanket charge on revocation, StartSSL will have to forego the "No charge
and 100% Free" branding on its class 1 certificates.

Jeremy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Jan Lühr]

Hello,

Am 28.04.2014 um 00:07 schrieb Eddy Nigg :

> On 04/25/2014 08:50 PM, Jan Lühr wrote:
>> What's your argument here? Is "crying foul" "Unjustified", because
>> nobody "cried foul" the moment you published your policies?
> 
> It's unjustified if as a subscriber you are not willing to accept the terms 
> and conditions of that service, e.g. you want to accept the convenient part 
> of it but not commit to your obligations.
> 
>> Please consider: Heartbleed-scale problems have hardly happened before.
> 
> True - the closest would be probably the Debian weak keys.
> 
>> I'ven't considered any mass-key-compromise scenarios before
> 
> I did - I learned from the Debian weak keys a lot.
> 
>> Personally, I am "crying foul" because I'm re-thinking your policies
>> having heartbleed in mind.
> 
> You can't really rethink our policies, this is something we might have to do 
> at some point. You can either agree or disagree with them though.

I can changed my mind. I try to learn from errors / mistakes I made, while 
reflecting / rethinking.
As stated earlier, I’ven’t considered mass key compromise so far. Is it my 
fault? Yes it is and you can blame me for doing so. But this is not the point 
we’re talking about.

> 
>> Personally, I vote no. StartSSL is not revoking certificates assumed to
>> be compromised, if a subscriber doesn't pay.
> 
> You are expecting to receive all benefits without taking responsibility for 
> your part?

Absolutely not. I’m not expecting any benefits and it’s not about that. 
It’s about the community (aka Mozilla) accepting StartSSL's gift (aka free 
certificates) by including StartSSL in your their products - or - rejecting it 
due to side constraints (aka revocation policy).

To make this clear:
Nobody is expecting StartSSL to do anything for free! Do what ever you like, 
for the price tag you like. 
I expect StartSSL to follow mozilla’s policies if they’re shipped with their 
products. This is one of the criteria _everybody_ needs to follow to be 
included.

Don’t follow it - fine.  Give out certificates for free while not being in the 
truststore (aka being a competitor of CAcert): Fine, I don’t care.


> Or lets put it like this:
> 
> As you stated before, how likely is it that such an event like this one 
> occurs? It might have never happened and in fact some 83% are not affected 
> (world-wide), which means that they will happily keep obtaining certificates 
> without ever paying a dime. Would you have used a different software, you 
> could be easily one of those 83% too.
> 
> Now, exactly because of this and other scenarios, where revocation of a 
> certificate is necessary or is requested for any other reason by the 
> subscriber and it's not due to a failure of the CA we decided to charge a fee 
> in order to protect us from losses.

We’re not taking about a provider customer relationship (aka: who has to pay?, 
who is to blame?) here. It’s about: What is the impact of StartSSL policies? I 
can do the math, too, but there’re no math and no probabilities in mozilla's 
policies: It is safety first - imho.

> Otherwise the current business model would probably not work...and I'm not 
> even talking about easy abuse that's possible with the current model without 
> raising a fee.

I’m perfectly fine with raising fees. This is ok - imho. But please do this 
while following mozilla’s policies.

Greetz, Jan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Eric Mill]

Hi Eddy,

I appreciate how diligent you're being about responding to everyone.
And, as I've said elsewhere, I haven't believed that there's an
ethical problem with offering free certs with paid revocations as a
general business practice.

But I'm still not hearing you explain why an exception shouldn't be
made for an unprecedented event like this. Debian weak keys was a big
deal, but did not have as widespread ramifications as Heartbleed.
Resist generalizing: would offering a one-time free revocation for any
domain whose owner says the word "Heartbleed" be feasible *right now*
for Startcom? Could Startcom get through it okay?

Presumably, your CRL lists have already expanded and your bandwidth
costs increased. If the number of vulnerable certificates is small
enough that you haven't felt guilt-ridden about charging them for
revocation, it should also be small enough that the additional
marginal cost of waiving the fees for them shouldn't cost you that
much.

So if you can, just do it. Going forward, everyone will be much more
aware of Startcom's revocation fee.

If the answer is no, and Startcom has gotten itself into a position
where it cannot afford to set aside its general business policy for an
Internet-wide emergency, then I guess I have to conclude that yeah,
it's not an ethical general business practice either. Part of having a
sustainable business is having enough of a buffer so that you can
weather an occasional tornado without having to lock your neighbors
out of the shelter.

-- Eric

On Sun, Apr 27, 2014 at 6:07 PM, Eddy Nigg  wrote:
> On 04/25/2014 08:50 PM, Jan Lühr wrote:
>>
>> What's your argument here? Is "crying foul" "Unjustified", because
>> nobody "cried foul" the moment you published your policies?
>
>
> It's unjustified if as a subscriber you are not willing to accept the terms
> and conditions of that service, e.g. you want to accept the convenient part
> of it but not commit to your obligations.
>
>
>> Please consider: Heartbleed-scale problems have hardly happened before.
>
>
> True - the closest would be probably the Debian weak keys.
>
>
>> I'ven't considered any mass-key-compromise scenarios before
>
>
> I did - I learned from the Debian weak keys a lot.
>
>
>> Personally, I am "crying foul" because I'm re-thinking your policies
>> having heartbleed in mind.
>
>
> You can't really rethink our policies, this is something we might have to do
> at some point. You can either agree or disagree with them though.
>
>
>> Personally, I vote no. StartSSL is not revoking certificates assumed to
>> be compromised, if a subscriber doesn't pay.
>
>
> You are expecting to receive all benefits without taking responsibility for
> your part? Or lets put it like this:
>
> As you stated before, how likely is it that such an event like this one
> occurs? It might have never happened and in fact some 83% are not affected
> (world-wide), which means that they will happily keep obtaining certificates
> without ever paying a dime. Would you have used a different software, you
> could be easily one of those 83% too.
>
> Now, exactly because of this and other scenarios, where revocation of a
> certificate is necessary or is requested for any other reason by the
> subscriber and it's not due to a failure of the CA we decided to charge a
> fee in order to protect us from losses. Otherwise the current business model
> would probably not work...and I'm not even talking about easy abuse that's
> possible with the current model without raising a fee.
>
>
>> ->  You say it is small / low by describing the circumstances under which
>> it happens and causes an impact.
>
>
> Currently the facts show that StartCom's revocation numbers are not lower,
> in fact a bit above average. And here some more interesting facts:
> http://news.netcraft.com/archives/2014/04/25/heartbleed-why-arent-certificates-being-revoked.html
>
>
>
> --
> Regards
> Signer: Eddy Nigg, COO/CTO
> StartCom Ltd. 
> XMPP:   start...@startcom.org 
> Blog:   Join the Revolution! 
> Twitter:Follow Me 
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy



-- 
konklone.com | @konklone
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Eddy Nigg]

On 04/26/2014 06:45 PM, Zack Weinberg wrote:

If a business chooses to give some or even all of its services away
free, those who benefit from those services are still customers and
still in the same ethical relationship with the business as people who
paid for services (perhaps the same service, perhaps not).


We call all of them "subscribers" and we make no difference between a 
"paying" subscriber and "non-paying" - the difference is only the 
verification level and respective certificates according to that level. 
Some of the services carry a fee and some don't - for example no 
validated subscriber pays actually for the certificates, he/she pays for 
the validations performed which entitles them for certain type of 
certificates.



In particular, the business may *not* duck out of ethical obligations
incurred by circumstances beyond any customer's control (e.g.
catastrophic bugs in software everyone relies on ;-) just because some
of its customers are not *paying* customers.


Nobody ducks here - such a bug is not under the control of the 
subscriber and not of the issuer of the certificates, nor can the 
issuing instance control with which software the certificates are being 
used, how the keys are handled and so forth.


This is not a one-way street and it takes at least two to tango. The 
subscriber has to comply to the terms and conditions (Subscriber 
Obligations) the issuer set forth. And the subscriber has to pay certain 
fees when they apply.



CAs should be carrying insurance to cover exactly this sort of
low-probability-but-still-foreseeable, high-cost event.


Interestingly CAs can insure themselves for mistakes made at their end 
(errors and omission, but not for mistakes of others. That's exactly the 
reason why those costs can't be turned onto the insurer (otherwise we'd 
have done exactly that).


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. 
XMPP:   start...@startcom.org 
Blog:   Join the Revolution! 
Twitter:Follow Me 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Eddy Nigg]

On 04/26/2014 10:53 PM, Daniel Micay wrote:
If the free certificates were not creating revenue by luring people 
into the paid offerings, I doubt they would be offered. There's no 
need to feel pity for a working business model.


You probably aren't around long enough to remember or know about how the 
StartCom CA was started. Of course to be a serious and realistic 
certificate provider that has taken down the costs of SSL certificates 
in general and in order provide an alternative to the existing model, a 
different business model had to be implemented that makes the operation 
sustainable.


Of course those that enroll for higher validations actually pay partly 
the issuance costs of the non-validated (Class 1, Free) certificates, 
however those costs are fairly low considering they share the same 
infrastructure and personnel.


Bottom line is, that though StartCom needs the higher validations in 
order to sustain the operations, it's the result of the former and the 
free certificates are not the result of the latter (initially StartCom 
had only domain control validated and free certificates).


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. 
XMPP:   start...@startcom.org 
Blog:   Join the Revolution! 
Twitter:Follow Me 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Eddy Nigg]

On 04/25/2014 08:50 PM, Jan Lühr wrote:

What's your argument here? Is "crying foul" "Unjustified", because
nobody "cried foul" the moment you published your policies?


It's unjustified if as a subscriber you are not willing to accept the 
terms and conditions of that service, e.g. you want to accept the 
convenient part of it but not commit to your obligations.



Please consider: Heartbleed-scale problems have hardly happened before.


True - the closest would be probably the Debian weak keys.


I'ven't considered any mass-key-compromise scenarios before


I did - I learned from the Debian weak keys a lot.


Personally, I am "crying foul" because I'm re-thinking your policies
having heartbleed in mind.


You can't really rethink our policies, this is something we might have 
to do at some point. You can either agree or disagree with them though.



Personally, I vote no. StartSSL is not revoking certificates assumed to
be compromised, if a subscriber doesn't pay.


You are expecting to receive all benefits without taking responsibility 
for your part? Or lets put it like this:


As you stated before, how likely is it that such an event like this one 
occurs? It might have never happened and in fact some 83% are not 
affected (world-wide), which means that they will happily keep obtaining 
certificates without ever paying a dime. Would you have used a different 
software, you could be easily one of those 83% too.


Now, exactly because of this and other scenarios, where revocation of a 
certificate is necessary or is requested for any other reason by the 
subscriber and it's not due to a failure of the CA we decided to charge 
a fee in order to protect us from losses. Otherwise the current business 
model would probably not work...and I'm not even talking about easy 
abuse that's possible with the current model without raising a fee.



->  You say it is small / low by describing the circumstances under which
it happens and causes an impact.


Currently the facts show that StartCom's revocation numbers are not 
lower, in fact a bit above average. And here some more interesting 
facts: 
http://news.netcraft.com/archives/2014/04/25/heartbleed-why-arent-certificates-being-revoked.html



--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. 
XMPP:   start...@startcom.org 
Blog:   Join the Revolution! 
Twitter:Follow Me 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Eddy Nigg]

On 04/25/2014 07:14 PM, Zack Weinberg wrote:
Please see 
http://www.lightbluetouchpaper.org/2014/04/25/heartbleed-and-rsa-private-keys/ 
for more detail.


Thanks for that link, we'll certainly study it too.

--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. 
XMPP:   start...@startcom.org 
Blog:   Join the Revolution! 
Twitter:Follow Me 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Daniel Micay]

On 26/04/14 10:26 AM, Erwann Abalea wrote:
> Le samedi 26 avril 2014 15:29:26 UTC+2, Zack Weinberg a écrit :
>> On 2014-04-26 4:51 AM, Erwann Abalea wrote:
>>> Le vendredi 25 avril 2014 18:14:39 UTC+2, Zack Weinberg a écrit :
>>>
 Moreover, it is my personal opinion that as a matter of basic business
 ethics, this is a cost you (or rather, your insurance) should absorb,
 not your customers.
>>>
>>> Please define "customer".
>>
>> The people who receive(d) certificates from this CA.  Why, do you think 
>> some other category of people is more appropriately considered a CA's 
>> customers?
> 
> A customer is someone who *buys* goods/services from a business. Buying 
> involves money (or anything playing the same role). I have certificates from 
> Startcom, I didn't pay a single penny for that, therefore I'm not a customer.
> All this is a money problem, and nothing is free.
> 
> Running a CA is expensive, costs associated to revocation (procedures, CRL 
> downloads, OCSP requests) are hidden but far from being negligible. They are 
> usually covered by the price of the certificate. In Startcom's case, this 
> isn't true. Maybe the business model needs to be changed?

If the free certificates were not creating revenue by luring people into
the paid offerings, I doubt they would be offered. There's no need to
feel pity for a working business model.

The Mozilla CA policy states that certificates suspected of compromise
*must* be revoked and gives the Debian OpenSSL bug as a clear example of
a case where they should be revoked. It doesn't say the customer must be
given an opportunity to pay for a revocation... it says they *must be
revoked* if the CA is made aware.

Mozilla is making it very clear to every CA that these policies do not
need to be taken seriously. They're free to violate it as much as they
want, and Mozilla will likely only take notice if it causes a major
media storm.



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Zack Weinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/26/2014 10:26 AM, Erwann Abalea wrote:
> Le samedi 26 avril 2014 15:29:26 UTC+2, Zack Weinberg a écrit :
>> On 2014-04-26 4:51 AM, Erwann Abalea wrote:
>>> Le vendredi 25 avril 2014 18:14:39 UTC+2, Zack Weinberg a
>>> écrit :
>>> 
 Moreover, it is my personal opinion that as a matter of
 basic business ethics, this is a cost you (or rather, your
 insurance) should absorb, not your customers.
>>> 
>>> Please define "customer".
>> 
>> The people who receive(d) certificates from this CA.  Why, do
>> you think some other category of people is more appropriately 
>> considered a CA's customers?
> 
> A customer is someone who *buys* goods/services from a business. 
> Buying involves money (or anything playing the same role).

Bullshit.

If a business chooses to give some or even all of its services away
free, those who benefit from those services are still customers and
still in the same ethical relationship with the business as people who
paid for services (perhaps the same service, perhaps not).

In particular, the business may *not* duck out of ethical obligations
incurred by circumstances beyond any customer's control (e.g.
catastrophic bugs in software everyone relies on ;-) just because some
of its customers are not *paying* customers.

> All this is a money problem, and nothing is free.

CAs should be carrying insurance to cover exactly this sort of
low-probability-but-still-foreseeable, high-cost event.

zw
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTW9SmAAoJEJH8wytnaapkVYUP+gPeX63M/Zkc7XkwQvUX1GvN
GWadUxZVD1PZDIHbyfudzlJgC+ru3AjPE33QV1hjZIY9Ez5MAgpUAkU+/Eav4J7K
wP/a6y+oh1GNF+1uz1w8QVgOV1fVD2hMGw3LJdorGDpl76+w63Bsal3x9Z5P1UVm
qDEiA23t4OOxVKJYhaDny84SzjNmIBePcYP4f0eke1kQqbnBXdu8bVaAlROVhxSn
/DYbP9+xb67eOpHTp8gmywc3rEb7v2oEr0xZOl0BhzErUzzASe2Pxf8ibkh36OBG
PhUn2F4vXariRFlyaGi5ZxPeQGj1Vs7q/trhFpnVI1wQIQwBolD7/Lh8SoigTt2N
WyRKGfYQCg7K8xGslA3C4O7SM3k3hsjXHwrZlku/xpwgt9ArpkB/0KTW6IMgc6lD
4+NutuXSosZYv+b4GMn/Gje69pmaNXuww36jWuibQ2ZUGSR6ZYYrUQSqobWx52aT
esZHnwQ+bwS7Zgqr+EZ81Vi0LINHihZUS6yL1wNswAMlDhvqJxMzuDEnY8GdgKvg
yJ00fG9w8KPmE8rDSRr8J6vkpo7KH9k0ZNaOG1DRCBd3WJs6xexIMfP6G6xYxMi+
3NwHSHGB5lQ+KMmaAFW7DZL66lhGvYIBcJqvAm9tjd6DCi25mD3SrkxJY/3bEoDS
PpVaZ93c95iRd/DoChq2
=7HgX
-END PGP SIGNATURE-
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Erwann Abalea]

Le samedi 26 avril 2014 15:29:26 UTC+2, Zack Weinberg a écrit :
> On 2014-04-26 4:51 AM, Erwann Abalea wrote:
> > Le vendredi 25 avril 2014 18:14:39 UTC+2, Zack Weinberg a écrit :
> >
> >> Moreover, it is my personal opinion that as a matter of basic business
> >> ethics, this is a cost you (or rather, your insurance) should absorb,
> >> not your customers.
> >
> > Please define "customer".
> 
> The people who receive(d) certificates from this CA.  Why, do you think 
> some other category of people is more appropriately considered a CA's 
> customers?

A customer is someone who *buys* goods/services from a business. Buying 
involves money (or anything playing the same role). I have certificates from 
Startcom, I didn't pay a single penny for that, therefore I'm not a customer.
All this is a money problem, and nothing is free.

Running a CA is expensive, costs associated to revocation (procedures, CRL 
downloads, OCSP requests) are hidden but far from being negligible. They are 
usually covered by the price of the certificate. In Startcom's case, this isn't 
true. Maybe the business model needs to be changed?

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Zack Weinberg]

On 2014-04-26 4:51 AM, Erwann Abalea wrote:

Le vendredi 25 avril 2014 18:14:39 UTC+2, Zack Weinberg a écrit :


Moreover, it is my personal opinion that as a matter of basic business
ethics, this is a cost you (or rather, your insurance) should absorb,
not your customers.


Please define "customer".


The people who receive(d) certificates from this CA.  Why, do you think 
some other category of people is more appropriately considered a CA's 
customers?


zw

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Erwann Abalea]

Le vendredi 25 avril 2014 18:14:39 UTC+2, Zack Weinberg a écrit :

> Moreover, it is my personal opinion that as a matter of basic business
> ethics, this is a cost you (or rather, your insurance) should absorb,
> not your customers.

Please define "customer".
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Zack Weinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/25/2014 01:50 PM, Jan Lühr wrote:

> (i) I really hope, that you change your mind by doing revocations
> for free and charge for re-keying. This will break the 
> issuing-revocation-cycle, too, while going safety first.

This does not eliminate the perverse incentive to certificate holders.
 Revocation *and* reissuance need to be zero-cost in a circumstance
like this -- **whether or not** the initial certificate was paid for.

zw

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTWrd/AAoJEJH8wytnaapkuKwQAKdWWJYzR9mU7feU7yiI57j5
yvzQY/Pe0N2hLCy6MviahdD+QjiRsHKSrgqring1DTgDEJ45aTcZXZddWe1zAMc6
wa43OyZH1hIEL12QWkarA/Qo/P2h08v4holfqy68ZzUKXx6VJhRBuzliewx1t1pJ
kaVfQNxZnVKxX8LgVifJmi3wWvL6XzueHCE431gQN/epRFArI0HBiQSBdnQYB1W+
yU3yDR4dbopBGLT10DJdnUeUUxUgz/QG3RAtbtmpYf0j1U8/edHa5BT6A35ktAX5
ya6N/O+BYChbn93xBqLTiF83Vicql0NSMziv9k2W2gVkg9JO4QvyACKtxuqxAYSx
gYIdkxzJnNDryrhW6T5wRxkr58D5rTukbzJeSBCfld0bmWcvR82c24Zb1C5oJQbN
Yz6BpX2wKA9d94GP9P49VyouC2q4BHCqx8XUFUw0YIc9s0n4Wu2pp9Hfth/RceD7
d2sVkpv5FmI5Y4RPVJ0hQ+6si+OmBl/9N5oAplbOqrJ1VCMlQld3+UpBMiZWUkrl
itG5/2LBfy5mEc9o8hXqljPM0oQW5PvirgZRMC3lbOCIEiiGl1j7kZnlbcCcd+0n
EpUODP7eS1SlyMEGVXZoeGZV8XSVZjxq7bIfEdej4vVFKxH8TlCrC5DImaNw225d
nJmgGMujAsC8c4Z2bqCX
=Rz2F
-END PGP SIGNATURE-
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Radu Hociung]

On Friday, April 25, 2014 1:50:35 PM UTC-4, Jan Lühr wrote:
> (ii)
> I strongly don't agree with that point:
> "For private sites that are usually not visited by the public
> (administrative panels for example), changing the host name, deleting
> the previous DNS entry, obtaining a new certificate and never visit the
> original site again might work too. Many of the free Class 1 level
> certificates are used for such purpose."
> 
> The point is: After key-leakage mitm attacks are possible. Think of an
> insider being in a encrypted Wifi network. Having "valid" cert for an
> unused subdomain can do harm ...


Let's not forget that the StartSSL Class1 certs are issued with two Subject 
Alternative Name: the subdomain's, (imap.example.com) and the *root domain*s 
(example.com). This plan implies serving nothing at example.com

I too would like to see a statement of official position wrt. Startcom's 
trustworthiness from Mozilla.

Eddy: How many Class1 certificates have you issued that are active and not 
expired? Check your OCSP logs for activity and your CA logs for expiration, but 
don't quote Netcraft's estimates. That's dishonest.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Jan Lühr]

Hello,

Am 04/23/2014 05:51 PM, schrieb Eddy Nigg:
> On 04/10/2014 07:05 PM, Eddy Nigg wrote:
>> I agree - I've saw the tweets bug reports and this posting. I'll be glad
>> to join the discussion and we intend to take a public stance as soon as
>> things calm down a bit.
>>
>> Currently all hell is lose, but I promise to get back to you all in due
>> time and will explain our position, policy and practices and also refute
>> some of the claims that were made.
>>
>> In the meantime please be patient, thanks.
>>
> 
> 
> Alright - things have calmed down luckily by now. As my first input to
> the discussion please read carefully my explanation, thoughts and
> comments I've written down in my blog at https://blog.startcom.org/?p=230

thanks for explaining your reasons, but I don't agree on your position
in two major points. You say:

"The majority understands and cooperate fully, but there are those that
cry foul. Unjustified though, because StartCom has clearly disclosed
this fact at its web sites and policies and has never hidden it."

What's your argument here? Is "crying foul" "Unjustified", because
nobody "cried foul" the moment you published your policies?
Please consider:
Heartbleed-scale problems have hardly happened before. I'ven't
considered any mass-key-compromise scenarios before [1] - Looking at the
state of OSCP out there, I might not be the only one.
Personally, I am "crying foul" because I'm re-thinking your policies
having heartbleed in mind. Is this unjustified? I don't think so. But
arguing it is, because I could have done this earlier is not constructive.

The crucial part is - imho:
Is StartSSL still trustworthy while having these policies? - aka: Does
it comply with the mozilla ones?
Personally, I vote no. StartSSL is not revoking certificates assumed to
be compromised, if a subscriber doesn't pay.

IMHO it boils down this question: What is the likelihood and impact of
encountering compromised, non-revoked StartSSL-certificates?
-> You say it is small / low by describing the circumstances under which
it happens and causes an impact.
-> Others disagree, going safety first. "(...) private keys should be
considered as compromised and regenerated as soon as possible." [2]

I respect your / StartSSLs opinion, but vote for safety first. IMHO
"safety first" is an important property of a trustworthy CA.

However, it's not up to me to decided whether StartSSL is still "ok" to
be shipped with mozilla. I hope to see an official statement of mozilla,
soon.

Greetz, Jan


P.S.

(i) I really hope, that you change your mind by doing revocations for
free and charge for re-keying. This will break the
issuing-revocation-cycle, too, while going safety first.

(ii)
I strongly don't agree with that point:
"For private sites that are usually not visited by the public
(administrative panels for example), changing the host name, deleting
the previous DNS entry, obtaining a new certificate and never visit the
original site again might work too. Many of the free Class 1 level
certificates are used for such purpose."

The point is: After key-leakage mitm attacks are possible. Think of an
insider being in a encrypted Wifi network. Having "valid" cert for an
unused subdomain can do harm ...

[1] "Debian-randomness" is the only think, I can remember, but it was
smaller, afaik.
[2] https://lists.debian.org/debian-security-announce/2014/msg00071.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Zack Weinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/23/2014 11:51 AM, Eddy Nigg wrote:
> On 04/10/2014 07:05 PM, Eddy Nigg wrote:
> 
> Alright - things have calmed down luckily by now. As my first input
> to the discussion please read carefully my explanation, thoughts
> and comments I've written down in my blog at
> https://blog.startcom.org/?p=230

I would like to point out that this assumption

> According to my understanding of this vulnerability, for [the
private > key to be leaked] an attacker must have performed the attack
on the
> server right after a restart when the private key is loaded into 
> memory and still within the first 64K allocated memory space

has been demonstrated to be false: due to further implementation bugs,
one of the RSA secret primes, 'p', has a chance to be copied to a
higher memory address, and not erased thereafter, upon each new TLS
handshake. Please see
http://www.lightbluetouchpaper.org/2014/04/25/heartbleed-and-rsa-private-keys/
for more detail.

That being the case, Heartbleed-related revocations should, per
section 4.9.1 of https://www.startssl.com/policy.pdf, be handled as
the case where "the subscriber's key is suspected to be compromised".
 It is my understanding of that document that such revocations do
*not* carry a handling fee; handling fees only apply to the final
clause in the list ("the subscriber makes a request for revocation")
*without* any of the other cases applying.  (I admit that the document
is ambiguous - you should also redraft it to make the scope of the (*)
footnote clearer.)

Moreover, it is my personal opinion that as a matter of basic business
ethics, this is a cost you (or rather, your insurance) should absorb,
not your customers.

zw
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTWoniAAoJEJH8wytnaapk0uAQAMdB3/IEWgHr+MdM4OBy/V1p
vG5Hkxa5hWJfrRs9zKc7L/30nzBeGaUqSzr6z++u/utVDbL6i0xc8Q02U31+CasJ
cC7XeytpId+au1cd6uf2el3CbSc12mQGHzSYXczqW0ThawL0JaEfscfol7TXTfDH
MS1qW6mTnzRtgwJLRUrV9tywqaB1zEAfH9JqwWO9XHQ+Ssl6/1TZ8C8VBYXl6A4M
D4tZS/KPEpRdPCrgg23MsV7cNawmPJiX6Xt7JGB979CfiCwc7j3+iEpqdtPkvCAT
SHvye1CTfDPn5wKWi1b5e7O0zhzn/rTU16Wi8nV6K1WN8POgaukdxEzEvbrp9XKA
xLcbu/ynYlD2icfqkE0Z0hBZFYraFOaksQbmIkVW7fmb1o3QVJDULpQRoQ8NjTp7
//XvK4gPTipAVl7h6ga4cr0ReY4tws9BflgovWVKj3ZOnI8D6q0Tiwix4q5zTs/2
g7OHVW2zndmTrjOGY+DsZEb0GoIeE/1vt8emegmF1kbvijMyUazlSvrZlLULGMA3
yxZabJTBgJgisYhG3FbzFHLKjc4It6R8Jy1i9w7KHFlnFYYglo7K0Ch2IHSPC21E
dibDD4STURX4F/5gxcwwaBHizh2MH65xNBo4nL/4sAtr6fP3XQaNSWI8yKBR/Cji
+VTeKZTjjm3MsTuDonSc
=r8JA
-END PGP SIGNATURE-
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Eric Mill]

Eddy -- it's a worldwide security vulnerability. Just make an exception.
One time free revocation for any class 1 certs where the customer uses the
word "Heartbleed" in their revocation request. It's not too late to change
your mind.

-- Eric


On Thu, Apr 24, 2014 at 1:24 PM, Eddy Nigg  wrote:

> On 04/24/2014 08:15 PM, Eddy Nigg wrote:
>
>> Without leaking any more data from Netcraft I can tell you that the
>> revocation rate of StartSSL is in fact higher than any other CA except
>> GlobalSign
>>
>
> Sorry, this statement should have said higher than the average and not
> every CA.
>
>
> --
> Regards
> Signer: Eddy Nigg, COO/CTO
> StartCom Ltd. 
> XMPP:   start...@startcom.org 
> Blog:   Join the Revolution! 
> Twitter:Follow Me 
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Jan Lühr]

Hello,

Am 04/10/2014 04:28 PM, schrieb Rob Stradling:
> The Mozilla CA Certificate Maintenance Policy (Version 2.2) [1] says
> (emphasis mine):
> 
> "CAs _must revoke_ Certificates that they have issued upon the
> occurrence of any of the following events:
> ...
>   - the CA obtains _reasonable evidence_ that the subscriber’s private
> key (corresponding to the public key in the certificate) has been
> compromised or is _suspected of compromise_ (e.g. Debian weak keys)"
> 
> I think that's pretty clear!

Yes. It is. I requested the revocation of two StartSSL certificates due
to CVE-2014-0160 more than two weeks ago.
The revocation has not happened, probably due lack of payment methods I
provided so far.
IMHO: This violates mozillas polices (as quoted).

I think, there is an urgent need for a public statement from mozilla:
Being either:
-> An explanation, why StartSSL is still in the trust store although
violating or mozilla's policies.
OR
-> An explanation, that StartSSL is removed.

This statement is urgently needed - imho.

Thanks, Jan


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Kathleen Wilson]

On 4/24/14, 10:15 AM, Eddy Nigg wrote:

On 04/24/2014 05:04 AM, Radu Hociung wrote:

On Wednesday, April 23, 2014 6:00:41 PM UTC-4, Eddy Nigg wrote:


I do have a few questions to you! How can you know that a site using a
certificate from ANY CA isn't or wasn't affected by the Heartbleed bug?

I'm planning on a more thorough answer that cross references the SSL
observatory data from 2010 with a fresh update, and with published
CRLs. One would expect that each CA would have about 17% of their
issued certificates be revoked and re-keyed due to heartbleed. In a
day or two I should have some stats.


Don't waste your time, I'll help you: https://isc.sans.edu/crls.html




In case anyone missed this one:
http://blog.cloudflare.com/the-hard-costs-of-heartbleed



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Eddy Nigg]

On 04/24/2014 08:15 PM, Eddy Nigg wrote:
Without leaking any more data from Netcraft I can tell you that the 
revocation rate of StartSSL is in fact higher than any other CA except 
GlobalSign


Sorry, this statement should have said higher than the average and not 
every CA.


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. 
XMPP:   start...@startcom.org 
Blog:   Join the Revolution! 
Twitter:Follow Me 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Eddy Nigg]

On 04/24/2014 05:04 AM, Radu Hociung wrote:

On Wednesday, April 23, 2014 6:00:41 PM UTC-4, Eddy Nigg wrote:


I do have a few questions to you! How can you know that a site using a
certificate from ANY CA isn't or wasn't affected by the Heartbleed bug?

I'm planning on a more thorough answer that cross references the SSL 
observatory data from 2010 with a fresh update, and with published CRLs. One 
would expect that each CA would have about 17% of their issued certificates be 
revoked and re-keyed due to heartbleed. In a day or two I should have some 
stats.


Don't waste your time, I'll help you: https://isc.sans.edu/crls.html

Now, using current data from Netcraft which I'm not really allowed to 
publish shows StartCom with slightly above 100,000 certificates. Without 
leaking any more data from Netcraft I can tell you that the revocation 
rate of StartSSL is in fact higher than any other CA except GlobalSign, 
but their situation is unique (and maybe also problematic due to the CRL 
size).


Assuming that 17% of all certificates were affected by teh bug you can 
see easily that about 1.5% of all certificates were revoked in average 
excluding GlobalSign. StartCom's revocations is currently slightly short 
of 2%, above average.


It also means that in average there are still 15.5% of certificates that 
might be affected and still not revoked, assuming none of them expired. 
Not that I believe that those keys in fact have been compromised, but 
applying your logic there are a bunch of CAs you probably should disable 
now.


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. 
XMPP:   start...@startcom.org 
Blog:   Join the Revolution! 
Twitter:Follow Me 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Martin Rublik]

On 24. 4. 2014 4:04, Radu Hociung wrote:
> I hope to update you in a few days with some stats from my investigation into 
> SSL-Observatory vs. current CRL lists, but I can tell you now that I see some 
> CAs that had an average of 20 revocations/day in March but have shot up to 
> 300 revocations/day in April (ie, 15x increase). Startcom went from ~4 to 
> ~22/day (5x increase). One would expect 17% of about 130k Startcom certs to 
> be revoked due to heartbleed. (or a cool $500K, right?). However at the 
> current rate of 22/day, 82% of the affected certificates will still be valid 
> on their expiration day.

SANS has a nice overview of recent revocation activity
https://isc.sans.edu/crls.html

Martin

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Radu Hociung]

On Wednesday, April 23, 2014 6:00:41 PM UTC-4, Eddy Nigg wrote:
 
> I do have a few questions to you! How can you know that a site using a 
> certificate from ANY CA isn't or wasn't affected by the Heartbleed bug? 

I'm planning on a more thorough answer that cross references the SSL 
observatory data from 2010 with a fresh update, and with published CRLs. One 
would expect that each CA would have about 17% of their issued certificates be 
revoked and re-keyed due to heartbleed. In a day or two I should have some 
stats.

But meanwhile, there is no way for me to know how many pkeys out there have 
been leaked. Google and a couple others had advance notice of the bug and I 
would imagine they've scanned the internet before the bug was announced, and 
have a more comprehensive list of certificates at risk. Maybe someone from 
Google can chime in? I fully expect them to build a blacklist into the 
SafeBrowsing Chrome filter.

As you well know, there is a sizeable number of admins that had the bug, and 
used a Startcom certificate, who are not planning on paying your fee. I have 
not heard of similar hardship from admins who use other providers' 
certificates. So it's fair to say, that the name Startcom will appear on a lot 
more compromised certificates, than the other guys names.

I hope to update you in a few days with some stats from my investigation into 
SSL-Observatory vs. current CRL lists, but I can tell you now that I see some 
CAs that had an average of 20 revocations/day in March but have shot up to 300 
revocations/day in April (ie, 15x increase). Startcom went from ~4 to ~22/day 
(5x increase). One would expect 17% of about 130k Startcom certs to be revoked 
due to heartbleed. (or a cool $500K, right?). However at the current rate of 
22/day, 82% of the affected certificates will still be valid on their 
expiration day.


> > Consider also that the presence of Startcom in this market is a barrier to 
> > entry to other, honest and potentially inexpensive CAs.
> 
> No, it's not, otherwise StartCom would own 100% of the market share 
> which it doesn't. The offerings of StartCom suite certain users and 
> others not.

Perhaps you are unaware of the competitive advantage you're currently enjoying.

Regards,
Radu Hociung
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Eddy Nigg]

On 04/23/2014 10:32 PM, Radu Hociung wrote:

What will you do do avoid this? Check what's behind the (now meaningless) green 
lock? what if the site replaced its certificate with a new one, non-startcom ? 
You can still be MITM'd using the existing, valid cert, so you can't even be 
certain that you're safe.


I do have a few questions to you! How can you know that a site using a 
certificate from ANY CA isn't or wasn't affected by the Heartbleed bug? 
Do you know how many certificates from CAs other than StartCom have NOT 
been revoked? And can you tell me which of the currently installed 
certificates no matter who the issuer is were issued after a revocation 
of a previous certificate?


Once you can answer me these questions I have an interesting surprise 
for you



Consider also that the presence of Startcom in this market is a barrier to 
entry to other, honest and potentially inexpensive CAs.


No, it's not, otherwise StartCom would own 100% of the market share 
which it doesn't. The offerings of StartCom suite certain users and 
others not.



How can they compete with the perceived "free" certificates that Startcom 
floods the SSL space with?


They are free of charge no matter what - and under normal circumstances 
will not cost anything. Approximately 17% might be affected by this bug, 
another 87% are not. This means users are getting year after year a free 
service for 0.00 US$ from StartCom and keep getting it now and in the 
future, the rare exception which isn't even under our control are 
revocations. And if it wouldn't be necessary to raise a fee for that we 
wouldn't either.


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. 
XMPP:   start...@startcom.org 
Blog:   Join the Revolution! 
Twitter:Follow Me 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Radu Hociung]

The total cost of the certificate is not $0. Total cost would include issuance, 
re-issuance and any revocations.

But consider this, when you  go about your daily browsing business, for some of 
the forums and sites you visit, someone other than the site's owner also holds 
a private key and a valid startcom certificate. On these sites, you can be 
MITM'd.

What will you do do avoid this? Check what's behind the (now meaningless) green 
lock? what if the site replaced its certificate with a new one, non-startcom ? 
You can still be MITM'd using the existing, valid cert, so you can't even be 
certain that you're safe.

Instead of forum, you can also think IMAP mailbox, or other services which are 
not browser based (jabber, vpn, SVN repo, etc), so there is no green lock that 
you can click on to investigate.

How can you prevent being owned?

1. You can avoid putting your private info anywhere.
2. You can right click the lock before clicking "submit", and double check if 
you're not trusting a startcom certificate, or if you are, figure out if this 
particular certificate has ever been susceptible to being heartbled?
3. Edit the certificate store and Untrust StartCom?

What is a typical person to do?

I do feel that discussing this further is pointless, as Mozilla still tells us 
to trust CNNIC, and a few other highly questionable CA's. It's probably unwise 
to trust Mozilla.

Consider also that the presence of Startcom in this market is a barrier to 
entry to other, honest and potentially inexpensive CAs. How can they compete 
with the perceived "free" certificates that Startcom floods the SSL space with?

BTW, I cannot find any discussion on Microsoft/Apple's position WRT Startcom? 
Please share a link if you have one.

Also, where can one buy some of those pkeys? Any links?

On Tuesday, April 22, 2014 11:04:05 AM UTC-4, Pontus Engblom wrote:
> So, getting a certificate for free, isn't free?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Eddy Nigg]

On 04/10/2014 07:05 PM, Eddy Nigg wrote:

I agree - I've saw the tweets bug reports and this posting. I'll be glad
to join the discussion and we intend to take a public stance as soon as
things calm down a bit.

Currently all hell is lose, but I promise to get back to you all in due
time and will explain our position, policy and practices and also refute
some of the claims that were made.

In the meantime please be patient, thanks.




Alright - things have calmed down luckily by now. As my first input to 
the discussion please read carefully my explanation, thoughts and 
comments I've written down in my blog at https://blog.startcom.org/?p=230


--
Regards

Signer: Eddy Nigg, COO/CTO
StartCom Ltd. 
XMPP:   start...@startcom.org 
Blog:   Join the Revolution! 
Twitter:Follow Me 


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Pontus Engblom]

So, getting a certificate for free, isn't free?
Or are they just a free CA up until you need to revocate?

Every business need to get a income from something, now this fee was
put on revocations to keep people from revocating/re-issuing etc,
think before you buy or whatever you like to call it.

The $25 fee been there since around 2010 at least according to
web.archive.org, meaning that none of your certificates can be claimed
"Well hey, this policy wasn't there when I signed up". Yeah, it kinda was.

And yes, I agree with Peter that maybe it would be better to implement
free revocation from StartCom's side but take out a fee for reissue,
that might be a plan for the future.

Now post-heartbleed we have learned that if you have a certificate at
StartCom, you have to pay to get it revoked (but some people claimed
their certs got revoked without paying), most people that seek to
StartCom is just in it for the padlock, their not willing to invest
any money whatsoever into security (if so, they clearly would have
paid the $25 and carried on with their day), we should really be
focusing on a Mozilla revocation policy, which must be a lot clearer
(and *stricter*?).

Tyler Szabo skrev 2014-04-22 07:18:
> It's worth noting that StartCom isn't actually a free CA. They've 
> demonstrated that with the business model they're using.
> 
> 
> On Mon, Apr 21, 2014 at 6:18 PM, Peter Eckersley
>  wrote:
> 
>> Removing Startcom from the trust root would be a catastrophe for
>> the security of Mozilla's users, since it would move the Web from
>> one free CA to zero free CAs, thereby forcing over a hundred
>> thousand websites from HTTPS (which is actually still not
>> terrible, even if you had a window of Heartbleed vulnerability)
>> to HTTP (which is completely and utterly insecurable).
>> 
>> Startcom needs to implement support for free self-signed
>> revocation, but I don't think they're obliged to reissue for
>> you.
>> 
>> And my advice to any website that (a) wants to do something to
>> feel better about Heartbleed and (b) isn't willing to pay $25 for
>> reissuance would be to turn on Perfect Forward Secrecy and keep
>> using their old cert.  That's going to get you to a better final
>> state than revoking and using HTTP or self-signed w/ cert
>> warnings.
>> 
>> 
>> On 21 April 2014 17:50, Radu Hociung  wrote:
>> 
>>> On Monday, April 21, 2014 12:32:43 PM UTC-4, Daniel Micay
>>> wrote:
>>>> Mozilla has all the cards in their hands here.
>>> 
>>> Indeed. I'm glad to see others before me reached the same
>>> conclusion,
>> that
>>> the appropriate response is to remove the trusted status of
>>> Startcom.
>>> 
>>> The original bugzilla #994033 was closed, this issue has been
>>> debated in the mailing list for a few days, but what is the
>>> resolution?
>>> 
>>> AFAICT, Mozilla's position is "Startcom is here to stay"? 
>>> ___ 
>>> dev-security-policy mailing list 
>>> dev-security-policy@lists.mozilla.org 
>>> https://lists.mozilla.org/listinfo/dev-security-policy
>>> 
>> ___ 
>> dev-security-policy mailing list 
>> dev-security-policy@lists.mozilla.org 
>> https://lists.mozilla.org/listinfo/dev-security-policy
>> 
> ___ dev-security-policy
> mailing list dev-security-policy@lists.mozilla.org 
> https://lists.mozilla.org/listinfo/dev-security-policy
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Tyler Szabo]

It's worth noting that StartCom isn't actually a free CA. They've
demonstrated that with the business model they're using.


On Mon, Apr 21, 2014 at 6:18 PM, Peter Eckersley  wrote:

> Removing Startcom from the trust root would be a catastrophe for the
> security of Mozilla's users, since it would move the Web from one free CA
> to zero free CAs, thereby forcing over a hundred thousand websites from
> HTTPS (which is actually still not terrible, even if you had a window of
> Heartbleed vulnerability) to HTTP (which is completely and utterly
> insecurable).
>
> Startcom needs to implement support for free self-signed revocation, but I
> don't think they're obliged to reissue for you.
>
> And my advice to any website that (a) wants to do something to feel better
> about Heartbleed and (b) isn't willing to pay $25 for reissuance would be
> to turn on Perfect Forward Secrecy and keep using their old cert.  That's
> going to get you to a better final state than revoking and using HTTP or
> self-signed w/ cert warnings.
>
>
> On 21 April 2014 17:50, Radu Hociung  wrote:
>
> > On Monday, April 21, 2014 12:32:43 PM UTC-4, Daniel Micay wrote:
> > > Mozilla has all the
> > > cards in their hands here.
> >
> > Indeed. I'm glad to see others before me reached the same conclusion,
> that
> > the appropriate response is to remove the trusted status of Startcom.
> >
> > The original bugzilla #994033 was closed, this issue has been debated in
> > the mailing list for a few days, but what is the resolution?
> >
> > AFAICT, Mozilla's position is "Startcom is here to stay"?
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Peter Eckersley]

Removing Startcom from the trust root would be a catastrophe for the
security of Mozilla's users, since it would move the Web from one free CA
to zero free CAs, thereby forcing over a hundred thousand websites from
HTTPS (which is actually still not terrible, even if you had a window of
Heartbleed vulnerability) to HTTP (which is completely and utterly
insecurable).

Startcom needs to implement support for free self-signed revocation, but I
don't think they're obliged to reissue for you.

And my advice to any website that (a) wants to do something to feel better
about Heartbleed and (b) isn't willing to pay $25 for reissuance would be
to turn on Perfect Forward Secrecy and keep using their old cert.  That's
going to get you to a better final state than revoking and using HTTP or
self-signed w/ cert warnings.


On 21 April 2014 17:50, Radu Hociung  wrote:

> On Monday, April 21, 2014 12:32:43 PM UTC-4, Daniel Micay wrote:
> > Mozilla has all the
> > cards in their hands here.
>
> Indeed. I'm glad to see others before me reached the same conclusion, that
> the appropriate response is to remove the trusted status of Startcom.
>
> The original bugzilla #994033 was closed, this issue has been debated in
> the mailing list for a few days, but what is the resolution?
>
> AFAICT, Mozilla's position is "Startcom is here to stay"?
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Daniel Micay]

On 21/04/14 08:50 PM, Radu Hociung wrote:
> On Monday, April 21, 2014 12:32:43 PM UTC-4, Daniel Micay wrote:
>> Mozilla has all the
>> cards in their hands here.
> 
> Indeed. I'm glad to see others before me reached the same conclusion, that 
> the appropriate response is to remove the trusted status of Startcom.
> 
> The original bugzilla #994033 was closed, this issue has been debated in the 
> mailing list for a few days, but what is the resolution?
> 
> AFAICT, Mozilla's position is "Startcom is here to stay"?

I think it's only realism to leave them in the trust store. Removing it
would break sites and cause users to flee to other browsers. Having it
stop being shown as a secure connection is a very realistic option. It
can still be shown as https, just without the "secure" marker.

It would also be great if it stopped telling users the connection is
secure when the cipher lacks perfect forward secrecy. If you want
servers to start supporting it, that's exactly how. We all know this
OpenSSL bug is not going to be the last. Traffic captured today over
connections not using perfect forward secrecy is *not secure*. Firefox
should stop telling users it is.



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Radu Hociung]

On Monday, April 21, 2014 12:32:43 PM UTC-4, Daniel Micay wrote:
> Mozilla has all the
> cards in their hands here.

Indeed. I'm glad to see others before me reached the same conclusion, that the 
appropriate response is to remove the trusted status of Startcom.

The original bugzilla #994033 was closed, this issue has been debated in the 
mailing list for a few days, but what is the resolution?

AFAICT, Mozilla's position is "Startcom is here to stay"?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Daniel Micay]

On 18/04/14 05:32 AM, tyler.sz...@gmail.com wrote:
> Would it be feasible for Mozilla to maintain a CRL-like that sidesteps the 
> need for the CA to revoke a cert?
> 
> This way if a CA is behaving badly the certificate still gets invalidated.

I think it would be a lot saner to simply stop showing a shiny green
lock for a CA violating the policy. This way, sites will continue to
work for users and there will be no loss of security. However, Firefox
won't be giving users a false sense of security. Mozilla has all the
cards in their hands here.



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[josef . schneider]

The way I see it, this is a clear violation of the Mozilla CA Certificate 
Maintenance Policy!
If such a violation has no consequence at all for the CA, what example would 
that be?
Wouldn't it encourage all CAs to ignore the policy in the future?
I see it this way:
StartSSL violates the policy, so it HAS to be removed!
One can then argue about changing the policy, and re add StartSSL if they 
comply to (a maybe changed) policy!

But until the policy is changed, every CA violating it has to be removed! No 
discussions!

This is just my opinion, of course!
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cloudflare heartbleed challenge, Re: Revocation Policy

[Eric Mill]

This description by Jeremy Gosni about how he cracked CloudFlare's challenge 
makes grabbing a private key sound much easier than thought:

https://gist.github.com/epixoip/10570627

I admit I don't 100.0% follow the approach, but it hinges on looking for the 
actual p and q prime factors in memory, rather than something that looks 
"key-like" in PEM format or whatever.

hat tip Harry Garrood: https://twitter.com/hdgarrood/status/455487235199344640

-- Eric

On Saturday, April 12, 2014 5:57:27 PM UTC-4, Peter Eckersley wrote:
> Florian, there's something that about legal rules that is often quite
> 
> unintuitive to those of us with technical backgrounds: lawyers don't
> 
> necessarily expect them to be followed exhaustively all of the time.  At
> 
> least in common law countries (.us, .uk, .ca, .au, .il, and many more),
> 
> legal rules exist most profoundly to resolve disputes between people who
> 
> cannot resolve their dispute by less formal means.
> 
> 
> 
> As a legal instrument, the Baseline Requirements should be understood in
> 
> the same tradition.  They exist as operational guidelines, and as a
> 
> fallback mechanism if there is an unresolved dispute with a CA.  The
> 
> Cloudflare Challenge is a pretty unusual case that probably wasn't
> 
> anticipated by whoever drafted the BRs and the Comodo CPS.  But if there's
> 
> nobody who has a security problem because of the Cloudflare Challenge, why
> 
> on earth would the cert be revoked?
> 
> 
> 
> Putting it another way, given that the Cloudflare Challenge is good for
> 
> Internet security (it's giving us better information about what the
> 
> blackhats can and can't do), why would you try to make Comodo revoke it?
> 
> 
> 
> 
> 
> 
> 
> On 12 April 2014 05:42, Florian Weimer wrote:
> 
> 
> 
> > * Jürgen Brauckmann:
> 
> >
> 
> > > Cloudflare set up a challenge with nginx on Ubuntu. Seems some
> 
> > > people succeeded in extracting the servers private key:
> 
> > >
> 
> > > https://www.cloudflarechallenge.com/heartbleed
> 
> >
> 
> > FWIW, I've asked Comodo to revoke the Cloudflare certificate due to
> 
> > this compromise.  The challenge itself is probably against the
> 
> > subscriber agreement, but that is an internal matter between
> 
> > Cloudflare and Comodo.
> 
> >
> 
> > On the other hand, I do think that a rule that requires CAs to revoke
> 
> > keys against the subscriber's will can be problematic.  But
> 
> > nevertheless, it's a rule, and we'll see if all those costly audits
> 
> > are good at ensuring that CAs follow it.
> 
> > ___
> 
> > dev-security-policy mailing list
> 
> > dev-security-policy@lists.mozilla.org
> 
> > https://lists.mozilla.org/listinfo/dev-security-policy
> 
> >
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[tyler . szabo]

Would it be feasible for Mozilla to maintain a CRL-like that sidesteps the need 
for the CA to revoke a cert?

This way if a CA is behaving badly the certificate still gets invalidated.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Tony França]

I think pay-to-revoke is pretty bad for security, and therefore should not be 
allowed.

I also think it's unnacceptable for a CA not to care that they have a green 
padlocks around that don't mean what they're supposed to - 
like Startcom is doing, they've received revocation requests, but they are only 
revoking after payment.

Mozilla and other browser vendors could stop this nonsense by providing their 
own CRL service - then anyone who has a certificate private key can revoke it.
Would that be possible? Should we discuss about that?

Cheers
Tony

On Tuesday, April 15, 2014 4:27:06 AM UTC-3, Matthias Hunstock wrote:
> Am 11.04.2014 18:46, schrieb Peter Eckersley:
> 
> > Of course, yes.  For revocation this is the correct approach.
> 
> 
> 
> Ah, for revocation. Your post read as if you meant reissuance also.
> 
> 
> 
> Regards

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[jan . helmuth42]

Hello,
Am Donnerstag, 10. April 2014 16:28:38 UTC+2 schrieb Rob Stradling:

> The Mozilla CA Certificate Maintenance Policy (Version 2.2) [1] says 

> "CAs _must revoke_ Certificates that they have issued upon the 
> 
> occurrence of any of the following events:
> 
> ...
> 
>- the CA obtains _reasonable evidence_ that the subscriber's private 
> 
> key (corresponding to the public key in the certificate) has been 
> 
> compromised or is _suspected of compromise_ (e.g. Debian weak keys)"
> 
> 
> 
> I think that's pretty clear!

yes. As of 2014-04-10 I revoked three certificates due to heartbleed. Comment 
was "OpenSSL Security Advisory [07 Apr 2014]/ TLS heartbeat read overrun 
(CVE-2014-0160)"

This certificates has not been revoked until now - (probably due to a lack of 
payment from my side).

Imho this is a violation of Mozilla's Policy.

Greetz, Jan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cloudflare heartbleed challenge, Re: Revocation Policy

[Michael Berg]

On Saturday, April 12, 2014 9:27:24 AM UTC+2, Jürgen Brauckmann wrote:

> Cloudflare set up a challenge with nginx on Ubuntu. Seems some
> 
> people succeeded in extracting the servers private key:

I think thats enough evidence that Heartbleed really did leak private keys.
What to do next? It seems that the interest on this topic is going to slow down 
here and on the Bugtracker. There should be a clear statement that Mozilla is 
not going to accept StartComs policy. 
Please give them a deadline and then just remove their Certificate from the 
Trust store. Admins will take action when their customers cannot access their 
sites without getting a security warning.
https://news.ycombinator.com/item?id=7577290 shows that they wont change their 
policy. So Mozilla should not change their policy either and just remove their 
trust.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[drew]

On Thursday, April 10, 2014 6:47:38 PM UTC-5, Peter Eckersley wrote:
> I think one large and tricky open question here is what the standard for
> 
> "suspected of compromise" is.
> 
> 

This is neither large nor tricky, for two reasons.

Firstly, look at the exact wording:

> the CA obtains reasonable evidence that the subscriber's private key... is 
> suspected of compromise

If I suspect that a key is compromised, then the key "is suspected" of 
compromise.  If I write down "I suspect this key is compromised" and sign by 
name, that is "reasonable evidence that the key is suspected of compromise".  
Mozilla clearly did not mean "_is_ compromised" (in fact, that case is handled 
in its own clause).  They wrote "is suspected", which has a pretty plain and 
clear meaning.

Now it does happen to be an absurd meaning.  By the language of the policy, I 
can write to a CA and get Microsoft's cert revoked.  And so perhaps what they 
meant was "is reasonably suspected of compromise".

If we read the adverb "reasonably" into the policy, which is not at all clear 
is the right thing to do, we have to ask: what would Mozilla mean by "is 
_reasonably_ suspected of compromise"?

And the answer immediately follows: "e.g. Debian weak keys".  The Debian weak 
key scenario is the contemplated purpose of "is suspected of compromise".

Ask yourself: when Mozilla said "Debian weak keys", did they contemplate 
somebody showing that an attacker specifically did break their key in 
particular?  No.  Such a thing would be virtually impossible to show, for one.  
What they contemplated was somebody showing that their key was vulnerable.

Similarly, if a person was running a bad OpenSSL, their key was vulnerable.  So 
what the policy contemplates in the Heartbleed scenario is a user showing that 
they were running a bad OpenSSL.  Not that an attacker actually did compromise 
them.

Drew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cloudflare heartbleed challenge, Re: Revocation Policy

[tonylampada]

I did this as a test:
https://revokame.tonylampada.com.br/

Given Startcom reply to it, it seems pretty clear to me that they are in 
violation of CA policy, they are already hurting the security of the internet 
and the internet should not trust them anymore.





On Saturday, April 12, 2014 9:42:26 AM UTC-3, Florian Weimer wrote:
> * Jürgen Brauckmann:
> 
> 
> 
> > Cloudflare set up a challenge with nginx on Ubuntu. Seems some
> 
> > people succeeded in extracting the servers private key:
> 
> >
> 
> > https://www.cloudflarechallenge.com/heartbleed
> 
> 
> 
> FWIW, I've asked Comodo to revoke the Cloudflare certificate due to
> 
> this compromise.  The challenge itself is probably against the
> 
> subscriber agreement, but that is an internal matter between
> 
> Cloudflare and Comodo.
> 
> 
> 
> On the other hand, I do think that a rule that requires CAs to revoke
> 
> keys against the subscriber's will can be problematic.  But
> 
> nevertheless, it's a rule, and we'll see if all those costly audits
> 
> are good at ensuring that CAs follow it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Matthias Hunstock]

Am 11.04.2014 18:46, schrieb Peter Eckersley:
> Of course, yes.  For revocation this is the correct approach.

Ah, for revocation. Your post read as if you meant reissuance also.

Regards
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Cloudflare heartbleed challenge, Re: Revocation Policy

[Jeremy Rowley]

Some comments:

>I agree with everything you say above: the PKIX should be a way of reliably
mapping between domain names and keys, and nothing more. 
[JR]  Incorrect.  From 5280:
"The goal of this specification is to develop a profile to facilitate
   the use of X.509 certificates within Internet applications for those
   communities wishing to make use of X.509 technology.  Such
   applications may include WWW, electronic mail, user authentication,
   and IPsec.  In order to relieve some of the obstacles to using X.509
   certificates, this document defines a profile to promote the
   development of certificate management systems, development of
   application tools, and interoperability determined by policy."

> Value judgements and policy belong at different layers of the stack that
PKI (ideally, in layers with more user control and less exposure to 50-150
jurisdictions).
[JR] Your statement above was a policy statement and value judgment.  By
doing so, you are placing a policy constraint on PKI that does not exist in
the RFCs.

>Unfortunately, the people who set up the PKIX didn't understand this, and
put a lot of foolish policy-like language into the hybrid CPS-Baseline
Requirements-industrial complex.
[JR] I think they understood it quite well. It was designed to map keys to
subject information and permit a variety of uses.  In that, PKI is quite
flexible as evidenced by the broad use across a variety of platforms and
applications (including email, access control, sign-on services, SSL, etc).

Jeremy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cloudflare heartbleed challenge, Re: Revocation Policy

[Peter Eckersley]

On 13 April 2014 13:36, Florian Weimer  wrote:

>
> The second reason is the following: What you are proposing is a value
> judgement.  But these have no place in the browser PKI.  For example,
> a properly contained sub-CA which issues interception certificates for
> internal company use arguably increases security for the covered users
> because content passing in and out can be reviewed independently from
> the end points.  Furthermore, many people will agree that interception
> certificates for targeting terrorists and other criminals would result
> in a net benefit as well.  I think it is extremely difficult to draw
> the line between "good" CA policy violations and "bad" ones, so it's
> better not to start.
>

I agree with everything you say above: the PKIX should be a way of reliably
mapping between domain names and keys, and nothing more.  Value judgements
and policy belong at different layers of the stack that PKI (ideally, in
layers with more user control and less exposure to 50-150 jurisdictions).
Unfortunately, the people who set up the PKIX didn't understand this, and
put a lot of foolish policy-like language into the hybrid CPS-Baseline
Requirements-industrial complex.

Now to make matters worse, there are *some* cases where we really expect
CAs to be doing extra legwork and revoking proactively.  Basically, that's
any situation where we should expect centralisation of expertise to be
socially productive.  Looking for and revoking certs that *without the
domain's knowledge* had a weak key (RNG bugs, for instance) in it is an
appropriate thing for CAs to refuse to issue/revoke on.

Heartbleed could turn into such a scenario, where we really think that some
large and identifiable set of certs now have untrustworthy keys, but the
evidence isn't there yet.


> Requesting certificates with the intent of leaking the private key is
> against the rules, so just don't do it.  It is debatable whether the
> rules makes sense (especially the CA-initiated revocations on key
> compromise, as mandated by Mozilla's rules, seem problematic to me),
> but then the rules need changing.
>

The cloudlfarechallenge.com case is totally different to a case where a
domain was unknowingly using a weak key.  Here we have a scenario where the
purpose of the domain is to *test* whether the name <-> key mapping is
secure.  Nobody is going to that site for any other purpose.  Of course
cloudflare could rekey the site now that the contest has been won, but
actually that would be slightly inconvenient to its users, since they can't
check claims of key compromise on Twitter as easily if the key on the site
changes.  And probably they want to leave it running a vulnerable OpenSSL,
so we can learn how much the blackhats and intelligence agencies could have
done with this bug.

Another distantly related example would be a site that knowingly selects an
RSA key with more than two factors, as an informed performance/security
tradeoff.

I think that forcing CAs to revoke in such cases is foolishly importing
judgement calls into the PKIX layer, just as much as going after the
"terrorists and other criminals'" certs would be.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cloudflare heartbleed challenge, Re: Revocation Policy

[Florian Weimer]

* Peter Eckersley:

> Florian, there's something that about legal rules that is often quite
> unintuitive to those of us with technical backgrounds: lawyers don't
> necessarily expect them to be followed exhaustively all of the time.

And they tend to withhold compassion (or technical judgments).

> At least in common law countries (.us, .uk, .ca, .au, .il, and many
> more), legal rules exist most profoundly to resolve disputes between
> people who cannot resolve their dispute by less formal means.

Exactly, once lawyers are involved, formalities matter, and the rules
are quite different compared to what we would use otherwise.

> As a legal instrument, the Baseline Requirements should be
> understood in the same tradition.  They exist as operational
> guidelines, and as a fallback mechanism if there is an unresolved
> dispute with a CA.  The Cloudflare Challenge is a pretty unusual
> case that probably wasn't anticipated by whoever drafted the BRs and
> the Comodo CPS.  But if there's nobody who has a security problem
> because of the Cloudflare Challenge, why on earth would the cert be
> revoked?

I totally disagree with that, for two reasons.  The first one is that
we are not merely dealing with a dispute between two contracting
parties.  If subscribers and CAs were free to negotiate alternative
terms, the current frameworks of policy reviews and audits would be
completely pointless.

The second reason is the following: What you are proposing is a value
judgement.  But these have no place in the browser PKI.  For example,
a properly contained sub-CA which issues interception certificates for
internal company use arguably increases security for the covered users
because content passing in and out can be reviewed independently from
the end points.  Furthermore, many people will agree that interception
certificates for targeting terrorists and other criminals would result
in a net benefit as well.  I think it is extremely difficult to draw
the line between "good" CA policy violations and "bad" ones, so it's
better not to start.

Requesting certificates with the intent of leaking the private key is
against the rules, so just don't do it.  It is debatable whether the
rules makes sense (especially the CA-initiated revocations on key
compromise, as mandated by Mozilla's rules, seem problematic to me),
but then the rules need changing.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cloudflare heartbleed challenge, Re: Revocation Policy

[Peter Eckersley]

Florian, there's something that about legal rules that is often quite
unintuitive to those of us with technical backgrounds: lawyers don't
necessarily expect them to be followed exhaustively all of the time.  At
least in common law countries (.us, .uk, .ca, .au, .il, and many more),
legal rules exist most profoundly to resolve disputes between people who
cannot resolve their dispute by less formal means.

As a legal instrument, the Baseline Requirements should be understood in
the same tradition.  They exist as operational guidelines, and as a
fallback mechanism if there is an unresolved dispute with a CA.  The
Cloudflare Challenge is a pretty unusual case that probably wasn't
anticipated by whoever drafted the BRs and the Comodo CPS.  But if there's
nobody who has a security problem because of the Cloudflare Challenge, why
on earth would the cert be revoked?

Putting it another way, given that the Cloudflare Challenge is good for
Internet security (it's giving us better information about what the
blackhats can and can't do), why would you try to make Comodo revoke it?



On 12 April 2014 05:42, Florian Weimer  wrote:

> * Jürgen Brauckmann:
>
> > Cloudflare set up a challenge with nginx on Ubuntu. Seems some
> > people succeeded in extracting the servers private key:
> >
> > https://www.cloudflarechallenge.com/heartbleed
>
> FWIW, I've asked Comodo to revoke the Cloudflare certificate due to
> this compromise.  The challenge itself is probably against the
> subscriber agreement, but that is an internal matter between
> Cloudflare and Comodo.
>
> On the other hand, I do think that a rule that requires CAs to revoke
> keys against the subscriber's will can be problematic.  But
> nevertheless, it's a rule, and we'll see if all those costly audits
> are good at ensuring that CAs follow it.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cloudflare heartbleed challenge, Re: Revocation Policy

[Florian Weimer]

* Jürgen Brauckmann:

> Cloudflare set up a challenge with nginx on Ubuntu. Seems some
> people succeeded in extracting the servers private key:
>
> https://www.cloudflarechallenge.com/heartbleed

FWIW, I've asked Comodo to revoke the Cloudflare certificate due to
this compromise.  The challenge itself is probably against the
subscriber agreement, but that is an internal matter between
Cloudflare and Comodo.

On the other hand, I do think that a rule that requires CAs to revoke
keys against the subscriber's will can be problematic.  But
nevertheless, it's a rule, and we'll see if all those costly audits
are good at ensuring that CAs follow it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Cloudflare heartbleed challenge, Re: Revocation Policy

[Jürgen Brauckmann]

Am 10.04.2014 21:34, schrieb Erwann Abalea:

FWIW, I'm pretty confident that my private key hasn't been
compromised, even if my personal server was "Heartbleed-enabled". So
far, private key leaks have been demonstrated on FreeBSD systems, not
on Linux. And only when the first request after the server launch is
a HB one. It may be related to different memory allocators.


Cloudflare set up a challenge with nginx on Ubuntu. Seems some
people succeeded in extracting the servers private key:

https://www.cloudflarechallenge.com/heartbleed

http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed

Juergen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Peter Eckersley]

On 11 April 2014 04:06, Matthias Hunstock  wrote:


> > Implementing a new tool that lets that happen
> > automatically, using a signature from the previous key, might be the
> right
> > way to make that scale.
>
> you are supposing to trust a signature created by a possibly compromised
> key ?
>


Of course, yes.  For revocation this is the correct approach.

Supposing you are unlucky and strange guy named Eve has the private key
from your cert.  Now there are two people who can revoke your certificate:
you, and Eve.

Reissuance should of course still involve fresh Domain Validation.  Which
is only moderately secure, but that's as good as PKIX can ever do for you
today.




> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Matthias Hunstock]

Am 11.04.2014 01:47, schrieb Peter Eckersley:
> Implementing a new tool that lets that happen
> automatically, using a signature from the previous key, might be the right
> way to make that scale.

you are supposing to trust a signature created by a possibly compromised
key ?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Peter Eckersley]

I think one large and tricky open question here is what the standard for
"suspected of compromise" is.

Most of the people who feel strongly about this issue and are posting here
are applying what might be termed a precautionary standard: if there was a
conceivable way that something might have been compromised, they suspect it
of being so.  That's the appropriate attitude for highly valuable or
sensitive systems.

There's a different metric which can be applied, which is what we actually
think the probability of a randomly sampled Class 1 CA cert being
compromised in the wild is?

In order to evaluate that, there are several sub-questions:

0. What is the probability that the cert was on a vulnerable server?  As a
baseline, 17.5% of HTTPS servers were vulnerable (
http://news.netcraft.com/archives/2014/04/08/half-a-million-widely-trusted-websites-vulnerable-to-heartbleed-bug.html),
though perhaps for Startcom Class 1 it's a bit higher, and for people who
ask StartCom for revocation it's probably in the 60-90% range.

1. What is the probability that key extraction from the vulnerable server
was possible?  We don't really have a number here yet.  At EFF we've been
trying to replicate reports of key extractions, setting up FreeBSD systems
with matched library versions, and we haven't succeeded in obtaining
portions of any private keys yet.  I would guess the probability on a
random server is somewhere between 0.1% and 10%, but the confidence
interval there is still pretty low.

2. How long was the window of likely successful attack?  Widespread attacks
began after the announcement of the bug at around 17:30 UTC on Monday
2013-04-07.  Researchers in Alex Halderman's group at the University of
Michigan were watching for IPv4-wide attack scans, and saw the first one at
23:01 GMT on 2013-04-09.  Servers that were unpatched at that point were
almost certain to be attacked maliciously.  Servers that were near the top
of the Alexa charts or otherwise interesting to some attacker accumulated a
growing risk of malicious attack as elapsed time after 17:30 UTC on Monday
grew.

At EFF we have been investigating the possibility that there were attacks
in the wild, and we currently think that was probably the case (
https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013),
although we have yet to receive any reports of replications of Terrence
Koeman's observation.  Our current most likely belief is that an
intelligence agency did use this bug prior to public disclosure, but not on
a widespread basis.  Servers that are likely to be of interest to these
types of APT actors are in a different risk category to other servers.

Overall, where does this leave us?  I think the situation is genuinely
somewhat ambiguous.  Given the current evidence, I think that the vast
majority of private keys certified by Startcom remain secret, and this may
be sufficient for StartCom to argue that the "suspicion of compromise" is
not significantly higher than the baseline in a world filled with malware
and bugs to begin with.

However it's also clear that rekeying is a sound precaution, and that
suspicion of compromise is especially rational for cert holders who (a) ran
FreeBSD, (b) failed to get a patch deployed quickly, (c) who are plausible
targets for APT attackers, or (d) who were likely to receive a lot of
malicious attention after the bug was published.

I think the *right* thing for Startcom to do here is to revoke and reissue
for anyone who cares to ask.  Implementing a new tool that lets that happen
automatically, using a signature from the previous key, might be the right
way to make that scale.

However whether a probabilistic suspicion of compromise is objectively
rational depends on a lot of variables, and probably only applies if at
least one of (a),(b),(c), or (d) is true.

Lastly there's a question about whether all old X.509 certs, or all
Startcom certs, or any such category, should be distrusted in bulk.  I
think it would be a disservice of insane proportions to Mozilla's users,
since doing so effectively imposes a TLS tax on every poor admin who has to
repair a server knocked over by that action, and the vast majority of certs
distrusted in such a campaign were in fact still good and serving to make
users safer.

One last point: please implement Perfect Forward Secrecy if you haven't
already everyone!  That's the single biggest thing we can do to reduce the
risk created by intelligence agencies' key compromise attacks.

On 10 April 2014 07:28, Rob Stradling  wrote:

> The Mozilla CA Certificate Maintenance Policy (Version 2.2) [1] says
> (emphasis mine):
>
> "CAs _must revoke_ Certificates that they have issued upon the occurrence
> of any of the following events:
> ...
>   - the CA obtains _reasonable evidence_ that the subscriber's private key
> (corresponding to the public key in the certificate) has been compromised
> or is _suspected of compromise_ (e.g. Debian weak ke

Re: Revocation Policy

[Kai Engert]

Can we try to gather more information about other CAs?

Do we know if there are other CAs who charge for revocations?

Are there CAs where getting a certificate revoked is difficult, because
it's not discoverable in the CA's web interface and not mentioned in
FAQs, etc.? Any experiences here?

Regards
Kai


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Kaspar Janßen]

Thanks for your contribution Pontus.

On 10/04/14 18:10, Pontus Engblom wrote:
> This assumes that the domain has been targeted yes and that a evil
> person would want to harm users using that domain yes.
>
> If we go in an event like this, it's not actually the CAs fault, neither
> the system administrators fault, this was a bug. Who should we really blame?
Admins a telling StartCom that they are holding an valid certificate to
an compromised key but they keep the cert valid. Why should Mozilla
trust their root anymore?
> If we are to blame the CA for not revocating, why aren't there a
> proposal for a explicit policy that forces CAs to remove certs that
> users ask for, but it's up to the CA to then either charge the client
> for a new certificate or not do business with that client.
This discussion shouldn't just lead to a decision about StartCom. We
need a policy that generally prohibits a fee for a revocation.

I am not sure if a rekey should be part of a companies freedom or not. I
could image that StartCom would say they revoke the certs for free but
want the fee for rekeying. In real life this wouldn't change much. At
the end of the day, they would stay untrustworthy due to we have to
assume a large number of compromised but active certs.

The rule of encryption: in doubt compromised!
>
> I am not really sure about this, but I never said that I support not
> revocating, all I say is that this is one way for StartSSL to actually
> earn some income. Which I must say can not be easy when everyone just
> want the stuff for free and not pay at all for security.
To stretch it a little bit: If we assume that they don't have a working
business model. Maybe I should donate them some money.. maybe in reward
of *.google.com? I think I wouldn't be the only interested person. Maybe
the NASA? :D

It's clear what I mean. This also doesn't make a CA more trustworthy.
> Yes, they have no obligation to give us free certificates either. They
> could start charging us like any other CA, that would just end up in
> lots of unsecured domains. Most people that holds a Class 1 I doubt
> would want to pay for SSL, at the current price ranges, but what do I know.

If a website is plaintext you know what you have. Also if it is
self-signed. Someone could still use CaCert or build an own CA.

If a CA is in the truststore, he should behave responsible. If this is
not possible with a reliable and free offer then we have to deal with
it. I don't want to lift the CaCert problem.

- end of response -

On some comments and on twitter I read things like "crying freetards"
and things like that. This makes me angry. I bet these people never
heard of things like BEAST or Compression Side Channel Attacks. We are
dancing with really bad problems in TLS and know there is a widely
trusted CA who gives a  what he keeps signed. Sorry but this is
ridiculous, otherwise the EFF could stop the the development of https
everywhere and start feed the world. No they won't and that is good.


Kaspar




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Dave Cridland]

On Thursday, April 10, 2014 7:31:29 PM UTC+1, Jon D wrote:
> On Thu, Apr 10, 2014 at 10:55:17 -0700, Dave Cridland wrote:
> > I absolutely agree; however I'd also suggest that the point is moot.
> > The question isn't whether or not people should have known, or even
> > did know, that StartCom's business model is based around charging fees
> > for revocations.
> 
> > It doesn't matter whether anyone thinks this is fair or not - I think
> > it's a dangerous business practise, and I'm surprised that it's
> > considered in line with §2 of Mozilla's CA Certificate Maintenance
> > Policy, but that again is largely irrelevant.
> 
> Given that Mozilla no longer checks CRLs anyway, the discussion in
> general may be largely irrelevant:
> https://bugzilla.mozilla.org/show_bug.cgi?id=867465#c12
> 

CRLs are a fairly painful method for a browser to check certificate status, as 
well as lagging behind (they're large - very large right now - and infrequently 
updated). I'd personally prefer these to be background-downloaded and used as a 
fallback instead of pass-on-fail OCSP, but hey.

> OCSP is still alive and kicking, but it has some pretty notable issues
> regarding how easy it is to make it soft-fail:
> https://www.imperialviolet.org/2012/02/05/crlsets.html
> 

If you're arguing that Mozilla should start distributing a CRL of sorts of 
sites that it deems important, I'm impressed.

Yes, OCSP can fail sometimes, and adds an additional initial time. Firefox at 
least does pass-on-fail by default; sensible users will have turned on 
fail-on-fail.

> In light of all of this, removal of the CA from Mozilla for this would
> be a bit out of proportion. After all, if a certificate is revoked in
> the forest and no one is around to watch, is it really revoked?

You're assuming that removal of the CA from Mozilla only affects Firefox.

Firstly, the effects are very different on an email client like Thunderbird. 
There, the OCSP "overhead" is trivial.

Secondly, the CA list from Mozilla is used by Debian, Ubuntu, and others who 
defer trust anchor maintenance to Mozilla.

Even if Firefox dropped revocation checking entirely - which would be very 
foolish in my opinion - it would still affect thousands of applications.

As a final point, the status quo in the Mozilla policy is that revocations must 
be supported; I am not, and do not intend, arguing for any kind of policy 
change.

Dave.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Erwann Abalea]

Le jeudi 10 avril 2014 16:28:38 UTC+2, Rob Stradling a écrit :
> The Mozilla CA Certificate Maintenance Policy (Version 2.2) [1] says 
> (emphasis mine):

> "CAs _must revoke_ Certificates that they have issued upon the 
> occurrence of any of the following events:
> ...
>- the CA obtains _reasonable evidence_ that the subscriber's private 
> key (corresponding to the public key in the certificate) has been 
> compromised or is _suspected of compromise_ (e.g. Debian weak keys)"
> 
> I think that's pretty clear!

FWIW, I'm pretty confident that my private key hasn't been compromised, even if 
my personal server was "Heartbleed-enabled". So far, private key leaks have 
been demonstrated on FreeBSD systems, not on Linux. And only when the first 
request after the server launch is a HB one. It may be related to different 
memory allocators.
What is absolutely certain is that passwords, cookies, bankind card numbers, 
and other sensible data has been easily leaked, you probably tried it, like I 
did. And I bet my bank won't reissue me a new banking card (for free?).

> The CABForum BRs go one step further, demanding that the CA revoke 
> _within 24 hours_.
> 
> AFAICT, non-payment by the Subscriber does not release the CA from this 
> obligation to revoke promptly.
> 
> Anyone disagree with my interpretation?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Kurt Roeckx]

On Thu, Apr 10, 2014 at 02:31:29PM -0400, Jon DeVree wrote:
> 
> OCSP is still alive and kicking, but it has some pretty notable issues
> regarding how easy it is to make it soft-fail:
> https://www.imperialviolet.org/2012/02/05/crlsets.html

Which is why I think we should really work on getting the majority
of the servers to do OCSP stapling.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Jon DeVree]

On Thu, Apr 10, 2014 at 10:55:17 -0700, Dave Cridland wrote:
> I absolutely agree; however I'd also suggest that the point is moot.
> The question isn't whether or not people should have known, or even
> did know, that StartCom's business model is based around charging fees
> for revocations.
> 
> It doesn't matter whether anyone thinks this is fair or not - I think
> it's a dangerous business practise, and I'm surprised that it's
> considered in line with §2 of Mozilla's CA Certificate Maintenance
> Policy, but that again is largely irrelevant.
> 

Given that Mozilla no longer checks CRLs anyway, the discussion in
general may be largely irrelevant:
https://bugzilla.mozilla.org/show_bug.cgi?id=867465#c12

OCSP is still alive and kicking, but it has some pretty notable issues
regarding how easy it is to make it soft-fail:
https://www.imperialviolet.org/2012/02/05/crlsets.html

In light of all of this, removal of the CA from Mozilla for this would
be a bit out of proportion. After all, if a certificate is revoked in
the forest and no one is around to watch, is it really revoked?


-- 
Jon
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Dave Cridland]

On Thursday, April 10, 2014 4:25:46 PM UTC+1, Pontus Engblom | DigiSSL AB wrote:
> I would like to inform you that when you get a service you tend to
> read the FAQs and Certificate Policy Statements, i.e StartSSL have a
> FAQ where a whole bunch of numbers concern revocation and handling fees.
> http://www.startssl.com/?app=25#72
> (#70 to #74). So please do not claim they do not clearly state it,
> either you didn't read or didn't care to read.

I absolutely agree; however I'd also suggest that the point is moot. The 
question isn't whether or not people should have known, or even did know, that 
StartCom's business model is based around charging fees for revocations.

It doesn't matter whether anyone thinks this is fair or not - I think it's a 
dangerous business practise, and I'm surprised that it's considered in line 
with §2 of Mozilla's CA Certificate Maintenance Policy, but that again is 
largely irrelevant.

> I can agree that some certificates _MIGHT_ be compromised and need
> revocation, but as StartSSL stated earlier, if you got no intention of
> paying $24.90 you could also create a _NEW_ certificate with a
> different subdomain and replace yours, that would cost you.. nothing?
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=994033#c4

That's a worrying position to take. It's actually irrelevant whether the 
certificate my site is legitimately using is compromised or not. It's whether 
anyone else can use it to impersonate my site in such a way that's undetectable 
to my users.

Preventing this requires a revocation, so even if you do use a new free 
certificate, or even switch CA, you still need to revoke the old one.

> But I can not for the life of me see why we can't pay $24.90, they
> have given us a service for free and now when we need to do something
> we think its wrong of them to charge us? Compare it to the real world,
> companies must make money somehow its just a question of how and where.

Again, it's not relevant whether I would pay, or you would pay. I'm aware of 
several people either unable to, or unwilling to. This is a logical consequence 
of a free certificate service, that charges for revocations, I'm afraid. 
Ordinarily this probably wouldn't even matter, but the situation we have is 
hardly ordinary, and therefore there are potentially thousands of StartSSL 
certificates in circulation, many for Open Source projects and non-profits, 
which are potentially compromised and therefore untrustworthy.

> Also this is issue is quite hard to handle, it is unknown how many
> certs that actually have been compromised since it's not traceable.

Also irrelevant. It's potential compromise we need to address, since that has a 
direct bearing on the trustworthiness of the certificates.

> As Rob Stradling said;
> > The Mozilla CA Certificate Maintenance Policy (Version 2.2) [1]
> > says
> 
> (emphasis mine):
> 
> > 
> > "CAs _must revoke_ Certificates that they have issued upon the
> occurrence of any of the following events:
> > ... - the CA obtains _reasonable evidence_ that the subscriber's
> private key (corresponding to the public key in the certificate) has
> been compromised or is _suspected of compromise_ (e.g. Debian weak keys)"
> 
> This is a bit of an issue here, we don't know whom might have been
> targeted with this bug, I find it hard that low traffic domains could
> have been compromised but theres a possibility, in this case there is
> no way to get reasonable evidence of a subscriber loosing its private
> key. And to suspect every cert has been compromised well, then all CAs
> would need to make a huge CRL and pretty much revoke any certificate
> that's been active during this incident, as all might be suspected of
> compromise.

Yes; that's more or less what needs to happen, unfortunately. Thousands of 
certificates have been, or are being, revoked currently at the request of their 
owners. It doesn't matter if I trust StartCom; it does matter that I do not 
trust the certificates they have signed.

> But as a end here, try to get a new certificate for a new subdomain if
> you can not pay $25. Or actually start to pay for SSL from the first
> place? I mean, nothing is really free in the world, something got to
> cost. IMHO this removing of StartCom is just bogus. Maybe that Mozilla
> can go together and force out a policy of instant removal from clients
> if they request so, but until then, they have been included, they have
> given out numerous certificates and even considering removing them
> from the trust store because of this is ludicrous.

While I firmly agree that using a sensible choice of CA, paying a small fee now 
to cover against disaster later, and all you suggest is sensible, unfortunately 
I for one cannot trust certificates signed by StartCom at this time and have 
removed it from my trust anchor list.

In the words of the inclusion policy's section 4, I feel they cause me "undue 
risk".

This means that sites such as eff.org and xmpp.org are no lon

Re: Revocation Policy

[Thorsten Glaser]

Walter Goulet dixit:

>offering. I personally have not yet decided if I will indeed revoke,

You *must* revoke.

http://arstechnica.com/security/2014/04/heartbleed-vulnerability-may-have-been-exploited-months-before-patch/
not only shows that this has been exploited since November, but also
contains a comment from the guy who said “don’t panic, it is unlikely
that private keys have leaked” yesterday, correcting himself.

See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744027

ObAmusing: switching to other implementations? Nope. OpenSSL, NSS
and the Java™ crowd are the only ones to mostly get it right.
http://pbs.twimg.com/media/Bk0DY8XCEAAPpS7.png:large

bye,
//mirabilos
-- 
 Warum ist MirWebseite eigentlich so cool?   weil ich
ich sie geschrieben habe   Hast du sie geschrieben oder geforkt?
 geschrieben, from scratch   Ach, deshalb finde ich
auch so selten Bugs dadrin. Irgendwie hast du Recht.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Thorsten Glaser]

Pontus Engblom | DigiSSL AB dixit:

>I would like to inform you that when you get a service you tend to
>read the FAQs and Certificate Policy Statements, i.e StartSSL have a
>FAQ where a whole bunch of numbers concern revocation and handling fees.
>http://www.startssl.com/?app=25#72
>(#70 to #74). So please do not claim they do not clearly state it,
>either you didn't read or didn't care to read.

They apparently changed this practice sometime in between.
People who signed up for their service years ago did not
have any “handling fee” for revocations.

>Now they do not charge the certificate in anyway for revocation, it's
>merely a handling fee, i.e the guys that work there need to get paid
>to do their job.

I do not disagree with people needing to get their money.
I’d happily pay 5 € for certificates, and possibly a handling
fee for a revocation “on my whim”, but not acting in the face
of a security breach like this one is inacceptable (and, as
Rob Stradling pointed out, a violation of their obligations).

>I can agree that some certificates _MIGHT_ be compromised and need

No. We must assume that all private keys ever used in vulnerable
systems have been compromised; there is evidence that this has
been exploited as early as November 2013.

>revocation, but as StartSSL stated earlier, if you got no intention of
>paying $24.90 you could also create a _NEW_ certificate with a
>different subdomain and replace yours, that would cost you.. nothing?

This would help absolutely nobody because the attacker *still*
can use the private key (which they stole from you) and the
StartCom-signed certificate (which they get during the handshake
anyway) to do an MITM attack on your visitors, with StartCom
saying that the MITM attacker is “the genuine thing”.

The only option is, for example, if you have www.foo.org as
StartCom certificate, to remove A and  records for both
www.foo.org. and foo.org. from the DNS, and get a certificate
for www2.foo.org – good luck getting any traffic there. And
even then, an attacker can just redirect their target’s DNS,
making the attack once again successful.

No, no matter what, those StartCom/StartSSL-issued certificates
*must* be revoked, or StartCom/StartSSL *must* be removed from
the trusted root store, no later than this Friday.

>But I can not for the life of me see why we can't pay $24.90, they
>have given us a service for free and now when we need to do something
>we think its wrong of them to charge us? Compare it to the real world,

It’s an obligation. CAs have an oligopoly and as such, they have
certain social responsibilities, for the good of the SSL ecosy-
stem as a whole.

>Also this is issue is quite hard to handle, it is unknown how many
>certs that actually have been compromised since it's not traceable.

All certificates that have been in use on systems running OpenSSL
1.x versions since the introduction of the bug and before its fix,
even if only for a fraction of a second.

>> ... - the CA obtains _reasonable evidence_ that the subscriber’s
>private key (corresponding to the public key in the certificate) has
>been compromised or is _suspected of compromise_ (e.g. Debian weak keys)"
>
>This is a bit of an issue here, we don't know whom might have been
>targeted with this bug, I find it hard that low traffic domains could

We must assume everyone has been compromised, by now. Please see my
messages to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744027
and https://bugzilla.mozilla.org/show_bug.cgi?id=994033 for sources.

>have been compromised but theres a possibility, in this case there is
>no way to get reasonable evidence of a subscriber loosing its private
>key. And to suspect every cert has been compromised well, then all CAs
>would need to make a huge CRL and pretty much revoke any certificate

Yes. (It would probably be easier to reboot the system…) But for all
we know, they need to act.

(Note that I am currently running a StartCom certificate that was
never compromised (due to only using OpenSSL 0.x) on one system,
a compromised one (which they refuse to revoke) on another system,
and a healthy mix of GoDaddy-rekeyed ones on most other systems.)

>> If the servers in your SSL environment do not use OpenSSL, if your
>servers
>> use OpenSSL 1.0.0 or earlier, if your servers do not use OpenSSL 
>> 1.0.2-beta1, or if your servers are compiled without the heartbeat
>extension
>> enabled, then your environment is not vulnerable to the Heartbleed
>> Bug attack.

Right, there’s still two years of certificates, and a stable release
of Debian, two releases of OpenBSD, and other OSes, to cover. Since
responsible admins would contact StartCom and ask for rekey/revoke
Right Now™ (or after getting back from vacation, i.e. this month,
probably), it would not be bad for them to waive their fees this
month to people citing this vulnerability. Just revoking *every*
certificate is probably a bit too much.

The important thing is to do that *right now*, and issue a sta

Re: Revocation Policy

[Thorsten Glaser]

Peter Eckersley dixit:

>On 10 April 2014 00:46, Kaspar Janßen  wrote:

>> If someone pays 100 USD for certification, he consideres to pay 100 USD
>> for revocation. If someone doesn't pay for certification, he will
>> hesitate to pay even 1 USD for revocation.

No. I fully expect a revocation for security reasons (as opposed
to just a customer saying so out of a whim) to be free of cost,
in all cases. It is acceptable for the CA to not reissue a cert
to that customer subsequently. A rekey would be preferable.

>> That makes me question if a certificate signed by StartCom can be
>> considered as trustworthy.
>>
>> I confrontated StartCom with my doubs and pleased them to find a way to
>> solve this hurdle. They wrote me: "This will not happen without changing
>> the entire business model".

>Kaspar, suppose that Mozilla followed your suggestion and removed
>StartCom's root certificates from its trust store (or revoked them!). What
>would the consequences of that decision be, for the large number of domains
>that rely on StartCom certs?

Mozilla is big enough to make StartCom reconsider this stance
(especially as approximately two or three people *did* get the
fee waived – I, along with several others, didn’t, and there
are cases where such a fee cannot realistically be paid).

And, if not, well, bite the bullet. Distrusting StartCom would
aversely affect me too, but unless StartCom changed their stance
until Friday, 16:00 UTC, I’ll be pushing for removal of all of
their certificates from the root store.

This is not a contractual matter between StartCom and their
users. This is about the stability of the cryptographic
ecosystem, and, in this case, a CA, every CA, has a public
responsibility (especially due to the oligopoly they have).

See also my eMail 
which apparently hasn’t made it to this list yet.

bye,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[nuxi17]

My $0.02 is that by charging a fee in order to revoke the certificate of a 
compromised key, StartCom is violating section #2 of the Mozilla CA Certificate 
Maintenance Policy which requires that certificates be revoked under certain 
circumstances, including reasonable evidence that the private key is 
compromised.

http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/


Whether or not StartCom can charge (or should) fees for revocations has come up 
on this list before.

https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/3naC_Qosfq4/G90NCqzVuK8J

In principle I actually agree with Eddy (who is the owner of StartCom) that it 
isn't the role of Mozilla to dictate a business model to the CAs. The exception 
to this is that it is Mozilla's role to dictate some security policies to the 
CAs and these security policies can impact some business models. In this case 
it is revocation of compromised certificates as stated under section #2 of the 
CA Policy. The CA policy requires these certificates to be revoked if there is 
reasonable beliefe that the private keys may be compromised, by making 
revocation contingent on receiving payment, a CA will fail to comply with this 
section if a customer does not pay.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Jon D]

On Thursday, April 10, 2014 10:28:38 AM UTC-4, Rob Stradling wrote:
> The Mozilla CA Certificate Maintenance Policy (Version 2.2) [1] says 
> (emphasis mine):
> 
> 
> "CAs _must revoke_ Certificates that they have issued upon the 
> occurrence of any of the following events:
> ...
>- the CA obtains _reasonable evidence_ that the subscriber's private 
> key (corresponding to the public key in the certificate) has been 
> compromised or is _suspected of compromise_ (e.g. Debian weak keys)"
> 
> 
> I think that's pretty clear!
> 
> 
> The CABForum BRs go one step further, demanding that the CA revoke 
> _within 24 hours_.
> 
> 
> AFAICT, non-payment by the Subscriber does not release the CA from this 
> obligation to revoke promptly.
> 
> 
> Anyone disagree with my interpretation?
> 

I agree 100% and had posted almost this exact statement to bugzilla before 
being directed here for discussion. The question of whether or not they can (or 
should) charge fees for this is essentially entirely seperate from the issue at 
hand.

They have failed to revoke certificates reasonably known to be compromised and 
this is in clear violation of the Moaillz CA Policy.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Greg]

On 10/04/2014 10:08, Peter Eckersley wrote:

Kaspar, suppose that Mozilla followed your suggestion and removed
StartCom's root certificates from its trust store (or revoked them!). What
would the consequences of that decision be, for the large number of domains
that rely on StartCom certs?


The consequences would be that those domains would not be considered to 
be secure any longer. This is a good thing, not a bad thing. The 
certificates must be considered to be compromised if the domain was 
exposed to the Heartbleed Bug.


In order to act responsibly, StartCom must do one of the following: 1) 
make it possible for all their certificate holders (paid or not) to 
claim exposure to the bug and have the certificate revoked for that 
reason without charge, 2) revoke and reissue all active certificates 
issued by them, or 3) their root CA must be removed from all user agents.


Revocation must not require a fee; re-issuing can. That gives 
certificate holders the option to either re-issue using StartCom, or 
find another CA.


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Matthias Hunstock]

Am 10.04.2014 17:25, schrieb Pontus Engblom | DigiSSL AB:
> But as a end here, try to get a new certificate for a new subdomain if
> you can not pay $25. Or actually start to pay for SSL from the first
> place?

The point is: issueing for free and revoking for fee is a model that
will lead to non-revocation of certificates with leaked keys.

Even if the business model is neither part of a CA's policy nor of the
Mozilla CA review process, this is a critical point, especially (but not
only) in combination with heartbleed.


> To actually have a chance here as a CA you would need to contact every
> certificate holder and get their SSL environment.

Actually it's the obligation of the certificate owner to care about the
security of the private key and to become active if something happens.
At the end it is his server(s) that can be MITM-ed.


> And to suspect every cert has been compromised well, then all CAs
> would need to make a huge CRL

Don't cry about that, Mozilla doesn't check them anyway.


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[dave]

On Thursday, April 10, 2014 10:10:58 AM UTC+1, Kaspar Janßen wrote:
> On 10/04/14 10:08, Peter Eckersley wrote:
> 
> > Kaspar, suppose that Mozilla followed your suggestion and removed
> 
> > StartCom's root certificates from its trust store (or revoked them!). What
> 
> > would the consequences of that decision be, for the large number of domains
> 
> > that rely on StartCom certs?
> 
> I hope that an appropriate policy will force authorities to reconsider
> 
> their revocation principle. I don't want to harm someone nor I want to
> 
> work off in any way.
> 
> 
> 
> The key is that anybody should be able to shout out "don't trust me
> 
> anymore!" without a fee. Isn't that part of the trustchain idea?
> 
> 

The actual policy of the CA might annoy me, and I might think it's wrong, but 
that in and of itself is not a reason to remove trust. I did have them in my 
trust store up until now, despite having recommended against them for some time 
due to their policy, which I consider a bait-and-switch. In other words, I 
trusted their cryptography, but disliked their business model. Many of my 
contacts in the XMPP world used their free certificate offering to secure their 
servers.

However, I have removed them from my trust stores at this time because of the 
number of cases I'm personally aware of where potentially compromised 
end-entity certificates have not been revoked due to an inability or 
unwillingness to pay. This does absolutely cause problems; in fact there's a 
clear argument that it's lowering security by removing my ability to 
authenticate the certificates of other XMPP servers. However, it's also 
removing the risk of authenticating a compromised certificate as genuine due to 
lack of revocation.

To put it more simply, the certificate authority has a very high volume of 
untrustworthy certificates in circulation.

At this point, I can no longer generally trust certificates signed by the CA, 
and I would recommend others do not trust the CA either. This is an unusual 
situation, and I'd expect cases such as this to be both rare and to require 
decisions on a case-by-case basis.

> 
> I read a few times that Chrome doesn't even check if a certificate is
> 
> revoked or not (at least not the default settings). That leads me to the
> 
> question: Is it mandatory for a CA in mozilla's truststore to have to
> 
> ability to revoke a certificate or is is only an optional feature
> 
> provided by some CAs?

StartCom can revoke certificates, and are willing to do so for a fee. This is 
not a question of technical ability.

Any CA, to function as a legitimate and trustworthy authority, ought to be able 
to revoke a certificate, and provide revocation information as published in 
their certificates according to the relevant standards. StartCom do pass this 
bar.

As to whether or not Chrom[ium] checks revocations, it's possible to set it to 
do so (and therefore be secure), and insecurity of some client applications is 
obviously no excuse for a CA to be insecure, but this is really a moot point in 
this case.

Dave.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bug#744027: Revocation Policy

[Raphael Geissert]

On 10 April 2014 16:38, Thorsten Glaser  wrote:
> http://pbs.twimg.com/media/Bk0DY8XCEAAPpS7.png:large

You can not expect an implementation that doesn't provide key usage
checks to, well, check key usage.

That said, even if for instance OpenSSL supports them, applications
must tell the library what they want it to check for. From a previous
look at the openssl-using applications in Debian, those cases are
rare.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Pontus Engblom]

Thorsten Glaser skrev 2014-04-10 17:48:
> Pontus Engblom | DigiSSL AB dixit:
> 
>> Now they do not charge the certificate in anyway for revocation, it's
>> merely a handling fee, i.e the guys that work there need to get paid
>> to do their job.
> 
> I do not disagree with people needing to get their money.
> I’d happily pay 5 € for certificates, and possibly a handling
> fee for a revocation “on my whim”, but not acting in the face
> of a security breach like this one is inacceptable (and, as
> Rob Stradling pointed out, a violation of their obligations).
> 
Yes, I can agree the timing of this is bad, but a company have its
policies to follow, if they have a fee for revocation it's quite hard to
step away from it. Now when we know the extent of this bug we can just
wait and see what happends, but as you mention further down, the best
way would be to either reboot the system or either do something and try
to implement a new system.

>> I can agree that some certificates _MIGHT_ be compromised and need
> 
> No. We must assume that all private keys ever used in vulnerable
> systems have been compromised; there is evidence that this has
> been exploited as early as November 2013.
> 
I do agree with you that its been around for a while and that we should
treat every system compromised that had thoose vulnerabilities. But I
know plenty of people that just upgraded their OpenSSL and restarted
apache and think their good. Also alot of thoose systems are extremely
lowlevel traffic or no traffic domains either. I'm just pointing out
that if all CAs were to remove ALL suspected compromised certs (which
would require alot of time and effort to track down all systems that the
admin doesnt know about this), there would be no Class 1 certificates
left untouched, every single Class 1 cert should in that case be
revocated. And this can cause a bit of a problem on alot of websites.
>> revocation, but as StartSSL stated earlier, if you got no intention of
>> paying $24.90 you could also create a _NEW_ certificate with a
>> different subdomain and replace yours, that would cost you.. nothing?
> 
> This would help absolutely nobody because the attacker *still*
> can use the private key (which they stole from you) and the
> StartCom-signed certificate (which they get during the handshake
> anyway) to do an MITM attack on your visitors, with StartCom
> saying that the MITM attacker is “the genuine thing”.
> 
> The only option is, for example, if you have www.foo.org as
> StartCom certificate, to remove A and  records for both
> www.foo.org. and foo.org. from the DNS, and get a certificate
> for www2.foo.org – good luck getting any traffic there. And
> even then, an attacker can just redirect their target’s DNS,
> making the attack once again successful.
> 
> No, no matter what, those StartCom/StartSSL-issued certificates
> *must* be revoked, or StartCom/StartSSL *must* be removed from
> the trusted root store, no later than this Friday.
> 
This assumes that the domain has been targeted yes and that a evil
person would want to harm users using that domain yes.

If we go in an event like this, it's not actually the CAs fault, neither
the system administrators fault, this was a bug. Who should we really blame?

If we are to blame the CA for not revocating, why aren't there a
proposal for a explicit policy that forces CAs to remove certs that
users ask for, but it's up to the CA to then either charge the client
for a new certificate or not do business with that client.

I am not really sure about this, but I never said that I support not
revocating, all I say is that this is one way for StartSSL to actually
earn some income. Which I must say can not be easy when everyone just
want the stuff for free and not pay at all for security.

>> But I can not for the life of me see why we can't pay $24.90, they
>> have given us a service for free and now when we need to do something
>> we think its wrong of them to charge us? Compare it to the real world,
> 
> It’s an obligation. CAs have an oligopoly and as such, they have
> certain social responsibilities, for the good of the SSL ecosy-
> stem as a whole.
> 
Yes, they have no obligation to give us free certificates either. They
could start charging us like any other CA, that would just end up in
lots of unsecured domains. Most people that holds a Class 1 I doubt
would want to pay for SSL, at the current price ranges, but what do I know.

>> have been compromised but theres a possibility, in this case there is
>> no way to get reasonable evidence of a subscriber loosing its private
>> key. And to suspect every cert has been compromised well, then all CAs
>> would need to make a huge CRL and pretty much revoke any certificate
> 
> Yes. (It would probably be easier to reboot the system…) But for all
> we know, they need to act.
> 
> (Note that I am currently running a StartCom certificate that was
> never compromised (due to only using OpenSSL 0.x) on one system,
> a compromised one (which

Re: Revocation Policy

[Eddy Nigg]

On 04/10/2014 10:46 AM, Kaspar Janßen wrote:

Hi,

initially i filled a bugreport [1] about the consequences of
CVE-2014-0160 but this seems to be a better place for a discussion.
There were still a discussion about the problem which may be interesing.



I agree - I've saw the tweets bug reports and this posting. I'll be glad 
to join the discussion and we intend to take a public stance as soon as 
things calm down a bit.


Currently all hell is lose, but I promise to get back to you all in due 
time and will explain our position, policy and practices and also refute 
some of the claims that were made.


In the meantime please be patient, thanks.

--
Regards

Signer: Eddy Nigg, COO/CTO
StartCom Ltd. 
XMPP:   start...@startcom.org 
Blog:   Join the Revolution! 
Twitter:Follow Me 


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Pontus Engblom | DigiSSL AB]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Walter Goulet skrev 2014-04-10 15:59:> On Thursday, April 10, 2014
4:10:58 AM UTC-5, Kaspar Janßen wrote:
>> On 10/04/14 10:08, Peter Eckersley wrote:
>> 
>> 
>> 
>> The key is that anybody should be able to shout out "don't trust
>> me
>> 
>> anymore!" without a fee. Isn't that part of the trustchain idea?
>> 
>> 
>> 
>> Kaspar
> 
> Hi Kaspar,
> 
> Your message is very timely; I have a domain I own using a
> StartSSL
Class 1 certificate that I was planning on requesting revocation for
due to Heartbleed. I had no idea that I had to pay for revocation
either; in my mind this changes the entire value proposition of their
offering. I personally have not yet decided if I will indeed revoke,
but I will be dropping a line to them to inform them that this
'revocation fee' should clearly be stated on their website and that
their 'free' Class 1 certificate is not actually free if you need to
pay for security controls like revocation!
> 
> Walter ___

Hi there Walter,
I would like to inform you that when you get a service you tend to
read the FAQs and Certificate Policy Statements, i.e StartSSL have a
FAQ where a whole bunch of numbers concern revocation and handling fees.
http://www.startssl.com/?app=25#72
(#70 to #74). So please do not claim they do not clearly state it,
either you didn't read or didn't care to read.

Now they do not charge the certificate in anyway for revocation, it's
merely a handling fee, i.e the guys that work there need to get paid
to do their job.

I can agree that some certificates _MIGHT_ be compromised and need
revocation, but as StartSSL stated earlier, if you got no intention of
paying $24.90 you could also create a _NEW_ certificate with a
different subdomain and replace yours, that would cost you.. nothing?
https://bugzilla.mozilla.org/show_bug.cgi?id=994033#c4

But I can not for the life of me see why we can't pay $24.90, they
have given us a service for free and now when we need to do something
we think its wrong of them to charge us? Compare it to the real world,
companies must make money somehow its just a question of how and where.
A good point of this is by Marcus Sundberg in the bug #994033,
https://bugzilla.mozilla.org/show_bug.cgi?id=994033#c23

Also this is issue is quite hard to handle, it is unknown how many
certs that actually have been compromised since it's not traceable.

As Rob Stradling said;

> The Mozilla CA Certificate Maintenance Policy (Version 2.2) [1]
> says
(emphasis mine):
> 
> "CAs _must revoke_ Certificates that they have issued upon the
occurrence of any of the following events:
> ... - the CA obtains _reasonable evidence_ that the subscriber’s
private key (corresponding to the public key in the certificate) has
been compromised or is _suspected of compromise_ (e.g. Debian weak keys)"

This is a bit of an issue here, we don't know whom might have been
targeted with this bug, I find it hard that low traffic domains could
have been compromised but theres a possibility, in this case there is
no way to get reasonable evidence of a subscriber loosing its private
key. And to suspect every cert has been compromised well, then all CAs
would need to make a huge CRL and pretty much revoke any certificate
that's been active during this incident, as all might be suspected of
compromise.

- From the cabfpub;
> Heartbleed Bug Impact
> 
> If the servers in your SSL environment do not use OpenSSL, if your
servers
> use OpenSSL 1.0.0 or earlier, if your servers do not use OpenSSL 
> 1.0.2-beta1, or if your servers are compiled without the heartbeat
extension
> enabled, then your environment is not vulnerable to the Heartbleed
> Bug attack.
> 
> However, if your servers are running an OpenSSL version 1.0.1
through 1.0.1f
> with the heartbeat extension enabled, then your environment is
vulnerable to
> a Heartbleed Bug attack. Although no Heartbleed Bug attacks have
> been documented, it is impossible to know if the Heartbleed Bug
vulnerability has
> been exploited because the attack does not leave a trace.

To actually have a chance here as a CA you would need to contact every
certificate holder and get their SSL environment. Most servers usually
run on older versions, for instance Debian squeeze have OpenSSL 0.9.8o.
Therefor it's hard to say how many have been impacted, how many that
has been targeted and what the next step would be.

But as a end here, try to get a new certificate for a new subdomain if
you can not pay $25. Or actually start to pay for SSL from the first
place? I mean, nothing is really free in the world, something got to
cost. IMHO this removing of StartCom is just bogus. Maybe that Mozilla
can go together and force out a policy of instant removal from clients
if they request so, but until then, they have been included, they have
given out numerous certificates and even considering removing them
from the trust store because of this is ludicrous.



- -- 
Pontus En

Re: Revocation Policy

[Phillip Hallam-Baker]

Before we get any further into this conversation, I'll just point out
that business models are not something we can discuss in CABForum.

We can 'probably' tell you what we believe the rules to be but we
can't make any comment on what they should be either in CABForum or
here.




On Thu, Apr 10, 2014 at 10:28 AM, Rob Stradling
 wrote:
> The Mozilla CA Certificate Maintenance Policy (Version 2.2) [1] says
> (emphasis mine):
>
> "CAs _must revoke_ Certificates that they have issued upon the occurrence of
> any of the following events:
> ...
>   - the CA obtains _reasonable evidence_ that the subscriber’s private key
> (corresponding to the public key in the certificate) has been compromised or
> is _suspected of compromise_ (e.g. Debian weak keys)"
>
> I think that's pretty clear!
>
> The CABForum BRs go one step further, demanding that the CA revoke _within
> 24 hours_.
>
> AFAICT, non-payment by the Subscriber does not release the CA from this
> obligation to revoke promptly.
>
> Anyone disagree with my interpretation?
>
>
> [1]
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/
>
>
> On 10/04/14 15:16, fhw...@gmail.com wrote:
>>
>> This an interesting issue Kaspar and I appreciate you raising it. I also
>> personally appreciate you framing it in terms of trust because that's really
>> what is at issue here.
>>
>> The whole idea of revocation is a gaping hole in the PKI landscape. The
>> ability to say "don't trust me" is so poorly implemented throughout PKI as
>> to be effectively non-existent.‎ If for some reason you need to revoke a
>> cert, you should do so because it's the right thing to do, but the best you
>> can hope for is that some anti-security person doesn't figure out a way to
>> use it anyway.
>> ‎
>> This means that theft and other compromises of private keys remain viable
>> attack vectors for those who wish to do so (government sponsored
>> organizations and otherwise).‎ Private keys and the certs that go with them
>> could be usable well after when people think they become invalid.
>>
>> This also means that ‎we should not be surprised to see an underground
>> market appear that seeks to sell "revoked" certs. Given that "high value"
>> internet destinations might have been impacted by the Heartbleed
>> vulnerability this could definitely become a concern. Should such a place
>> appear I would think StartCom - issued certs would easily be included for
>> sale.
>> ‎
>> This also means that all "pay to revoke" policies should be viewed as
>> anti-security and we need to "strongly encourage" they be discontinued in
>> short order. If a CA wishes to continue such policies I would question their
>> trustworthiness.
>> ‎
>> Further I think we are reaching the point where browsers have to refuse
>> SSL connections when OCSP validation fails. I think it's getting harder to
>> argue otherwise, but I'll let the Mozilla folks speak to that.
>>
>>
>> -  Original Message  -
>> From: Kaspar Janßen
>> Sent: Thursday, April 10, 2014 4:12 AM
>>
>> On 10/04/14 10:08, Peter Eckersley wrote:
>>>
>>> Kaspar, suppose that Mozilla followed your suggestion and removed
>>> StartCom's root certificates from its trust store (or revoked them!).
>>> What
>>> would the consequences of that decision be, for the large number of
>>> domains
>>> that rely on StartCom certs?
>>
>> I hope that an appropriate policy will force authorities to reconsider
>> their revocation principle. I don't want to harm someone nor I want to
>> work off in any way.
>>
>> The key is that anybody should be able to shout out "don't trust me
>> anymore!" without a fee. Isn't that part of the trustchain idea?
>>
>> I read a few times that Chrome doesn't even check if a certificate is
>> revoked or not (at least not the default settings). That leads me to the
>> question: Is it mandatory for a CA in mozilla's truststore to have to
>> ability to revoke a certificate or is is only an optional feature
>> provided by some CAs?
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy



-- 
Website: http://hallambaker.com/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Rob Stradling]

The Mozilla CA Certificate Maintenance Policy (Version 2.2) [1] says 
(emphasis mine):


"CAs _must revoke_ Certificates that they have issued upon the 
occurrence of any of the following events:

...
  - the CA obtains _reasonable evidence_ that the subscriber’s private 
key (corresponding to the public key in the certificate) has been 
compromised or is _suspected of compromise_ (e.g. Debian weak keys)"


I think that's pretty clear!

The CABForum BRs go one step further, demanding that the CA revoke 
_within 24 hours_.


AFAICT, non-payment by the Subscriber does not release the CA from this 
obligation to revoke promptly.


Anyone disagree with my interpretation?


[1] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/


On 10/04/14 15:16, fhw...@gmail.com wrote:

This an interesting issue Kaspar and I appreciate you raising it. I also 
personally appreciate you framing it in terms of trust because that's really 
what is at issue here.

The whole idea of revocation is a gaping hole in the PKI landscape. The ability to say 
"don't trust me" is so poorly implemented throughout PKI as to be effectively 
non-existent.‎ If for some reason you need to revoke a cert, you should do so because 
it's the right thing to do, but the best you can hope for is that some anti-security 
person doesn't figure out a way to use it anyway.
‎
This means that theft and other compromises of private keys remain viable 
attack vectors for those who wish to do so (government sponsored organizations 
and otherwise).‎ Private keys and the certs that go with them could be usable 
well after when people think they become invalid.

This also means that ‎we should not be surprised to see an underground market appear that seeks to 
sell "revoked" certs. Given that "high value" internet destinations might have 
been impacted by the Heartbleed vulnerability this could definitely become a concern. Should such a 
place appear I would think StartCom - issued certs would easily be included for sale.
‎
This also means that all "pay to revoke" policies should be viewed as anti-security and 
we need to "strongly encourage" they be discontinued in short order. If a CA wishes to 
continue such policies I would question their trustworthiness.
‎
Further I think we are reaching the point where browsers have to refuse SSL 
connections when OCSP validation fails. I think it's getting harder to argue 
otherwise, but I'll let the Mozilla folks speak to that.


-  Original Message  -
From: Kaspar Janßen
Sent: Thursday, April 10, 2014 4:12 AM

On 10/04/14 10:08, Peter Eckersley wrote:

Kaspar, suppose that Mozilla followed your suggestion and removed
StartCom's root certificates from its trust store (or revoked them!). What
would the consequences of that decision be, for the large number of domains
that rely on StartCom certs?

I hope that an appropriate policy will force authorities to reconsider
their revocation principle. I don't want to harm someone nor I want to
work off in any way.

The key is that anybody should be able to shout out "don't trust me
anymore!" without a fee. Isn't that part of the trustchain idea?

I read a few times that Chrome doesn't even check if a certificate is
revoked or not (at least not the default settings). That leads me to the
question: Is it mandatory for a CA in mozilla's truststore to have to
ability to revoke a certificate or is is only an optional feature
provided by some CAs?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy



--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[fhw843]

This an interesting issue Kaspar and I appreciate you raising it. I also 
personally appreciate you framing it in terms of trust because that's really 
what is at issue here. 

The whole idea of revocation is a gaping hole in the PKI landscape. The ability 
to say "don't trust me" is so poorly implemented throughout PKI as to be 
effectively non-existent.‎ If for some reason you need to revoke a cert, you 
should do so because it's the right thing to do, but the best you can hope for 
is that some anti-security person doesn't figure out a way to use it anyway. 
‎
This means that theft and other compromises of private keys remain viable 
attack vectors for those who wish to do so (government sponsored organizations 
and otherwise).‎ Private keys and the certs that go with them could be usable 
well after when people think they become invalid. 

This also means that ‎we should not be surprised to see an underground market 
appear that seeks to sell "revoked" certs. Given that "high value" internet 
destinations might have been impacted by the Heartbleed vulnerability this 
could definitely become a concern. Should such a place appear I would think 
StartCom - issued certs would easily be included for sale.
‎
This also means that all "pay to revoke" policies should be viewed as 
anti-security and we need to "strongly encourage" they be discontinued in short 
order. If a CA wishes to continue such policies I would question their 
trustworthiness. 
‎
Further I think we are reaching the point where browsers have to refuse SSL 
connections when OCSP validation fails. I think it's getting harder to argue 
otherwise, but I'll let the Mozilla folks speak to that.


-  Original Message  -
From: Kaspar Janßen
Sent: Thursday, April 10, 2014 4:12 AM

On 10/04/14 10:08, Peter Eckersley wrote:
> Kaspar, suppose that Mozilla followed your suggestion and removed
> StartCom's root certificates from its trust store (or revoked them!). What
> would the consequences of that decision be, for the large number of domains
> that rely on StartCom certs?
I hope that an appropriate policy will force authorities to reconsider
their revocation principle. I don't want to harm someone nor I want to
work off in any way.

The key is that anybody should be able to shout out "don't trust me
anymore!" without a fee. Isn't that part of the trustchain idea?

I read a few times that Chrome doesn't even check if a certificate is
revoked or not (at least not the default settings). That leads me to the
question: Is it mandatory for a CA in mozilla's truststore to have to
ability to revoke a certificate or is is only an optional feature
provided by some CAs?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Walter Goulet]

On Thursday, April 10, 2014 4:10:58 AM UTC-5, Kaspar Janßen wrote:
> On 10/04/14 10:08, Peter Eckersley wrote:
> 
> > Kaspar, suppose that Mozilla followed your suggestion and removed
> 
> > StartCom's root certificates from its trust store (or revoked them!). What
> 
> > would the consequences of that decision be, for the large number of domains
> 
> > that rely on StartCom certs?
> 
> I hope that an appropriate policy will force authorities to reconsider
> 
> their revocation principle. I don't want to harm someone nor I want to
> 
> work off in any way.
> 
> 
> 
> The key is that anybody should be able to shout out "don't trust me
> 
> anymore!" without a fee. Isn't that part of the trustchain idea?
> 
> 
> 
> I read a few times that Chrome doesn't even check if a certificate is
> 
> revoked or not (at least not the default settings). That leads me to the
> 
> question: Is it mandatory for a CA in mozilla's truststore to have to
> 
> ability to revoke a certificate or is is only an optional feature
> 
> provided by some CAs?
> 
> 
> 
> 
> 
> Kaspar

Hi Kaspar,

Your message is very timely; I have a domain I own using a StartSSL Class 1 
certificate that I was planning on requesting revocation for due to Heartbleed. 
I had no idea that I had to pay for revocation either; in my mind this changes 
the entire value proposition of their offering. I personally have not yet 
decided if I will indeed revoke, but I will be dropping a line to them to 
inform them that this 'revocation fee' should clearly be stated on their 
website and that their 'free' Class 1 certificate is not actually free if you 
need to pay for security controls like revocation!

Walter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Kaspar Janßen]

On 10/04/14 10:08, Peter Eckersley wrote:
> Kaspar, suppose that Mozilla followed your suggestion and removed
> StartCom's root certificates from its trust store (or revoked them!). What
> would the consequences of that decision be, for the large number of domains
> that rely on StartCom certs?
I hope that an appropriate policy will force authorities to reconsider
their revocation principle. I don't want to harm someone nor I want to
work off in any way.

The key is that anybody should be able to shout out "don't trust me
anymore!" without a fee. Isn't that part of the trustchain idea?

I read a few times that Chrome doesn't even check if a certificate is
revoked or not (at least not the default settings). That leads me to the
question: Is it mandatory for a CA in mozilla's truststore to have to
ability to revoke a certificate or is is only an optional feature
provided by some CAs?


Kaspar
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Revocation Policy

[Peter Eckersley]

Kaspar, suppose that Mozilla followed your suggestion and removed
StartCom's root certificates from its trust store (or revoked them!). What
would the consequences of that decision be, for the large number of domains
that rely on StartCom certs?


On 10 April 2014 00:46, Kaspar Janßen  wrote:

> Hi,
>
> initially i filled a bugreport [1] about the consequences of
> CVE-2014-0160 but this seems to be a better place for a discussion.
> There were still a discussion about the problem which may be interesing.
>
> To give a short introduction: StartCom is offering free Class 1
> certificates under the label StartSSL. The certification is completly
> free of charge but the revocation costs 25 USD.
>
> The Problem: I don't think that this is much money but I think this will
> prevent many people from renewing their keys which should be considered
> as compromised.
>
> They are, maybe not intentionally, throwing people in the pool but they
> don't check if they can swim. Customers of other companies were faced to
> the decision if they would like and can spend money for TLS. But due to
> the free certification, people tend to create dedicated keys for every
> service. That is good for the encryption side but bad if these people
> know have to pay ~10 * 25 USD.
>
> As a result of that, the most people just will not change their keys.
> That makes me question if a certificate signed by StartCom can be
> considered as trustworthy.
>
> I confrontated StartCom with my doubs and pleased them to find a way to
> solve this hurdle. They wrote me: "This will not happen without changing
> the entire business model".
>
> In germany, this _could_ be considered as fraud but they don't comply to
> european law anyway.
>
> The Consequence: I would like to start a discussion about that and the
> reactions. My Idea is that there should be a general policy that says
> that a revocation can't cost more that the creation or something like that.
>
> If someone pays 100 USD for certification, he consideres to pay 100 USD
> for revocation. If someone doesn't pay for certification, he will
> hesitate to pay even 1 USD for revocation.
>
>
> Yours sincerely,
>
> Kaspar Janßen
>
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=994033
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Revocation Policy

[Kaspar Janßen]

Hi,

initially i filled a bugreport [1] about the consequences of
CVE-2014-0160 but this seems to be a better place for a discussion.
There were still a discussion about the problem which may be interesing.

To give a short introduction: StartCom is offering free Class 1
certificates under the label StartSSL. The certification is completly
free of charge but the revocation costs 25 USD.

The Problem: I don't think that this is much money but I think this will
prevent many people from renewing their keys which should be considered
as compromised.

They are, maybe not intentionally, throwing people in the pool but they
don't check if they can swim. Customers of other companies were faced to
the decision if they would like and can spend money for TLS. But due to
the free certification, people tend to create dedicated keys for every
service. That is good for the encryption side but bad if these people
know have to pay ~10 * 25 USD.

As a result of that, the most people just will not change their keys.
That makes me question if a certificate signed by StartCom can be
considered as trustworthy.

I confrontated StartCom with my doubs and pleased them to find a way to
solve this hurdle. They wrote me: "This will not happen without changing
the entire business model".

In germany, this _could_ be considered as fraud but they don't comply to
european law anyway.

The Consequence: I would like to start a discussion about that and the
reactions. My Idea is that there should be a general policy that says
that a revocation can't cost more that the creation or something like that.

If someone pays 100 USD for certification, he consideres to pay 100 USD
for revocation. If someone doesn't pay for certification, he will
hesitate to pay even 1 USD for revocation.


Yours sincerely,

Kaspar Janßen

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=994033

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy