Thank you very much for your continued disclosure.
We (Sectigo) are working on a CPS revision which will clarify the forms of
proof of compromise that we accept.
Our customer service staff have to respond to compromise notifications quickly
and accurately and we are best able to achieve that
> > The necessary evidence was provided to Sectigo and they have thus far
> > failed to deal with the evidence or clearly articulate reasons for
> > concluding this case to not be a compromise.
>
> What I've found works best when reporting these cases to m.d.s.p is to
> provide all the
> .. There’s plenty of precedent in having Root Policy or the
> Baseline Requirements require a CP/CPS explicitly state something;
> examples such as the CAA domain name, the problem reporting mechanism
> and contact address, and compliance to the latest version of the BRs.
>
> If we apply that
> -Original Message-
> From: Kurt Roeckx via dev-security-policy
> Sent: 01 November 2019 10:15
> To: Matthias van de Meent
> Cc: MDSP
> Subject: Re: Certificate OU= fields with missing O= field
>
> On Fri, Nov 01, 2019 at 11:08:23AM +0100, Matthias van de Meent via dev-
>
> The aforementioned comments, however, indicate CAs have reported that
> Microsoft does [require the EKU chaining].
I agree that statement is true, but I think it inadvertently misleads.
We cannot speak for Microsoft about what their requirements for
id-kp-OCSPSigning are, and we are not aware
Nick, Ángel,
Sectigo is not affected by this incident.
https://sectigo.com/blog/attention-journalists-and-researchers-dont-confuse-comodo-with-sectigo
Regards
Robin Alden
Sectigo Limited
> -Original Message-
> From: Nick Lamb via dev-security-policy
> Sent: 27 July 2019 23:42
>
Wayne, Mattias,
We have a post-rebrand CPS which is almost ready to publish and has
a new Certificate Profiles section.
To the OP's first question, we continue to accept (amongst others)
comodo.com and comodoca.com as Issuer Domain Names in CAA records that
authorize us to issue.
RFC6844
I understand the OP's concern and will respond to the bug shortly.
Regards
Robin Alden
Comodo CA Ltd.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Hi Hanno,
The certificate has been revoked.
We're in the process of migrating our email addresses to all be on comodoca.com
and the emails for ssl_abuse@ got directed away from the monitored queue we
have in place for it. We didn't notice it straight away because there are some
other
This same information has also been posted to
https://bugzilla.mozilla.org/show_bug.cgi?id=1461391
Andrew Ayer reported this problem report to mailto:sslab...@comodoca.com:
<<<
I was able to obtain a certificate from Comodo that was not properly
validated under the Baseline Requirements, as
Hi Kathleen,
Comodo issued a number of certificates to .tg domains during the
period of interest.
We see a history of applications for .gouv.tg certificates which
we had been previously been rejecting and suddenly in the period of interest
we issued them - which might support the notion
Peter,
As you noted in your post to the cryptography list, Francisco
Partners' website states that they exited from their investment in Blue
Coat.
https://www.franciscopartners.com/investments/blue-coat?sector=Comms-Securit
y=1200
Regards
Robin Alden
Comodo
> -Original Message-
>
> -Original Message-
> From: Gerv
> Subject: Re: Francisco Partners acquires Comodo certificate authority
business
>
> On 31/10/17 13:21, Kyle Hamilton wrote:
> > http://www.eweek.com/security/francisco-partners-acquires-comodo-s-
> certificate-authority-business
>
> Comodo notified
13 matches
Mail list logo
