Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

640 views
Skip to first unread message

Fiedler, Arno

unread,
Aug 8, 2017, 11:22:53 AM8/8/17
to mozilla-dev-s...@lists.mozilla.org, Henschel, Andreas (D-Trust), Rootstores, ge...@mozilla.com, arno.f...@outlook.com
Dear Mozilla Security Policy Community,

Thanks for the advice about the short serial numbers and apologies for the delayed response.

Since 2016, all D-TRUST TLS certificates based on electronic Certificate Requests have a certificate serial number which includes 64 bits of entropy.

Between 2012 and July 6th, 2017 we produced a small number of certificates with paper-based Certificate Registration Requests using 64 bits of entropy in the "DNqualifier" field instead of the serial number field.

Since the 7th of July, 2017, all D-TRUST TLS-Certificates have 64 bits of entropy in the serial number.

I hope this helps and please do not hesitate to contact us if there are any further questions.

Best regards
Arno Fiedler
Standardization & Consulting
Bundesdruckerei GmbH
Kommandantenstraße 18 · 10969 Berlin · Deutschland

Tel. : + 49 30 25 98 - 3009
Mobil: + 49 172 3053272

arno.f...@bdr.de · www.bundesdruckerei.de<http://www.bundesdruckerei.de>

Sitz der Gesellschaft: Berlin · Handelsregister: AG Berlin-Charlottenburg HRB 80443. USt.-IdNr.: DE 813210005
Aufsichtsratsvorsitzender: Willi Berchtold
Geschäftsführer: Ulrich Hamann (Vorsitzender), Christian Helfrich

This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, we hereby give notice that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this message in error, please delete the message and notify us immediately.
Diese Nachricht kann vertrauliche und gesetzlich geschützte Informationen enthalten. Sie ist ausschließlich für den Adressaten bestimmt. Wenn Sie nicht der beabsichtigte Adressat sind, möchten wir Sie hiermit darüber informieren, dass das Weiterleiten, Verteilen oder Kopieren dieser Mail nicht gestattet ist. Wenn Sie diese Mail irrtümlicherweise erhalten haben, informieren Sie uns bitte schnellstmöglich und löschen Sie bitte die Mail.

Ryan Sleevi

unread,
Aug 8, 2017, 12:49:54 PM8/8/17
to mozilla-dev-s...@lists.mozilla.org
Thanks for acknowledging this, Arno, but I can't help but feel this is an insufficient and incomplete analysis.

Could you share more along the following:
1) How many certificates were affected?
2) How did you determine this?
3) Did you detect this prior to July 7?
4) If not, why not, given the availability of tools?
5) Have you completed an analysis of what the root cause of your failure to follow the Baseline Requirements was?
6) If so, what was it? If not, why not?
7) Was this detected by your audits?
8) If so, why was it not noted at the time? If not, what would you suggest be added to prevent this in the future?
9) What systematic steps have you taken to ensure compliance with the BRs in a timely fashion?

The goal here is not penance from a CA, nor is it granting indulgences or special dispensation - it's about demonstrating an awareness of the requirements and the opportunity to improve how a CA is managed to comply to these requirements, if it is to continue to be trusted as a CA.

Jonathan Rudenberg

unread,
Aug 8, 2017, 1:12:24 PM8/8/17
to Fiedler, Arno, mozilla-dev-s...@lists.mozilla.org

> On Aug 8, 2017, at 08:58, Fiedler, Arno via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> Dear Mozilla Security Policy Community,
>
> Thanks for the advice about the short serial numbers and apologies for the delayed response.
>
> Since 2016, all D-TRUST TLS certificates based on electronic Certificate Requests have a certificate serial number which includes 64 bits of entropy.
>
> Between 2012 and July 6th, 2017 we produced a small number of certificates with paper-based Certificate Registration Requests using 64 bits of entropy in the "DNqualifier" field instead of the serial number field.
>
> Since the 7th of July, 2017, all D-TRUST TLS-Certificates have 64 bits of entropy in the serial number.
>
> I hope this helps and please do not hesitate to contact us if there are any further questions.

Hi Arno,

It doesn’t look like this certificate has been revoked yet? https://crt.sh/?id=174827359&opt=cablint

Can you explain why it hasn’t been revoked yet and when it will be?

Thanks,

Jonathan

Fiedler, Arno

unread,
Aug 10, 2017, 7:56:05 AM8/10/17
to Jonathan Rudenberg, Rootstores, mozilla-dev-s...@lists.mozilla.org
Hello Jonathan,

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.

Do you see a security need for revoking the certificate?

Viele Grüße

Arno Fiedler
Standardization & Consulting
Bundesdruckerei GmbH
Kommandantenstraße 18 · 10969 Berlin · Deutschland

Tel. : + 49 30 25 98 - 3009
Mobil: + 49 172 3053272

arno.f...@bdr.de · www.bundesdruckerei.de

