RE: Sectigo: Failure to revoke certificate with compromised key
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- > MIICozCCAYsCAQAwXjEYMBYGA1UEC
Re: Sectigo: Failure to revoke certificate with compromised key
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- MIICozCCAYsCAQAwXjEYMBYGA1UECgwPQ29tcHJvbWlzZWQgS2V5MUIwQAYDVQQD DDlUaGUga2V5IHRoYXQgc2lnbmVkIHRoaXMgQ1NSIGhhcyBiZWVuIHB1YmxpY2x5 IGRpc2Nsb3NlZC4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDL7fFo EIq/60Ai9XO9pYiUQc7vFnpNKjlSeRyjljddtaZhVH3GAewEQUbihrLhNvFMX4rI kuGIpNPoBLb9bjrzVWm0pLkCjpF2oJVlHhlFJDDT6iELf7BlSz7EJEJUjdRGAYGv LsrLYURi2zqMjgJkbuRC3LmkwGl6/tnMlibQotpSnEcyosLA8ySk0k6raUxnbEyD tH76OvPs/L+HB5YMjJ6J7r8FZpidlLPyl0UcwMdkL2WDLyIgjGGOdTRKnk/HdQ+b p9Xw7XMIdx5FxFG5xkyvA7iAblYZUpwnFp0AzohIjj9FuDZBitruxSekoB1Yuuyi EUTjiD0GwRChCe3DAgMBAAGgADANBgkqhkiG9w0BAQsFAAOCAQEAD259nk0geb+C 5VZXz0Q0e1zvcEnLavRkF8L9LX3UOOduFQVaQyIPWc2Ae+VRzc7l67Y75BL82sDs qCeQmcuWmq3j1AhkHDeV2ihCoo+qDgJbyg7J4YKVFuV/M07MB3BPEbQfeBkUKVQ+ SbpWyxD33Q+fKdALn8DqRBDkg+lEr2wN7ERqtbKsWMScR4CNkIv7UenzfnA/PuKg boW4yeYbvizVy/dXcqZ6PXqvtUkIoHH/1w2sx3xYFz6EKcOJOa3rWF6oCt6gmSNy 4OAdTEdpsVfuuGJnGdMGXKIIsIaZeG4Hat2EJOZVCT511GDJm4k3JgIzEmvd8v4i VHizlMtMGg== -END CERTIFICATE REQUEST- ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Sectigo: Failure to revoke certificate with compromised key
> > 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 (substantive) correspondence, exactly as it was > sent/received, along with UTC timestamps. That allows for independent > assessment that Sectigo has, in fact, fallen down on the job, rather than it > being possible that there's just a big ol' misunderstanding going on. > Here's an example of the sort of thing I mean: > > https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/wtM7 > uX1stIA > > - Matt I can see the report in to our problem reporting mailbox (sslab...@sectigo.com) and the ticket on our side. I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1635840 and I will follow up with an incident report in that bug. Regards Robin Alden Sectigo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sectigo: Failure to revoke certificate with compromised key
On Mon, May 04, 2020 at 08:45:34AM -0700, sandybar497--- via dev-security-policy wrote: > Additionally, Sectigo referred to pwnedkeys as > some sort of authority that they say it’s not compromised. Bless their little cotton socks, pwnedkeys is now such an authority that Sectigo thinks I've got every compromised key in existence. I feel so validated. > 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 (substantive) correspondence, exactly as it was sent/received, along with UTC timestamps. That allows for independent assessment that Sectigo has, in fact, fallen down on the job, rather than it being possible that there's just a big ol' misunderstanding going on. Here's an example of the sort of thing I mean: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/wtM7uX1stIA - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sectigo: Failure to revoke certificate with compromised key
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 :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Sectigo: Failure to revoke certificate with compromised key
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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
