Re: Cerificate Concern about Cloudflare's DNS

[gerhard . tinned]

On Wednesday, November 2, 2016 at 11:42:00 PM UTC+1, Kristian Fiskerstrand 
wrote:
> On 11/02/2016 11:38 PM, Peter Kurrasch wrote:
> > This raises an interesting point and I'd be interested in any comments
> > ‎that Comodo or other CA's might have.
> > 
> 
> It really seems like a matter of discussion for the terms of agreement
> and interaction between the user and service provider, and not a CA matter.
> 

This is true in general. But when the used practice of validating a domain is
possible against the will and knowledge of the domain owner, ... I guess that
puts the CA in trouble at some point as well. Even if it is only in form of a
loss of trust.

> 
> -- 
> 
> Kristian Fiskerstrand
> Blog: https://blog.sumptuouscapital.com
> Twitter: @krifisk
> 
> Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> 
> Aurum est Potestas
> Gold is power
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[gerhard . tinned]

On Wednesday, November 2, 2016 at 11:39:09 PM UTC+1, Peter Kurrasch wrote:
> This raises an interesting point and I'd be interested in any comments ‎that 
> Comodo or other CA's might have.
> 
> 
> It appears we have a situation where a cert is being issued to what is 
> presumably an authorized party yet that party is not actually authorized by 
> the subscriber. How does Comodo or any other CA validate that a "domain 
> manipulator" has been and continues to be authorized by the actual domain 
> registrant? Is any attestation provided by a party (such as CloudFlare) that 
> they have authorization by their own clients to do whatever they are doing?
> 
> 
> It's in the interest of CA's to ‎have some well thought-out plans here 
> because I think we know who is getting the blame when the system breaks down. 
> I don't think it would sit well if a CA were to come here and say "you can't 
> blame us for the misissuance because we will give CloudFlare any cert they 
> want."
> 
>   
> > 
>   
> > 
>   >   
> From: gerhard...@gmail.com
> Sent: Wednesday, November 2, 2016 4:16 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Cerificate Concern about Cloudflare's DNS
> 
> 
> Hi, 
> 
> > 
> > Since you delegated your DNS server to Cloudflare, you implicitly allowed 
> > them to perform this certificate request on your behalf.
> > 
> > 
> This is where I strongly disagree! I have checked the TOS and Security 
> policy, ... etc. There is nowhere stated that Cloudflare is allowed without 
> the Users knowledge to manipulate there DNS settings. That sad, there is the 
> proxy service they offer which is changing the DNS settings. But as you 
> actively enable it, you are aware. 
> 
> By delegating the DNS server to Cloudflare, you entrust Cloudflare to 
> distribute the User defined DNS settings. To be able to validate for the 
> certificate, the DNS settings are changed without the users knowledge. No TOS 
> or any other policy states this. 
> 
> Even if that might not be issue for the CA itself (which i do not agree on), 
> This is definitely braking the trust to its users.
> 
> And the CA (Comodo) informed about it, and not at least requesting a 
> statement from Cloudflare, means they support this, from my point of view, 
> wrong behavior.
> 
> 
> As it seems the only thing that can be done is move to a different DNS 
> provider!! Still, this is a vialation of trust!!!
> 
> ___
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Thank you. I could not agree more.

Befor I contacted this group, I contacted Cloudflare and asked them to stop
creating certificates with my domain. The answer in short was, ... they cannot
change it and as long as I am using there service, they will continue.

I also contacted Comodo as the CA and asked them. The answer was different but
also not helping. In short, ... I can use a CAA DNS record (not supported by
many DNS providers like Cloudflare) to avoid it in the future. But in the next
sentence telling me that those records are not honoured by many CA's.

I started reading the TOC and policies of Cloudflare again looking for any clue
about this. Nothing. No mention about the certificates that get issued, nothing
about the DNS changes, ... Still everybody tells me something like, "Well if
Cloudflare is doing it, it must be right. Why do you complain?"

It is nice to read a answer like this even if it doe not solve it. :)

Thanks!
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Cerificate Concern about Cloudflare's DNS

[gerhard . tinned]

On Wednesday, November 2, 2016 at 11:34:44 PM UTC+1, Peter Gutmann wrote:
> Tom Ritter  writes:
> 
> >There's been (some) mention that even if a user moves off Cloudflare, the CA
> >is not obligated to revoke.
> 
> Would it matter?  I guess it depends on circumstances (whether you control the
> private key or Cloudflare does, whether you intend to use the same domain
> elsewhere or not, etc), but in most cases it seems like no revocation is
> necessary, you destroy or stop using the private key and that's it.  

That is exactly the point of it, the "domain owner" / "Cloudflare customer" 
does not have or ever get the key of the certificate that was created without 
the knowledge of the domain owner. And Cloudflare will continue using the 
wildcard certificate with a number of domains in them. Oh, and they are valid 
for 2 years!

> Even in
> the worst-case scenario, Cloudflare has your private key and you intend to
> keep using the domain, presumably there's some contractual obligation for them
> to stop using it when you close your account with them.  It seems like a
> revocation isn't necessary (not just for this but for pretty much every
> revocation reason except keyCompromise).
> 
> Peter.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New SHA-1 certificates issued in 2016

[c]

On Saturday, October 29, 2016 at 12:02:54 PM UTC-5, Gervase Markham wrote:
> The scope of the BRs is debateable. These certs are clearly in scope for
> Mozilla policy, as they chain up to trusted roots; however Mozilla
> policy does not (yet) ban SHA-1 issuance other than via the BRs. This
> may be fixed in policy version 2.3.
> 
> Without tls-server-auth and with other EKUs, these certs would not be
> trusted in Firefox. The systemic risks from SHA-1 issuance remain, however.
> 
> Gerv

Gerv,
Given the discussions in the past about risks of SHA-1 issuance for *any* cert 
type, and the responses from action #1c from the March 2016 CA communication, 
are there any public plans for dealing type of certificate yet?
Do these non-server-certs only fall under the BR's sigAlg policy if a generated 
certificate collision has an EKU of server auth? (And by that time, is it too 
late?)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Gervase Markham]

