Hi Arno, Tools like https://github.com/alex/ct-tools or https://github.com/grahamedgecombe/ct-submit can be used to manually submit specific certificates to CT logs.
Alex On Thu, Aug 17, 2017 at 9:07 AM, Arno Fiedler via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Am Montag, 14. August 2017 18:44:59 UTC+2 schrieb Jonathan Rudenberg: > > Hi Arno and Martin, > > > > > On Aug 14, 2017, at 11:44, Arno Fiedler <arno.fied...@outlook.com> > wrote: > > > > > > Dear Forum, > > > > > > since the 07-07-2017, all new issued D-TRUST TLS-Certificates have at > least 64 bits of entropy in the serial number. > > > > > > Since 01-12-2016 D-TRUST TLS certificates requested via our enterprise > platform have a serial number which includes at least 64 bits of entropy. > We informed the CA-Program Manager about the 3 Month delay in moving the > entropy from the "DNqualifier” to the “SerialNumber” via eMail on 27-10-16. > > > > Does this mean that you knew you would not be complying with Ballot 164 > / BRs 1.3.7 by the effective date of 2016-09-30? When did you realize this? > Did you receive permission for this non-compliance from the relevant > Application Software Suppliers, including Mozilla? > Answer: > We realized that there were problems with the implementation of Ballot 164 > in September 2016 and we informed the Rootstore/Browser Provider via email > on 2016-10-27 that we would be delayed until December 2016. > We believed ourselves to be compliant with Ballot 164 from 2016-12-01 when > we implemented it into our enterprise platform. However, on 2017-08-07, we > received knowledge about the case. > > > > Between 2012 and 06-07-2017 we still produced a smaller number of > certificates using our retail platform with additional entropy in the > “DNqualifier” field instead of the serial number field, because our > certified third party software was not able to handle long serial numbers > earlier. We defined this issue as minor nonconformity, because the > requirement for entropy in the certificate was fulfilled. > > > > What other issues have you defined as a "minor nonconformity"? > Answer: > We didn´t detect any other minor nonconformity. In general we work with an > accreditation scheme based on ISO 27 and EN 319 403 to implement the > requirements from Root-Policies, CA/B-Forum Guidelines, eIDAS-Regulation > and ETSI Policies, there are defined audit procedures to recognize, control > and remediate nonconformities under the supervision of the certification > audit body > > > > > On 20-07-17 Mozilla asked D-TRUST for clarification, due to the > holiday period this message reached us on 07-08-17, AF answered on 08-08-17 > and 10-08-17: “the certificate has 64 bits of entropy in the "DNqualifier" > field instead of the serial number field. Since 2012 we used this way of > adding random bits to certificates to mitigate preimage attacks. From a > security perspective the amount of Entropy in the certificate should be > reasonable”. > > > > > > On 10-08-2017 we got the information, that we issued in the Individual > Certificate Registration process a certificate with less entropy than 64 > bit, Jonathan reported “The DNqualifier appears to have a 33-bit number, > not a 64-bit number”. > > > > > > On the 11-08-2017 we defined this case as a major issue, because our > internal examinations confirmed, that just using numeric characters causes > entropy less than 64 bit. > > > > > > The review with our tool “PKI-watcher” gave the following result of > effected certificates: > > > D-TRUST SSL Class 3 CA 1 2009 (607) > > > D-TRUST SSL Class 3 CA 1 EV 2009 (63) > > > > To provide transparency, can you please add all of these certificates to > at least one CT log and post the serial numbers, certificate fingerprints, > or crt.sh IDs? > Answer: > We have implemented the CT logs into our EV production process and are > currently unaware about how to manually export specific certificates to a > log; we will publish the affected certificate serial numbers immediately > via *.csv. Please advise us about the receiver. > A new certificate – instead of “www.lbv-gis.brandenburg.de/lbvagszit” – > has been issued, the old one is revoked. > Arno > > > > > Jonathan > > _______________________________________________ > 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
