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 by limiting the forms of
proof we accept to a set on which our staff have trained.
In the absence of an explicit limitation in our CPS as to the forms of proof we
can accept our staff tried their best to respond and escalated it internally
for action. The certificate https://crt.sh/?id=2081585376 has been revoked.
I will include all of these details in the incident report which is in
preparation.
Regards
Robin Alden
Sectigo Limited
> -Original Message-
> From: dev-security-policy
> On Behalf Of sandybar497--- via dev-security-policy
> Sent: 07 May 2020 03:27
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Sectigo: Failure to revoke certificate with compromised key
>
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> On Wednesday, May 6, 2020 at 5:50:09 AM UTC+10, Ryan Sleevi wrote:
> > On Tue, May 5, 2020 at 12:35 PM sandybar497--- via dev-security-policy
> > wrote:
> > >
> > > I submitted a compromised key report to Sectigo
> [ssl_ab...@sectigo.com] on 1 May 2020 at 2:03pm UTC but Sectigo failed to
> revoke the certificate per cab-forum guidelines [4.9.1.1. Reasons for
> Revoking a Subscriber Certificate].
> > >
> > > Upon submitting my report [case ref: _00D1N2Ljih._5003l11VztU], I
> received an automated response at 1 May 2020 at 2:03pm UTC and the first
> human response came 4 hours later on 1 May 2020 at 6:24pm UTC with what I
> believe was an incorrect assessment and failure to carefully review the
> evidence provided. The impacted certificate as of writing this post is still
> not
> revoked.
> > >
> > > The certificate in question: https://crt.sh/?id=2081585376
> > >
> > > A CSR signed by the original private key was provided with the following
> subject details as evidence of possession:
> > > CN = The key that signed this CSR has been publicly disclosed.
> > > O = Compromised Key
> > >
> > > The response I received from Sectigo failed to demonstrate competency
> to deal with report and instead made references to the commonName
> attribute as being a problem, however without providing any form of
> explanation as to what is wrong with it? Additionally, Sectigo referred to
> pwnedkeys as some sort of authority that they say it’s not compromised.
> However, I suspect what Sectigo staff really meant is they were unable to
> find the spki sha256 fingerprint against pwnedkeys database but I don’t see
> how that means anything or why they are checking pwnedkeys when the
> evidence was attached along with the report. 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.
> > >
> > > I have sent further emails to Sectigo over 24 hours ago requesting their
> decision to be carefully reviewed and have still not received a reply. I
> suspect
> my case was closed and response went into a blackhole.
> > >
> > > I would like to request Sectigo to again review this matter, revoke the
> certificate and provide an incident report.
> >
> > Thanks for sharing this. Could I ask you to post the CSR and/or
> > evidence you shared somewhere?
> >
> > Mostly to help confirm that indeed, Sectigo did make the wrong call,
> > and that this is an incident :) I was in the process of writing up the
> > Bugzilla bug and realized it probably makes sense to do a little due
> > diligence myself. Sectigo is expected to be watching this mailing list
> > and can also respond (and open the Bugzilla incident). I just didn't
> > recognize your e-mail / past posts, and so wanted to at least confirm
> > before making noise :)
>
> In the latest reply from Sectigo I am advised "The CSR provided looks dummy
> and it is not used in the above issued certificate.". Although Sectigo
> continues to disagree with the evidence provided they did not provide me
> with specific directions as to what proof they would consider but according to
> their reply it would seem a copy of the original CSR would suffice. This is a
> deeply concerning response from Sectigo.
>
> Here is a copy of the CSR as provided to Sectigo
>
> -BEGIN CERTIFICATE REQUEST-
> MIICozCCAYsCAQAwXjEYMBYGA1UECgwPQ29tcHJvbWlzZWQgS2V5MUIwQA
> YDVQQD
> DDlUaGUga2V5IHRoYXQgc2lnbmVkIHRoaXMgQ1NSIGhhcyBiZWVuIHB1Ymxp
> Y2x5
> IGRpc2Nsb3NlZC4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD
> L7fFo
> EIq/60Ai9XO9pYiUQc7vFnpNKjlSeRyjljddtaZhVH3GAewEQUbihrLhNvFMX4rI
> kuGIpNPoBLb9bjrzVWm0pLkCjpF2oJVlHhlFJDDT6iELf7BlSz7EJEJUjdRGAYGv
> LsrLYURi2zqMjgJkbuRC3LmkwGl6/tnMlibQotpSnEcyosLA8ySk0k6raUxnbEyD
>