Sitz der Gesellschaft: Berlin · Handelsregister: AG Berlin-Charlottenburg HRB 80443. USt.-IdNr.: DE 813210005
Aufsichtsratsvorsitzender: Willi Berchtold
Geschäftsführer: Ulrich Hamann (Vorsitzender), Christian Helfrich

This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, we hereby give notice that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this message in error, please delete the message and notify us immediately.

Diese Nachricht kann vertrauliche und gesetzlich geschützte Informationen enthalten. Sie ist ausschließlich für den Adressaten bestimmt. Wenn Sie nicht der beabsichtigte Adressat sind, möchten wir Sie hiermit darüber informieren, dass das Weiterleiten, Verteilen oder Kopieren dieser Mail nicht gestattet ist. Wenn Sie diese Mail irrtümlicherweise erhalten haben, informieren Sie uns bitte schnellstmöglich und löschen Sie bitte die Mail.


-----Ursprüngliche Nachricht-----
Von: Jonathan Rudenberg [mailto:jona...@titanous.com]
Gesendet: Dienstag, 8. August 2017 19:12
An: Fiedler, Arno
Cc: mozilla-dev-s...@lists.mozilla.org
Betreff: Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

Arno Fiedler

unread,
Aug 10, 2017, 8:02:00 AM8/10/17
to mozilla-dev-s...@lists.mozilla.org
Hello Jonathan,

this 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.

Do you see a security need for revoking the certificate?

Viele Grüße

Ryan Sleevi

unread,
Aug 10, 2017, 9:58:20 AM8/10/17
to Fiedler, Arno, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Rootstores
Under the Baseline Requirements, v1.4.8 (current version), 4.9.1.1,

"The CA SHALL revoke a Certificate within 24 hours if one of more of the
following occurs:
9. The CA is made aware that the Certificate was not issued in accordance
with these requirements or the CA's Certificate Policy or Certification
Practice Statement"

Since the passage of Ballot 165 (
https://cabforum.org/2016/07/08/ballot-164/ ), adopted in version 1.3.7
"Effective September 30, 2016, CAs SHALL generate Certificate serial
numbers greater than zero (0) containing at least 64 bits of output from a
CSPRNG."

So these were not issued in accordance with these Requirements, and thus
subject to revocation.

On Thu, Aug 10, 2017 at 7:55 AM, Fiedler, Arno via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Hello Jonathan,
>
> 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.
>
> Do you see a security need for revoking the certificate?
>
> Viele Grüße
>
> Arno Fiedler
> Standardization & Consulting
> Bundesdruckerei GmbH
> Kommandantenstraße 18 · 10969 Berlin · Deutschland
>
> Tel. : + 49 30 25 98 - 3009
> Mobil: + 49 172 3053272
>
> certificates with paper-based Certificate Registration Requests using 64
> bits of entropy in the "DNqualifier" field instead of the serial number
> field.
> >
> > Since the 7th of July, 2017, all D-TRUST TLS-Certificates have 64 bits
> of entropy in the serial number.
> >
> > I hope this helps and please do not hesitate to contact us if there are
> any further questions.
>
> Hi Arno,
>
> It doesn’t look like this certificate has been revoked yet?
> https://crt.sh/?id=174827359&opt=cablint
>
> Can you explain why it hasn’t been revoked yet and when it will be?
>
> Thanks,
>
> Jonathan
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Jonathan Rudenberg

unread,
Aug 10, 2017, 10:00:52 AM8/10/17
to Fiedler, Arno, mozilla-dev-s...@lists.mozilla.org, Rootstores

> On Aug 10, 2017, at 07:55, Fiedler, Arno via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> Hello Jonathan,
>
> 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.
>
> Do you see a security need for revoking the certificate?

1) The dnQualifier appears to have a 33-bit number, not a 64-bit number.

2) One of the SAN dnsNames is "www.lbv-gis.brandenburg.de/lbvagszit”, which is clearly invalid.

3) The Baseline Requirements are extremely clear about this:

> The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:
> […]
> 9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;

So yes, I believe this certificate needs to be revoked immediately. It should have been revoked within 24 hours of learning about it. I believe July 20th was the latest date that you could have learned about it, when Gerv sent a notification to you.

Arno Fiedler

unread,
Aug 10, 2017, 11:52:06 AM8/10/17
to mozilla.dev.s...@googlegroups.com, Fiedler, Arno, Jonathan Rudenberg, Rootstores, A.Hen...@d-trust.net, mozilla-dev-s...@lists.mozilla.org, m.ri...@d-trust.net
We´ll talk with the Management and the Certification Audit Body and will
give feedback.

Arno
> .
>

--
Arno Fiedler
Nimbus Technologieberatung GmbH
Reichensteiner Weg 17
14195 Berlin
Mobil: 0049-(0)172-3053272
Fax: 0049-(0)30-89745-777
E-Mail: arno.f...@nimbus-berlin.com
Web: www.nimbus-berlin.com
Geschäftsführer: Arno Fiedler
USt-IdNr. : DE 203 269 920
D-U-N-S® Nr. 50-730-8117
HandelsregisterNr:HRB 109409 B

