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

Reply via email to