On 02/11/16 23:26, gerhard.tin...@gmail.com wrote:
> Befor I contacted this group, I contacted Cloudflare and asked them
> to stop creating certificates with my domain. The answer in short
> was, ... they cannot change it and as long as I am using there
> service, they will continue.

How would you expect the service to work without them doing that?

> I also contacted Comodo as the CA and asked them. The answer was
> different but also not helping. In short, ... I can use a CAA DNS
> record (not supported by many DNS providers like Cloudflare) to avoid
> it in the future. But in the next sentence telling me that those
> records are not honoured by many CA's.

Hopefully this will change before too long.

However, I still don't get why you want to use Cloudflare's SSL
termination services but are unwilling to allow them to get a
certificate for your domain name.

AIUI their free tier uses certs they obtain, but if you pay, you can
provide your own cert. So if you want to use Cloudflare but don't want
them obtaining certs for you, join the paying tier.

Gerv
___
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 18/10/16 19:15, Rob Stradling wrote:
> Hi Hanno.  The questions that you and others have posted are entirely
> reasonable.  Sorry for the delay.  Robin intends to post a reply this week.

It seems like this reply has not yet appeared?

I would like to make sure my initial question about "Where does Comodo's
documentation of this methodological equivalence
reside? etc." is answered.

And also, how does:

"Today we performed an exhaustive search of all the server
authentication certificates we've issued since November 1 2015, and as a
result we found just one further certificate [6] in which we'd included
a public suffix (rivne.ua) due to this bug."

fit with:
https://crt.sh/?id=4467456
?

Why did you stop searching at Nov 1st 2015? It seems like the bug has
been present for longer...

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

References to key generation guideline across Mozilla

[Tim Guan-tin Chien]

Hi there,

I've already regarding the document here [1] as the updated document
to "how to generate a SSH key", however as my new hires points out
there are other documents out there [2] [3].

Should we be updating [2] [3] and ask everyone to look at [1] instead?

[1] https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Key_generation
[2] https://mana.mozilla.org/wiki/display/SD/Generating+a+SSH+Public+Key
[3] https://www.mozilla.org/en-US/about/governance/policies/commit/
which point to a GitHub tutorial.


Tim
PS Apologies if this is not in-scope for dev-security-policy.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Patrick Figel]

On 03/11/16 10:59, Gervase Markham wrote:
> However, I still don't get why you want to use Cloudflare's SSL
> termination services but are unwilling to allow them to get a
> certificate for your domain name.
> 
> AIUI their free tier uses certs they obtain, but if you pay, you can
> provide your own cert. So if you want to use Cloudflare but don't want
> them obtaining certs for you, join the paying tier.

It is possible to use Cloudflare as a DNS-only provider, without any
CDN/reverse proxying functionality. That's what seems to be the issue
here - certificates are requested as soon as a domain is added to
Cloudflare, even if the CDN functionality is never enabled.

I don't think these certificates are mis-issued or that this practice is
shady, but I can see how it might surprise a domain owner who is only
looking for a DNS provider.

This is probably not something that can or should be resolved by the
CA/B Forum or Mozilla. Realistically speaking, asking CAs to confirm
that the actual domain registrant has authorized the issuance (rather
than whoever is operating the DNS for that domain) is not possible in
practice for DV. Going overboard with such a requirement carries the risk

The only other thing the BRs could ask for is that a subscriber (which
would be Cloudflare in this case) has to include language regarding
certificate issuance in their ToS if they act on behalf of other domain
registrants. However, given that the goal is to avoid surprising the
domain registrant, adding yet another section to a typical ToS document
is hardly going to change anything.

I don't think it's worth optimizing for the "I trust someone to host my
entire DNS zone and hold my DNSSEC keys (if you're into that kind of
thing) but TLS certificates? Boo!"-use-case.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Rob Stradling]

On 03/11/16 09:59, Gervase Markham wrote:
> On 02/11/16 23:26, gerhard.tin...@gmail.com wrote:
>> Befor I contacted this group, I contacted Cloudflare and asked them
>> to stop creating certificates with my domain. The answer in short
>> was, ... they cannot change it and as long as I am using there
>> service, they will continue.
> 
> How would you expect the service to work without them doing that?
> 
>> I also contacted Comodo as the CA and asked them. The answer was
>> different but also not helping. In short, ... I can use a CAA DNS
>> record (not supported by many DNS providers like Cloudflare) to avoid
>> it in the future. But in the next sentence telling me that those
>> records are not honoured by many CA's.
> 
> Hopefully this will change before too long.
> 
> However, I still don't get why you want to use Cloudflare's SSL
> termination services but are unwilling to allow them to get a
> certificate for your domain name.
> 
> AIUI their free tier uses certs they obtain, but if you pay, you can
> provide your own cert. So if you want to use Cloudflare but don't want
> them obtaining certs for you, join the paying tier.

In my experience, joining Cloudflare's paying tier doesn't guarantee
that Cloudflare won't also obtain a free cert.

A few weeks ago we moved crt.sh onto Cloudflare.  It was in the paying
tier from the start, and we uploaded an EV cert straight away.  I was
surprised when https://crt.sh/atom?q=crt.sh alerted me to
https://crt.sh/?id=42619974

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Rob Stradling]

On 03/11/16 12:13, Han Yuwei wrote:
> 在 2016年11月3日星期四 UTC+8下午7:09:48，Rob Stradling写道：
>> On 03/11/16 09:59, Gervase Markham wrote:
>>> On 02/11/16 23:26, gerhard.tin...@gmail.com wrote:
 Befor I contacted this group, I contacted Cloudflare and asked them
 to stop creating certificates with my domain. The answer in short
 was, ... they cannot change it and as long as I am using there
 service, they will continue.
