Re: O=U.S. Government for non-USG entity (IdenTrust)

[identrust--- via dev-security-policy]

On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote:
> > On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy 
> > <dev-security-policy@lists.mozilla.org> wrote:
> > 
> > I looked through the CT logs and found 15 more unexpired unrevoked 
> > certificates that are trusted by NSS and appear to have the same inaccurate 
> > organizationName of “U.S. Government” for a non-USG entity.
> > 
> > The list is here: https://misissued.com/batch/10/
> > 
> > Can you explain why your review missed these? Are there any more in 
> > addition to these 15 and previous 5?
> > 
> > Jonathan
> 
> After looking into this more, I’ve found that the majority of certificates 
> issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates 
> are not BR-compliant.
> 
> The issues fall into three categories:
> 
> 1) Certificates with HTTPS OCSP URLs
> 2) Certificates with otherName SANs
> 3) Certificates that appear to be intended as client certificates, but have 
> the anyExtendedKeyUsage EKU, putting them in scope for the Mozilla Root 
> Policy.
> 
> I’ve found 33 certificates that have one or more of these issues that are 
> unexpired and unrevoked.
> 
> Here is the full list: https://misissued.com/batch/11/ (note that it is a 
> superset of the batch I posted earlier today)
> 
> Jonathan
and also in reference to number 1 but regarding non US Government issue 
certificates, here is the reply in the expected format:
Issue: Non US Government Certificates issued with o=US Government (IdenTrust)   
1.      How your CA first became aware of the problems listed below (e.g. via a 
Problem Report, via the discussion in mozilla.dev.security.policy, or via this 
Bugzilla Bug), and the date.
IdenTrust: Problem Reported to IdenTrust  via the Mozilla Dev Security Policy 
Forum on August 8, 2017
2.      Prompt confirmation that your CA has stopped issuing TLS/SSL 
certificates with the problems listed below.
IdenTrust: on August 9, IdenTrust acknowledged the issue and offered a formal 
reply before the end of the business day. A formal reply was supplied to the 
forum the following day August 10, 2017:
3.      Complete list of certificates that your CA finds with each of the 
listed issues during the remediation process. The recommended way to handle 
this is to ensure each certificate is logged to CT and then attach a CSV 
file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct 
problem.
IdenTrust: On August 16, 2017 we have identified a total of 164 ACES 
certificates reflecting o=US Government for non-US government entities. 
4.      Summary of the problematic certificates. For each problem listed below:
number of certs, date first and last certs with that problem were issued.
IdenTrust: The date range of the ACES certificates with issue is from 
08/21/2015 to 05/12/2017
5.      Explanation about how and why the mistakes were made, and not caught 
and fixed earlier. 
IdenTrust: When IdenTrust initially established the ACES SSL certificate 
profile (around 2002), it was intended to apply only to US government entities. 
 At that time, the Organization was defined as a static value of “U.S. 
Government” in our profiles.  Subsequently around 2007, when non-agencies were 
identified to require ACES SSL certificates under the ACES policy, IdenTrust 
interpreted the policy at that time that this static value continued to be 
acceptable as these entities must identify themselves as organizations that act 
as relying parties affiliated with a government program, accepting client 
certificates issued under the ACES program, and are in some capacity associated 
with the U.S. Government programs.  Once we were notified of the problem, we 
consulted internally and with GSA (owner of the ACES policy) and have 
determined that this interpretation needs to be updated to align  with BR 
requirements.  As such we updated our processes and profiles to include the 
Organization as the non-agencies when the FQDN owner is not directly U.S. 
Government agency.     
6.      List of steps your CA is taking to resolve the situation and ensure 
such issuance will not be repeated in the future, accompanied with a timeline 
of when your CA expects to accomplish these things.
IdenTrust:
1.      Effective August 7, 2017 the ACES SSL profile and process has been 
updated to use the applicant Organization name in the Subject DN organization 
field include only HTTP OCSP URLs. 
2.      Other IdenTrust SSL Sub-CA’s have been examined and confirmed that this 
issue does not exist. 
3.      We have been proactively contacting clients via email notifications and 
phone calls inviting them to replace those certificates. As of August 17 2017 
AM we have 153 ACES SSL certificates with this issue. On August 31, 2017 at the 
latest, we will be making a decision regarding any outstanding certificates 
with this issue and will post an update to the forum. 
 
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy