On Wed, Aug 8, 2018 at 8:13 AM, Juan Angel Martin via dev-security-policy < [email protected]> 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
