On Thursday, August 10, 2017 at 12:21:18 PM UTC-4, Ryan Sleevi wrote:
> On Thu, Aug 10, 2017 at 11:55 AM, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote:
> > > What's it going to take for mozilla to set up near real-time
> > > monitoring/auditing of certs showing up in ct logs?
> > >
> > > Lee
> > >
> > > On 8/9/17, Alex Gaynor via dev-security-policy
> > > <dev-security-policy@lists.mozilla.org> wrote:
> > > > (Whoops, accidentally originally CC'd to m.d.s originally! Original
> > mail
> > > > was to IdenTrust)
> > > >
> > > > Hi,
> > > >
> > > > The following certificates appear to be misissued:
> > > >
> > > > https://crt.sh/?id=77893170&opt=cablint
> > > > https://crt.sh/?id=77947625&opt=cablint
> > > > https://crt.sh/?id=78102129&opt=cablint
> > > > https://crt.sh/?id=92235995&opt=cablint
> > > > https://crt.sh/?id=92235998&opt=cablint
> > > >
> > > > All of these certificates have a pathLenConstraint value with CA:FALSE,
> > > > this violates 4.2.1.9 of RFC 5280: CAs MUST NOT include the
> > > > pathLenConstraint field unless the cA boolean is asserted and the key
> > usage
> > > > extension asserts the keyCertSign bit.
> > > >
> > > > Alex
> > > >
> > > > --
> > > > "I disapprove of what you say, but I will defend to the death your
> > right to
> > > > say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> > > > "The people's good is the highest law." -- Cicero
> > > > GPG Key fingerprint: D1B3 ADC0 E023 8CA6
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > "I disapprove of what you say, but I will defend to the death your
> > right to
> > > > say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> > > > "The people's good is the highest law." -- Cicero
> > > > GPG Key fingerprint: D1B3 ADC0 E023 8CA6
> > > > _______________________________________________
> > > > dev-security-policy mailing list
> > > > dev-security-policy@lists.mozilla.org
> > > > https://lists.mozilla.org/listinfo/dev-security-policy
> > > >
> > We aware of this situation and had previously introduced logic into our
> > certificate authority that a pathLengthConstraint will never be set for a
> > certificate other than a CA.  We have confirmed that only the stated
> > five (5)
> > certificates contain the issue.  Three (3) of these are real certificates;
> > however, one has expired. We have revoked the other two certificates. The
> > remaining two (2) are pre-certificates.
> 
> 
> It might be helpful if you can share more details regarding this situation,
> to better help the community understand the procedures Identrust has in
> place.
> 
> 1) Were you aware of this issue before it was reported? It's unclear, based
> on this reply, whether this was something you were previously aware of,
> given the logic you mentioning having introduced.
> 2) Given this issue, have you examined other Identrust-issued certificates
> for issues - for example, running the corpus of issued certificates over
> the past year (whether from your own DB or logged in CT) - for other forms
> of violations, such as by using tools as certlint or cablint?
> 3) What processes and procedures are in place at Identrust to help ensure
> certificates properly adhere to RFC 5280? Why did these not detect the
> issue? What steps are being taken in the future to provide greater
> assurance of future conformance?
> 
> While it's useful to hear that you've revoked those certificates, it's
> equally useful to help the community understand what, if any, changes that
> Identrust is making. If the answer is "There was a bug, we fixed it," then
> it's useful to understand what, if any, changes are being made to detect
> and/or prevent such bugs in the future.
> 
> Cheers

Your questions are reasonable.  Here is additional information to address your 
follow up comments.  IdenTrust did identify this situation during a routine 
audit in March of 2017.  The fix mentioned previously was put into place at 
that time.  The certificates (which are all internal to IdenTrust) were 
reissued and those that were incorrect were intended to be revoked; 
unfortunately the revocation did not occur.  

Additional information that might be useful:

These certificates were created during the process of building a new product, 
which has not yet been officially launched and no additional certificates have 
been issued under this profile.  Quarterly audits, comprised of evaluating a 
sampling of certificates, has been conducted; however, due to the fact that a 
revocation order had been issued for these certificates and we have no active 
production certificates for this program, no sampling was warranted.  

With respect to the revocation snafu, because these certificates were not 
production certificates issued to actual subscribers, our standard revocation 
process for “live certificates” does not appear to have been followed; rather, 
an informal emailed request was initiated and was apparently overlooked.  We 
have addressed this internally and put remediation steps into place that will 
alleviate this possibility in the future.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to