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
> 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.
dev-security-policy mailing list