>>>
>>> How would you expect the service to work without them doing that?
>>>
 I also contacted Comodo as the CA and asked them. The answer was
 different but also not helping. In short, ... I can use a CAA DNS
 record (not supported by many DNS providers like Cloudflare) to avoid
 it in the future. But in the next sentence telling me that those
 records are not honoured by many CA's.
>>>
>>> Hopefully this will change before too long.
>>>
>>> However, I still don't get why you want to use Cloudflare's SSL
>>> termination services but are unwilling to allow them to get a
>>> certificate for your domain name.
>>>
>>> AIUI their free tier uses certs they obtain, but if you pay, you can
>>> provide your own cert. So if you want to use Cloudflare but don't want
>>> them obtaining certs for you, join the paying tier.
>>
>> In my experience, joining Cloudflare's paying tier doesn't guarantee
>> that Cloudflare won't also obtain a free cert.
>>
>> A few weeks ago we moved crt.sh onto Cloudflare.  It was in the paying
>> tier from the start, and we uploaded an EV cert straight away.  I was
>> surprised when https://crt.sh/atom?q=crt.sh alerted me to
>> https://crt.sh/?id=42619974
>>
>> -- 
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
> 
> So it is impossible to request a revocation even I do refuse to let 
> Cloudflare issue the certificate of my domain and keep using Cloudflare's DNS 
> service under these rules(CA/B BR and COMODO CPS)?

Comodo does check CAA records, so you could add a CAA record for your
domain that doesn't permit Comodo to issue.  This won't stop Cloudflare
from requesting a free cert, but it should block the issuance of any
requested cert.  (Note however that our CAA checks fail open if there's
an error with the CAA DNS lookup).

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Jakob Bohm]

On 03/11/2016 12:09, Rob Stradling wrote:


In my experience, joining Cloudflare's paying tier doesn't guarantee
that Cloudflare won't also obtain a free cert.

A few weeks ago we moved crt.sh onto Cloudflare.  It was in the paying
tier from the start, and we uploaded an EV cert straight away.  I was
surprised when https://crt.sh/atom?q=crt.sh alerted me to
https://crt.sh/?id=42619974



So I guess you haven't added your own domains (such as crt.sh) to the
list of "high-value manual review" domains for your own certificate
issuance processes?

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Rob Stradling]

On 03/11/16 14:18, Jakob Bohm wrote:
> On 03/11/2016 12:09, Rob Stradling wrote:
> 
>> In my experience, joining Cloudflare's paying tier doesn't guarantee
>> that Cloudflare won't also obtain a free cert.
>>
>> A few weeks ago we moved crt.sh onto Cloudflare.  It was in the paying
>> tier from the start, and we uploaded an EV cert straight away.  I was
>> surprised when https://crt.sh/atom?q=crt.sh alerted me to
>> https://crt.sh/?id=42619974
> 
> So I guess you haven't added your own domains (such as crt.sh) to the
> list of "high-value manual review" domains for your own certificate
> issuance processes?

So it would seem.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New SHA-1 certificates issued in 2016

[Gervase Markham]

On 28/10/16 16:11, Patrick Figel wrote:
> I found a number of SHA-1 certificates chaining up to CAs trusted by
> Mozilla that have not been brought up on this list or on Bugzilla yet.

Using the handy crt.sh link posted by Rob, I have gone through the 2016
SHA-1 issuances known to crt.sh to filter out those which chain up to a
root trusted by Mozilla. (Handily, crt.sh contains this information as
well.) There are a distressingly large number of them :-(

Based on Patrick's report, I filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1313874 (Gov of Spain)
https://bugzilla.mozilla.org/show_bug.cgi?id=1313872 (DigiCert)
https://bugzilla.mozilla.org/show_bug.cgi?id=1313873 (DocuSign)

and based on this additional research, I have filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1315019 (TeliaSonera)
https://bugzilla.mozilla.org/show_bug.cgi?id=1315016 (Visa)
https://bugzilla.mozilla.org/show_bug.cgi?id=1315018 (GlobalSign)
https://bugzilla.mozilla.org/show_bug.cgi?id=1315035 (T-Systems)

There may be more in the future. I would be interested in the group's
opinion on what to do about:

A) SHA-1 precerts with no actual cert logged (1 CA)

B) SHA-1 email certificates with no DNS names, although their lack of
   an EKU means they are valid for server auth (2 CAs)

C) SHA-1 email certificates with EKU but no serverAuth (1 CA)

D) Small numbers (1 or 2) of SHA-1 certs issued in early January. One
   could perhaps charitably say that the CA or their subCA made a
   mistake, realised, has fixed it, and hasn't made it since. Now it's
   November, is this worth chasing? (4 CAs)

Also, does it make it better if the CA has already revoked the
certificate before we report it to them?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: References to key generation guideline across Mozilla

[Gervase Markham]

On 03/11/16 10:30, Tim Guan-tin Chien wrote:
> PS Apologies if this is not in-scope for dev-security-policy.

I think you might be better off asking Mozilla IT :-)

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New SHA-1 certificates issued in 2016

[Andrew Ayer]

On Thu, 3 Nov 2016 17:53:01 +
Gervase Markham  wrote:

> On 28/10/16 16:11, Patrick Figel wrote:
> > I found a number of SHA-1 certificates chaining up to CAs trusted by
> > Mozilla that have not been brought up on this list or on Bugzilla
> > yet.
> 
> Using the handy crt.sh link posted by Rob, I have gone through the
> 2016 SHA-1 issuances known to crt.sh to filter out those which chain
> up to a root trusted by Mozilla. (Handily, crt.sh contains this
> information as well.) There are a distressingly large number of
> them :-(
> 
> Based on Patrick's report, I filed:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1313874 (Gov of Spain)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1313872 (DigiCert)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1313873 (DocuSign)
> 
> and based on this additional research, I have filed:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1315019 (TeliaSonera)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1315016 (Visa)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1315018 (GlobalSign)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1315035 (T-Systems)
> 
> There may be more in the future. I would be interested in the group's
> opinion on what to do about:
> 
> A) SHA-1 precerts with no actual cert logged (1 CA)

