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
