On Fri, Aug 11, 2017 at 4:43 PM, identrust--- via dev-security-policy < [email protected]> wrote:
> 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. > Thanks for the background and the detail. Given that you're intentionally ignoring the 24-hour revocation rule, could you at least provide an estimate of when Identrust will force revocations to be done by? Have clients initiated prompt replacements? -- Eric > > Thank you for the opportunity to represent our position. > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