This is just as bad as signing an actual cert with SHA-1.  RFC6962 says:

"The signature on the TBSCertificate indicates the
certificate authority's intent to issue a certificate.  This intent
is considered binding (i.e., misissuance of the Precertificate is
considered equal to misissuance of the final certificate)."

This is not just a theoretical concern.  When this came up earlier this
year with Symantec, I explained that pre-certificates are a vector for
exploiting a SHA-1 collision, since the forged/collided certificate
need not contain the pre-certificate poison extension.

> B) SHA-1 email certificates with no DNS names, although their lack of
>an EKU means they are valid for server auth (2 CAs)

The more pertinent question is the issuing CA's EKU.

> C) SHA-1 email certificates with EKU but no serverAuth (1 CA)

Ditto.

> D) Small numbers (1 or 2) of SHA-1 certs issued in early January. One
>could perhaps charitably say that the CA or their subCA made a
>mistake, realised, has fixed it, and hasn't made it since. Now it's
>November, is this worth chasing? (4 CAs)
> 
> Also, does it make it better if the CA has already revoked the
> certificate before we report it to them?

No. Revocation doesn't help because the forged/collided cert need not
share the same serial number.  Revocation would only help if it were
based on the SHA-1 hash of the TBSCertificate.

The common thread in all of these answers is that the forged/collided
certificate need not look anything like the data that the CA signed
with SHA-1.  Any time a CA trusted for serverAuth signs
attacker-controlled data using SHA-1 there is a risk of a forged
serverAuth certificate.

Regards,
Andrew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Update on transition of the Verizon roots and issuance of SHA1 certificates

[Jeremy Rowley]

Resent without a signature



Hi everyone,



This email is intended to gather public and browser feedback on how we are 
handling the transitioning Verizon's customers to DigiCert and share with 
everyone the plan for when all non-DigiCert hosted sub CAs will be fully 
compliant with the BRs and network security guidelines. Primarily, this letter 
addresses when all issuing CAs previously held by Verizon will be covered by an 
unqualified audit and how we are responding to the sub CAs that issued SHA1 
certificates. We are looking forward to the browser and public feedback on how 
to handle the non-compliant cross-signs and insight on how the public views our 
transition progress and planned completion dates.



Background

Prior to presenting the plan for remediation, I thought I'd share a bit about 
our progress with migrating Verizon customers.  About a year ago in July, 
DigiCert closed an agreement with Verizon where DigiCert took ownership of 
three publicly-trusted Verizon root certificates. These certificates are the 
Verizon Global Root CA, the Baltimore CyberTrust Root CA, and the Verizon Root 
CA. There were many reasons the acquisition made sense, including acquisition 
of a root that had cross-signed DigiCert for many years. The ubiquity of the 
Verizon roots is wide-spread, which meant a lot of CAs like to cross-sign with 
them. Another significant reason for the acquisition was an attempt to improve 
the CA industry. After watching the issuance of wildcard EV certs, 
non-compliant subordinate CAs, and certs with poor profiles, we made a 
conscious decision to purchase these roots with the intention of migrating them 
to more complaint system. We felt that helping these CAs get to the point of
  regular audits and best practices would raise the quality of the entire 
industry.



Prior to the acquisition, we were made aware of several potential 
non-compliances by Verizon's customers. We worked closely with Verizon to clean 
up many of the Sub CAs, including revoking CAs that would never be compliant 
with the requirements and attempting to technically constrain others.  Sub CAs 
were revoked because they either didn't have an audit, were unresponsive to 
communication, or couldn't control their issuance. Verizon was a great partner 
and took a very proactive approach in removing CAs that were not actively 
working towards compliance. Unfortunately, the age of the roots and large 
number of cross-signs led to a lot of missing paperwork and certain issues in 
identifying which CAs were covered by audits. Prior to closing we believed 
there were approximately five technically constrained sub CAs and around 20 
unconstrained sub CAs. Turns out there were actually more than 200, each with 
various levels of compliance. Most of these Sub CAs operated under the Baltimo
 re Cybertrust root, which was created in 2000.



To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's 
acquisition of the roots. Unfortunately, this left around 150 for our small 
team to work through. Although the endeavor was daunting, Ben Wilson and others 
worked to gather audit reports, email customers about compliance dates, monitor 
certificates issued, and revoke non-compliant customers. Verizon was very good 
at assisting us in these efforts. This information is now recorded in the 
Mozilla database and continuously updated as the information changes.



Transition Process

After our operational acquisition of the roots (which occurred the last part of 
September, 2015), we identified 15 expired issuing CAs, 70 revoked sub CAs, 131 
audited sub CAs, and 36 where the status was unknown. Since then, we've revoked 
25 issuing CAs and assisted others with technical constraints, exodus from the 
Omniroot cross-signing program, or obtaining audits. Of the existing sub CAs, 
about half remain operational and are either audited or technically 
constrained. The other half are either winding down or have been revoked. All 
revoked certificates were disclosed to Mozilla via Salesforce and should be 
part of OneCRL.



Issuing CAs

