Hi Julie, To clarify, I am involved with the Mozilla security policy group as a personal project. I do work for a company that also owns a certificate authority (Amazon), but no longer am associated with our CA operations.
From the emails, it sounds like you should work with your CA operator (Entrust) to identify a path forward. They are the entity that would need to submit an application to Mozilla to add a new CA to the trust list. Thanks, Peter On Wed, Nov 27, 2019 at 8:48 AM Rivett, Julie <julie.riv...@va.gov> wrote: > Peter and Eric, > > > > It’s been a while. I believe I may have spoken to one if not both of you > in the past. Mr. James Bowen is my technical team lead and has been > working with you both on the below matter. Thanks very much for taking the > time and sharing dialogue. It is my understanding that you both are > associated and do work to support Mozilla. I’d like to speak with you if > you have time this afternoon. > > > > Peter, I don’t see your number listed so feel free to reach out when you > have time. I answer my phone 24x7 for these sorts of endeavors. > > > > Eric, I’ll try you here in a bit. > > > > If I can’t get either of you before the Holiday hits tomorrow; I hope you > and your family have a great Thanksgiving! > > > > Best, > > Julie > > ~ > > Julie Rivett > > IT Specialist, Team Lead VA NOC, TIC Gateway Network Operations > > Service Operations - Infrastructure Operations > > VA Office of Information and Technology, IT Operations and Services > > Mobile (571) 235-5277 > > > > > > > > *From:* Eric Mill <e...@konklone.com> > *Sent:* Tuesday, November 26, 2019 4:28 PM > *To:* Peter Bowen <pzbo...@gmail.com> > *Cc:* Bowen, James E. <james.bo...@va.gov>; O'Donnell, Derek < > Derek.O'donn...@va.gov>; dev-security-policy@lists.mozilla.org > *Subject:* Re: [EXTERNAL] Re: INC8119596 Other | Entrust Certs and DHS > > > > Yeah, there's something amiss with how you're analyzing the issue here - > whether an entrust.com or entrust.net domain is in use shouldn't matter. > > > > More generally, Mozilla is unlikely to add any root certificates whose > expected uses don't contain a significant public-facing component. The root > store is about public trust, not easing internal enterprise IT operations. > DHS relies on the Mozilla root store for their scans because they only scan > internet-accessible systems, which they generally assume should be using > publicly trusted certificates. (I used to work closely with this team when > I worked for GSA, and created GSA's own HTTPS scanning system that formed > the initial basis for DHS' scans.) > > > > There's no rule saying VA can't run a staff-facing system that is also > internet-accessible - in fact, it'd be great to hear that the VA is moving > away from relying on an intranet as a security boundary. But either way, if > the system in question is exclusively used by laptops and devices which can > reliably be expected to have the relevant certificate installed, and there > are no users who you're forcing to click through certificate warnings to > use the service, you could make an argument to DHS that you're compliant > with the relevant directives. > > > > But there are many federal services that try to use a non-publicly trusted > certificate for services which have a slice of public users, and federal IT > shops frequently make incorrect assumptions about how reliably custom root > certificates are installed on devices that have to use that service. > Because of this, agencies usually can't be trusted to self-attest that no > public users are affected by the use of a non-publicly trusted certificate. > DHS' scans are optimized to protect the public users of federal services. > > > > So if I was DHS, I would ask you to prove that by using HSTS preloading > for the relevant second-level domain, which blocks users from clicking > through certificate warnings. (Dynamic HSTS won't be good enough, because > the server-delivered HSTS policy would never be trusted by affected > clients.) If you're talking about va.gov, that second-level domain has so > many subdomains that it may be challenging to establish an HSTS preload > policy, since it would enforce HTTPS strictly for every single va.gov > subdomain. > > > > If that's not feasible, then I would strongly recommend VA use a publicly > trusted certificate for the affected service - I don't think VA's sense > that their government certs are more trustworthy than public certs is > accurate. VA is likely already dependent on the security of public CAs for > most or all of its public web services already, since anyone who gets a > publicly trusted cert for a va.gov hostname can use it to intercept > traffic to that service, whether or not the VA CIO has chosen to use a > publicly trusted certificate themselves. > > > > On Mon, Nov 25, 2019 at 1:29 PM Peter Bowen via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > On Mon, Nov 25, 2019 at 7:10 AM Bowen, James E. <james.bo...@va.gov> > wrote: > > > DHS is only using Mozilla’s trust store for determining trust. They are > > not using a government-based trust store. > > > > > > > > We talked to Entrust last week. Entrust was creating certificates with “ > > entrust.net” as the old way. Recently, Entrust has been generating > > certificates with “entrust.com” as their current and preferred method. > > > > > > > > We want to get the entrust.com domain added to Mozilla’s trust store, so > > DHS scans don’t come back with false positives. What is the process of > > getting entrust.com added to Mozilla’s trust base?? > > > > The Mozilla trust list is not based on domains, rather it is based on > specific CAs which is identified by the Issuer Name + Public key. Mozilla > (and presumably DHS) do follow chains of certificates, so if the direct > issuer is certified by a trusted CA, then the certificate is trusted. > > If you provide the full issuer name for the certificate you are referring > to, then it might be possible to determine if you are actually on a > government-only certificate or if you have some other issue. > > Thanks, > Peter > > > > > > > *From:* Peter Bowen <pzbo...@gmail.com> > > *Sent:* Saturday, November 23, 2019 7:24 PM > > *To:* O'Donnell, Derek <Derek.O'donn...@va.gov> > > *Cc:* dev-security-policy@lists.mozilla.org; Bowen, James E. < > > james.bo...@va.gov> > > *Subject:* [EXTERNAL] Re: INC8119596 Other | Entrust Certs and DHS > > > > > > > > On Sat, Nov 23, 2019 at 1:08 PM O'Donnell, Derek via dev-security-policy > < > > dev-security-policy@lists.mozilla.org> wrote: > > > > We have a customer at the VA who uses an Entrust root: > > Issuer Entrust > > > > AIA: > > > http://nfitestweb.managed.entrust.com/AIA/CertsIssuedToNFIMediumSSPCA.p7c > > > > They are repeatedly flagged by DHS for not using a trusted certificate > and > > using a self-signed certificate. DHS uses Mozilla Trust Store. > > > > Taking a look at the following file: > > > > > https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/bu > > iltins/certdata.txt, we can see that everything pertaining to Entrust end > > in > > .NET. > > > > The Entrust CA our customer uses ends in .COM. Both extensions are the > > same > > thing. How can we have the .COM certificate added Globally to Mozilla's > > Trust Store? This will resolve the issues being reported by DHS for us. > > Any help on this would be greatly appreciated. > > > > > > > > Hi Derek, > > > > > > > > Entrust Datacard runs a number of different CAs. The various CAs are > > intended for various purposes. > > > > > > > > The CA you are using is intended for government-only applications. The > > CAs that are included in the Mozilla Trust Store are intended for citizen > > or business-facing applications. It sounds like DHS is recommending that > > you use a certificate that is designed for citizen or business-facing > > applications. I would talk to Entrust Datacard or another CA in the > > Mozilla Trust Store to see about getting a new certificate. > > > > > > > > Thanks, > > > > Peter > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > > > > > -- > > Eric Mill > > 617-314-0966 | konklone.com | @konklone <https://twitter.com/konklone> > > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
