Thank you for the incident report Juan. I created https://bugzilla.mozilla.org/show_bug.cgi?id=1481862 to track this issue. Please update the bug as action items are completed.
On Wed, Aug 8, 2018 at 8:41 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wed, Aug 8, 2018 at 8:13 AM, Juan Angel Martin via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Hello, > > > > We detected 5 certificates issued with ERROR: organizationName too long > > (X.509 lint) > > > > 1. How your CA first became aware of the problem (e.g. via a problem > > report submitted to your Problem Reporting Mechanism, a discussion in > > mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and > > the time and date. > > > > We detected these certificates checking the CA issued certificates into > > crt.sh on August 3, 2018. > > > > 2. A timeline of the actions your CA took in response. A timeline is a > > date-and-time-stamped sequence of all relevant events. This may include > > events before the incident was reported, such as when a particular > > requirement became applicable, or a document changed, or a bug was > > introduced, or an audit was done. > > > > 2018-08-03 09:58 UTC --> We detected these 5 certificates and asked the > > team that manages them to revoke them. > > 2018-08-03 15:35 UTC --> All the certificates are revoked. > > > > 3. Whether your CA has stopped, or has not yet stopped, issuing > > certificates with the problem. A statement that you have will be > considered > > a pledge to the community; a statement that you have not requires an > > explanation. > > > > The issuance of certificates from this CA was suspended until the > > operational control was deployed. > > > > > > 4. A summary of the problematic certificates. For each problem: number of > > certs, and the date the first and last certs with that problem were > issued. > > > > https://crt.sh/?id=617995390 > > https://crt.sh/?id=606954201 > > https://crt.sh/?id=606953975 > > https://crt.sh/?id=606953727 > > https://crt.sh/?id=604874282 > > > > > > 5. The complete certificate data for the problematic certificates. The > > recommended way to provide this is to ensure each certificate is logged > to > > CT and then list the fingerprints or crt.sh IDs, either in the report or > as > > an attached spreadsheet, with one list per distinct problem. > > > > https://crt.sh/?id=617995390 > > https://crt.sh/?id=606954201 > > https://crt.sh/?id=606953975 > > https://crt.sh/?id=606953727 > > https://crt.sh/?id=604874282 > > > > > > 6. Explanation about how and why the mistakes were made or bugs > > introduced, and how they avoided detection until now. > > > > There was no effective control into Multicert's PKI platform about DN's O > > lenth and this CA wasn't included into Camerfirma's quality controls > until > > 2018-08-03. > > > > > > 7. List of steps your CA is taking to resolve the situation and ensure > > such issuance will not be repeated in the future, accompanied with a > > timeline of when your CA expects to accomplish these things. > > > > - Multicert's team have added an operational control and they'll delploy > > the techinical control on August 9 > > - Multicert's team will check crt.sh for misissued certificates (from > > today forward). > > - Camerfirma will check for certificates issued by new intermedite CAs > > into crt.sh no more than 24 hours after the CA certificate issuance (from > > today forward). > > > > Your comments and suggestions will be appreciated. > > > > Hi Juan, > > Can you speak more to what the technical controls being deployed are? > > The DNs O length comes from X.509v3 and RFC 5280, so it's a bit baffling to > understand how there wasn't an effective control there. It does call into > question the potential for a lack of other effective controls, which could > be concerning. > > With respect to Camerfirma checking post-issuance what Multicert is doing, > that's certainly the minimum expected, as you've cross-certified them. Can > you help explain why this wasn't already part of your process and controls > when working with third-party CAs? Can you explain why Multicert's PKI > platform is allowed independent issuance, rather than having Camerfirma > manage and maintain that for them, and how the community can rely on > Camerfirma appropriately supervising and mitigating that risk going > forward? > > I think it is good that you detected this, but note that your incident > report doesn't actually examine when Multicert first had this issue. > Looking at https://crt.sh/?id=617995390 for example, I see it being July > 24. Can you explain why it took so long to detect? Can you discuss how far > back you've examined Multicerts issuance? > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
