Matt,
Our investigation reopened at March 9, 9:36 AM based on the information you
provided in this forum. We were able to research and run appropriate testing
which led to evidence of key compromise being determined March 9, 10:24 AM. We
continued our diligence in accordance with the Baseline
On Tue, Mar 10, 2020 at 05:53:13PM -0500, Matthew Hardeman via
dev-security-policy wrote:
> Isn't the evident answer, if reasonable compromise is not forthcoming, just
> to publish the compromised private key. There's no proof of a compromised
> private key quite as good as providing a copy of
Isn't the evident answer, if reasonable compromise is not forthcoming, just
to publish the compromised private key. There's no proof of a compromised
private key quite as good as providing a copy of it.
I understand the downsides, but I think that capricious burdens encourage
stripping the issue
For 0% of impact the FPs do not matter that much, so agreed!
Of course for now reality is not that... yet!
https://github.com/certbot/certbot/issues/1028 seems so appropriate :)
PS I was definitely not advocating for 5% false negative, no; we must
strive for 0% false negatives as well; all I
On Tue, Mar 10, 2020 at 05:18:51PM -0400, Ryan Sleevi via dev-security-policy
wrote:
> I'm sympathetic to CAs wanting to filter out the noise of shoddy reports
> and shenanigans, but I'm also highly suspicious of CAs that put too
> unreasonable an onus on reporters.
If CAs want a 100% reliable
On Tue, Mar 10, 2020 at 01:25:11PM -0700, bif via dev-security-policy wrote:
> Voluntarily providing CSR is not an ideal way to prove key compromise,
> because you could've simply found this CSR somewhere (I know, I know,
> super unlikely with your Subject... but still could happen.)
Feel free
On Tue, Mar 10, 2020 at 5:56 PM Piotr Kucharski wrote:
> I'm sympathetic to CAs wanting to filter out the noise of shoddy reports
>> and shenanigans, but I'm also highly suspicious of CAs that put too
>> unreasonable an onus on reporters. It seems, in the key compromise case,
>> the benefit of
On Tue, 10 Mar 2020 at 22:19, Ryan Sleevi wrote:
>
>
> On Tue, Mar 10, 2020 at 4:25 PM bif via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Matt,
>>
>> Voluntarily providing CSR is not an ideal way to prove key compromise,
>> because you could've simply found this
On Tuesday, March 10, 2020 at 1:25:21 PM UTC-7, bif wrote:
> Matt,
>
> Voluntarily providing CSR is not an ideal way to prove key compromise,
> because you could've simply found this CSR somewhere (I know, I know, super
> unlikely with your Subject... but still could happen.)
>
While a CSR
On Tue, Mar 10, 2020 at 4:25 PM bif via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Matt,
>
> Voluntarily providing CSR is not an ideal way to prove key compromise,
> because you could've simply found this CSR somewhere (I know, I know, super
> unlikely with your
Matt,
Voluntarily providing CSR is not an ideal way to prove key compromise, because
you could've simply found this CSR somewhere (I know, I know, super unlikely
with your Subject... but still could happen.)
And while "compromised" is way too short (one can sign up to 32 bytes using it
as a
Hi Joanna,
Thanks for responding. When can this list, or Bugzilla, expect GoDaddy's
incident report? Also, for the avoidance of further doubt, can you give an
exact timestamp at which GoDaddy considers that evidence of key compromise
was "obtained" for this certificate?
- Matt
On Mon, Mar 09,
Matt,
Thank you for sharing your experience with our problem reporting mechanism on
this forum. It is due to this that we were able to get to the root of the
issue. Here is some detail into what we saw.
Yesterday, we launched an investigation which included various members of the
team
Following a problem report sent to the CPS-specified address, evidence of
key compromise for a private key used in a certificate issued by GoDaddy has
not been revoked within the 24 hour timeframe required by the Baseline
Requirements s4.9.1.1.
Whilst GoDaddy did provide a response within 24
14 matches
Mail list logo
