Re: Does Heartbleed count for the purposes of BR 4.9.1.1 point 11? ("proven or demonstrated method")
在 2019年5月27日星期一 UTC+8上午10:05:25,Matt Palmer写道: > On Sun, May 26, 2019 at 06:57:08PM -0700, Han Yuwei via dev-security-policy > wrote: > > If malloc() is correctly implemented, private keys are secure from > > Heartbleed. So > > I think it doesn't meet the criteria. > > Just to make sure I'm understanding you correctly, you're saying that being > vulnerable to Heartbleed doesn't *necessarily* expose private keys, it > requires an additional criteria (malloc being "incorrectly implemented"), > thus it doesn't fit the definition of a "proven method that exposes the > Subscriber's Private Key to compromise"? > > > CAs can't revoke a certificate without noticing subscriber in advance. > > Can you point me to where that requirement comes from? Some CAs don't > necessarily have *any* notification method for their subscribers (Let's > Encrypt immediately comes to mind); does that mean they're immune from > revocation requirements? Is there any requirement around how quickly CAs > are required to notify subscribers, and does that time come out of the 24 > hour / 5 day budget, or is it some additional time period? > > > But if any bugs found in future which can retrieve private keys from TLS > > endpoints, > > you can just use automated tools to scan them and get private keys to > > request a > > revoke. I thought this is the best practice to this BR. > > OK, so that's one vote for "just scan the Internet and drop private keys on > CAs for revocation within 24 hours". > > - Matt 1. Yes, it doesn't fit ( for what I thought) 2. I missed some words. please add "without proven fact that the certificate is not secure" I thought what Matt says is not about charge, it is about potential policy to further mass private key compromising. I don't think this have anything to do with StartCom. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Does Heartbleed count for the purposes of BR 4.9.11 point 11? ("proven or demonstrated method")
If malloc() is correctly implemented, private keys are secure from Heartbleed. So I think it doesn't meet the criteria. CAs can't revoke a certificate without noticing subscriber in advance. But if any bugs found in future which can retrieve private keys from TLS endpoints, you can just use automated tools to scan them and get private keys to request a revoke. I thought this is the best practice to this BR. 在 2019年5月27日星期一 UTC+8上午9:34:31,Matt Palmer写道: > Hi everyone, > > In pondering ways of getting yet more keys for pwnedkeys.com, my mind turned > to everyone's favourite bug, Heartbleed. Whilst hitting all the vulnerable > servers and pulling their keys is eminently possible (see, as just one > example, https://github.com/robertdavidgraham/heartleech), I recalled that > CAs are responsible for revoking certificates within 5 days (with a "SHOULD" > of 24 hours) when: > > > The CA is made aware of a demonstrated or proven method that exposes the > > Subscriber's Private Key to compromise, methods have been developed that > > can easily calculate it based on the Public Key (such as a Debian weak > > key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence > > that the specific method used to generate the Private Key was flawed > > (Taken from BRs v1.6.3, because that's what I happened to have handy) > > That sounds an *awful* lot like Heartbleed: "a [...] proven method that > exposes the Subscriber's Private Key to compromise". > > Several questions arise from this, which I'd like to get the opinion of the > members of this illustrious debating society: > > 1. Do others agree that Heartbleed appears to meet the criteria of this >paragraph in the BRs? > > 2. Assuming "yes" to the above question, is it (still) reasonable to require >CAs to revoke certificates within 5 days if notified that a certificate >they issued is being served from an endpoint vulnerable to Heartbleed? > > 3. Assuming "yes" to the above questions, should I stand up a tool to watch >certificates coming out of CT logs, identify endpoints serving those >certificates, test them for Heartbleed, and report these facts to CAs for >appropriate handling? > > Of course, if it's deemed that Heartbleed *isn't* "a proven method etc etc", > the keys could just be pulled directly, which I'm led to believe typically > takes a lot less than four days (and which would trigger the > 24-hour-required revocation), but it seems to me "politer" to everyone to > use the less intrusive option. > > Additional comments surrounding this issue, not pertaining specifically to > the above three questions, would also be gladly received. > > - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAA record checking issue
This raised a question: How can CA prove they have done CAA checks or not at the time of issue? 在 2019年5月10日星期五 UTC+8上午10:05:36,Jeremy Rowley写道: > FYI, we posted this today: > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1550645 > > > > Basically we discovered an issue with our CAA record checking system. If the > system timed out, we would treat the failure as a DNS failure instead of an > internal failure. Per the BRs Section 3.2.2: > > "CAs are permitted to treat a record lookup failure as permission to issue > if: > > . the failure is outside the CA's infrastructure; > > . the lookup has been retried at least once; and > > . the domain's zone does not have a DNSSEC validation chain to the ICANN > root" > > > > The failure was not outside our infrastructure so issuance was improper. > > > > We checked all the applicable CAA records and found 16 where the CAA record > would not permit us to issue if we were issuing a new cert today. What we > are proposing is to revoke these certificates and reissue them (if they pass > all the proper checks). The rest would pass if we issued today so we were > going to leave these where they are while disclosing them to the Mozilla > community. > > > > Other suggestions are welcome. > > > > The issue was put into the code back when CAA record checking became > mandatory (Sept 2017). We generally have a peer review of our code so that > at least one other developer has looked at the system before release. In > this case, neither PM nor a second reviewer was involved in the development. > We've since implemented more stringent development processes, including > ensuring a PM reviews and brings questions about projects to the compliance > team. > > > > Anyway, let me know what questions, comments, etc you have. > > > > Thanks! > > Jeremy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Reported Digicert key compromise but not revoked
Thanks for that. So now I should send another email to rev...@digicert.com or just wait for revocation? And who should I contact if this address doesn't work? 在 2019年5月10日星期五 UTC+8上午8:26:09,Jeremy Rowley写道: > No argument from me there. We generally act on them no matter what. > Typically any email sent to supp...@digicert.com requesting revocation is > forwarded to rev...@digicert.com. That's the standard procedure. This one > was missed unfortunately. > > -Original Message- > From: dev-security-policy On > Behalf Of Daniel Marschall via dev-security-policy > Sent: Thursday, May 9, 2019 4:16 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: RE: Reported Digicert key compromise but not revoked > > I personally do think that it matters to this forum. A CA - no matter what > kind of certificates it issues - must take revocation requests seriously and > act immediately, even if the email is sent to the wrong address. If an > employee at the help desk is unable to forward revocation requests, or needs > several weeks to reply, then there is something not correct with the CA, no > matter if the revocation request is related to a web certificate or code > signing certificate. That's my opinion on this case. > ___ > 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
Reported Digicert key compromise but not revoked
Hi m.d.s.p I have reported a key compromise incident to digicert by contacting support(at)digicert.com at Apr.13, 2019 and get replied at same day. But it seems like this certificate is still valid. This certificate is a code signing certificate and known for signing malware. So I am here to report this to Digicert. If private key is needed I will attach it. Certificate Info. CN:Beijing Founder Apabi Technology Limited SN: 06B7AA2C37C0876CCB0378D895D71041 SHA1: 8564928AA4FBC4BBECF65B402503B2BE3DC60D4D ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Found something I can't understand in these cerificates.
https://crt.sh/?id=7040227 https://crt.sh/?id=30328289 I am confused for those reasons. 1. the CN of two cerificates are same. So it is not necessary to issue two certificates in just 2 minutes. 2. second one used SHA1, though is consistent with BR, but first one used SHA256. 3. first one has 39 month period of validity which is very rare. 4. Since they are issued so close they should be logged at CT same time but second one are too late. So is there some common parctice I don't know or another mistake made by Wosign? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Find a 5-year certificate
I have found this: https://crt.sh/?id=6885329 I don't know whether Mozilla had allowed the certificate valid more than 39 months, so I am here to verify it. I have searched on Github but found nothing. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods
A question:How would a domain holder express denial for certain certificate requests? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Symantec: Draft Proposal
So Mozilla think Symantec's issues are on t serious enough to lose trust entirely? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy