On 8/9/17, Eric Mill <e...@konklone.com> wrote: > On Wed, Aug 9, 2017 at 4:28 PM, Lee <ler...@gmail.com> wrote: > >> On 8/9/17, Eric Mill via dev-security-policy >> <dev-security-policy@lists.mozilla.org> wrote: >> > On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy < >> > dev-security-policy@lists.mozilla.org> wrote: >> > >> >> On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg >> wrote: >> >> > > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy < >> >> dev-security-policy@lists.mozilla.org> wrote: >> >> > > >> >> > > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg >> >> wrote: >> >> > >> “IdenTrust ACES CA 2” has issued five certificates with an OCSP >> >> responder URL that has a HTTPS URI scheme. This is not valid, the OCSP >> >> responder URI is required to have the plaintext HTTP scheme according >> >> to >> >> Baseline Requirements section 7.1.2.2(c). >> >> > >> >> >> > >> Here’s the list of certificates: https://misissued.com/batch/4/ >> >> > >> >> >> > >> Jonathan >> >> > > >> >> > > IdenTrust had previously interpreted HTTP to be inclusive of HTTPS >> in >> >> this >> >> > > context. That being said, we have altered our profiles for >> >> certificates >> >> > > issued under this Sub CA to include only HTTP OCSP URLs. All >> >> certificates >> >> > > issued going forward will contain an HTTP OCSP URL. We will also >> >> examine all >> >> > > other sub CA to ensure only HTTP OCSP URLs are included. Thank >> >> > > you >> >> for giving >> >> > > us an opportunity to address this with the community >> >> > >> >> > Thanks for the update. >> >> > >> >> > Can you also clarify why the subject organizationName is "U.S. >> >> Government” for all of these certificates, despite the other subject >> >> fields >> >> indicating organizations that are not a component of the US >> >> Government? >> >> > >> >> > Jonathan >> >> >> >> Yes, >> >> IdenTrust ACES SSL Certificates are issued in accordance with the ACES >> >> certificate policy defined by U.S. General Service Administration ( >> >> http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/docum >> >> ents/ACES-CP-v3-2_signed_05122017.pdf) and the GSA approved IdenTrust >> CPS >> >> (https://secure.identrust.com/certificates/policy/aces/IdenT >> >> rust_ACES_CPS_v5.1_20161110.pdf) >> >> These ACES SSL certificates are issued to either U.S. Government >> agencies >> >> and/or their sub-contractors in support of government >> >> programs\projects. >> >> The >> >> CP requires an approved CA, such as IdenTrust, to identify U.S. >> Government >> >> in >> >> subject organizationName along with other applicable organizations >> >> (e.g. >> >> sub-contractors, or local government agency, etc...). >> >> >> > >> > If that's the case, I would expect each certificate to be >> > authenticating >> > hostnames that are used solely to provide such services to the U.S. >> > Government. That doesn't appear to be the case with these. >> > >> > For example, one of them is for the homepage for a service provider: >> > www.mudiaminc.com >> >> What am I doing wrong? goto https://www.mudiaminc.com/ >> check the cert and it says >> Issued To >> Common Name (CN) *.opentransfer.com >> Organization (O) ECOMMERCE, INC. >> > > You're not doing anything wrong, that hostname is just not using that > certificate at this time, at least not to public users. But issuance is > what matters here. > > Given the capitalization of the common name, and the > organizationalUnitName, the certificate was clearly issued to the same > company. > > >> And one of them is for what appears to be a state government revenue >> > service's VPN: vpn.revenue.louisiana.gov >> >> I see that one - goto https://vpn.revenue.louisiana.gov/ >> check the cert and it says >> Issued To >> Common Name (CN) Vpn.revenue.louisiana.gov >> Organization (O) U.S. Government >> >> > (So it's clear, "U.S. Government" only refers to the federal >> > government, >> > not state/local/tribal governments.) >> > >> > I personally (and to be clear, this is in my individual capacity and I >> > am >> > not representing my employer) think these are invalid >> > organizationNames, >> > constitute misissuance, and that Identrust should be using the "U.S. >> > Government" only for hostnames providing services operated exclusively >> > on >> > behalf of the federal government. >> >> playing devils' advocate: how do you know that >> https://vpn.revenue.louisiana.gov/ wasn't set up in collaboration with >> the IRS or some other branch of the U.S. Government? >> > > That wouldn't meet the definition that Identrust said in their email above, > which is that certificates are "issued to either U.S. Government agencies
if it was a cooperative project, it seems possible/reasonable that the USG ordered the certs. > and/or their sub-contractors in support of government programs\projects". > Maybe there's some very novel arrangement I'm not familiar with where the > State of Louisiana can act as a subcontractor to the federal government, > but in both of these cases, the burden is on Identrust to identify how it > could have been appropriate to put "U.S. Government" as the > organizationName for these certificates. +1 identr...@gmail.com has been cc'ed on the thread; is that enough or is a formal request for an explanation required? > For the other 3 in the batch, there are more plausible reasons why the > hostname might exclusively be for U.S. Government purposes - > > * networx-billing-pricer.nhc.noblis.org - In support of the Noblis Networx > contract > * sslacesvalid.identrust.com - In support of the overall ACES CA > * smbf1.smbisao.com - Related to a Small and Medium Business (SMB)-oriented > Information Sharing and Analysis Organization Initiative (iSAO), related to > a DHS initiative: https://www.icf.com/-/media/files/icf/white-pape > rs/2015/response_to_dhs_public_comment_information_sharing.ashx > > Although it is also quite plausible that those certificates are also used > for non-USG-affiliated purposes. > > Only Identrust can explain it for certain, but for at least the two I > called out, I think it is reasonable to presume their organizationName is > inaccurate until shown otherwise. Which means the 24 hr. countdown clock to revocation should have already started? That seems a bit much.. what's a reasonable period of time to wait for an explanation from Identrust for why these certs don't need to be revoked? 5 days? longer? Lee _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
