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 <rob.stradl...@comodo.com> 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
