I am happy to create the bugs, and have done so for this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1534147
On Sun, Mar 10, 2019 at 11:52 AM James Burton via dev-security-policy < [email protected]> wrote: > Hi Fotis, > > You need to file this as a bugzilla bug. > > Thank you, > > Burton > > On Sun, 10 Mar 2019 at 18:34, Fotis Loukos via dev-security-policy < > [email protected]> wrote: > > > SSL.com has been following the recent discussions at > > mozilla.dev.security.policy regarding the behavior of EJBCA based CAs in > > the matter of serial number generation. > > > > SSL.com is using EJBCA internally and is affected by the same issue. > > After consulting with our auditors, we would like to post a preliminary > > report of our findings. > > > > ### 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. > > > > SSL.com has been following discussion of this issue in > > mozilla.dev.security.policy and initiated a review on 05/03/2019. > > > > ### 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. > > > > - 10/07/2016 - Ballot 164 on Certificate Serial Number Entropy is voted. > > - 30/09/2016 - Ballot 164 enters into effect. > > - 05/03/2019 - Initial review initiated. > > - 05/03/2019 - Confirmed issue exists in SSL.com certificates. > > - 05/03/2019 - Tested and deployed correction to production systems. > > - 06/03/2019 - A full plan for the revocation of all certificates has > > been initiated. We plan on revoking all certificates within 30 days. > > > > ### 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. > > > > A patch was deployed as soon as we confirmed that the issue exists in > > SSL.com certificates. Certificate issuance has been resumed with serials > > meeting all requirements. > > > > ### 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. > > > > - 6931 End Entity TLS Certificates > > > > We will post an update that will include all S/MIME and CA certificate > > information. > > > > ### 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. > > > > Please find attached the file tlseelist.txt containing the fingerprints > > of all affected end entity TLS certificates. S/MIME and CA certificate > > information will be posted during an update. > > > > ### Explanation about how and why the mistakes were made or bugs > > introduced, and how they avoided detection until now. > > > > EJBCA's method of generating serial numbers has led to a discrepancy > > between expected and actual behavior and output, such that any CA using > > EJBCA with the default settings will encounter this issue (and be > > therefore in violation of BR 7.1). > > > > ### 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. > > > > The number of bits of entropy used for the generation of serial numbers > > has been increased to 127. > > > > In addition to remediation related to this issue, we will initiate a > > review of other technical requirements of CA/B Forum and how they are > > implemented by EJBCA in order to ensure no more problematic practices > > are followed. > > > > SSL.com intends to exceed minimum technical requirements where ever > > possible to guard against similar issues in the future and ensure the > > highest possible level of security and compliance. > > > > Regards, > > Fotis > > > > -- > > Fotis Loukos, PhD > > Director of Security Architecture > > SSL Corp > > e: [email protected] > > w: https://www.ssl.com > > _______________________________________________ > > dev-security-policy mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
