On Thu, May 9, 2019 at 8:56 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 10/05/2019 02:22, Wayne Thayer wrote:
> > Thank you for this response Francois. I have added it to the issues list
> > [1]. Because the response is not structures the same as the
On 10/05/2019 02:22, Wayne Thayer wrote:
Thank you for this response Francois. I have added it to the issues list
[1]. Because the response is not structures the same as the issues list, I
did not attempt to associate parts of the response with specific issues. I
added the complete response to
On 10/05/2019 05:25, Ryan Sleevi wrote:
On Thu, May 9, 2019 at 10:44 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 09/05/2019 16:35, Ryan Sleevi wrote:
Given that the remark is that such a desire is common, perhaps you can
provide some external
On Thu, May 9, 2019 at 10:44 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 09/05/2019 16:35, Ryan Sleevi wrote:
> > Given that the remark is that such a desire is common, perhaps you can
> > provide some external references documenting how one might go
On 09/05/2019 16:35, Ryan Sleevi wrote:
> On Wed, May 8, 2019 at 10:36 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> [ Note, I am arguing a neutral position on the specific proposal ]
>>
>> The common purpose of having an internally secured (managed
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
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
Thank you for this response Francois. I have added it to the issues list
[1]. Because the response is not structures the same as the issues list, I
did not attempt to associate parts of the response with specific issues. I
added the complete response to the bottom of the page.
On Thu, May 9, 2019
Thanks Wayne. We’ll update our CPS to keep it clear.
From: Wayne Thayer
Sent: Thursday, May 9, 2019 5:04 PM
To: Andrew Ayer
Cc: Jeremy Rowley ; Jeremy Rowley via
dev-security-policy
Subject: Re: Reported Digicert key compromise but not revoked
DigiCert CPS section 1.5.2 [1] could also
DigiCert CPS section 1.5.2 [1] could also more clearly state that
rev...@digicert.com is the correct address for 'reporting suspected Private
Key Compromise, Certificate misuse, or other types of fraud, compromise,
misuse, inappropriate conduct, or any other matter related to
Certificates.' Since
Thanks Andrew. Yes - it should be rev...@digicert.com
-Original Message-
From: Andrew Ayer
Sent: Thursday, May 9, 2019 4:46 PM
To: Jeremy Rowley
Cc: Jeremy Rowley via dev-security-policy
Subject: Re: Reported Digicert key compromise but not revoked
On Thu, 9 May 2019 14:47:05 +
On Thu, 9 May 2019 14:47:05 +
Jeremy Rowley via dev-security-policy
wrote:
> Hi Han - the proper alias is rev...@digicert.com. The support alias
> will sometimes handle these, but not always.
Is that also true of SSL certificates? supp...@digicert.com is listed
first at
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
On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer wrote:
> On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi wrote:
>
>> Thank you David and Ryan! This appears to me to be a reasonable
>> improvement to our policy.
>>
>
> Brian: could I ask you to review the proposed change?
>
>
>> This does not,
Le mardi 16 avril 2019 20:44:41 UTC+2, Wayne Thayer a écrit :
> Mozilla has decided that there is sufficient concern [1] about the
> activities and operations of the CA Certinomis to collect together a list
> of issues. That list can be found here:
> https://wiki.mozilla.org/CA/Certinomis_Issues
>
Hi Han - the proper alias is rev...@digicert.com. The support alias will
sometimes handle these, but not always. We picked up the request from your
post here and are working on it.
Of course, this is out of scope of the Mozilla policy since its code signing
only.
-Original Message-
On Thu, May 9, 2019 at 8:59 AM Han Yuwei via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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
On Wed, May 8, 2019 at 10:36 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> [ Note, I am arguing a neutral position on the specific proposal ]
>
> The common purpose of having an internally secured (managed or on-site)
> CA in a public hierarchy is to have
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
19 matches
Mail list logo
