Re: GRCA: Out-of-date CPS provided in CCADB
We have updated our CP and English website. Please see https://grca.nat.gov.tw/GRCAeng/index.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours
Do you have a copy of the OCSP response? With such issues, we may need signed artifacts to demonstrate non-compliance. For example, it shows as revoked via both OCSP and CRL for me. On Thu, May 14, 2020 at 4:32 PM sandybar497--- via dev-security-policy wrote: > > On 7 May 2020 at 12:07:07 PM UTC I reported a certificate to GoDaddy at > practi...@starfieldtech.com as having its private key compromised. > > I received the automated acknowledgement confirmation, however, as of > 2020-05-09 03:39:36 UTC (well after 24 hours), OCSP still shows the > certificate as being "Good" > > The unrevoked certificate is https://crt.sh/?id=2366734355 > > I believe this is a breach of the CA-BR [4.9.1.1. Reasons for Revoking a > Subscriber Certificate] - > > "The CA SHALL revoke a Certificate within 24 hours if one or more of the > following occurs""The CA obtains evidence that the Subscriber's Private > Key corresponding to the Public Key in the Certificate suffered a Key > Compromise" > > I would like to request GoDaddy revoke the certificate and provide an > incident report on this matter. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
ZLint 2.1.0-RC1 and announcement list
Hi all, Earlier this year, we began publishing semantically versioned ZLint releases based on several requests from CAs. Yesterday, we tagged 2.1.0-RC1 (https://github.com/zmap/zlint/releases/tag/v2.1.0-rc1), which includes the first batch of Mozilla Root Store Policy lints. We have created a new minimal-traffic announcement list, which is where we will be announcing releases and other major project updates in the future: https://groups.google.com/forum/#!forum/zlint-announcements. Thanks, Zakir ___ 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 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
GoDaddy: Failure to revoke certificate with compromised key within 24 hours
On 7 May 2020 at 12:07:07 PM UTC I reported a certificate to GoDaddy at practi...@starfieldtech.com as having its private key compromised. I received the automated acknowledgement confirmation, however, as of 2020-05-09 03:39:36 UTC (well after 24 hours), OCSP still shows the certificate as being "Good" The unrevoked certificate is https://crt.sh/?id=2366734355 I believe this is a breach of the CA-BR [4.9.1.1. Reasons for Revoking a Subscriber Certificate] - "The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs""The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise" I would like to request GoDaddy revoke the certificate and provide an incident report on this matter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: AIA CA Issuer field pointing to PEM encoded certs
Dear Hanno, Many thanks for the report. This has now been fixed for Multicert and an incident report was filed at Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1637093 Best regards, NP segunda-feira, 11 de Maio de 2020 às 17:09:08 UTC+1, Hanno Böck escreveu: > Hi, > > As I mentioned in my previous mail I found some instances of CAs > pointing to PEM encoded certificates in their AIA fields, while they > should be DER encoded. > > I found such instances for 4 CAs, I'll list them with one example cert > and the URL of the referenced intermediate. > > Entrust/Affirmtrust: > https://crt.sh/?id=2747041731 > http://aia.affirmtrust.com/aftov1ca.crt > > Telia: > https://crt.sh/?id=2793617446 > http://repository.trust.teliasonera.com/teliasoneraservercav2.cer > > Multicert: > https://crt.sh/?id=2369674005 > http://pki.multicert.com/cert/SSL_CA01.cer > > TWCA: > https://crt.sh/?id=1238438742 > http://sslserver.twca.com.tw/cacert/secure_sha2_2014.crt > > I have informed all 4 CAs via their problem reporting mechanism from > CCADB. > > -- > Hanno Böck > https://hboeck.de/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: 7.1.6.1 Reserved Certificate Policy Identifiers
Yes, I should have asked this on the CABF list, and you answered my question with the links below. Thanks! From: Ryan Sleevi Sent: Thursday, May 14, 2020 8:57 AM To: Doug Beattie Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: 7.1.6.1 Reserved Certificate Policy Identifiers Did you mean to ask this on the CABF list? This is https://github.com/cabforum/documents/issues/179 which I was going to try to fix in https://github.com/sleevi/cabforum-docs/pull/12 (aka “spring” cleanup that is seeking endorsers) The discussion thread is https://cabforum.org/pipermail/validation/2020-May/001469.html smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 7.1.6.1 Reserved Certificate Policy Identifiers
Did you mean to ask this on the CABF list? This is https://github.com/cabforum/documents/issues/179 which I was going to try to fix in https://github.com/sleevi/cabforum-docs/pull/12 (aka “spring” cleanup that is seeking endorsers) The discussion thread is https://cabforum.org/pipermail/validation/2020-May/001469.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
7.1.6.1 Reserved Certificate Policy Identifiers
I have a question about section, 7.1.6.1. It says: This section describes the content requirements for the Root CA, Subordinate CA, and Subscriber Certificates, as they relate to the identification of Certificate Policy. For Subscriber certificates I totally understand and agree with section 7.1.6.1, and specifically: If the Certificate asserts the policy identifier of 2.23.140.1.2.1, then it MUST NOT include organizationName, . and If the Certificate asserts the policy identifier of 2.23.140.1.2.2, then it MUST also include organizationName,. This means you can have one or the other, but never both in one certificate. But, if a Root and a subordinate MUST have an Organizational name, then there is no way it could ever have the DV policy OID (2.23.140.1.2.1) and comply with that requirement. The scope of this section should be for Subscriber Certificates only. Can we agree that was a bug? Section 7.1.6.3 goes on to say that a CA "MAY include the CA/Browser Forum reserved identifiers . to indicate the Subordinate CA's compliance with these Requirements " which further implies that CA certificates can contain CABF Policy identifiers (there are 6 defined CABF OIDs, https://cabforum.org/object-registry/) Doug smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
