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