On Thursday, August 10, 2017 at 11:51:54 PM UTC-4, Eric Mill wrote: > On Thu, Aug 10, 2017 at 11:34 AM, identrust--- via dev-security-policy < > [email protected]> wrote: > > > > We acknowledge seeing this issue and are looking into it. > > Details will be supplied as soon we can but not later that today’s end of > > business day. > > > > Thanks for looking into it. It's coming up on the end of the day - do you > have an update? > > -- Eric > > > > _______________________________________________ > > dev-security-policy mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-security-policy > > > > > > -- > konklone.com | @konklone <https://twitter.com/konklone>
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. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
