Re: Identrust Commercial Root CA 1 EV Request

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

On Wednesday, October 17, 2018 at 9:08:41 PM UTC-4, Matt Palmer wrote:
> On Wed, Oct 17, 2018 at 03:09:52PM -0700, identrust--- via 
> dev-security-policy wrote:
> > On Tuesday, October 16, 2018 at 7:19:07 PM UTC-4, Matt Palmer wrote:
> > > On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via 
> > > dev-security-policy wrote:
> > > > 5.Explanation about how and why the mistakes were made, and not caught 
> > > > and
> > > > fixed earlier.
> > > >
> > > > IdenTrust: The certificate was generated for a server within IdenTrust. 
> > > > The certificate contained internal domain names which were not reachable
> > > > externally.  Two domain names in the SAN (Autodiscover.identrus.int and
> > > > Mercury.identrus.int) were included at that time.  When the certificate
> > > > was generated, these domains were internally hosted domains.
> > > 
> > > This doesn't explain why the mistakes were made, nor does it explain why
> > > they were not caught and fixed earlier.
> >
> > IdenTrust:IdenTrust has strict procedures regarding issuance of publicly
> > trusted website certificates.  However at the time of this certificate
> > issuance (2015) the procedures did allow ability to request exceptions for
> > IdenTrust internal deployments that were not accessible externally.
> 
> On what date was this exception-requesting element added to IdenTrust's
> procedures?
> 
> Please share the criteria which were used to evaluate exception requests.
> 
> How many times has the procedure for requesting an exception been used?  How
> many times has the exception been granted?  I think it would be best if all
> certificates issued under this exception process were made public, to ensure
> that there is full transparency around the extent to which this exception
> process was used.
> 
> Finally, can you speak to why the BR requirements around internal names and
> certificate expiry dates wasn't followed in this case?
> 
> > However due to human error in implementation the server was made available
> > external to our network.  Also due to human error, the IT staff failed to
> > request certificate revocation when the certificate was no longer needed.
> 
> Speaking of revocation, can you explain why this certificate wasn't caught
> by the requirement to revoke all certificates containing internal names by
> 2016-10-01?
> 
> > Upon discovering of this misissuance on 02/22/2018, IdenTrust updated the
> > website certificate approval procedures to eliminate the ability to
> > request exceptions to the standard domain validation\verification
> > procedures.  Please note that these website issuance procedures apply to
> > all applications regardless of the TLD(s) requested in the certificate
> > application.
> 
> Correct me if I'm wrong, but does this mean that until the date you
> specified above, it was procedurally possible for IdenTrust to issue a
> certificate for *any* domain based on the invocation of this exception? 
> Under which subsection of BR section 3.2.2.4 does IdenTrust believe this
> procedure was permitted as of the date of the procedure update?
> 
> - Matt
IdenTrust: We acknowledge the request for more information and are actively 
working on getting the necessary details to accurately respond.   We will 
respond as soon as we can.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy