On 14/07/2017 21:04, Ryan Sleevi wrote:
On Fri, Jul 14, 2017 at 2:07 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
That's my point. The current situation is distinct from weak keys, and
we shouldn't sacrifice the weak keys BR to make room for a
On Fri, Jul 14, 2017 at 2:07 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> That's my point. The current situation is distinct from weak keys, and
> we shouldn't sacrifice the weak keys BR to make room for a compromised
> keys BR.
But a weak key is
On 14/07/2017 18:19, Ryan Sleevi wrote:
On Fri, Jul 14, 2017 at 11:11 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 14/07/2017 15:53, Ryan Sleevi wrote:
On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy <
On Fri, Jul 14, 2017 at 11:11 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 14/07/2017 15:53, Ryan Sleevi wrote:
>
>> On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>>
>>> But
On 14/07/2017 16:07, Alex Gaynor wrote:
On Fri, Jul 14, 2017 at 10:03 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
...
>> ...
On 14/07/2017 15:53, Ryan Sleevi wrote:
On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
But that doesn't clearly include keys that are weak for other reasons,
such as a 512 bit RSA key with an exponent of 4 (as an extreme
On Fri, Jul 14, 2017 at 10:03 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > So there are several questions and possible
On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> So there are several questions and possible situations here.
>
> I think it's relatively clear that a CA could prevent reissuance of
> certs if they know about a key compromise.
On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> But that doesn't clearly include keys that are weak for other reasons,
> such as a 512 bit RSA key with an exponent of 4 (as an extreme example).
>
Yes. Because that's clearly
On Wed, 12 Jul 2017 10:47:51 -0400
Ryan Sleevi wrote:
> One challenge to consider is how this is quantified. Obviously, if you
> reported to Comodo the issue with the key, and then they issued
> another certificate with that key, arguably that's something Comodo
> should have
On 12/07/2017 16:47, Ryan Sleevi wrote:
On Wed, Jul 12, 2017 at 10:19 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
* Comodo re-issued certs with the same key. I wonder if there should be
a rule that once a key compromise event is known to the CA it
On Thu, Jul 13, 2017 at 7:07 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 12/07/17 15:47, Ryan Sleevi wrote:
> > One challenge to consider is how this is quantified. Obviously, if you
> > reported to Comodo the issue with the key, and then they
On 12/07/17 15:47, Ryan Sleevi wrote:
> One challenge to consider is how this is quantified. Obviously, if you
> reported to Comodo the issue with the key, and then they issued another
> certificate with that key, arguably that's something Comodo should have
> caught.
I'd say so.
> However, if
Hello,
I recently did an investigation where I tried to simply download private
keys from web servers with common filenames. I collected these
filenames simply from common tutorials on the web (server.key,
privatekey.key, myserver.key, key.pem and [hostname].key with and
without www).
In several
14 matches
Mail list logo