Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[identrust--- via dev-security-policy]

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.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy