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
Re: Identrust Commercial Root CA 1 EV Request
identrust--- via dev-security-policy Thu, 18 Oct 2018 15:23:20 -0700
- Re: Identrust Commercia... identrust--- via dev-security-policy
- Re: Identrust Commercial Root CA... identrust--- via dev-security-policy
- Re: Identrust Commercial Root CA... nicholas.hatch--- via dev-security-policy
- Re: Identrust Commercial Ro... identrust--- via dev-security-policy
- Re: Identrust Commercia... Matt Palmer via dev-security-policy
- Re: Identrust Comme... Jakob Bohm via dev-security-policy
- Re: Identrust C... identrust--- via dev-security-policy
- Re: Identrust C... identrust--- via dev-security-policy
- Re: Identrust Comme... identrust--- via dev-security-policy
- Re: Identrust C... Matt Palmer via dev-security-policy
- Re: Identr... identrust--- via dev-security-policy
- Re: Identr... Wayne Thayer via dev-security-policy
- Re: Identr... identrust--- via dev-security-policy
- Re: Identr... Wayne Thayer via dev-security-policy
- Re: Identr... identrust--- via dev-security-policy
- Re: Identr... Wayne Thayer via dev-security-policy
- Re: Identr... Wayne Thayer via dev-security-policy