There are only a handful of non-audited sub CAs remaining (see 
https://crt.sh/mozilla-disclosures#disclosureincomplete). We have a plan for 
each of them that we'd like to share with you. We welcome both browser and 
public feedback. This is, of course, simply a proposal on how to finish the 
transition and provide transparency into where we are at. We are certainly 
willing to modify the plan as needed to further online security and meet the 
requirements of the root store operators.



The seven companies listed below are responsible for the remaining unaudited 
sub CAs:



1.   ABB has three unaudited issuing CAs. ABB didn't undergo an audit 
earlier this year on the assumption that their sub CAs were technically 
constrained. Unfortunately, the constraints weren't properly implemented, a 
fact that escaped notice until Rob Stradling's excellent tool exposed a 
deficiency 

Re: Cerificate Concern about Cloudflare's DNS

[gerhard . tinned]

On Thursday, November 3, 2016 at 10:59:53 AM UTC+1, Gervase Markham wrote:
> On 02/11/16 23:26, wrote:
> > Befor I contacted this group, I contacted Cloudflare and asked them
> > to stop creating certificates with my domain. The answer in short
> > was, ... they cannot change it and as long as I am using there
> > service, they will continue.
> 
> How would you expect the service to work without them doing that?
> 
> > I also contacted Comodo as the CA and asked them. The answer was
> > different but also not helping. In short, ... I can use a CAA DNS
> > record (not supported by many DNS providers like Cloudflare) to avoid
> > it in the future. But in the next sentence telling me that those
> > records are not honoured by many CA's.
> 
> Hopefully this will change before too long.
> 
> However, I still don't get why you want to use Cloudflare's SSL
> termination services but are unwilling to allow them to get a
> certificate for your domain name.
> 
> AIUI their free tier uses certs they obtain, but if you pay, you can
> provide your own cert. So if you want to use Cloudflare but don't want
> them obtaining certs for you, join the paying tier.
> 
> Gerv

Hi, 

I guess you never used Cloudflare, right? So let me explain it to you so you 
understand my concern. I have posted my whole explanation to this group but it 
is somewhere lost I think. 

1.) Yes, Cloudflare offers a kind of MITM as a service. You dont have a 
certificate, you want there protection, ... etc. So they create it for you, 
intercept and cache the traffic.

2.) Cloudflare does offer much more. beside other things you can disable all 
those features and use cloudflare as "DNS-only mode" as they call it. This 
means the SSL option is switched of by the user. (my expectation would be that 
there are no ssl certificates issued for my domain in that mode.

Now, knowing that, I get back to your questions:

> How would you expect the service to work without them doing that?

As far as I understand aDNS-only service, a SSL certificate is not required. My 
expectation would be that Cloudflare honers the settings I set on the 
account/domain.

> However, I still don't get why you want to use Cloudflare's SSL
> termination services but are unwilling to allow them to get a
> certificate for your domain name.

Again, I sue Cloudflare in the DNS-only mode. All the features (except DNS) is 
disabled. SSL: OFF, Intercepting traffic: OFF, ...

> 
> AIUI their free tier uses certs they obtain, but if you pay, you can
> provide your own cert. So if you want to use Cloudflare but don't want
> them obtaining certs for you, join the paying tier.

As far as I understood you can even upload the cert in the free plan, but 
beside the point. DNS-Only mpde would not require it.


I would have at least expected that they stop issuing certificates after I 
requested it. But they dont!
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[gerhard . tinned]

On Thursday, November 3, 2016 at 1:23:48 PM UTC+1, Rob Stradling wrote:
> On 03/11/16 12:13, Han Yuwei wrote:
> > 在 2016年11月3日星期四 UTC+8下午7:09:48，Rob Stradling写道：
> >> On 03/11/16 09:59, Gervase Markham wrote:
> >>> On 02/11/16 23:26, gerhard.tin...@gmail.com wrote:
>  Befor I contacted this group, I contacted Cloudflare and asked them
>  to stop creating certificates with my domain. The answer in short
>  was, ... they cannot change it and as long as I am using there
>  service, they will continue.
> >>>
> >>> How would you expect the service to work without them doing that?
> >>>
>  I also contacted Comodo as the CA and asked them. The answer was
>  different but also not helping. In short, ... I can use a CAA DNS
>  record (not supported by many DNS providers like Cloudflare) to avoid
>  it in the future. But in the next sentence telling me that those
>  records are not honoured by many CA's.
> >>>
> >>> Hopefully this will change before too long.
> >>>
> >>> However, I still don't get why you want to use Cloudflare's SSL
> >>> termination services but are unwilling to allow them to get a
> >>> certificate for your domain name.
> >>>
> >>> AIUI their free tier uses certs they obtain, but if you pay, you can
> >>> provide your own cert. So if you want to use Cloudflare but don't want
> >>> them obtaining certs for you, join the paying tier.
> >>
> >> In my experience, joining Cloudflare's paying tier doesn't guarantee
> >> that Cloudflare won't also obtain a free cert.
> >>
> >> A few weeks ago we moved crt.sh onto Cloudflare.  It was in the paying
> >> tier from the start, and we uploaded an EV cert straight away.  I was
> >> surprised when https://crt.sh/atom?q=crt.sh alerted me to
> >> https://crt.sh/?id=42619974
> >>
> >> -- 
> >> Rob Stradling
> >> Senior Research & Development Scientist
> >> COMODO - Creating Trust Online
> > 
> > So it is impossible to request a revocation even I do refuse to let 
> > Cloudflare issue the certificate of my domain and keep using Cloudflare's 
> > DNS service under these rules(CA/B BR and COMODO CPS)?
> 
> Comodo does check CAA records, so you could add a CAA record for your
> domain that doesn't permit Comodo to issue.  This won't stop Cloudflare
> from requesting a free cert, but it should block the issuance of any
> requested cert.  (Note however that our CAA checks fail open if there's
> an error with the CAA DNS lookup).
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online

This seems to be the standard answer from Comodo. Conveniently Cloudflare does 
not support CAA records. So this suggestion is not helping with Cloudflare.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[gerhard . tinned]

On Thursday, November 3, 2016 at 11:23:18 PM UTC+1, Matt Palmer wrote:
> On Thu, Nov 03, 2016 at 02:08:04PM -0700, gerhard.tin...@gmail.com wrote:
> > Sadly, the shady behaviour is not with Comodo but with Cloudflare. As
> > cloudflare does not state anywhere that they issue certificates when SSL
> > and CDN features are explicitly switched off from the beginning.
> 
> They do state it: in a blog post from 2014.  They appear to believe this is
> sufficient notice.

Well a blog post is not a TOS or a security policy. But maybe in some far away 
country it is accepted. Any way, can you send me the link to that post??

> 
> > 1. trust issue: Cloudflare issues certificates without asking permission
> > or staing it in TOS or elsewhere.  Doing so when in DNS-only mode appears
> > to me illegal.
> 
> Illegal?  In which jurisdiction(s)?

Well, If you buy a VPS and the provider creates a certificate by validating by 
adding content to your webserver, ... we would agree that this is wrong, right? 
But when I get a service to host MY DNS entries, it is fine if the provider 
manipulates them without my knowledge? ... But I have noticed that in some 
countries the understanding of legal and iligal is different. Sad.

> 
> > 2. trust issue: Cloudflare modifies the DNS entries to validate without
> > consent of the domain owner or account holder.  Again, no mention of it in
> > TOS or anywheer else.  So the modification is not permitted in DNS-only
> > mode.
> 
> So go tell Cloudflare.  Take your business elsewhere.

I understand, go and just lieve with a certificate that is issued without my 
permission. It seems that CT is useless if there are no actions are taken from 
wrong behaviour.

> 
> There is no need to keep banging on about it on this list.  Everyone here
> knows what Cloudflare is doing, they have their opinion of it, and as a
> group this list can do nothing about it.
> 
> > But from the moment on when the CA (Comodo) is informed about this shady
> > behavior by multiple domain owners / account owners, Comodo should start
> > acting.
> 
> As the Wikipedians say: "Citation Needed".
> 
> - Matt

Still sad that wrong behaviour of companies that trick CAs into issuing 
certificates is protected by "go away!" comments. I would have expected more. 

And as this thread shows, I am not alone.


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Matt Palmer]

