RE: Sectigo: Failure to revoke certificate with compromised key

[Robin Alden via dev-security-policy]

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-
> MIICozCCAYsCAQAwXjEYMBYGA1UECgwPQ29tcHJvbWlzZWQgS2V5MUIwQA
> YDVQQD
> DDlUaGUga2V5IHRoYXQgc2lnbmVkIHRoaXMgQ1NSIGhhcyBiZWVuIHB1Ymxp
> Y2x5
> IGRpc2Nsb3NlZC4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD
> L7fFo
> EIq/60Ai9XO9pYiUQc7vFnpNKjlSeRyjljddtaZhVH3GAewEQUbihrLhNvFMX4rI
> kuGIpNPoBLb9bjrzVWm0pLkCjpF2oJVlHhlFJDDT6iELf7BlSz7EJEJUjdRGAYGv
> LsrLYURi2zqMjgJkbuRC3LmkwGl6/tnMlibQotpSnEcyosLA8ySk0k6raUxnbEyD
> 

RE: Sectigo: Failure to revoke certificate with compromised key

[Robin Alden via dev-security-policy]

> > 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

[Robin Alden via dev-security-policy]

> .. 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

[Robin Alden via dev-security-policy]

> -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

[Robin Alden via dev-security-policy]

> 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

[Robin Alden via dev-security-policy]

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?

[Robin Alden via dev-security-policy]

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

[Robin Alden via dev-security-policy]

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

[Robin Alden via dev-security-policy]

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

[Robin Alden via dev-security-policy]

This same information has also been posted to 
https://bugzilla.mozilla.org/show_bug.cgi?id=1461391

Andrew Ayer reported this problem report to mailto:sslab...@comodoca.com:

<<<
I was able to obtain a certificate from Comodo that was not properly
validated under the Baseline Requirements, as follows:

1. Visit https://www.positivessl.com/ and click "Try Now" under "Free SSL 
Certificate".

2. Provide a CSR for the FQDN dcv.party.

3. On the next page, select "CNAME CSR Hash 2" as the method of Domain Control 
Validation.

4. Publish the following DNS record:
ae104fe977c36b235260d331c949b8ca.dcv.party. CNAME 
7b4c2cd1009045dc12d3e8b0c3d02912.406b5877e3a9f1eda4b7d8253ac1eb18.comodoca.com.

5. Complete the form and submit the order.

6. Receive a valid certificate for dcv.party and www.dcv.party (attached).

Section 3.2.2.4.7 ("DNS Change") of the BRs says:

"Confirming the Applicant's control over the FQDN by confirming the presence of 
a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record 
for either 
1) an Authorization Domain Name; or 
2) an Authorization Domain Name that is prefixed with a label that begins with 
an underscore character."

Since ae104fe977c36b235260d331c949b8ca.dcv.party is not an Authorization Domain 
Name for (www.)dcv.party, nor is it an Authorization Domain Name that is 
prefixed with a label that begins with an underscore character, this 
certificate was not properly validated.
>>>

Incident report:

1) How Comodo CA first became aware of the problem
We were informed by an email from Andrew Ayer to our abuse email address 
mailto:sslab...@comodoca.com at 18:50 BST (UTC + 1) on Monday 14th May.

2) A timeline of the actions Comodo CA took in response. 

2017 July 11 - We introduced our new implementations of DCV methods designed to 
meet the requirements of the CA/B Forums BR's version 1.4.1 section 3.2.2.4, as 
required by Mozilla.
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a05o03WrzBC
(See Action #1 in that link)

2017 July 13 - We reviewed version 1.4.1 of the BRs along with the then 
in-process ballots in the CA/B Forum.
We determined that the underscore at the start of the CNAME LValue in 3.2.2.4.7 
was optional.  This now appears to have been a mistake.

2017 July 20 - We withdrew our old DCV methods that consciously relied on the 
'Any Other Method'. 

2017 July 20 - In response to complaints from some EU operators who found that 
their DNS web portals would not let them specify a leading underscore in a 
CNAME LValue, we introduced a new DCV variant that permitted the underscore to 
be omitted.

2018 May 14 - Initial problem report received from Andrew Ayer.

2018 May 15 - Code changes prepared to remove the option for the leading 
underscore to be omitted from the CNAME LValue in 3.2.2.4.7 domain validation.
QA begins.

2018 May 18 17:20 (UTC+1) - QA completed.  Code released to live.  No further 
domains will be validated using the flawed method.

3) A summary of the problematic certificates. 
A total of 11099 TLS/SSL certificates were issued that used the variant of 
3.2.2.4.7 that omitted the leading underscore.
The earliest such certificate was issued on 2017 July 20.
10993 of those TLS/SSL certificates remain unexpired and unrevoked.

4) The complete certificate data for the problematic certificates. 
This is a list of all of the unexpired certificates:
https://docs.google.com/spreadsheets/d/1ZW-YdrjeoUsMpTY0CW3f2D59Bl188K398oda7qTUM1Q/edit?usp=sharing

5) How and why we came to issue these certificates
When implemented code to remove our reliance on the old 'Any other method' 
domain validation section 3.2.2.4.11 in May, June, and July 2017, the 
then-current version of the BRs did not actually contain any of the new DCV 
methods.  Mozilla had requested compliance with 3.2.2.4 from version 1.4.1 
which was issued in September 2016.  That version including the 'blessed' 
methods - albeit somewhat out of date.
In 2017 July we misinterpreted the words 
"for an Authorization Domain Name 
  or an Authorization Domain Name that is prefixed with a label that begins 
with an underscore character" to mean
"for an Authorization Domain Name prefixed with a label 
  or an Authorization Domain Name that is prefixed with a label that begins 
with an underscore character".
With hindsight we agree that this interpretation of the BRs was incorrect.

We added the variant of 3.2.2.4.7 without the underscore in response to 
customer requests and mistakenly believed it to be a permitted variation when 
we implemented it.

Our implementation of 3.2.2.4.7 (with or without underscore) has always 
required that a request-specific label is prefixed to the Authorization Domain 
Name as part of the Request Token.
Our syntax for constructing the CNAME to pass validation is documented in
https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf, but 
in brief is this:
"When using DNS CNAME 

RE: .tg Certificates Issued by Let's Encrypt

[Robin Alden via dev-security-policy]

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

[Robin Alden via dev-security-policy]

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 
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

[Robin Alden via dev-security-policy]

> -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