Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
On Monday, March 9, 2020 at 2:48:56 PM UTC-4, Kathleen Wilson wrote: > * The root contains subject L and organizationIdentifier fields which > are arguably in violation of BR 7.1.4.3 [5]. Some, if not all, of the > subCAs also exhibit this issue. Given that Mozilla explicitly encourages CAs to provide detailed identity information in subCA/root certificates on its Forbidden or Problematic Practices Wiki page [1], I don't see how including these additional subject fields would run afoul of Mozilla Root Policy, especially considering that the example given on the Wiki page includes the OU subject RDN. What is Mozilla's expectation for subject field encoding, considering the discussion in the CAB Forum and the aforementioned Wiki page? Thanks, Corey [1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Generic_Names_for_CAs ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours
On Tue, Mar 10, 2020 at 05:53:13PM -0500, Matthew Hardeman via dev-security-policy wrote: > Isn't the evident answer, if reasonable compromise is not forthcoming, just > to publish the compromised private key. There's no proof of a compromised > private key quite as good as providing a copy of it. Yes, going full-disc is one option. I'm hopeful that there is a happy middle ground somewhere that means I don't have to drop keys in full public view, though. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ssl.com: Certificate with Debian weak key
On Tue, Mar 10, 2020 at 01:48:49PM -0700, Chris Kemmerer via dev-security-policy wrote: > We have updated https://bugzilla.mozilla.org/show_bug.cgi?id=1620772 with > the findings of our current investigation. Thanks for this update. I have... comments. Before I get into the nitty-gritty, though, I'd just like to say that I found your response to be unnecessarily defensive. So much of it reads -- to me, at least -- as "please don't blame us, it wasn't our fault!". Fault isn't really the issue at hand. Discovering what went wrong, and making sure that the issues are fixed, both for SSL.com and, if appropriate, other CAs, is what I, at least, am trying to achieve. Therefore, while a lot of my responses below address specific points that you've made in your defence, please understand that I'm not trying to rebut them in an attempt to say "nee nah nee nah, it *is* your fault!", but rather to try and provide further information that SSL.com and other CAs could benefit from considering for improvement in the future, given my experience dealing with Debian weak keys. > For the purpose of identifying whether a Private Key is weak, SSL.com uses > a set of Debian weak keys that was provided by our CA software vendor as > the basis for our blacklist. I think it's worth getting additional, *very* detailed, information from your CA software vendor as to where *they* got their Debian weak key list from. That appears to be the fundamental breakdown here -- you relied on a third-party to give you good service, and they didn't. So I think that digging into your vendor's practices is an important line of enquiry to go down. Also, given that there is a non-zero chance that other CAs trusted by Mozilla may be using the same software, with the same incomplete list of weak keys, I think it's important that the fact that the vendor is using a demonstrably incomplete list be circulated to the other customers of this vendor. How would you suggest this is best accomplished? > This information was disclosed on 2020-03-07 to the person that submitted > the Certificate Problem Report. I don't see anything from SSL.com that looks relevant in my inbox, but it's not an important point, just thought I'd mention it in passing. > The above practices comply with our CP/CPS, version 1.8, section 6.1.1.2, > which states: > > "SSL.com shall reject a certificate request if the request has a known > weak Private Key". Hmm, "known" is doing a lot of work in that sentence. Known to *whom* is the important, but unanswered, question. It may be a question which should be answered explicitly in SSL.com's CPS, as well as the CPS of all other CAs (and even, potentially, in the BRs -- although my understanding is that that little bit of the BRs may at some point in the near future get a tidy-up, per https://github.com/cabforum/documents/issues/164). If the appropriate answer is "known to SSL.com", then you could run your CA software with an empty blacklist, issue certs for all manner of known-weak keys, and still be compliant with your CPS. As such, that's probably not an acceptable answer to Mozilla. "Known to SSL.com's CA vendor" is similarly problematic. If, on the other hand, the appropriate interpretation is "known to anyone", then because the key was known to me, and I think I count as "anyone", your CPS was not followed. "Known to the vendor of the software which generated the known-bad key" is also an answer that results in your violating your CPS and the BRs, because the key you issued a certificate for was, as previously mentioned, included in the `openssl-blacklist` Debian package. Do you have another answer to the question "known to whom?" which SSL.com is using in that sentence? > Our understanding is that there is no single or complete list with all > known Debian weak keys, either one that is normative for use by the CAs > included in the Mozilla Root Program, nor one specified in the Baseline > Requirements. That is, I believe, correct, however (at the risk of tooting my own horn) there is quite a comprehensive collection of Debian weak keys in the pwnedkeys.com database. You are welcome to encourage your CA software vendor to perform lookups against the public API if you wish. I don't claim that any possible key you could generate from a buggy Debian system is already in pwnedkeys, but I've accumulated a fair collection of likely candidates, at great cost of (mostly emulated) CPU cycles. > This can be demonstrated by submitting the following CSR That CSR uses a 2048 bit key generated on an i386 system, using OpenSSH with an exponent of 3, with PID 23747. It might not be in certwatch, but it's in pwnedkeys. :grin: > We have strong indications that there are several different lists of > precalculated vulnerable keys whose precise populations depend on > combinations of: > > architecture Yes, different CPU word sizes and endianness produce different keys. That is covered in
Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours
Isn't the evident answer, if reasonable compromise is not forthcoming, just to publish the compromised private key. There's no proof of a compromised private key quite as good as providing a copy of it. I understand the downsides, but I think that capricious burdens encourage stripping the issue bare. You can't dodge a copy of a key. On Tue, Mar 10, 2020 at 5:31 PM Piotr Kucharski via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > For 0% of impact the FPs do not matter that much, so agreed! > > Of course for now reality is not that... yet! > https://github.com/certbot/certbot/issues/1028 seems so appropriate :) > > PS I was definitely not advocating for 5% false negative, no; we must > strive for 0% false negatives as well; all I was saying was exercising > caution for the perhaps-not-so-clear-cut 5% cases. (Probably closer to 1%) > > On Tue, 10 Mar 2020 at 23:08, Ryan Sleevi wrote: > > > > > > > On Tue, Mar 10, 2020 at 5:56 PM Piotr Kucharski wrote: > > > >> I'm sympathetic to CAs wanting to filter out the noise of shoddy reports > >>> and shenanigans, but I'm also highly suspicious of CAs that put too > >>> unreasonable an onus on reporters. It seems, in the key compromise > case, > >>> the benefit of the doubt should largely deal with the reporter. If we > saw > >>> some quantifiable increase in hijinks and misrevocations, there are a > >>> myriad of ways to deal with that. The most effective of these reasons > seems > >>> to be facilitating rapid replacement of certificates, rather than > >>> preferring ossification. > >>> > >> > >> I am totally against putting unreasonable onus on reporters! But > >> hopefully you agree that CAs should strive for zero false positives in > >> revocations. > >> > > > > I'd happily take a 95% false positive of revocations if there were 0% > > impact in the revocation (e.g. due to easy replacement). I'm mainly > > hesitant to setting up a system of 0% false positives but which has a 5% > > false negative. > > > > That's why I'm less excited for standard systems of signaling revocation > > (not that there isn't some value!), and more keen on systems that make > > revocation easier, quicker, and less-impactful. That's obviously Hard > Work, > > but that's the exciting part of working in PKI. Everything is Hard Work > > these days :D > > > ___ > 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
Re: ssl.com: Certificate with Debian weak key
We have updated https://bugzilla.mozilla.org/show_bug.cgi?id=1620772 with the findings of our current investigation. We believe all issues raised in this thread are addressed in this update. Our investigation is ongoing and we welcome any positive input by the community as an opportunity to improve our practices and communal PKI operations generally. Our team is evaluating possible improvements for this process, such as acquiring actual public keys created by the weak Debian RNG and using those keys to produce fingerprints compatible with our CA software. We have also contacted our CA software vendor regarding an improved blacklist. csk Chris Kemmerer SSL.com On Monday, March 9, 2020 at 3:41:09 PM UTC-5, Nick Lamb wrote: > On Sun, 8 Mar 2020 10:57:49 +1100 > Matt Palmer via dev-security-policy > wrote: > > > > The fingerpint of the claimed Debian weak key was not included in > > > our database. > > > > I think it's worth determining exactly where SSL.com obtained their > > fingerprint database of weak keys. The private key in my possession, > > which I generated for inclusion in the pwnedkeys.com database, was > > obtained by using the script provided in the `openssl-blacklist` > > source package, with no special options or modifications. > > Yes, I would certainly want SSL.com's report to give me confidence > that > > #1 they've identified why they didn't spot this key, were there (many?) > other keys which would also have been missed? > > #2 they now have a complete and accurate list of such keys > > #3 they went back and did the work to re-check other certificates > they've issued for this (these?) extra weak keys and any matches were > revoked and the subscriber contacted > > > Depending on the circumstances in #1 there may well be a lesson for > other CAs, especially if using a setup which is similar in some way to > SSL.com and so this point is very important. There might also be > further questions about SSL.com's processes which failed to detect this > mistake. > > This sort of incident is also important because of the impact on the > Subscriber. Had this subscriber used a different CA with a complete > list they'd have been informed immediately that their chosen key was a > problem. Because SSL.com didn't do that in fact this subscriber was > potentially vulnerable to active, and in some cases even passive > attacks on their TLS services for the period between issuance and > discovery. > > > Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours
For 0% of impact the FPs do not matter that much, so agreed! Of course for now reality is not that... yet! https://github.com/certbot/certbot/issues/1028 seems so appropriate :) PS I was definitely not advocating for 5% false negative, no; we must strive for 0% false negatives as well; all I was saying was exercising caution for the perhaps-not-so-clear-cut 5% cases. (Probably closer to 1%) On Tue, 10 Mar 2020 at 23:08, Ryan Sleevi wrote: > > > On Tue, Mar 10, 2020 at 5:56 PM Piotr Kucharski wrote: > >> I'm sympathetic to CAs wanting to filter out the noise of shoddy reports >>> and shenanigans, but I'm also highly suspicious of CAs that put too >>> unreasonable an onus on reporters. It seems, in the key compromise case, >>> the benefit of the doubt should largely deal with the reporter. If we saw >>> some quantifiable increase in hijinks and misrevocations, there are a >>> myriad of ways to deal with that. The most effective of these reasons seems >>> to be facilitating rapid replacement of certificates, rather than >>> preferring ossification. >>> >> >> I am totally against putting unreasonable onus on reporters! But >> hopefully you agree that CAs should strive for zero false positives in >> revocations. >> > > I'd happily take a 95% false positive of revocations if there were 0% > impact in the revocation (e.g. due to easy replacement). I'm mainly > hesitant to setting up a system of 0% false positives but which has a 5% > false negative. > > That's why I'm less excited for standard systems of signaling revocation > (not that there isn't some value!), and more keen on systems that make > revocation easier, quicker, and less-impactful. That's obviously Hard Work, > but that's the exciting part of working in PKI. Everything is Hard Work > these days :D > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: key compromise revocation methods [was: GoDaddy: Failure to revoke key-compromised certificate within 24 hours]
On Tue, Mar 10, 2020 at 05:18:51PM -0400, Ryan Sleevi via dev-security-policy wrote: > I'm sympathetic to CAs wanting to filter out the noise of shoddy reports > and shenanigans, but I'm also highly suspicious of CAs that put too > unreasonable an onus on reporters. If CAs want a 100% reliable and trustworthy means of receiving key compromise reports, they can stand up a server which implements RFC8555 s7.6. The backend doesn't have to immediately revoke the cert; it can create a ticket in the CA's workflow management system saying "this cert has been demonstrated to have a compromised private key, do the needful". No need for compliance specialists, PKI experts, or anyone to be on hand to check what's going on. Put a link to the ACME directory in s4.9.12 of their CPS and in CCADB, Job done. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CSRs as a means of attesting key compromise [was: GoDaddy: Failure to revoke key-compromised certificate within 24 hours]
On Tue, Mar 10, 2020 at 01:25:11PM -0700, bif via dev-security-policy wrote: > Voluntarily providing CSR is not an ideal way to prove key compromise, > because you could've simply found this CSR somewhere (I know, I know, > super unlikely with your Subject... but still could happen.) Feel free to trawl the Internet looking for CSRs with a subject that indicates that the private key is compromised, where that key is used in a publicly-trusted certificate issued to a third party, and for which the private key hasn't been compromised (feel free to confirm that last part via the pwnedkeys.com search API). When you find one -- just one -- we can continue debating the merits of using a static CSR as a method of attesting key compromise. Until then, I'll keep using them as the least-worst available option. > And while "compromised" is way too short (one can sign up to 32 bytes > using it as a nonce in regular TLS session) to prove the key compromise, > in the absence of the actual compromised private key, about the only way > to ensure the possession is to get the reporter to sign some data chosen > by the CA. It very well may be a random CN in the CSR, or plain old > openssl dgst. That would require the database of all pwnedkeys to be available live, to permit real-time generation of signatures in response to CA requests. Having that many keys online is a *spectacular* security risk, given the importance of some of the certificates whose private keys have been publicly disclosed (there's another gao.gov certificate yet to be revoked, not to mention the one for *.avast.com!). I deliberately and *very* purposely keep the database of actual private keys out of harm's way, and requiring the database to be kept online to respond to challenge-response interactions with CAs seems like a spectacularly bad security compromise. Further, given the lack of any sort of standardisation of revocation workflows, even within a single CA, a challenge-response mechanism for key compromise attestation would almost certainly require manual intervention on my part. Given the large backlog of certificates still to be revoked, and the ongoing stream of new certificates and private keys that will, seemingly, never stop, requiring manual steps from me for every one of those is, I'm sure you can understand, not something I'd be keen on. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours
On Tue, Mar 10, 2020 at 5:56 PM Piotr Kucharski wrote: > I'm sympathetic to CAs wanting to filter out the noise of shoddy reports >> and shenanigans, but I'm also highly suspicious of CAs that put too >> unreasonable an onus on reporters. It seems, in the key compromise case, >> the benefit of the doubt should largely deal with the reporter. If we saw >> some quantifiable increase in hijinks and misrevocations, there are a >> myriad of ways to deal with that. The most effective of these reasons seems >> to be facilitating rapid replacement of certificates, rather than >> preferring ossification. >> > > I am totally against putting unreasonable onus on reporters! But hopefully > you agree that CAs should strive for zero false positives in revocations. > I'd happily take a 95% false positive of revocations if there were 0% impact in the revocation (e.g. due to easy replacement). I'm mainly hesitant to setting up a system of 0% false positives but which has a 5% false negative. That's why I'm less excited for standard systems of signaling revocation (not that there isn't some value!), and more keen on systems that make revocation easier, quicker, and less-impactful. That's obviously Hard Work, but that's the exciting part of working in PKI. Everything is Hard Work these days :D ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours
On Tue, 10 Mar 2020 at 22:19, Ryan Sleevi wrote: > > > On Tue, Mar 10, 2020 at 4:25 PM bif via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Matt, >> >> Voluntarily providing CSR is not an ideal way to prove key compromise, >> because you could've simply found this CSR somewhere (I know, I know, super >> unlikely with your Subject... but still could happen.) >> > > That seems to be making the perfect the enemy of the good. > Most likely :) Take it as more general musings for having generally accepted recipes for providing proof of key possession, using which would not allow CAs to wiggle out of responsibility of revocation. > This seems like a perfectly reasonable thing to allow and accept. If we're > concerned about someone "might" having done something as a reason to reject > it, it seems like we'd need another pass through the BRs validation methods > - e.g. to remove the non-IANA-reserved mail addresses. > Sure, as long as CN is long enough, and CSR is clean, ie. no extensions allowing to fit, say, collision attacks. > > I don't disagree that this is a possibility, but the probability of this > possibility seems incredibly low, and the risk of a CA deciding to revoke > on this basis seems immeasurably better than the risk of deciding to not > revoke. > As a CA I would most likely accept this proof, considering the incredibly low false positive possibility. :) All I'm saying is that proof of key possession is not clearly defined in the absence of said key being shared with a CA. > > >> And while "compromised" is way too short (one can sign up to 32 bytes >> using it as a nonce in regular TLS session) to prove the key compromise, in >> the absence of the actual compromised private key, about the only way to >> ensure the possession is to get the reporter to sign some data chosen by >> the CA. It very well may be a random CN in the CSR, or plain old openssl >> dgst. >> > > I'm concerned about CAs disproportionately adding burdens to reporters of > compromise. For example, your 'compromised' case doesn't really make sense. > The string 'compromised', or even the hash of the string 'compromised', > would not in and of itself be a sufficient TLS transcript. I agree with you > that one can't simply /look/ for the string 'compromised' in the unsigned > data, where that signed data is a TLS transcript, but that's not what you > really described, and that distinction seems important. > > I also disgree with, and have concerns with, the CA being able to direct > the signing of the data. I think the ecosystem learned a lot from the > Heartbleed scenario, of "We're not affected, we're not affected... oh crap, > we're affected". > > I'm sympathetic to CAs wanting to filter out the noise of shoddy reports > and shenanigans, but I'm also highly suspicious of CAs that put too > unreasonable an onus on reporters. It seems, in the key compromise case, > the benefit of the doubt should largely deal with the reporter. If we saw > some quantifiable increase in hijinks and misrevocations, there are a > myriad of ways to deal with that. The most effective of these reasons seems > to be facilitating rapid replacement of certificates, rather than > preferring ossification. > I am totally against putting unreasonable onus on reporters! But hopefully you agree that CAs should strive for zero false positives in revocations. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours
On Tuesday, March 10, 2020 at 1:25:21 PM UTC-7, bif wrote: > Matt, > > Voluntarily providing CSR is not an ideal way to prove key compromise, > because you could've simply found this CSR somewhere (I know, I know, super > unlikely with your Subject... but still could happen.) > While a CSR isn't particularly sensitive in itself, people don't often go around posting them publicly. One of the most likely places to find it is on the machine it was generated on, indicating that the machine holding the private key was probably breached, or somewhere in a CA's infrastructure, indicating the CA was breached. Even if the person providing the CSR *doesn't*, in fact, have the private key, I'd be extremely worried about who *does*. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours
On Tue, Mar 10, 2020 at 4:25 PM bif via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Matt, > > Voluntarily providing CSR is not an ideal way to prove key compromise, > because you could've simply found this CSR somewhere (I know, I know, super > unlikely with your Subject... but still could happen.) > That seems to be making the perfect the enemy of the good. This seems like a perfectly reasonable thing to allow and accept. If we're concerned about someone "might" having done something as a reason to reject it, it seems like we'd need another pass through the BRs validation methods - e.g. to remove the non-IANA-reserved mail addresses. I don't disagree that this is a possibility, but the probability of this possibility seems incredibly low, and the risk of a CA deciding to revoke on this basis seems immeasurably better than the risk of deciding to not revoke. > And while "compromised" is way too short (one can sign up to 32 bytes > using it as a nonce in regular TLS session) to prove the key compromise, in > the absence of the actual compromised private key, about the only way to > ensure the possession is to get the reporter to sign some data chosen by > the CA. It very well may be a random CN in the CSR, or plain old openssl > dgst. > I'm concerned about CAs disproportionately adding burdens to reporters of compromise. For example, your 'compromised' case doesn't really make sense. The string 'compromised', or even the hash of the string 'compromised', would not in and of itself be a sufficient TLS transcript. I agree with you that one can't simply /look/ for the string 'compromised' in the unsigned data, where that signed data is a TLS transcript, but that's not what you really described, and that distinction seems important. I also disgree with, and have concerns with, the CA being able to direct the signing of the data. I think the ecosystem learned a lot from the Heartbleed scenario, of "We're not affected, we're not affected... oh crap, we're affected". I'm sympathetic to CAs wanting to filter out the noise of shoddy reports and shenanigans, but I'm also highly suspicious of CAs that put too unreasonable an onus on reporters. It seems, in the key compromise case, the benefit of the doubt should largely deal with the reporter. If we saw some quantifiable increase in hijinks and misrevocations, there are a myriad of ways to deal with that. The most effective of these reasons seems to be facilitating rapid replacement of certificates, rather than preferring ossification. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours
Matt, Voluntarily providing CSR is not an ideal way to prove key compromise, because you could've simply found this CSR somewhere (I know, I know, super unlikely with your Subject... but still could happen.) And while "compromised" is way too short (one can sign up to 32 bytes using it as a nonce in regular TLS session) to prove the key compromise, in the absence of the actual compromised private key, about the only way to ensure the possession is to get the reporter to sign some data chosen by the CA. It very well may be a random CN in the CSR, or plain old openssl dgst. On Monday, 9 March 2020 23:26:26 UTC+1, Matt Palmer wrote: > Hi Joanna, > > Thanks for responding. When can this list, or Bugzilla, expect GoDaddy's > incident report? Also, for the avoidance of further doubt, can you give an > exact timestamp at which GoDaddy considers that evidence of key compromise > was "obtained" for this certificate? > > - Matt > > On Mon, Mar 09, 2020 at 01:46:17PM -0700, Joanna Fox via dev-security-policy > wrote: > > Matt, > > > > Thank you for sharing your experience with our problem reporting mechanism > > on this forum. It is due to this that we were able to get to the root of > > the issue. Here is some detail into what we saw. > > > > Yesterday, we launched an investigation which included various members of > > the team researching this issue. We took this investigation as far as we > > could with the information we had and concluded that the CSR provided, as > > we read it, was malformed. We ran this CSR through various tools but were > > unable to successfully confirm validity. > > > > This morning, based on the statements in this forum, we discovered that our > > email system had misinterpreted the CSR formatting due to it being pasted > > in the body of the email. When we fix Base64 encoding, the CSR verifies. > > > > Upon this discovery we have initiated revocation to occur within the > > guidelines of 24 hours from obtaining evidence that the private key was > > compromised. We take key compromises very seriously and recognize the > > importance to the industry and health of the ecosystem. > > > > Lastly, we also noticed that the email you received was malformed, missing > > some of the required content for the OpenSSL command. This event has led > > to a review of our email system to learn how we can avoid malformed > > encoding issues in the future. > > > > Thank you, > > Joanna Fox > > GoDaddy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
Comments inline and snipped On Mon, Mar 9, 2020 at 2:48 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > ==Meh== > * Microsec issued two certificates in 2018 with 3-year validity periods [1]. > That bug, and the related discussion, discussions Microsec's confusion but does not appear to lead to any understanding about what systemically has been changed to prevent this confusion in the future. At the time of the discussion, it was also pointed out how that confusion was unreasonable. > * CP section 1.3.2 permits 3rd party RAs, but in their BR > Self-Assessment, Microsec states that “The Trust Service Provider do not > apply third parties for RA activities.” > * CPS section 4.9.5 provides a detailed explanation of the revocation > process but fails to mention the required preliminary report to the > Subscriber and the entity who filed the Certificate Problem Report. > * CPS section 4.9.1 contains a section titled “Reasons for Revoking a > Subordinate CA Certificate operated by another CA” but in their BR > Self-assessment, Microsec states that “All Subordinate CA-s under the > Microsec roots are operated by Microsec.” > > ==Bad== > * I was unable to locate the description of email address validation > practices required by Mozilla policy section 2.2. Microsec published new > CPS version adding section 3.2.7 to resolve this issue. > * Microsec recently issued what appears to be two certificate used for > testing that violate the BRs [3][4]. They are now expired. > * CCADB currently lists 9 audit letter validation failures for Microsec. > * The root contains subject L and organizationIdentifier fields which > are arguably in violation of BR 7.1.4.3 [5]. Some, if not all, of the > subCAs also exhibit this issue. > * BR section 4.9.3 requires CPS section 1.5.2 to contain instructions > for reporting an issue such as key compromise to the CA. The Microsec > CPS’ only state that questions related to the policy may be reported via > the info in that section, and other email addresses > (“highprioritycertificateproblemrep...@e-szigno.hu”, > “revocat...@e-szigno.hu") are found in other sections of some documents. > Section 4.9.5 then states that revocation requests are only accepted at > the address listed in section 1.2, but there is no email address in this > section. > * Three EV (QWAC) certificates have been issued with an extra > subject:serialNumber field that contains what appears to be a policy OID > [6]. Only one is currently revoked. > * In comment #18 of the inclusion bug dated January 2019, Microsec > confirms that their CPS did not contain the required CAA information, > despite Microsec being a Mozilla root program member at that time. > Every one of the non-snipped incidents here (including the 3 year certs) seem to point to a systemic failure to understand and follow industry developments, either within m.d.s.p. or within the CA/Browser Forum's Baseline Requirements. That's concerning, as Microsec already operates a trusted root - https://crt.sh/?caid=778 - in Mozilla's program, and so it's not unreasonable to expect them to be following and adhering to these requirements, especially as it relates to the CP/CPS. I've highlighted similar issues, below, regarding the same systemic concerns: * The following non-conformities were listed in the 2018 BR attestation > statement [7]. (they are not defined as “major” or “minor”): > ** The TSP shall maintain dual control for performing critical functions > on > the core systems (including Root CA, intermediate CAs, archiving system, > TSA system, OCSP responders etc.) [ETSI EN 319 411-1, GEN-6.4.3-02, > OVR-6.4.8-07, GEN-6.5.1-04, GEN-6.5.2-06] > ** The TSP shall modify the web application form and the registration > interface in such a way that it is clearly indicated what kind of > information are required for the issuance of the given certificate in > accordance with the policies. Misleading information shall be avoided. > [ETSI EN 319 401, REQ-6.1-01] > and > * The following non-conformities were listed in the 2019 BR attestation > statement [9]: > ** The TSP shall not issue non-compliant test certificates from the live > environment. As this has been occurred in the past, the TSP shall > provide evidences of the changed testing procedures to avoid further > occurrence of such events. [ETSI EN 319 401, REQ-6.1-07] > ** The TSP shall review the re-keying procedure in the CPS and shall > align the CPS with the real process-es and the relating standards. [ETSI > EN 319 411-1, REG-6.2.3-02] > ** The TSP shall ensure that the reusing procedure of all data fulfills > the EVCG 11.14 and the CPS corresponds to these reusing requirements. > [ETSI EN 319 411-1, REG-6.2.3-03] > ** There are conflicts between Hungarian law and EV Guideline regarding > to the witnessing the root ca key generation by a Qualified Auditor, the > TSP must inform the CAB/Forum about this fact. [ETSI 319 411-1 > GEN-6.5.1-14], [BRG,
RE: GlobalSign: Failure to revoke certificate with compromised private key within 24 hours
An incident report was created for this yesterday: https://bugzilla.mozilla.org/show_bug.cgi?id=1620922 > -Original Message- > From: dev-security-policy On > Behalf Of Matt Palmer via dev-security-policy > Sent: dinsdag 10 maart 2020 1:41 > To: dev-security-policy@lists.mozilla.org > Subject: GlobalSign: Failure to revoke certificate with compromised private key > within 24 hours > > A certificate with a publicly-disclosed private key was reported to GlobalSign for > revocation within the BR-mandated 24 hour period, however the revocation took > place over 46 hours after the report was sent. Several requests for information I > had already provided were made by GlobalSign, however the revocation eventually > took place without any further information being required. Communication from > GlobalSign then appeared to suggest that the certificate had "already" been > revoked, despite timestamps in the CRL indicating otherwise. > > I believe an incident report for this event is warranted, given that GlobalSign was > provided with sufficient information to revoke the certificate in the initial problem > report (based on the fact that revocation eventually took place with no further > information being provided by myself), but failed to do so within the BR-mandated > time period. > > Excuciatingly detailed timeline follows. > > 2020-03-06 21:48:53Z E-mail sent to report-ab...@globalsign.com: > > -8<- > Date: Sat, 7 Mar 2020 08:48:53 +1100 > From: Matt Palmer > To: report-ab...@globalsign.com > Subject: Problem Report for certificate(s) with compromised private key > > One or more certificates issued by your CA are using a private key which has been > publicly disclosed. The list of affected certificates can be retrieved from > > https://crt.sh/?spkisha256=6a02703a7a2ba3f368a2915305383549cf8ada826242269 > 7d62d5ba410e4d93f > > Included below is a CSR, signed by the compromised private key, demonstrating > proof of possession: > > -BEGIN CERTIFICATE REQUEST- > MIIE0TCCArkCAQAwgYsxaTBnBgNVBAMMYFRoZSBrZXkgdGhhdCBzaWduZWQg > dGhp > cyBDU1IgaGFzIGJlZW4gcHVibGljbHkgZGlzY2xvc2VkLiBJdCBzaG91bGQgbm90 > IGJlIHVzZWQgZm9yIGFueSBwdXJwb3NlLjEeMBwGA1UECgwVaHR0cHM6Ly9wd2 > 5l > ZGtleXMuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2OMM6yti > 3q+GhnZsMPYrACVrZWYqn2yz2fH5J6kPONDvHm3P4UgPJb5j0OFUbmng3e41Fw > Wf > QhD7UFbiEtH/fCJLnxuhAlCBZkVTwIBIwIYRpBmSp/shtNBJZvHBPgktF78qQBr5 > HaX9jZOl/z0rLVw42wnzHlMyyeJNCQzBgRqA+Lcgig/9I2qxQvm3C53868i0EE3k > B418D63cEhz6hldoxELt7twoYulwyLk/PXWj/I0qHQZGT1weLD6UXINuxhmcFUDj > 4i5V9UqNWhP4LT/QWjNtqE5y1OOT5qtkczjmSd3TS3GCik3o7v2M7JxwME1T/e/z > unTqhCarZF3HkrN5MxDB/28HsPaSRUpbxzmIUt+GApuVjNWnRW0awlzp8i5wQnmo > x7nNtSSht44DhlWETpPeT3n27LKM64no97aN0NS0LEKc5sFuOcS5sCj5FvsxNm/8 > RhqfQkHXjkhZByTPhYvkQZTTA8Gxsh52Pnr0aTKrNz/fNpcJWzlKvbSmQn7i1Nmn > z6f9cTB3gW9+DjgSq/XjgVZJdGAWD9k5/i+v8b0zSbpprGNh2gkn39QYmWLlS2eu > XhtAhdWAroEBxm5pLA3T50KWcfM1IHsZSHIeneIcR3anUhqnA1vMjZdFdFkX+TCE > n/c6cotq/fESE+ieMdc7NjpTn4w2a+10xHECAwEAAaAAMA0GCSqGSIb3DQEBCw > UA > A4ICAQCnPqJFlaTaNTz0ldS+PepRa8cpf4DXJ/shKBf8ChJ7ivY8+Q6qQWLU4WTM > DSChT+5K2Zlr5LRoIBeTsgyl3345agsPI8BKjw1OpRlxgVsMKlKOd6nCSJPw2NDl > +Ud+s/LbnZJsIn9nb4fQdF+mC4L6Q1GikCkTfQ1SD8RykVgwojiQFwsdaNRy1U2z > uw3QtlYXZ1s/zdgEITBB4x5js1r8+njue3X4hbgmTrnppEpxeaiuKIImLxFCOveo > pv6evi9g8mYCZ2hqvLO2RTO3iTSvbDAgbImr6D0Asem1qdCdNPbhiGXj/kxJNNUQ > P5hb1KmbcdCLIjvMz0+Z6TkIW0q4MowUpUeKx8Y18Pjt9D+nLN9sRLi8vfjvlnt4 > eLENX2156CWMmJQg4n16UjYKaf6dSCvWJYC2TzYJzs+ZEKU71LCkUl/hdj7ZNLtZ > o3Z3C892nPZ56LdJES2wBMFgfMV5EWo4MrriFO7yhpkVp3NlOWkWVjIuTPDsm0g > K > fLVgHQPfgpVR6LT/e2HWISdiogUrACsVFrb5vfehXY2PAewPghkD5Cn3LG6hnXYn > hmjgXDwz2dK5ud3ABJT1UxJtn82o3z3okUDISdeioxw43HBhCQ84p3G+JoRq9x6+ > 2ncweNmCQQ66tsX386ywKpPQJ4/1DrRsOKdSSy7siwwtR437Rg== > -END CERTIFICATE REQUEST- > > Please revoke all affected certificates within 24 hours, as per the Baseline > Requirements. > > - Matt > ->8- > > 2020-03-06 21:49:04Z E-mail is accepted for delivery by a GlobalSign MX: > > -8<- > Mar 6 21:49:04 minotaur postfix/smtp[26026]: 75BC71857EE: > to=, > relay=globalsign-com.mail.protection.outlook.com[104.47.93.36]:25, > delay=6.8, delays=0.47/0.01/0.9/5.4, dsn=2.6.0, status=sent (250 2.6.0 > <20200306214853.kpohtnh5y2m3k...@hezmatt.org> [InternalId=34857954577034, > Hostname=HK0PR03MB2755.apcprd03.prod.outlook.com] 10967 bytes in 3.479, > 3.078 KB/sec Queued mail for delivery) > ->8- > > 2020-03-06 21:49:15Z Auto-ack e-mail received from GlobalSign: > > -8<- > Dear Matt Palmer, > > Thank you for reporting this issue to GlobalSign. Case #04076325: "Problem > Report for certificate(s) with compromised private key" has been created and a > GlobalSign representative will investigate this immediately. If requested you will > receive a response from a designated representative as soon as possible. > > Thank you, > Customer Service Team GlobalSign > ->8- > > 2020-03-06 22:08:06Z Human response from GlobalSign: >