On Thu, Nov 03, 2016 at 03:39:11PM -0700, gerhard.tin...@gmail.com wrote:
> On Thursday, November 3, 2016 at 11:23:18 PM UTC+1, Matt Palmer wrote:
> > On Thu, Nov 03, 2016 at 02:08:04PM -0700, gerhard.tin...@gmail.com wrote:
> > > Sadly, the shady behaviour is not with Comodo but with Cloudflare. As
> > > cloudflare does not state anywhere that they issue certificates when SSL
> > > and CDN features are explicitly switched off from the beginning.
> > 
> > They do state it: in a blog post from 2014.  They appear to believe this is
> > sufficient notice.
> 
> Well a blog post is not a TOS or a security policy. But maybe in some far
> away country it is accepted.  Any way, can you send me the link to that
> post??

https://blog.cloudflare.com/introducing-universal-ssl/

> > > 1. trust issue: Cloudflare issues certificates without asking permission
> > > or staing it in TOS or elsewhere.  Doing so when in DNS-only mode appears
> > > to me illegal.
> > 
> > Illegal?  In which jurisdiction(s)?
> 
> Well, If you buy a VPS and the provider creates a certificate by
> validating by adding content to your webserver, ...  we would agree that
> this is wrong, right?

It would depend on the circumstances.  However that is not what happened.

> But when I get a service to host MY DNS entries, it
> is fine if the provider manipulates them without my knowledge?  ...  But I
> have noticed that in some countries the understanding of legal and iligal
> is different.  Sad.

Which country or countries (or other legal jurisdiction) has an
understanding that Cloudflare's behaviour as described in this thread is
illegal?  You've made a fairly specific claim, I would be interested to see
the rationale for it.

> > > 2. trust issue: Cloudflare modifies the DNS entries to validate without
> > > consent of the domain owner or account holder.  Again, no mention of it in
> > > TOS or anywheer else.  So the modification is not permitted in DNS-only
> > > mode.
> > 
> > So go tell Cloudflare.  Take your business elsewhere.
> 
> I understand, go and just lieve with a certificate that is issued without
> my permission.  It seems that CT is useless if there are no actions are
> taken from wrong behaviour.

There are actions taken for wrong behaviour.  It's just that not every wrong
behaviour results in the same action.

I'm actually interested in what specific action you think should be taken
here, and how keeping on about it on this list will help that action to
occur.  Please, state exactly what you think should be done.

> > There is no need to keep banging on about it on this list.  Everyone here
> > knows what Cloudflare is doing, they have their opinion of it, and as a
> > group this list can do nothing about it.
> > 
> > > But from the moment on when the CA (Comodo) is informed about this shady
> > > behavior by multiple domain owners / account owners, Comodo should start
> > > acting.
> > 
> > As the Wikipedians say: "Citation Needed".
> > 
> > - Matt
> 
> Still sad that wrong behaviour of companies that trick CAs into issuing
> certificates

What trickery was involved with the CA?  Comodo requires proof of control
over the domain to issue a certificate.  $DEITY knows there are enough
perfectly legitimate reasons to look askance at Comodo, but this isn't one
of them.

Cloudflare demonstrated the required domain control to Comodo, because YOU
GAVE CONTROL TO CLOUDFLARE.  Cloudflare may well have acted in bad faith, by
taking an action you deemed unexpected or illegitimate, however that isn't
something that a browser vendor or root store program can do anything about. 

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Update on transition of the Verizon roots and issuance of SHA1 certificates

[Han Yuwei]

