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?
IdenTrust:
At this point we are unable to ascertain the exact date the
exception-requesting element was added. We can confirm the that the
exception-requesting element pre-dates 2012.
> Please share the criteria which were used to evaluate exception requests.
IdenTrust:
The criteria for the exception is that Registration desk, upon request of
IdenTrust IT Staff, can request to risk management an exception to complete an
attempted Verification of Domain through external registrars for domain name
that is IdenTrust owned domain equivalent for servers that will not be
accessible externally.
> 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.
IdenTrust:
The exception request has been used on the issuance of the 13 certificates
listed below, now in CT logs. Please note that majority of the certificates
listed were issued pre-2012.
https://crt.sh/?id=514746
https://crt.sh/?id=7852280
https://crt.sh/?id=882509134
https://crt.sh/?id=882509077
https://crt.sh/?id=882509158
https://crt.sh/?id=882509159
https://crt.sh/?id=882597656
https://crt.sh/?id=882509100
https://crt.sh/?id=882509154
https://crt.sh/?id=882509101
https://crt.sh/?id=882597659
https://crt.sh/?id=882509103
https://crt.sh/?id=882509147
> Finally, can you speak to why the BR requirements around internal names and
> certificate expiry dates wasn't followed in this case?
IdenTrust:
As noted the exception request procedure pre-dates 2012. Our best
determination is that the procedure was not updated correctly to remove the
ability to allow the exception for internal names for IdenTrust owned domains
on at the time BR v1 was adopted in 2012 as it should have been.
> > 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?
IdenTrust:
This was due to human error in interpreting the exception granted to
certificates issued to internal names of IdenTrust owned domain equivalents on
servers that were not supposed to be accessible externally. The following
certificates containing internal names were not revoked as of 2016-10-01:
https://crt.sh/?id=514746
https://crt.sh/?id=7852280
https://crt.sh/?id=882509134
https://crt.sh/?id=882509077
> > 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?
IdenTrust:
The exception is limited to IdenTrust internal servers for internal name
equivalent of IdenTrust owned domain name. While its conceivable that any
domain could have been requested it is not possible (with exception of human
error) that it would pass the test that domain equivalent is owned by
IdenTrust and therefore not in scope for granting an exception. Of course its
clear that upon adoption of BR v1 in 2012 we should have removed this pre-BR
exception as it is not allowed under BR section 3.2.2.4.
> - Matt
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
