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
> > 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: Terms and Conditions that use technical measures to make it difficult to change CAs
> .. There’s plenty of precedent in having Root Policy or the > Baseline Requirements require a CP/CPS explicitly state something; > examples such as the CAA domain name, the problem reporting mechanism > and contact address, and compliance to the latest version of the BRs. > > If we apply that idea here, it might make sense to require the CA’s > CP/CPS make a clear and unambiguous statement about whether or not > they engage in X as a practice. I’m not quite sure what X should say, > but the idea is that it would be transparent to Relying Parties > wanting to evaluate a CA, as well as to User Agents when evaluating > whether or not a given CA's practices provide a service relevant to > user's of that software product. While it's conceivable that sites are > already having these practices disclosed to them, having a consistent > and public disclosure would help bring transparency into what CAs are > engaging in this practice, and which have committed not to use > revocation in this way, which can help make it easier to compare the > trustworthiness of CAs up-front. I am ambivalent to the idea of having a list of business practices, presumably over and above those required in law, that CAs must publish to the community. I suppose that CAs' existing contractual terms, particularly for large subscribers such as enterprise organizations, are negotiated between the two parties and so are typically known only to the CA and to the subscriber. For other individual subscribers a standard subscriber agreement published in advance more likely applies. I'm sure that some subscribers will be happy to have additional oversight of contractual terms rather than rely on their own reading and understanding of the contract they sign, while others would not choose it, were that choice available to them. Paraphrasing Jeremy's answer, actions speak louder than words. Are these things that have been done, or things that contracts permit? Is it words or actions that you seek to restrict? Kathleen posted this on the Mozilla PKI Policy github. https://github.com/mozilla/pkipolicy/issues/208 saying > ".. some CAs have Terms and Conditions which say that if the customer > moves to (or even tries to use) another CA, all of their certificates > will be revoked. Enforcing all revocations (independent of reason) > supports this bad behavior by CAs, helping them to hold their > customers hostage. But if CAs always add the CRLReason for > revocations, we can selectively enforce revocation for certain reasons, > and have varying levels of enforcement (e.g. overridable versus > not-overridable) Enforcing or restricting some revocation reasons is an interesting idea but I think that selective implementation of revocation based on the concept of there being 'good' and 'bad' revocation reasons has an implicit challenge. It changes the certificate life-cycle. Simplistically, the life of a certificate today is either: Issue - use - expire; or Issue - use - revoke, and in each case no further management of the certificate's state is possible by either the CA or the subscriber after the terminal event. However, if there are 'bad' revocations that will be ignored the life-cycle gets another step under certain circumstances: Issue - use - 'bad' revocation (ignored) - use - 'good' revocation. This requires both that the user is able to request a second revocation for a different reason after an earlier revocation, and also that the CA has further obligations to take actions concerning this certificate after it had been initially revoked, e.g. re-revoking if misissuance or subscriber key compromise were detected. Regards Robin Alden Sectigo Limited 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: Certificate OU= fields with missing O= field
> -Original Message- > From: Kurt Roeckx via dev-security-policy > Sent: 01 November 2019 10:15 > To: Matthias van de Meent > Cc: MDSP > Subject: Re: Certificate OU= fields with missing O= field > > On Fri, Nov 01, 2019 at 11:08:23AM +0100, Matthias van de Meent via dev- > security-policy wrote: > > Hi, > > > > I recently noticed that a lot of leaf certificates [0] have > > organizationalUnitName specified without other organizational > > information such as organizationName. Many times this field is used > > for branding purposes, e.g. "issued through " > > or "SomeBrand SSL". > > > > That OU clearly doesn't have anything to do with the subject that > was validated, so I also consider that a misissue. > [Robin Alden] Kurt, Matthias, We are aware of 7.1.4.2 i. but we had not read it the same way. We originally read it as saying that where information pertaining to the subject organization was included in an OU field: a) That information must be validated per 3.2.2.1, and b) It must only be included in an OV or EV certificate, i.e. it could not be included in DV. Looking at it now, it seems to say that you can only have meaningful, validated, OU information in a certificate which is either OV or EV, and which also includes subject:givenName and subject:surname attributes. That seems to be a very limited subset. The BR language around OUs (apart from the givenName and surname) was proposed in 2012, and that is probably the last time we evaluated it from scratch. Other interpretations are definitely possible. If the prohibition on name, tradename, trademark, address, etc., is not intended to apply to the subject organization then it is hard to see how you would verify it under 3.2.2.1. We believed that the prohibition was there to bolster the CA Warranty (9.6.1 4) that the CA (i) implemented a procedure for reducing the likelihood that the information contained in the Certificate's subject:organizationalUnitName attribute would be misleading. Regards Robin Alden Sectigo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Question about the issuance of OCSP Responder Certificates by technically constrained CAs
> The aforementioned comments, however, indicate CAs have reported that > Microsoft does [require the EKU chaining]. I agree that statement is true, but I think it inadvertently misleads. We cannot speak for Microsoft about what their requirements for id-kp-OCSPSigning are, and we are not aware of documentation from Microsoft that sets out the answer, but we do have experience that sheds some light on the matter. The Scenario === We are a root CA. In compliance with Mozilla CA policy we signed a constrained intermediate CA certificate whose public key corresponded to a private key held by a customer organization. The constrained intermediate CA was to sign end entity certificates. The constrained intermediate CA was not directly to sign OCSP responses, but instead was to sign an OCSP responder certificate that would be used to sign OCSP responses. The intermediate CA certificate included an EKU, but the EKU did not include id-kp-OCSPSigning. The first certificate that the intermediate CA was to sign was the OCSP responder certificate, and the OCSP responder certificate was to include an EKU with id-kp-OCSPSigning. The Problem === The customer was using Microsoft's Certificate Authority platform to issue end entity certificates using the Intermediate CA. The customer found they were unable to issue the OCSP responder certificate (including id-kp-OCSPSigning) because the Microsoft CA software would not issue such a certificate since the signing CA (i.e. the intermediate CA) had an EKU but did not include id-kp-OCSPSigning. I.e. Microsoft's Certificate Authority requires EKU chaining. An 'obvious' solution would have been to re-issue the Intermediate CA certificate and include id-kp-OCSPSigning in its EKU. Obviously wrong in this case since had we done so the Intermediate CA (i.e. our customer) would then have been able to sign OCSP responses for any certificate issued by our Root CA. Another solution would have been to re-issue the Intermediate CA certificate and omit the EKU extension altogether but this would have been against policy since the BRs require the EKU to be present for a CA to be considered technically constrained. The fix = The work around was for us to create for our customer a second CA certificate that had an EKU including id-kp-OCSPSigning and used the same public key and subjectDN as the Intermediate CA certificate, but this time for us to sign it with an untrusted CA. We anticipate that the customer could also have created a self-signed CA for themselves using the Intermediate CA key, but did not test that. The Microsoft CA Platform was then happy to sign an OCSP responder certificate including id-kp-OCSPSigning from this second untrusted CA. Since the key and subjectDN for the untrusted CA are the same as the key and subjectDN of the Intermediate CA certificate, this OCSP responder certificate also chains up through the Issuing CA to our trusted root. The OCSP responder could now be provisioned and the Intermediate CA could then begin to issue end entity certificates whose OCSP responses were signed by the OCSP responder certificate's key. The take-away The OCSP responses for the end entity certificates worked fine with browsers on the web. As far as the relying parties were concerned, the only certificate that included id-kp-OCSPSigning was the OCSP responder certificate. No other certificate in the chain included id-kp-OCSPSigning. So, while it is true to say that "Microsoft does require the EKU chaining", for id-kp-OCSPSigning the only place we have observed them to require it is in the Microsoft Certificate Authority software. We have no reason to believe that their operating systems or browsers require EKU chaining for id-kp-OCSPSigning in the web PKI. Does anyone have any evidence to the contrary? Regards Robin Alden Sectigo Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Comodo password exposed in GitHub allowed access to internal Comodo files
Nick, Ángel, Sectigo is not affected by this incident. https://sectigo.com/blog/attention-journalists-and-researchers-dont-confuse-comodo-with-sectigo Regards Robin Alden Sectigo Limited > -Original Message- > From: Nick Lamb via dev-security-policy > Sent: 27 July 2019 23:42 > > On Sun, 28 Jul 2019 00:06:38 +0200 > Ángel via dev-security-policy > wrote: > > > A set of credentials mistakenly exposed in a public GitHub repository > > owned by a Comodo software developer allowed access to internal > Comodo > > documents stored in OneDrive and SharePoint: > > > > https://techcrunch.com/2019/07/27/comodo-password-access-data/ > > > > > > It doesn't seem that it affected the certificate issuance system, but > > it's an ugly security incident nevertheless. > > What was once the Comodo CA is named Sectigo these days, so conveniently > for us this makes it possible to simply ask whether the incident > affected Sectigo at all: > > - Does Sectigo in practice share systems with Comodo such that this > account would have access to Sectigo internal materials ? > > In passing it's probably a good time to remind all programme > participants that Multi-factor Authentication as well as being > mandatory for some elements of the CA function itself (BR 6.5.1), is a > best practice for any security sensitive business like yours to be using > across ordinary business functions in 2019. Don't let embarrassing > incidents like this happen to you. > > Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: CAA policy - ComodoCA or Sectigo?
Wayne, Mattias, We have a post-rebrand CPS which is almost ready to publish and has a new Certificate Profiles section. To the OP's first question, we continue to accept (amongst others) comodo.com and comodoca.com as Issuer Domain Names in CAA records that authorize us to issue. RFC6844 says ".. authorizes the holder of the domain name or a party acting under the explicit authority of the holder of that domain name to issue certificates for the domain in which the property is published." We are the holder of comodoca.com. We have explicit authority to use comodo.com for this purpose. We have always disclosed updates to our CAA domains to the CCADB promptly. Regards Robin Alden Sectigo Limited > -Original Message- > From: dev-security-policy > On Behalf Of Wayne Thayer via dev-security-policy > Sent: 05 February 2019 15:58 > To: Matthias van de Meent > Cc: Ryan Sleevi ; MDSP pol...@lists.mozilla.org> > Subject: Re: CAA policy - ComodoCA or Sectigo? > > On Tue, Feb 5, 2019 at 4:37 AM Matthias van de Meent via > dev-security-policy wrote: > > > On Mon, 4 Feb 2019 at 18:06, Ryan Sleevi wrote: > > > > > > On Mon, Feb 4, 2019 at 10:46 AM Matthias van de Meent via > > dev-security-policy wrote: > > >> > > >> Hi, > > >> > > >> Today we've bought a wildcard certificate [0] for our cofano.io domain > > >> from Sectigo (previously ComodoCA) via a reseller. Our CAA policy > > >> describes that only "comodoca.com" can issue wildcards. The > > >> certificate has been issued and signed by Sectigo's 'new' intermediate > > >> and root [1] [2]. > > >> > > >> My question is the following: Was Sectigo allowed to sign the > > >> certificate using their Sectigo (not ComodoCA) keys, while my CAA > > >> record specifies 'issuewild "comodoca.com"'? > > > > > > > > > Yes > > > > > >> > > >> I.E. How should a CA name > > >> change be reflected in ( CAA ) conformance? Especially since the > > >> Sectigo CPS [3] still only specifies Comodo as their issuer name, > > >> which conflicts with the CN/O of the signing certificate [1]. > > > > > > > > > There's zero requirement about any such mapping. > > > > > > The Baseline Requirements, Section 2.2, requires that CAs disclose their > > policies and respected domains for their CAA policy. > > > > > > Section 3.2.2.8 places more requirements, largely around the > > processing/validation model. To the question of domain names is not > touched. > > > > > > Thus, a CA can disclose in their CP/CPS many domains, including those of > > affiliated or non-affiliated CAs. Provided that this is disclosed in their > > CP/CPS, and their exception process is clearly documented for domains not > > in that enumerated list, then they're complying. > > > > > > Sectigo's CP/CPS discloses that they'll issue for comodoca.com (4.2 of > > their CPS - https://sectigo.com/uploads/files/Comodo-CA-CPS-4-2.pdf ; > > section 4.2.4), therefore they've met the requirements. > > > > I agree that sectigo hosts a CPS which meets the requirements for them > > to issue a certificate for the website. The issue is different here, > > though. > > > > The apparent signee (ComodoCA/Sectigo) has issued their CPS here > > (https://sectigo.com/legal , https://www.comodoca.com/en-us/legal/ ), > > latest version both being 4.2, which mentions (in section 7.1.1 > > ) that the certificates > > will be issued according based on the CPS, Appendix C, which only > > includes 'O=Comodo Limited'-, 'O=Comodo CA Limited'- and 'O=The > > USERTRUST Network'-issuer certificates. > > > > As the signee of my certificate is not included in any way or form in > > the CPS of neither ComodoCA nor Sectigo, this would _not_ qualify as a > > certificate signed according to ComodoCAs nor Sectigos CPS (using a > > strict reading), and as such this would be an indication of a rogue > > intermediate certificate authority (if that is the correct term). > > > > Please advise > > > > It appears that the "Sectigo RSA Organization Validation Secure Server CA" > was issued on 2-November, after Sectigo last updated their CPS (version 4.2 > is dated 5-October). Using that new intermediate CA certificate to sign > subscriber certificates prior to updating the CPS does seem like a problem, > although I can't point to a specific requirement that forbids doing so. > Mozilla policy section 5.3.2 requires all new intermediate CA certificates > to be disclosed in CCADB within one week of creation, and that was done > properly by Sectigo. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy 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: Violation report - Comodo CA certificates revocation delays
I understand the OP's concern and will respond to the bug shortly. Regards Robin Alden Comodo CA Ltd. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: localhost.megasyncloopback.mega.nz private key in client
Hi Hanno, The certificate has been revoked. We're in the process of migrating our email addresses to all be on comodoca.com and the emails for ssl_abuse@ got directed away from the monitored queue we have in place for it. We didn't notice it straight away because there are some other variants of the abuse email addresses which are still active and were still receiving mail. This was corrected and this certificate was revoked after checking the key. Regards Robin Alden Comodo CA Ltd. > -Original Message- > From: Hanno Böck > Sent: 08 August 2018 15:18 > Cc: Alex Cohn ; summern1...@gmail.com; mozilla- > dev-security-policy@lists.mozilla.org; #SSL_ABUSE > > Subject: Re: localhost.megasyncloopback.mega.nz private key in client > > On Sun, 5 Aug 2018 15:23:42 -0500 > Alex Cohn via dev-security-policy > wrote: > > > The certificate [1] in the GitHub link you posted was issued by > > Comodo, not by GeoTrust. The two share a private key, though, so both > > the Comodo and GeoTrust certs should be considered compromised at this > > point. I've added the Comodo-issued cert to several CT logs for > > tracking, and I'm CCing ssl_ab...@comodoca.com for followup. > > As of today this is still unrevoked: > https://crt.sh/?id=630835231=ocsp > > Given Comodo's abuse contact was CCed in this mail I assume they knew > about this since Sunday. Thus we're way past the 24 hour in which they > should revoke it. > > -- > Hanno Böck > https://hboeck.de/ > > mail/jabber: ha...@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 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
Incident Report - Domain validation by CNAME with omitted underscore
f/latest/Domain%20Control%20Validation.pdf, but in brief is this: "When using DNS CNAME based DCV, the Request Token should appear as successive labels in the CNAME RDATA (i.e. the right hand side of the DNS CNAME definition). The format is always of the form: '_' . CNAME .[.]comodoca.com." The 'hashes' there, both MD5 and SHA-256, are of the PKCS#10 certificate request. The variant without the underscore differed only in the omission of the initial underscore. While this was not strictly compliant with the BRs, certificates issued using this method do not pose an urgent security concern as the DCV method used provides as high a degree of certainty that the applicant controlled the certified domain as it would have done had the underscore been included. 6) Why we didn't spot it until now. One of the individuals involved in originally misinterpreting this portion of the BRs in Q2 and Q3 2017 was also responsible for our 2018 BR compliance review and repeated the original interpretation. 7) Resolution steps 2018 May 18 17:20 (UTC+1) - Code released to live. We have removed the implementation variant of the DCV check under 3.2.2.4.7 that permitted the underscore to be omitted. Some of our websites and documentation still present the "CNAME CSR Hash 2" validation method - but this cannot now lead to validation of the domain unless the underscore is present. We will remove all mentions of "CNAME CSR Hash 2" from our public facing systems over the next few days. Within the next 30 days we will have different Comodo CA staff perform a fresh BR compliance review to help ensure that no other misunderstandings of the BRs persist. We are grateful to Andrew Ayer for the problem report. Regards Robin Alden CTO for SSL Email: robin.al...@comodoca.com ComodoCA.com ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: .tg Certificates Issued by Let's Encrypt
Hi Kathleen, Comodo issued a number of certificates to .tg domains during the period of interest. We see a history of applications for .gouv.tg certificates which we had been previously been rejecting and suddenly in the period of interest we issued them - which might support the notion of the .tg registry being compromised. It could, of course, also indicate a sudden burst of activity by the Togo government in setting up websites. It is hard to tell. We issued certificates including around 170 names matching .gouv.tg. Issued names certificates 19/06/2017 2 1 01/08/2017 1 1 25/10/2017 31 7 26/10/2017 46 15 27/10/2017 7 3 28/10/2017 8 4 30/10/2017 19 8 31/10/2017 20 4 01/11/2017 12 2 02/11/2017 9 3 03/11/2017 8 4 04/11/2017 5 2 and that's when we blocked .tg. When we first got a heads-up about this we looked at the data and I said that it looked to me like 25th October was the transition to chaos, since that is when we issued the first of many gouv.tg certificates. I hope that helps a little. Regards Robin Alden Comodo CA Ltd > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+robin=comodo@lists.mozilla.org] On Behalf Of Kathleen Wilson > via dev-security-policy > Sent: 14 November 2017 16:31 > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: .tg Certificates Issued by Let's Encrypt > > On 11/14/17 4:34 AM, douglas.beat...@gmail.com wrote: > > > > Do we believe that this issue has been resolved by the Registry and issuance > an resume as normal, or are there ongoing concerns which CAs should be > aware of when issuing certificates to .tg domains? > > > > > Based on information from folks that are monitoring their NS Records, we > believe that the .tg Registry problems were fixed on November 1, and > have remained fixed since then. > > I have not looked into how Registries are operated and maintained, so > here is my personal (uneducated) opinion: I think it is possible that > the .tg Registry could be compromised again. I have no idea if all of > the newer Registries are using good network and security protocols, > infrastructure, etc. > > I think that we will need to have much deeper investigation and > discussions about Registries, so I have added this to my to-do list, but > I will not be able to get to it until January. > > Thanks, > Kathleen > > > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy 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: Francisco Partners acquires Comodo certificate authority business
Peter, As you noted in your post to the cryptography list, Francisco Partners' website states that they exited from their investment in Blue Coat. https://www.franciscopartners.com/investments/blue-coat?sector=Comms-Securit y=1200 Regards Robin Alden Comodo > -Original Message- > From: Peter Gutmann > via dev-security-policy > Sent: 01 November 2017 04:08 > To: mozilla-dev-security-pol...@lists.mozilla.org; m...@flanga.io > Subject: Re: Francisco Partners acquires Comodo certificate authority business > > mw--- via dev-security-policy <dev-security-policy@lists.mozilla.org> writes: > > >So they sell multiple roots over to a company that is "the leader in Deep > >Packet Inspection (DPI) and we've got a lot going on in that space" and > >enable them to issue trusted certificates and mitm all encrypted connections > >with that? That is a good halloween joke! > > Francisco Partners is more a general investment company, but in that regard > they also have a stake in firms like Blue Coat, whose products have been used > by repressive regimes against their citizens. > > Still, it's amusing that a perfect mechanism for performing MITM attacks is > now controlled by a company who has other arms that actively perform MITM > attacks. > > Peter. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy 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: Francisco Partners acquires Comodo certificate authority business
> -Original Message- > From: Gerv > Subject: Re: Francisco Partners acquires Comodo certificate authority business > > On 31/10/17 13:21, Kyle Hamilton wrote: > > http://www.eweek.com/security/francisco-partners-acquires-comodo-s- > certificate-authority-business > > Comodo notified Mozilla of this impending acquisition privately in > advance, and requested confidentiality, which we granted. Now that the > acquisition is public, it is reasonable for the community to have a > discussion about the implications for Mozilla's trust of Comodo, if any. http://www.businesswire.com/news/home/20171031005584/en/Francisco-Partners-A nnounces-Acquisition-Comodo%E2%80%99s-Certificate-Authority We can confirm that a majority stake in Comodo CA Ltd. has been acquired by Francisco Partners. The deal has closed, i.e. the transaction is complete. We are conscious of the requirements of section 8 of the Mozilla Root Store Policy. As you have seen from the announcement, we have a new CEO and new Chairman who have prior experience in managing a trusted CA organization. There are to be no resultant changes to our CPS, our operations, our business policies or procedures, or the secure locations from which we operate our CA infrastructure. The operational personnel in Comodo CA Limited will not change. The certificate validation teams will remain unchanged. Regards Robin Alden & Rob Stradling Comodo CA Ltd. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Compliance with 7.1.4.2.1 (internal names revocation)
Hi Nick, I expect that our auditors would have noticed and reported if we had not tried to comply with 7.1.4.2.1. Our next WebTrust audit starts shortly and I anticipate that the criteria used will be "WebTrust Principles and Criteria for Certification Authorities - SSL Baseline with Network Security - Version 2.1" http://www.webtrust.org/principles-and-criteria/item83666.pdf Those criteria specifically call out 7.1.4.2.1 and the 1 October 2016 date. Regards Robin Alden Comodo > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+robin=comodo@lists.mozilla.org] On Behalf Of Nick Lamb > Sent: 09 January 2017 16:41 > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Compliance with 7.1.4.2.1 (internal names revocation) > > On Monday, 9 January 2017 14:05:25 UTC, Robin Alden wrote: > > Nick, > > Thanks for the heads-up. > > We agree that the certificates you found should have been revoked. > > Thank you Robin for investigating this, for your explanation of what > happened and for the sensible response of CT logging and revoking the > affected certificates. Please pass on my thanks to any additional people at > Comodo who made that happen. > > It would also be good to know (if you have relevant insight) whether you > would expect your auditors to > > a) Notice and report if Comodo had not even tried to comply with this > element of 7.1.4.2.1 > OR > b) Notice and report the type of mistake made here, in which a process was > followed to attempt compliance but it missed a proportion of affected > certificates. > ___ > 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: Compliance with 7.1.4.2.1 (internal names revocation)
Nick,
Thanks for the heads-up.
We agree that the certificates you found should have been revoked.
We revoked a body of certificates on 1st October 2016 in accordance with
7.1.4.2.1.
Regrettably a mistake was made when we created the list of certificates to
be revoked.
As a word of background we track replacement certificates within the
lifetime of a particular certificate order, in part to avoid unnecessary
certificate revocations and associated CRL bloat.
E.g. If a customer requests (and we issue) a certificate C1 for key k1 with
domains d1.dom, d2.com, and subsequently requests (and has issued) a
replacement certificate for C2 {k1, d1.com, d2.com, d3.com} we do not
automatically revoke the prior certificate - although we reserve the right
to do so.
Our error in creating the list of certificates to be revoked was in not
including in that list certificates for which a replacement certificate had
been requested.
We had two people independently, using different methods, produce the list
of certificates to be revoked today to increase confidence in the result.
This has led us to revoke 28 further certificates, including the 2 that you
brought to our attention.
Here are links to the certificates we have revoked today. All but 3 are
newly published today to CT.
https://crt.sh/?id=1246507
https://crt.sh/?id=1825806
https://crt.sh/?id=39425459
https://crt.sh/?id=74893260
https://crt.sh/?id=74893262
https://crt.sh/?id=74893264
https://crt.sh/?id=74893267
https://crt.sh/?id=74893270
https://crt.sh/?id=74893273
https://crt.sh/?id=74893275
https://crt.sh/?id=74893278
https://crt.sh/?id=74893281
https://crt.sh/?id=74893284
https://crt.sh/?id=74893286
https://crt.sh/?id=74893289
https://crt.sh/?id=74893292
https://crt.sh/?id=74893295
https://crt.sh/?id=74893297
https://crt.sh/?id=74893299
https://crt.sh/?id=74893301
https://crt.sh/?id=74893303
https://crt.sh/?id=74893305
https://crt.sh/?id=74893307
https://crt.sh/?id=74893308
https://crt.sh/?id=74893310
https://crt.sh/?id=74893312
https://crt.sh/?id=74893314
https://crt.sh/?id=74893317
Thank you for your diligence.
Regards
Robin Alden
Comodo
> -Original Message-
> From: dev-security-policy On Behalf Of Nick Lamb
> Sent: 06 January 2017 09:52
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Compliance with 7.1.4.2.1 (internal names revocation)
>
> Work continues. After the initial good news, to my surprise the second
> million or so certificates processed threw up some deviations from major
> public CAs
>
> Comodo
> https://crt.sh/?id=1246507
> https://crt.sh/?id=1825806
>
> Verisign / Symantec
> https://crt.sh/?id=1450883
>
> I would appreciate feedback, generally from m.d.s.policy participants
about
> whether they believe that for some reason these certificates did not need
to
> be revoked to achieve compliance with 7.1.4.2.1 and specifically from
> Comodo and Symantec on why the certificates weren't in fact revoked.
>
> I would also be interested in learning whether auditors would be expected
to
> identify and report this deviation.
> ___
> 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: Comodo issued a certificate for an extension
Nick Lamb, on 02 October 2016 17:50, said.. > The first thing that jumps out at me from their report is that they mistake .sb > for a gTLD when it is actually a ccTLD. That was a mistake in writing the report. The point is that it is a TLD. > The second thing obviously is that they do have exactly the "rule" Richard > Wang described, and they believe this was justified under the BRs old 3.2.2.4 > method 7 (which isn't a method at all, it's basically a catch-all). > > I examined the Comodo CPS and wasn't able to find any mention of this rule. > Indeed based on the CPS I would have assumed that control over a website > www.example.com would under no circumstances be sufficient to get a > certificate for the name example.com from Comodo and I would be grateful > if anyone can point me to where they have written that it is. > I can't speak to your assumptions, but I concede that it is not explicit in the CPS. It is now documented at https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf and in the knowledgebase article at: https://support.comodo.com/index.php?/Knowledgebase/Article/View/791/16/alte rnative-methods-of-domain-control-validation-dcv Regards Robin Alden Comodo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Incident Report - certificate with 'sb' as a SAN:dnsName
Hi Hanno, Hanno Böck, on 04 October 2016 13:34, said.. > There seem to be more certificates of that kind that weren't mentioned > in the incident report. Here's a .re / www.re certificate (expired > 2015): > https://crt.sh/?id=4467456 > > Has comodo checked its systems for other certificates of that kind? Can > you provide a full list of all such certificates? > Yes, we have. The initial check was for certificates issued on or after Nov 1st 2015, that being the date when internal server names were finally outlawed. In certificates issued before that date dNSName=sb could arguably be considered an internal server name (given that https://sb/ isn't supposed to resolve on the public Internet). At any rate, in the interests of getting the incident report out, it was simpler to only go back as far as Nov 1st 2015 so that we didn't have to consider internal server names at all. We took another pass through the data looking for all server authentication certificates where we included DOMAIN, and for which DOMAIN is also included in the PSL or is a TLD, but where we validated (something).DOMAIN instead of DOMAIN. This should produce a superset of all certificates that exhibit this problem. In each case, the (something) was 'www'. Going back to 2011, which was when we started checking the PSL in addition to a (then) fixed list of TLDs, we find the following certificates: Issued PSL section State 25/07/2011 k12.wa.us ICANN expired 25/07/2011 k12.wa.us ICANN expired 12/11/2011 re ICANN expired 10/12/2012 gov.uk ICANN expired 02/05/2013 fredrikstad.no ICANN expired 10/06/2013 k12.wa.us ICANN expired 02/08/2013 ks.ua ICANN expired 30/06/2014 re ICANN expired 28/08/2014 iki.fi PRIVATE Valid (still live on https://iki.fi) 17/06/2015 gov.lk ICANN expired 20/09/2015 net.kg ICANN expired Plus these ones which were already discussed: 26/11/2015 rivne.uaICANN 03/08/2016 tc ICANN 03/08/2016 tc ICANN 03/08/2016 tc ICANN 21/09/2016 sb ICANN Plus three more certificates which turned out to be on the private section of the PSL now, but were not in the PSL when we issued the certificates. > > Also my understanding is that the error here was that control over the > www.[domain] subdomain would indicate control over [domain]. Does that > mean that this bug could've been used to also get wildcard certificates > in the form of *.[tld]? No. Regardless of other controls, the nature of this bug was that it only affected cases where a customer requested www.DOMAIN, because that was the case in which we also added DOMAIN into the SAN. No certificates were issued for *.[tld] Regards Robin Alden Comodo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Comodo issued a certificate for an extension
Eric Mill, on 03 October 2016 03:14, said.. > On Sun, Oct 2, 2016 at 9:23 PM, Nick Lamb <tialara...@gmail.com> wrote: > > On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen wrote: > > > There is some good news. The CA/Browser Forum has already addressed > > > this, even prior to the current discussions. Ballot 169 > > > (https://cabforum.org/2016/08/05/ballot-169-revised- > > validation-requirements/) > > > revises 3.2.2.4 considerably. > > > > I'm aware of Ballot 169 > > > > > Under the new rules, which should be in > > > effect as of 1 March 2017, validating www. will not be a valid > > > method of showing control of . The name is true for any valid > > > hostname under . The only note is that names in the form > > > _. (that is starting with an underscore) can be > > > used to validate . > > > > I wish I shared your confidence. My expectation is that if we leave this > > as it is, in April 2017 subscribers will still be able to get a certificate > > issued using this lackadaisical validation, and the issuing CA will say > > they feel it's not "really" disobeying the rules, that it's just a > > "technicality" and anyway what's the harm, it's so much more convenient > for > > their customers this way? > > > > Comodo's document never actually says that they're abolishing this "rule" > > as a result of Ballot 169. It lets you choose to draw that implication, by > > specifying that their current practices pre-date Ballot 169's changes, but > > it never says as much. Hence I think Mozilla's rep should take this to > > CA/B, or it should go in one of the bulk CA communications, to find out at > > least how widespread the crazy is and whether it's even consistent in how > > it works from one CA to the next. > > > > It would be nice for Comodo to make it explicit that this practice will > cease when Ballot 169 takes effect, and the lack of an explicit update > jumped out at me immediately when I read it. But the BRs post-169 seem > crystal clear on this, and I don't think CAs would be able to write off > this practice as a technicality or misinterpretation. > > -- Eric I'm happy to state definitively that this practice will cease when Ballot 169 takes effect. To avoid suggestions of weasel-words around the CA/B forum's struggle with their IP policy my understanding is that at least Microsoft, and I hope other browsers too, will incorporate the Ballot 169 wording into their policy regardless of whether the CA/B has ratified it by then. Comodo will have implemented some or all of the new validation methods described in Ballot 169 before 1 March 2017. Comodo will be withdrawing any and all validation methods which do not conform with Ballot 169, and/or which rely on the pre-Ballot 169 3.2.2.4.7 'any-other-equivalent method' rule before 1 March 2017. Regards Robin Alden Comodo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Incident Report - certificate with 'sb' as a SAN:dnsName
Gervase Markham, on 04 October 2016 07:10, said.. > Thank you for this report. > > On 27/09/16 02:07, Robin Alden wrote: > > When we use an 'agreed-upon change to website' method to prove > domain > > control, we consider proof of control of 'www.' as also > > proving control of '' (except where '' is a > > public suffix). > > We don't give any other sub-domain this treatment, only 'www'. > > We believe that the currently enforced and audited (pre-ballot 169) BRs > > permit us to do this under section 3.2.2.4 method 7. > > 3.2.2.4 section 7 says: > > "Using any other method of confirmation, provided that the CA maintains > documented evidence that the method of confirmation establishes that the > Applicant is the Domain Name Registrant or has control over the FQDN to > at least the same level of assurance as those methods previously described." > > Where does Comodo's documentation of this methodological equivalence > reside? Is it in your CP/CPS or elsewhere? Could you share it with us > please? It previously existed only in unpublished documentation, so far as I am aware. Our auditors were aware of it. Our validation and support staff have freely offered this information to assist customers in getting certificates validated and issued. It is now publicly documented at https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf and in the knowledgebase article at: https://support.comodo.com/index.php?/Knowledgebase/Article/View/791/16/alte rnative-methods-of-domain-control-validation-dcv Regards Robin Alden Comodo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Incident Report - OCR
> -Original Message- > From: Ryan Sleevi > Sent: 21 October 2016 16:06 > > As pointed out in https://bugzilla.mozilla.org/show_bug.cgi?id=1311713 , it > does seem like there's a rather large gap here between notification and report > - from 23 Sept to Oct 19. > > While it's entirely reasonable that Comodo wanted to ensure that, before > disclosing any incident, that systems were properly protected - and, indeed, > it's fairly typical in other disclosure circles to ensure vendors have time to > remediate - could you explain a bit more about how that time was spent? > ___ Hi Ryan, The security researchers contacted us on 23rd September and intimated that they had a disclosure to make. There were some negotiations over the terms on which the information would be shared and released and we obtained the report from them on the 28th September. We stopped using the OCR system on 28th September. On 4th October we received a draft article from the security researchers which there were planning to send to heise.de. On 15th October we had the first complete draft of our own report and it was approved and published on 19th October. I apologize for the tardy production and release of our report. Referring to the release of our report rather than our internal response to the report we received, there were too many fingers in this particular pie and that made for a slow release of information. Regards Robin Alden Comodo 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
Incident Report - OCR
SUMMARY: Comodo was informed by security researchers Florian Heinz and Martin Kluge that on 23rd September 2016 they had been able to obtain a server authentication certificate [1] from Comodo for a domain which they did not own or control. The researchers shared their discovery with Comodo and this assisted Comodo to ensure that no further such certificates were issued. DOMAIN CONTROL VALIDATION One of the methods that Comodo uses to validate that a certificate applicant owns or controls a domain to be included in the subjectAlternativeName of a server authentication certificate is set out in the CA/B Forum's Baseline Requirements document [2] at section 3.2.2.4.2. That method may be summarized as the sending of an email to an email address (and obtaining a confirming response) where the email is identified as belonging to the Domain Name Registrant, technical contact, or administrative contract as listed in the WHOIS record of the domain. For the TLDs .eu and .be the registries offer only a redacted port 43 WHOIS service which does not include the contact email addresses. They also offer a web-based WHOIS service which presents the contact email addresses, but which does so in the form of a graphical image in a page instead of text. For these TLDs (.eu and .be) we were using an OCR system to read the contact email addresses. The researchers disclosed to Comodo that, while obtaining a certificate from Comodo for a domain that they did control, Comodo's certificate application process presented them with an email address which was not the same as they had registered in WHOIS but which was substantially similar. They inferred from the nature of the difference between the email addresses that the difference was due to an error in reading the email address, most likely by OCR (Optical Character Recognition). They verified that the error in transcribing the email address led to a vulnerability in the certificate application process by identifying a domain name which was also subject to the OCR transcription error and, by registering a domain with the name produced by the transcription error, were able to obtain a certificate from Comodo for the domain name which was subject to the transcription error despite them not controlling it. The domain that they used for their proof of concept was a1-telekom.eu The registrant email address in the WHOIS entry was domain.bill...@a1telekom.at <mailto:domain.bill...@a1telekom.at> which was misread by OCR as domain.bill...@altelekom.at <mailto:domain.bill...@altelekom.at> (the "1" in a1telekom.at was detected as a lower case 'L') IMMEDIATE RESPONSE Comodo's immediate response to the disclosure was to revoke the identified certificate and to disable the use of OCR in the interpretation of WHOIS responses for the validation new certificate requests. INVESTIGATION OF SCOPE Comodo used an OCR system to interpret WHOIS information from 2 TLDs. The TLDs were .be and .eu . Comodo used OCR for the WHOIS on these two domains between 27-JUL-2016 and 28-SEP-2016. Comodo is performing a thorough review of all server certificates issued by Comodo between those dates for domains on the .be and .eu TLDs which used the domain control validation method described in 3.2.2.4.2 of the BRs. The review is ongoing but no other examples have been found of certificates issued as a consequence of OCR mis-reads. WHOIS Comodo notes that the port 43 WHOIS service provided by most registries is a valuable source of information for CAs and for other parties who have a legitimate need to contact domain name registrants. Some domain registrars provide registrants with a means to effectively opt-out of having their contact details made public through the port 43 WHOIS server, or otherwise, by providing a 'privacy' or 'anonymization' service whose details appear in the WHOIS results for the domain instead of those of the registrant. Comodo understands that some registrants will not want to be identified and supports their right to a choice as to whether they should be identified in WHOIS. Comodo understands that some registries do not offer a port 43 WHOIS service because they are not able to do so. There are some registries for small or poor regions where we cannot expect technical excellence. Comodo finds it regrettable that some registries choose to offer a port 43 WHOIS service which redacts information for all registrants which even the registry themselves would normally consider to be public. We find it even more regrettable that a sub-set of those registries refuse to consider offering unredacted access to that information even when contractual and/or commercial terms (including binding restrictions on the use of that information) are offered. Robin Alden Comodo CA Ltd. [1] https://crt.sh/?id=47045653 [2] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf [3] http://w
RE: Comodo issued a certificate for an extension
Hi All, We did receive a direct report of the problem yesterday (24th September) from a Mozilla rep., thanks, and we undertook an investigation and remediation exercise yesterday. The software problem which caused or allowed this certificate to be issued has been corrected. That certificate (https://crt.sh/?id=34242572) was revoked yesterday morning. We will issue a report tomorrow (26th September). Regards Robin Alden Comodo > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+robin=comodo@lists.mozilla.org] On Behalf Of Peter Bowen > Sent: 25 September 2016 17:37 > To: Nick Lamb <tialara...@gmail.com> > Cc: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Comodo issued a certificate for an extension > > On Sun, Sep 25, 2016 at 9:19 AM, Nick Lamb <tialara...@gmail.com> wrote: > > On Sunday, 25 September 2016 15:35:07 UTC+1, mono...@gmail.com > wrote: > >> am I the only one who a) thinks this is slightly problematic and b) is > surprised that the cert still isn't revoked? > > > > I don't know enough about the .sb ccTLD to be clear how problematic the > described scenario is. I would certainly like to know more. Wikipedia tells me > that .sb is operated like .uk used to be, with registrant domains appearing > only as 3LDs e.g. you used to able to buy example.co.uk but not example.uk, > so that having control of example.sb is itself exceptional, let alone www.sb > > According to https://nic.net.sb/, which is linked from > http://www.iana.org/domains/root/db/sb.html: > > "Starting from February 12, 2016 Solomon Telekom Company Limited is > pleased to announce the extending of .sb domain space place by > allowing registrations directly at the ‘second-level’." > > So it appears that the scenario is that someone (presumably the > reporter of this issue) registered www.sb., a second level domain > name, which would be in accordance with the described change. > > > It is important to me - as a relying party - to know if there is a problem > > in > Comodo's domain validation which allows people to obtain certificates for > names which they do not (or perhaps, depending how .sb is run, even > cannot) control. It is not terribly important to me in principle which names > are > affected, but in practice the extent of the risk might influence Mozilla's > decision as to what if anything should be done, by them or by Comodo. > > > > However right now it's the weekend, people who do this stuff as their day > job, rather than an outside interest, may not have responded because > they're busy watching televised sports or baking cakes. I will grow more > concerned if there's no follow-up from anybody next week. > > It is unclear if this has been reported to the CA (Comodo). While > some CA operators do read this Mozilla forum, it is not an official > communication channel for any CA, as far as I know. Any request to > revoke a certificate needs to be sent to the address specified by the > CA in their CPS. > > Thanks, > Peter > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy 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: Server certificate domain validation bug
Hi Nick, Sorry for the slow reply. > -Original Message- > From: Nick Lamb > Sent: 30 July 2016 00:04 > To: mozilla-dev-security-pol...@lists.mozilla.org > > Hi Robin, > > On Friday, 29 July 2016 18:54:56 UTC+1, Robin Alden wrote: > > We received a report of bugs in the construction of the emails we send out > > in order to confirm authorization by the domain name registrant prior to > > issuing a server certificate. > > > > Colloquially these are known as Domain-Control Validation Emails. > > Indeed. A few questions arise. First about this specific occurrence, all > questions are about the state prior to the incident. It's interesting to hear > about things which have changed, but my focus at first is on how things were > _before_ you knew about this specific problem. > > 1. Did Comodo grasp that these emails were a critical element of their CA > systems? e.g. do you have a document that calls them out as being important > in this way and distinguishes them from marketing communications and > other "fluff" that, though it may be important to your business, is not vital to > the web PKI ? > Hmm, that's one of those 'When did you stop beating your wife?' type questions. Yes, Comodo grasps that these emails are a critical element of the CA system. We treat the sending of these emails differently from marketing communications, although that is not hard since marketing communications come from different systems. We treat the sending of these emails differently from the sending of other emails concerning the certificate lifecycle, precisely because we are aware that they are a critical piece of the validation and issuance process. > 2. Was it impressed upon the software engineers responsible for Comodo's > software which sends these emails how critical this content was ? Were they > given suitable training e.g. based on OWASP in how to make the software > secure against well-known risks like this ? > Yes, the development team that maintains the CA software use a development process that includes review of all code by staff with experience and training in secure coding techniques. > 3. Had Comodo engaged a third party to conduct penetration testing of their > web site https://secure.comodo.com/ ? How often was this testing > done ? Yes. We are required to have this done at least annually. > If so, did that engagement include > these emails as part of the system to be tested ? These emails were generated, sent, received by, and interacted with by the pen testers as part of the pen test. Could we have drawn more attention to these emails for the pen testers as a special area of interest, and will we do so in the future? - yes. > > 4. How long had this bug been present in your production systems, and to > what certainty do you know this answer ? > Since Jan 23rd, 2015. The date is tracked as part of the change control system. > > https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard- > ssl- > > certificates-from-comodo-via-dangling-markup-injection/index.html > > Thanks for the link. > > > We are pleased to report that no certificates were issued contrary to the > > terms of our CPS. > > Two more, this time from the point of view of Comodo after the problem > was reported: > > 5. What methods were actually used to determine whether any certificates > had been issued contrary to the terms? Were those methods independent > of the specific technique used in this incident, or did they assume that this > method was the only possible means by which certificates might be mis- > issued by Comodo at this time ? > Our investigation covered the effects of markup injection into the DCV emails. We retain all details associated with a certificate request in a database. This data is not changed or deleted once a certificate is generated from the request. > 6. Given the timeline established in question 4, were you able to perform > such checks for the whole period affected, or only some of it ? > For the whole period. > > We will be further engaging with external security consultants to ensure > > that our systems remain secure so that we may continue to meet our policy > > obligations. > > Now a final question from the point of view of the incident having happened, > but independent of Comodo itself: > > 7. In your view what new requirements should be imposed on CAs by CA/B > or by the individual trust stores in order to reduce the risk of this sort of > incident in future, whether at Comodo or another CA ? I'm going to decline to suggest what anyone should impose. I would say that having more eyes on the code is always a good thing. Specifying a white-box pen test woul
RE: Server certificate domain validation bug
Hi Hanno, Simplicity is certainly a powerful aid to security. I like the text-only idea for the DCV emails. Not containing any user controlled content is a harder sell, I think, because we really want to give the domain owner all the information we can about the certificate request that has been submitted. We anticipate that in the Enterprise case it is of significant value to the applicant if the DCV email contains some information to assist the recipient of the DCV email to relate the certificate request to his organization's operation. A message such as this could save them a lot of time: "Required for https://svn.bambleweeny.net/trac/Project57/ticket/123, please phone Bob Kahn on extension #2719 if questions arise." Although I can see that this message looks pretty similar "Required for https://phishingsport.darknet/we_have_cookies, please phone Pete McNasty on +963-444-4 if questions arise." and expecting the recipient to tell the difference between the two approaches pre-supposes a non-knuckle-dragging domain administrator. If we pass no user controlled content at all, the problem is that in the Enterprise case the domain administrator doesn't know who (within his organization) originated the certificate request. The domain administrator needs some out-of-band communication with the applicant to be certain that the certificate request originated within his organization. I suppose the problem there is really one of the Enterprise's policy in regard to the approval of issuance of certificates for its domains being up to scratch. Regards Robin Alden Comodo 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
Server certificate domain validation bug
We received a report of bugs in the construction of the emails we send out in order to confirm authorization by the domain name registrant prior to issuing a server certificate. Colloquially these are known as Domain-Control Validation Emails. The security researcher, Matthew Bryant, followed a responsible disclosure process and we were afforded the opportunity to resolve this bug before he published his blog post at https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl- certificates-from-comodo-via-dangling-markup-injection/index.html We are pleased to report that no certificates were issued contrary to the terms of our CPS. We have informed our external WebTrust auditors of the report and of its resolution. We will be further engaging with external security consultants to ensure that our systems remain secure so that we may continue to meet our policy obligations. Regards Robin Alden Comodo This email has also been posted to pub...@cabforum.org <mailto:pub...@cabforum.org> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Name issues in public certificates
Peter said.. > While I realize that it is not clear cut in many contexts, RFC 5280 is > rather clear cut. The authors clearly wanted to avoid stumbling and > being eaten by a grue, so they wrote: > >When the subjectAltName extension contains a domain name system >label, the domain name MUST be stored in the >dNSName (an IA5String). >The name MUST be in the "preferred name syntax", as specified by >Section 3.5 of [RFC1034] and as modified by Section 2.1 of >[RFC1123]. > > This makes it clear that the "preferred name syntax" is not a > recommendation when it comes to certificates. It is mandatory. Ah, but the lead-in there is "When the subjectAltName extension contains a domain name system label," weird_place.example.com is not a domain name system label. It is not expected to (and likely does not, and maybe could not) resolve to an IP address on the public internet. In practice, the people to whom weird_place.example.com is a useful name will be running Microsoft kit which is very happy with an underscore in a name. All that matters to them is that weird_place.example.com resolves within their environment. The CAB Forum BRs can be met in the validation of such a certificate providing that ownership or control of example.com is shown in the approved methods. The BRs place no requirement on the full name weird_place.example.com appearing on the internet or being accessible by the CA. Regards Robin 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: Policy about root cert transfers
Brian Howson said.. . I'm not sure if this should be additions to the original inclusion request or a new request, that might depend on whether it is wholesale (like today's Digicert acquisition of Verizon) or piecemeal (like the one root Amazon acquired from Comodo). Amazon have not acquired a root from Comodo. Regards Robin Alden Comodo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Consequences of mis-issuance under CNNIC
Peter Gutmann said.. I was using IT news stories as the source, e.g. IDG's 'Secure' advertising tool PrivDog compromises HTTPS security: Instead, the problem was tracked down to another advertising-related application called PrivDog, which was built with the involvement of Comodo's CEO, Melih Abdulhayoglu. New PrivDog releases are announced on the Comodo community forum by people tagged as Comodo staff. That does sound like there's Comodo involvement. It does sound that way, and we have shipped some versions of PrivDog with some of our products. You may even find an IT news story that says it in your exact words, but that doesn't make 'Comodo provided the PrivDog MITM software' a correct statement. Regards Robin ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Consequences of mis-issuance under CNNIC
Peter Gutmann said.. Daniel Micay danielmi...@gmail.com writes: CNNIC is known to have produced and distributed malware for the purpose of mass surveillance and censorship. TeliaSonera aided totalitarian governments, Comodo provided the PrivDog MITM software, and that's just the first two off the top of my head. If you have solid evidence that other CAs do this, feel free to present and I'll be a loud supporter of ripping out their certificates too. We'll start with Comodo then, shall we? Hi Peter, Your assertion about Comodo is wrong and that blunts your point instead of helping you make it. I refer you to my previous statement on Privdog. https://cabforum.org/pipermail/public/2015-February/005095.html and Hanno's post to this list https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg01 544.html Robin ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: address prefixes allowed for domain control validation
I wonder if the current publicity will lead all webmail providers to do a review, and then we won't see any further problems... That would be nice! Pertaining to Peter Bowen's suggestion that some CAs who use email authentication could provide statistics on what percent of customers choose each option., Comodo finds that those 5 options are very popular with applicants for SSL certificates. Of all email-based domain control validation we perform those email addresses (on the same domain being applied for) are used as follows: admin@ 33.9% hostmaster@ 7.8% webmaster@ 7.6% administrator@ 7.5% postmaster@ 4.5% Regards Robin Alden Comodo 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: address prefixes allowed for domain control validation
Robin said.. Of all email-based domain control validation we perform those email addresses (on the same domain being applied for) are used as follows: admin@ 33.9% hostmaster@ 7.8% webmaster@ 7.6% administrator@ 7.5% postmaster@ 4.5% Gerv said.. I'm sure there's an obvious reason, but why doesn't this add up to 100%? Is it because the other validations use an email address sourced from WHOIS? Yes, exactly so. Of all email-based DCV we do, 69.4% use an email address on the same domain as the certificate is being purchased for (allowing for pruning, too). Of those 69.4%, most use one of those 5 email addresses mentioned in the BRs as detailed above which add up to 61.3% of the total. The difference, being (69.4% - 61.3% =) 8.1% of the total use an email address on the same domain as the certificate but not one of the above 5. This is only permitted when that email address is sourced from WHOIS. #6 on the list is info@ with ~0.5% The rest, being (100% - 69.4% =) 30.6% use email addresses on a different domain, and these are only permitted when that email address is sourced from WHOIS. Do the above percentages include some where the email is sourced from WHOIS but happens to match the permitted five? I think they must include some, yes. I'll see if we have some data to give a ballpark figure as to how often that is the case. Robin 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: KIR S.A. Root Inclusion Request
Hi Przemyslaw, 1) Suspension I can see that it's no problem for a certificate's status as shown in OCSP or in a CRL (as viewed from outside your organization) to transition from valid to 'Revoked' as a result of a 'suspension' within your system. The problem comes when you try to 'unsuspend'. You can't transition back from 'revoked' to valid. http://www.ietf.org/rfc/rfc5280.txt 3.3. Revocation ... An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period. Regards Robin Alden -Original Message- From: dev-security-policy [mailto:dev-security-policy- bounces+robin=comodo@lists.mozilla.org] On Behalf Of Certificates Sent: 25 September 2014 14:03 To: dev-security-policy@lists.mozilla.org Subject: Re: KIR S.A. Root Inclusion Request Answers for Jeremy Rowley questions: A couple of notes: 1) Under Section 3.4 and 4.9, suspension is not permitted for SSL certs under the BRs. Where the BR forbids certificates suspension? The Repository gives an answer revoke for suspended certificate, so it's consistent withe BR s13.2.7. 2) Section 3.3 should specify when re-verification is required (at least every 39 months). Although the CPS does say the original issuance process is followed, I didn't this specified at the certificate lifecycle is 5 years. Also, be aware that five year certs are only permitted until April 1, 2015. After that, the maximum lifecycle is 39 months Yes, we know about this requirement. Presently, we do not issue certificates above 2 years validity period, although we mentioned such possibility in CPS. We do verification both for first certificate and renewal, in particular we verify rights to domain for SSL certificates. Our internal procedures describe this process in details. 3) See section 13.1.5 of the BRs for the reasons a CA must revoke a certificate. Section 4.9 of your CPS doesn't really match these. The reasons for revoking subscriber certificate pointed in CSP corresponds to the reasons pointed in BR. But if the connection isn't clear we can clarified it more in CSP by introducing some changes. 4) Archiving is required for 7 years under the BRs (5.4.3 and 5.5). That's a mistake in CPS. We will change it. 5) 6.28 should require at least two individuals acting together to activate the private key It is done by two persons. It is mentioned in CPS s.6.2.2 that the secrets are distributed among 5 persons. CSP s6.2.6. Uploading a private key to cryptographic modules is done in the following situations: 1) launch of the certification authority during the system start-up; 2) recovery of the key of the certification authority in the back-up location; 3) replacement of the cryptographic module. The key is uploaded to the module with the presence of the holders of co-shared secrets. To upload the key it is necessary to have the presence of the number of secrets described in Clause 6.2.2. Uploading is done within a closed security environment. A private key is made up of elements. Parts of the secret key from the cards are provided in sequence, enciphered files are uploaded into the module's memory and then deciphered. A private key is ready to use. Uploading of the key into the module is recorded in the register of events. CSP s.6.2.8 Once uploaded into the module, the key shall be active. 6) Some of your EKU extensions are not permitted in the same certificate. We are aware of it. In the SSL certificates we use only clientAuthentication and serverAuthentication. 7) Note the recently announced SHA-2 requirement. SHA-1 is the only hash specified in the CPS. 5 year certificates will not be possible. We are aware of it and we will start issuing certificates with SHA 256 before this date and also supplement our CSP accordingly. 8) What is your OCSP response for a not issued cert? The answer is unknown - CSP s4.9.9. Krajowa Izba Rozliczeniowa S.A., ul. rtm. W. Pileckiego 65, 02-781 Warszawa, zarejestrowana w Sądzie Rejonowym dla m. st. Warszawy, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 113064, NIP 526-030-05-17, REGON 012105474, kapitał zakładowy i wpłacony 5.445.000 zł. Informacja zawarta w tej transmisji jest przeznaczona tylko dla osoby lub jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i poufne informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie można kopiować, rozpowszechniać lub podejmować żadnych czynności w oparciu o nią. W przypadku otrzymania tej transmisji przez pomyłkę, proszę powiadomić nadawcę za pomocą emaila zwrotnego i usunąć tę transmisję (wraz z załącznikami) z Państwa systemu. The information contained in this transmission is intended only for the individual or entity to whom it is addressed. It may contain privileged and confidential information and if you
RE: Client certs
Hi Gerv, I can send out a million client certificates for negligible cost. That is especially attractive cost-wise for an existing system that I have to increase the security of (say over username and password), but which has not been identified as needing 2 factor authentication. Sending out a million anythings by snail-mail is spendy. If you could rely on the user already having the number-sequence widget, or of having a virtual widget on their smartphone (like Google Authenticator) then the cost argument is irrelevant. Regards Robin -Original Message- From: dev-security-policy [mailto:dev-security-policy- bounces+robin=comodo@lists.mozilla.org] On Behalf Of Gervase Markham Sent: 25 September 2014 13:29 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Client certs A question which occurred to me, and I thought I'd put before an audience of the wise: * What advantages, if any, do client certs have over number-sequence widgets such as e.g. the HSBC Secure Key, used with SSL? http://www.hsbc.co.uk/1/2/customer-support/online-banking- security/secure-key It seems like they have numerous disadvantages (some subjective): * Client certs can be invisibly stolen if a machine is compromised * Client certs are harder to manage and reason about for an average person * Client certs generally expire and need replacing, with no warning * Client certs are either single-machine, or need a probably-complex copying process What are the advantages? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy 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
Mail list playing up?
Hi, There seems to be some problem with emails getting through the list, for some participants, on some occasions. In the recent thread on this list, entitled Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory Gerv pointed out to me that an email I had sent had not appeared in the Google Groups view of the list. I went through the thread to see what was missing, and recorded which were missing in this spreadsheet: https://docs.google.com/spreadsheets/d/1nRpDJEZqSskdCujL5RdO9kM8caZXrUCm KOSEp0j9Ffk/edit?usp=sharing The posts to this thread by Robin Alden (me), Moudrick Dadashov, and Kyle Hamilton didn't make it to the Google Groups view. This isn't a complaint so much as a heads-up, that the google groups view of the list is broken and if you rely on the Google Groups view you are missing out on parts of the conversation! Perhaps Google Groups throws away posts from people who aren't members of the Google Group. I've joined the google group, to see if the behaviour changes for me. Regards Robin Alden Comodo 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: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.
+1 Robin -Original Message- From: Jeremy Rowley [mailto:jeremy.row...@digicert.com] Sent: 23 July 2014 16:05 To: 'Moudrick M. Dadashov'; 'Robin Alden'; 'Gervase Markham'; nick.l...@lugatech.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory. I agree he was in favor of requiring the BR OIDs, as I think most CAs are. Jeremy -Original Message- From: Moudrick M. Dadashov [mailto:m...@ssc.lt] Sent: Wednesday, July 23, 2014 9:02 AM To: Jeremy Rowley; 'Robin Alden'; 'Gervase Markham'; nick.l...@lugatech.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory. Having these identifiers takes us a long way towards our goal of deterministic evaluation of certificate issuance policy - that said not all CAs have adopted them which is technically alright since the Baseline Requirements do allow them to use their own Policy Identifiers. This is what Ryan said about Policy OID based (Deterministic) approach, I read this as in favor of Policy OIDs. Any other criticism why CAs should not support the Deterministic approach? Thanks, M.D. On 7/23/2014 5:34 PM, Jeremy Rowley wrote: Ryan Hurst wrote a blog post on this very topic not too long ago. His conclusion was that determining, programmatically, the difference was difficult. See http://unmitigatedrisk.com/?p=203. This is mostly because there are some certs that still include a domain in the org field. Requiring a BR OID serves two purposes - 1) the OID is a positive assertion to the browser by the CA that the cert was issued under the BRs and intended for SSL and 2) the OID identifies the sections relied on for validation. The OID assists in auditing whether a CA is aware of its practices and how it is choosing to comply with the BRs. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy- bounces+jeremy.rowley=digicert.com@lists.m ozilla.org] On Behalf Of Robin Alden Sent: Wednesday, July 23, 2014 8:02 AM To: 'Gervase Markham'; nick.l...@lugatech.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: [SPAM] Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory. On 23/07/14 10:06, nick.l...@lugatech.com wrote: The status quo today means that it is not possible to discriminate programatically between a DV and OV certificate in a standardized, reliable way. Gerv said.. This is because Mozilla's position is that, in security terms, there is no relevant difference. That is not the reason. That may be a contributory reason to Mozilla not proposing or supporting the proposition of language to change the BR's 9.3.1 which result in it not being compulsory to include a mandated policy OID in a certificate which would identify it unequivocally as being a DV or an OV certificate, but it is not the definitive reason why the BRs do not mandate it. If the BRs already mandated it I would not expect your opinion or your UI to change, but the OP's question would not have arisen as he would have easily programmatically been able to tell whether a certificate was OV or DV. This is unreasonable as the validation and assurance on such certificates are very different. They are different, but not in a way that is reasonably measurable and auditable. snip If a cert does not meet the EV standards for information validation, we feel you cannot sufficiently trust the O field, and therefore from a security perspective there is no difference between that certificate and one where the O field is absent. Hence we make no UI distinction between OV and DV. Whilst I disagree with your sentiment, in your UI (browser, certificate viewer, mail client, etc.) it's your game, so it's your rules. The compulsory inclusion of a Policy Identifier OID in the certificate definitively stating DV or OV need not offend you, since you will probably continue to ignore it. As to the issue which presumably ignited the thread in the first place, I think that for a non-EV BR compliant certificate you probably can distinguish programmatically between OV and DV. According to section 9.2.4 of the BRs, if the certificate subject contains an organizationName field and also contains one or both of (stateOrProvinceName and localityName) then it is an OV certificate. If the certificate subject does not contain an organizationName field then it is an OV certificate. This begs the question of whether the certificate is claiming to be an EV certificate or claiming to be BR compliant. Regards Robin Alden Comodo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https
