Re: Revocation Policy

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

Re: Revocation Policy

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

Re: Revocation Policy

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 cer

Re: Revocation Policy

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

Re: Revocation Policy

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

Re: Revocation Policy

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 busines

Re: Revocation Policy

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,

Re: Revocation Policy

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

Re: Revocation Policy

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

Re: Revocation Policy

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 Polic

Re: Revocation Policy

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 ho

Re: Revocation Policy

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 conf

Re: Revocation Policy

-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

Re: Revocation Policy

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 (conf

Re: Revocation Policy

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:

Re: Revocation Policy

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

Re: Revocation Policy

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

Re: Revocation Policy

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 general

Re: Revocation Policy

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 w

Re: Revocation Policy

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 ar

Re: Revocation Policy

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 >

Re: Revocation Policy

ed, 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 certific

Re: Revocation Policy

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 shoul

Re: Revocation Policy

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,

Re: Revocation Policy

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 ho

Re: Revocation Policy

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 ac

Re: Revocation Policy

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.

Re: Revocation Policy

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 bu

Re: Revocation Policy

-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

Re: Revocation Policy

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 rat

Re: Revocation Policy

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

Re: Revocation Policy

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

Re: Revocation Policy

-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

Re: Revocation Policy

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

Re: Revocation Policy

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

Re: Revocation Policy

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

Re: Revocation Policy

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

Re: Revocation Policy

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 ev

Re: Revocation Policy

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

Re: Revocation Policy

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:

Re: Revocation Policy

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

Re: Revocation Policy

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/

Re: Revocation Policy

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 d

Re: Revocation Policy

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 y

Re: Revocation Policy

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 val

Re: Revocation Policy

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

Re: Revocation Policy

ple 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 *strict

Re: Revocation Policy

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

Re: Revocation Policy

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

Re: Revocation Policy

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 stat

Re: Revocation Policy

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 c

Re: Revocation Policy

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 showin

Re: Revocation Policy

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

Re: Cloudflare heartbleed challenge, Re: Revocation Policy

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,

Re: Revocation Policy

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

Re: Revocation Policy

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 ar

Re: Revocation Policy

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 _r

Re: Cloudflare heartbleed challenge, Re: Revocation Policy

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 seem

Re: Revocation Policy

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 reasona

Re: Cloudflare heartbleed challenge, Re: Revocation Policy

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:

Re: Revocation Policy

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

RE: Cloudflare heartbleed challenge, Re: Revocation Policy

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

Re: Cloudflare heartbleed challenge, Re: Revocation Policy

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

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. And they tend to withhold compassion (or technical judgments).

Re: Cloudflare heartbleed challenge, Re: Revocation Policy

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 exi

Re: Cloudflare heartbleed challenge, Re: Revocation Policy

* 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 it

Cloudflare heartbleed challenge, Re: Revocation Policy

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 ser

Re: Revocation Policy

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

Re: Revocation Policy

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 ? __

Re: Revocation Policy

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 bee

Re: Revocation Policy

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? Rega

Re: Revocation Policy

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 admi

Re: Revocation Policy

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 bu

Re: Revocation Policy

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 _reas

Re: Revocation Policy

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 th

Re: Revocation Policy

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

Re: Revocation Policy

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

Re: Revocation Policy

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 contain

Re: Revocation Policy

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

Re: Revocation Policy

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

Re: Revocation Policy

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 ke

Re: Revocation Policy

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 obt

Re: Revocation Policy

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 c

Re: Revocation Policy

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

Re: Revocation Policy

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

Re: Bug#744027: Revocation Policy

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 wh

Re: Revocation Policy

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 thei

Re: Revocation Policy

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

Re: Revocation Policy

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

Re: Revocation Policy

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, 2

Re: Revocation Policy

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

Re: Revocation Policy

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 impl

Re: Revocation Policy

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

Re: Revocation Policy

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 h

Re: Revocation Policy

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

Revocation Policy

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 labe