在 2016年11月4日星期五 UTC+8上午3:52:23，Jeremy Rowley写道：
> Resent without a signature
> 
> 
> 
> Hi everyone,
> 
> 
> 
> This email is intended to gather public and browser feedback on how we are 
> handling the transitioning Verizon's customers to DigiCert and share with 
> everyone the plan for when all non-DigiCert hosted sub CAs will be fully 
> compliant with the BRs and network security guidelines. Primarily, this 
> letter addresses when all issuing CAs previously held by Verizon will be 
> covered by an unqualified audit and how we are responding to the sub CAs that 
> issued SHA1 certificates. We are looking forward to the browser and public 
> feedback on how to handle the non-compliant cross-signs and insight on how 
> the public views our transition progress and planned completion dates.
> 
> 
> 
> Background
> 
> Prior to presenting the plan for remediation, I thought I'd share a bit about 
> our progress with migrating Verizon customers.  About a year ago in July, 
> DigiCert closed an agreement with Verizon where DigiCert took ownership of 
> three publicly-trusted Verizon root certificates. These certificates are the 
> Verizon Global Root CA, the Baltimore CyberTrust Root CA, and the Verizon 
> Root CA. There were many reasons the acquisition made sense, including 
> acquisition of a root that had cross-signed DigiCert for many years. The 
> ubiquity of the Verizon roots is wide-spread, which meant a lot of CAs like 
> to cross-sign with them. Another significant reason for the acquisition was 
> an attempt to improve the CA industry. After watching the issuance of 
> wildcard EV certs, non-compliant subordinate CAs, and certs with poor 
> profiles, we made a conscious decision to purchase these roots with the 
> intention of migrating them to more complaint system. We felt that helping 
> these CAs get to the point of regular audits and best practices would raise 
> the quality of the entire industry.
> 
> 
> 
> Prior to the acquisition, we were made aware of several potential 
> non-compliances by Verizon's customers. We worked closely with Verizon to 
> clean up many of the Sub CAs, including revoking CAs that would never be 
> compliant with the requirements and attempting to technically constrain 
> others.  Sub CAs were revoked because they either didn't have an audit, were 
> unresponsive to communication, or couldn't control their issuance. Verizon 
> was a great partner and took a very proactive approach in removing CAs that 
> were not actively working towards compliance. Unfortunately, the age of the 
> roots and large number of cross-signs led to a lot of missing paperwork and 
> certain issues in identifying which CAs were covered by audits. Prior to 
> closing we believed there were approximately five technically constrained sub 
> CAs and around 20 unconstrained sub CAs. Turns out there were actually more 
> than 200, each with various levels of compliance. Most of these Sub CAs 
> operated under the Baltimore Cybertrust root, which was created in 2000.
> 
> 
> 
> To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's 
> acquisition of the roots. Unfortunately, this left around 150 for our small 
> team to work through. Although the endeavor was daunting, Ben Wilson and 
> others worked to gather audit reports, email customers about compliance 
> dates, monitor certificates issued, and revoke non-compliant customers. 
> Verizon was very good at assisting us in these efforts. This information is 
> now recorded in the Mozilla database and continuously updated as the 
> information changes.
> 
> 
> 
> Transition Process
> 
> After our operational acquisition of the roots (which occurred the last part 
> of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub 
> CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then, 
> we've revoked 25 issuing CAs and assisted others with technical constraints, 
> exodus from the Omniroot cross-signing program, or obtaining audits. Of the 
> existing sub CAs, about half remain operational and are either audited or 
> technically constrained. The other half are either winding down or have been 
> revoked. All revoked certificates were disclosed to Mozilla via Salesforce 
> and should be part of OneCRL.
> 
> 
> 
> Issuing CAs
> 
> There are only a handful of non-audited sub CAs remaining (see 
> https://crt.sh/mozilla-disclosures#disclosureincomplete). We have a plan for 
> each of them that we'd like to share with you. We welcome both browser and 
> public feedback. This is, of course, simply a proposal on how to finish the 
> transition and provide transparency into where we are at. We are certainly 
> willing to modify the plan as needed to further online security and meet the 
> requirements of the root store operators.
> 
> 
> 
> The seven companies listed below are responsible for the remaining unaudited 
> sub CAs:
> 
> 
> 
> 1.   ABB has three unaudited issuing CAs. ABB didn't 

RE: Update on transition of the Verizon roots and issuance of SHA1 certificates

[Jeremy Rowley]

I'm not sure exactly what you are asking. These sub CAs are cross-signs with 
other entities. DigiCert controls the root, but not the issuing CAs. Except for 
the ones I listed, they are all WebTrust or ETSI audited so we trust them. They 
are primarily government, large corporations, and other CAs. Most are 
transferring away from DigiCert or moving to a solution where we host the 
private keys and certificates. There are some who insist on operating their own 
root and cross-sign for ubiquity. 

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Han Yuwei
Sent: Thursday, November 3, 2016 6:14 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Update on transition of the Verizon roots and issuance of SHA1 
certificates

在 2016年11月4日星期五 UTC+8上午3:52:23，Jeremy Rowley写道：
> Resent without a signature
> 
> 
> 
> Hi everyone,
> 
> 
> 
> This email is intended to gather public and browser feedback on how we are 
> handling the transitioning Verizon's customers to DigiCert and share with 
> everyone the plan for when all non-DigiCert hosted sub CAs will be fully 
> compliant with the BRs and network security guidelines. Primarily, this 
> letter addresses when all issuing CAs previously held by Verizon will be 
> covered by an unqualified audit and how we are responding to the sub CAs that 
> issued SHA1 certificates. We are looking forward to the browser and public 
> feedback on how to handle the non-compliant cross-signs and insight on how 
> the public views our transition progress and planned completion dates.
> 
> 
> 
> Background
> 
> Prior to presenting the plan for remediation, I thought I'd share a bit about 
> our progress with migrating Verizon customers.  About a year ago in July, 
> DigiCert closed an agreement with Verizon where DigiCert took ownership of 
> three publicly-trusted Verizon root certificates. These certificates are the 
> Verizon Global Root CA, the Baltimore CyberTrust Root CA, and the Verizon 
> Root CA. There were many reasons the acquisition made sense, including 
> acquisition of a root that had cross-signed DigiCert for many years. The 
> ubiquity of the Verizon roots is wide-spread, which meant a lot of CAs like 
> to cross-sign with them. Another significant reason for the acquisition was 
> an attempt to improve the CA industry. After watching the issuance of 
> wildcard EV certs, non-compliant subordinate CAs, and certs with poor 
> profiles, we made a conscious decision to purchase these roots with the 
> intention of migrating them to more complaint system. We felt that helping 
> these CAs get to the point of regular audits and best practices would raise 
> the quality of the entire industry.
> 
> 
> 
> Prior to the acquisition, we were made aware of several potential 
> non-compliances by Verizon's customers. We worked closely with Verizon to 
> clean up many of the Sub CAs, including revoking CAs that would never be 
> compliant with the requirements and attempting to technically constrain 
> others.  Sub CAs were revoked because they either didn't have an audit, were 
> unresponsive to communication, or couldn't control their issuance. Verizon 
> was a great partner and took a very proactive approach in removing CAs that 
> were not actively working towards compliance. Unfortunately, the age of the 
> roots and large number of cross-signs led to a lot of missing paperwork and 
> certain issues in identifying which CAs were covered by audits. Prior to 
> closing we believed there were approximately five technically constrained sub 
> CAs and around 20 unconstrained sub CAs. Turns out there were actually more 
> than 200, each with various levels of compliance. Most of these Sub CAs 
> operated under the Baltimore Cybertrust root, which was created in 2000.
> 
> 
> 
> To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's 
> acquisition of the roots. Unfortunately, this left around 150 for our small 
> team to work through. Although the endeavor was daunting, Ben Wilson and 
> others worked to gather audit reports, email customers about compliance 
> dates, monitor certificates issued, and revoke non-compliant customers. 
> Verizon was very good at assisting us in these efforts. This information is 
> now recorded in the Mozilla database and continuously updated as the 
> information changes.
> 
> 
> 
> Transition Process
> 
> After our operational acquisition of the roots (which occurred the last part 
> of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub 
> CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then, 
> we've revoked 25 issuing CAs and assisted others with technical constraints, 
> exodus from the Omniroot cross-signing program, or obtaining audits. Of the 
> existing sub CAs, about half remain operational and are either audited or 
> technically constrained. The other half are 

Re: Update on transition of the Verizon roots and issuance of SHA1 certificates

[Peter Bowen]

On Thu, Nov 3, 2016 at 11:28 AM, Jeremy Rowley
 wrote:
> This email is intended to gather public and browser feedback on how we are
> handling the transitioning Verizon's customers to DigiCert and share with
> everyone the plan for when all non-DigiCert hosted sub CAs will be fully
> compliant with the BRs and network security guidelines. Primarily, this
> letter addresses when all issuing CAs previously held by Verizon will be
> covered by an unqualified audit and how we are responding to the sub CAs
> that issued SHA1 certificates. We are looking forward to the browser and
> public feedback on how to handle the non-compliant cross-signs and insight
> on how the public views our transition progress and planned completion
> dates.

Jeremy,

Thank you for addressing this non-compliance head on.  While it
probably would have been better to raise this when you became aware of
it, it is good that DigiCert brought this to the group proactively
rather than waiting for a discussion on "should we dump these roots".

I have a bunch of questions, through out the document.

First, a couple of questions about DigiCert itself.  The press release
at 
https://thomabravo.com/2015/10/22/thoma-bravo-completes-acquisition-of-majority-stake-in-digicert/
says that Thoma Bravo acquired a majority stake in DigiCert in October
2015.  Looking at the current portfolio
(https://thomabravo.com/portfolio/all/current/), I don't see any other
CAs, but can you confirm that (a) they still own a majority &
controlling share of DigiCert and (b) that Thoma Bravo does not own a
majority or controlling share (directly or indirectly) of any other
CA?

What is the relationship between Cyber Secure Asia
(https://www.cybersecureasia.com/about-cyber-secure-asia-csa/newsroom)
and DigiCert?  Are they a subsidiary, a subordinate CA, a reseller or
something else?  It is hard to tell, as they talk about DigiCert all
over their site but also say something about being a subsidiary of
CyberTrust Japan (which might be part of DigiCert?)

> About a year ago in
> July, DigiCert closed an agreement with Verizon where DigiCert took
> ownership of three publicly-trusted Verizon root certificates. These
> certificates are the Verizon Global Root CA, the Baltimore CyberTrust Root
> CA, and the Verizon Root CA.

According to 
https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport,
DigiCert currently has 10 roots in the Mozilla trust anchor list.
These include eight with "DigiCert Inc" in the organization name
attribute, one with "Baltimore" in the organization name attribute,
and one with "CyberTrust, Inc" in the organization name attribute.
The removed CA report
(https://mozillacaprogram.secure.force.com/CA/RemovedCACertificateReport)
lists one root as belonging to DigiCert.  This has "GTE Corporation"
in the organization name attribute.

You list three root certificates in your email.  Which of the DigiCert
certificates in the Mozilla root reports map to the three you list?

You talk about taking ownership of three "root certificates".  Did you
also take ownership and control of all copies of the associated
private keys?  Did you take control of other CAs and private keys
(e.g. subordinate CAs) or just the three listed above?

> After watching the
> issuance of wildcard EV certs, non-compliant subordinate CAs, and certs with
> poor profiles, we made a conscious decision to purchase these roots with the
> intention of migrating them to more complaint system. We felt that helping
> these CAs get to the point of regular audits and best practices would raise
> the quality of the entire industry.

So would just revoking them.

> Unfortunately, the age of the
> roots and large number of cross-signs led to a lot of missing paperwork and
> certain issues in identifying which CAs were covered by audits. Prior to
> closing we believed there were approximately five technically constrained
> sub CAs and around 20 unconstrained sub CAs. Turns out there were actually
> more than 200, each with various levels of compliance. Most of these Sub CAs
> operated under the Baltimore Cybertrust root, which was created in 2000.
> To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's
> acquisition of the roots.

Given this huge variance, how sure are you that you have identified
all the CA certificates issued by these roots?  Did all of the CA
certificates include zero path length constraints or are there
possibly whole trees of CAs out there that are unknown?

> After our operational acquisition of the roots (which occurred the last part
> of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub
> CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then,
> we've revoked 25 issuing CAs and assisted others with technical constraints,
> exodus from the Omniroot cross-signing program, or obtaining audits.

What is "Omniroot"?

How many of these are operated by DigiCert and how many are