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: Audit Reminders for Intermediate Certs
Forwarded Message Subject: Summary of May 2020 Outdated Audit Statements for Intermediate Certs Date: Tue, 5 May 2020 14:00:08 + (GMT) CA Owner: SECOM Trust Systems CO., LTD. - Certificate Name: SECOM Passport for Web MH CA SHA-256 Fingerprint: 4E62A252592F9D71FFE2037757F855D4A0235D6638BD105E9EF17086CE2BBC25 Standard Audit Period End Date (mm/dd/): 01/29/2019 BR Audit Period End Date (mm/dd/): 01/29/2019 - Certificate Name: FujiSSL Public Validation Authority - G3 SHA-256 Fingerprint: 56DA6EFEF1D504134C72EEDC3AE44AA7FA11B848820DBFAA86CA8E35D60EDB04 Standard Audit Period End Date (mm/dd/): 01/29/2019 BR Audit Period End Date (mm/dd/): 01/29/2019 - Certificate Name: CrossTrust DV CA5 SHA-256 Fingerprint: 18F4368FE93B3CAE025230BCE7EAD340FD90FB27F9A10E36FEE89FC454F22788 Standard Audit Period End Date (mm/dd/): 01/29/2019 BR Audit Period End Date (mm/dd/): 01/29/2019 - Certificate Name: CrossTrust OV CA5 SHA-256 Fingerprint: 79C4091B05B15C1683128B7A355E0AAD62E1BBBC3E5F3735370C06CC4D1AFB44 Standard Audit Period End Date (mm/dd/): 01/29/2019 BR Audit Period End Date (mm/dd/): 01/29/2019 - Certificate Name: EINS/PKI Public Certification Authority V4 SHA-256 Fingerprint: 38B26CF45C932EA28019D93E440AC72BAE83F9CBF52D6AD913698B18FCC8717D Standard Audit Period End Date (mm/dd/): 01/29/2019 BR Audit Period End Date (mm/dd/): 01/29/2019 - Certificate Name: KDDI Web Communications Certification Authority 3 SHA-256 Fingerprint: 2B30D5E912906358C9AD6FB57FD7B368A01A78E395B4EC11645C5B98A0967DE8 Standard Audit Period End Date (mm/dd/): 01/29/2019 BR Audit Period End Date (mm/dd/): 01/29/2019 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT May 2020 CA Communication/Survey
On 5/4/20 9:31 AM, Corey Bonnell wrote: Thank you very much for the clarifications. If I'm understanding correctly, it sounds like Mozilla is considering to add sub-items of item 4 on the survey as Mozilla Root Program requirements if the associated CAB Forum ballot does not pass. However, there is concern that many CAs may not be compliant with these requirements, so the purpose of the survey is to gauge potential impact to CAs so that effective dates can be set such that CAs can react appropriately as well as to gather data to better inform Mozilla's position in the CAB Forum. Is that a correct assessment of the purpose of question 4? Correct. I created the issues in Github so these items get considered for Mozilla's policy in one form or other (direct, through BRs, or both). Here is a breakdown of my perspective of the Browser Alignment Ballot (https://github.com/sleevi/cabforum-docs/pull/10) specifically in regards to Mozilla’s Root Store Policy. Audit Reporting - CAs should already be following all but one of the additions, because they are already part of section 3.1.4 of Mozilla’s Root Store Policy[1] and section 5.1 of the CCADB Policy[2]. - I filed https://github.com/mozilla/pkipolicy/issues/210 for the requirement that would be new to Mozilla policy: “CCADB Policy: Require audit statements to be text-searchable PDF” (SUB ITEM 4.3 in the May 2020 CA Communication/Survey.) OCSP - I filed https://github.com/mozilla/pkipolicy/issues/211 to consider updating section 6 of Mozilla’s Root Store Policy: “Require OCSP and Reduce OCSP response max validity from 10 days to 7 days” (SUB ITEM 4.4 in the May 2020 CA Communication/Survey.) - Mozilla may propose in the CABF that the other three items in this section be removed from the ballot (fresh OCSP responses at one-half of validity interval, must contain revocationReason, must not contain a reasonCode singleExtension). CRLs - Mozilla may propose in the CABF that these changes be removed from the ballot (reasonCode requirements for intermediate cert revocations). I don't see a reason for Mozilla to require this or enforce such a rule. Certificate Policies - I filed https://github.com/mozilla/pkipolicy/issues/212 to consider updating Mozilla’s Root Store Policy if this doesn’t get added to the BRs: “Require at least one CABF defined-policy OID in certificatePolicies extension for TLS certs” (SUB ITEM 4.1 in the May 2020 CA Communication/Survey.) Authority Key ID - CAs should already be following this item because it is already part of RFC 5280 and section 5.2 of Mozilla’s Root Store Policy. (RFC 5280: authorityKeyIdentifier MUST be present and MUST contain a keyIdentifier, Mozilla Policy: “CAs MUST NOT issue certificates that have … authority key IDs that include both the key ID and the issuer’s issuer name and serial number”) Extended Key Usage - CAs should already be following this item because it is already part of section 5.3 of Mozilla’s Root Store Policy. Name Encoding Rules - I filed https://github.com/mozilla/pkipolicy/issues/213 to consider updating Mozilla’s Root Store Policy even if this does get added to the BRs: “Require Byte-for-byte Identical Issuer and Subject Distinguished Names” (SUB ITEM 4.2 in the May 2020 CA Communication/Survey.) CP/CPS - CAs should already be following this item because it is already in section 3.3 of Mozilla’s Root Store Policy. Key Algorithms and Sizes - CAs should already be following this item because it is already in section 5 of Mozilla’s Root Store Policy. Signature Algorithms - These clarifications were added to section 5 of Mozilla’s Root Store Policy in version 2.7, with an effective date of January 1, 2020. Certificate Lifetimes - https://github.com/mozilla/pkipolicy/issues/204 (ITEM 3 in the May 2020 CA Communication/Survey.) Clarify Effective Dates - This is a clarification that seems reasonable, and does not require action. Thanks, Kathleen [1] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy [2] https://www.ccadb.org/policy ___ 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
