> On Aug 15, 2017, at 14:53, identrust--- via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > On Friday, August 11, 2017 at 6:05:29 PM UTC-4, paul.l...@gmail.com wrote: >> On Friday, August 11, 2017 at 3:43:17 PM UTC-5, iden...@gmail.com wrote: >>> IdenTrust is fully aware of the situation and has consulted with internal >>> and external parties to ensure that our course of action is appropriate and >>> commensurate with our business practices and accommodates our customer’s >>> needs. >>> When IdenTrust initially established the ACES SSL profile, 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. Later, >>> when non-agencies applied, IdenTrust reasoned at that time that this static >>> value continued to be acceptable as these entities must identify themselves >>> as organizations that act as relying parties, accepting certificates issued >>> under the ACES program, and are in some capacity associated with the U.S. >>> Government. We have discussed internally and taken a fresh look at this >>> decision. As a result, IdenTrust has updated the ACES SSL profile to use >>> the applicant Organization name in the Subject DN organization field. This >>> change will accommodate all applications for ACES SSL certificates, both >>> U.S. agencies and non-agencies. At the same time, we have modified the >>> OCSP validation URL from HTTPS to HTTP. >>> It is important to note that all certificates that are impacted by this >>> situation have been appropriately vetted by the IdenTrust Registration team >>> according to Identity Validation requirements stated in the ACES CP, >>> therefore the need to revoke affected certificates immediately is less >>> critical. Our key objective is to revoke all incorrect certificates as >>> quickly as possible, while minimizing the impact to our customers and >>> avoiding disruption to critical business processes. As such, IdenTrust is >>> working directly with these customers to initiate a replacement for the >>> offending certificates. The replacement process allows the client to use >>> an online mechanism to request a new certificate with the correct >>> attributes and immediately download the new certificate. The replacement >>> process also automatically revokes the certificate being replaced. This >>> will enable our clients to receive a newly vetted certificate and they will >>> not be inconvenienced by a forced revocation, which would likely adversely >>> impact their business processes. IdenTrust will ultimately force a >>> revocation, in the event that the clients do not initiate a certificate >>> replacement in response to our communications. >>> >>> Thank you for the opportunity to represent our position. >> >> Is it Identrust's contention that the revocation rules required under the >> requirements they are audited under do not apply to these certificates >> because it would inconvenience their customers? This is a clear violation of >> the baseline requirements and I'd like some clarity on why Identrust >> believes it's permissible to pick and choose what their revocation timelines >> will be. >> >> -Paul > No, IdenTrust is not insinuating that the revocation rules do not apply here. > IdenTrust, upon notification, immediately started reviewing our historical > understanding of our ACES SSL program and how it complied with both the ACES > CP and CA/B CP. This review involving internal and external resources began > in earnest. As previously stipulated, all certificates impacted were > appropriately vetted by the IdenTrust Registration team according to Identity > Validation requirements stated in the ACES CP. IdenTrust worked to bridge > the gap between historical definitions and CA/B forum compliance while > balancing the needs of the community and IdenTrust customers alike. > Concurrently, IdenTrust reviewed, implemented and validated programmatic > controls prohibiting the population of the "U.S. Government" for ACES > non-agency entities. Once our technical fix was verified, our priority > objective has been to revoke all non-compliant certificates as quickly as > possible, while minimizing the impact to our customers and avoiding > disruption to critical business processes. IdenTrust has been working with > the certificate sponsors to initiate a replacement for these identified > certificates. One certificate has been successfully replaced. For one > certificate, the customer has requested an extension until Wednesday > (tomorrow) to replace--we have granted this extension, but will revoke if the > replacement in not completed by 5 p.m. MT on Wednesday. For the three > certificates where we were not successful in facilitating a replacement, we > have completed a revocation. We will confirm replacement or revocation of > the last remaining certificate after 5 p.m. MT tomorrow.
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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
