Without an FQDN, I doubt they are in scope for the baseline requirements. They are in scope for the Mozilla policy. The BRs require the cert to be intended for web tls. These are not. The Mozilla policy covers client certs as well as tls.
> On Aug 17, 2017, at 12:27 PM, identrust--- via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