Arno Fiedler

unread,
Aug 14, 2017, 11:37:32 AM8/14/17
to mozilla-dev-s...@lists.mozilla.org
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.

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.
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)
As result we confirm to do the following steps and report about the implementation latest until 15-09-2017
• Contact all effected customers, inform them and get the certs replaced (includes revocation)
• Improve the security controls for any “Individual Certificate Registration“ with advice from our certification audit body to ensure, that 06-07-17 was the latest date for issuing certs without the 64 bit entropy in serial number and to avoid any other possible technical non compliance to the CA/B-Forum Ballots
• Set up a new mechanism for follow and be aware of discussions in the mozilla.dev.security.policy forum
• Implement a new version of a CSR-Validator to avoid any wrong encoding
• Review the impact of the CA/B-Forum ballots within time possible timeframe for implementation

We really regret this strong delay in conformance to the CA/B-Forum and Mozilla requirements.

Dr. Martin Riegel COO D-TRUST GmbH

Arno Fiedler; Standardization and Consulting


Arno Fiedler

unread,
Aug 14, 2017, 11:55:16 AM8/14/17
to mozilla.dev.s...@googlegroups.com, Ryan Sleevi, Gervase Markham, Frank Steinfeldt, A.Hen...@d-trust.net, mozilla-dev-s...@lists.mozilla.org, Fiedler, Arno, Kathleen Wilson, Jonathan Rudenberg, kim nguyen, Rootstores, Lautenschlager, Stefan, m.ri...@d-trust.net, Nguyen Dr., Kim, Ryan Hurst
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.
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.
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)
As result we confirm to do the following steps and report about the implementation latest until 15-09-2017

* · Contact all effected customers, inform them and get the certs replaced (includes revocation)
* · Improve the security controls for any “Individual Certificate Registration“ with advice from our certification audit body to ensure,
that 06-07-17 was the latest date for issuing certs without the 64 bit entropy in serial number and to avoid any other possible technical non compliance to the CA/B-Forum Ballots
* · Set up a new mechanism for follow and be aware of discussions in the mozilla.dev.security.policy forum
* · Implement a new version of a CSR-Validator to avoid any wrong encoding
* · Review the impact of the CA/B-Forum ballots within time possible timeframe for implementation

We really regret this strong delay in conformance to the CA/B-Forum and Mozilla requirements.
Dr. Martin Riegel,
COO D-TRUST GmbH

Jonathan Rudenberg

unread,
Aug 14, 2017, 12:44:59 PM8/14/17
to Fiedler, Arno, m.ri...@d-trust.net, mozilla-dev-s...@lists.mozilla.org
Hi Arno and Martin,

> On Aug 14, 2017, at 11:44, Arno Fiedler <arno.f...@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?

> 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"?

> 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?

Jonathan

Eric Mill

unread,
Aug 14, 2017, 6:16:57 PM8/14/17
to Arno Fiedler, mozilla-dev-s...@lists.mozilla.org
Hi Arno, Martin,

On Mon, Aug 14, 2017 at 11:37 AM, Arno Fiedler via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> As result we confirm to do the following steps and report about the
> implementation latest until 15-09-2017
> • Contact all effected customers, inform them and get the certs
> replaced (includes revocation)


Can you be a bit more detailed about this step? By what date will all
affected certs be revoked?

-- Eric



>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

Gervase Markham

unread,
Aug 15, 2017, 10:21:03 AM8/15/17
to mozilla-dev-s...@lists.mozilla.org
On 14/08/17 16:44, Arno Fiedler wrote:
> fulfilled. 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

I was going to complain about this but, re-reviewing the CCADB Common
Policy[0], it says:

"Notification of security and audit-related issues will be emailed to
all POCs and the email aliases; CAs are advised to supply sufficient
POCs that will enable them to respond to an issue promptly."

As I only sent the notification to Arno alone (the primary PoC) then I
have to take responsibility for not providing sufficient notification.
My apologies.

Gerv

[0] http://ccadb.org/policy

Arno Fiedler

unread,
Aug 16, 2017, 8:17:06 AM8/16/17
to mozilla-dev-s...@lists.mozilla.org
We really genuinely regret the delayed reaction, today we add the non-personal contact email
"roots...@d-trust.net"
that should improve the process.

Arno

Arno Fiedler

unread,
Aug 17, 2017, 9:08:08 AM8/17/17
to mozilla-dev-s...@lists.mozilla.org
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.f...@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

Alex Gaynor

unread,
Aug 17, 2017, 9:27:52 AM8/17/17
to Arno Fiedler, mozilla-dev-s...@lists.mozilla.org
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-secur...@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.f...@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
>
> >
Reply all
Reply to author
Forward
0 new messages