Re: ETSI Audits Almost Always FAIL to list audit period

[Arno Fiedler via dev-security-policy]

Am Dienstag, 31. Oktober 2017 10:21:47 UTC+1 schrieb Dimitris Zacharopoulos:
> It is not the first time this issue is brought up. While I have a very 
> firm opinion that ETSI auditors under the ISO 17065 (focused on the 
> quality of products/services) and ETSI EN 319 403 definitely check 
> historical data to assess the level of conformance, I will communicate 
> this to our auditor and ask if they would like to provide more specific 
> feedback.
> 
> During the CA/Browser Forum F2F 41 in Berlin, it was stated that TUV-IT 
> (CAB and chair in ACAB-c), was in discussions with Root Programs to 
> determine an "ETSI audit report template" that would include all 
> critical information that Root programs would like to be included in the 
> public (or browser) audit letter/report. Minutes 
> (https://cabforum.org/2017/06/21/2017-06-21-f2f-minutes-meeting-41-berlin/)
> 
> --- BEGIN QUOTE ---
> 
> Clemens Wanko from TÜVIT/ACABc – “Update: Addressing Browser Audit 
> Requirements under eIDAS/ETSI”
> 
> Clemens said that there were several discussions with the Browsers that 
> resulted in an audit report template that would meet the Browser’s 
> expectations.
> 
> Dimitris asked if this template could be posted on the public mailing list.
> 
> --- END QUOTE ---
> 
> Until today, such a template has not been published or circulated either 
> in the CA/Browser Forum or the m.d.s.p. I hope this discussion will push 
> for this template to be published.
> 
> I believe the issue being raised here is more of an audit report issue 
> and not of audit criteria. Auditors under the ETSI audit scheme, just as 
> with the Webtrust scheme, in order for the audit to be "effective", must 
> obtain evidence of actions that took place in the past. How far back, 
> should be determined by the audit criteria and requirements. For 
> example, the Baseline Requirements and Root programs require a full 
> audit to occur once a year which means auditors must collect evidence 
> from "at least" one year. Auditors may examine evidence even further 
> back if they consider that this is required in order for them to get a 
> better understanding of CA operations for their assessment.
> 
> Also check Section 7.9 Surveillance (ETSI EN 319 403): "In addition, a 
> sample of records relating to the operation of TSP over the historical 
> period since the previous audit shall be examined by the auditor".
> 
> The 17065 scheme is used to assess products like food. You can't make an 
> effective assessment in such a critical area by just looking at the 
> "current status" without looking at historical data. In the ETSI/ISO 
> audit schemes, CABs are supervised and audited by National Accreditation 
> Bodies (NABs), at least annually which provides some extra level of 
> assurance that the audits conducted by CABs are examined by an 
> independent party. NABs also have the right to witness audits conducted 
> by CABs.
> 
> Finally, when a CA changes audit criteria, like the Firmaprofesional 
> case, the audit is by definition a point-in-time (system bootstrap) for 
> that specific audit standard. However, it is very likely that their 
> auditors checked historical information to complete their assessment. 
> This is poorly communicated in their audit report but we have seen 
> updated reports in the past, clarifying these issues.
> 
> 
> Dimitris.
> 
> 
> PS: I hope we are not mixing audit failures, that are likely to occur in 
> all audit standards, with audit criteria.
> 
> 
> On 30/10/2017 9:16 μμ, Kathleen Wilson via dev-security-policy wrote:
> > All,
> >
> > It is extremely frustrating to deal with ETSI audits, because they 
> > typically do not specifically state the audit period start and end dates. 
> > And it is very difficult to determine if their audit statement is for a 
> > point-in-time audit versus a period-of-time audit.
> >
> > They have a concept of their ETSI certification being valid for one year, 
> > and will list an expiration date for their ETSI certification that is in 
> > the future. Many of the CAs mistakenly enter their ETSI certification dates 
> > for the audit period start and end dates.
> >
> > This is an ongoing problem that I'm very frustrated with.
> >
> > ~~
> >
> > Definition (From BRs):
> > Audit Period: In a period‐of‐time audit, the period between the first day 
> > (start) and the last day of operations (end) covered by the auditors in 
> > their engagement. (This is not the same as the period of time when the 
> > auditors are on‐site at the CA.)"
> >
> > ~~
> >
> > Here is the requirement according to the Baseline Requirements:
> > https://cabforum.org/baseline-requirements-documents/
> > Section 8.1:"The period during which the CA issues Certificates SHALL be 
> > divided into an unbroken sequence of audit periods.
> > An audit period MUST NOT exceed one year in duration."
> >
> > Here's the requirement according to Mozilla's Policy:
> > 

Re: ETSI audits not listing audit periods

[Arno Fiedler via dev-security-policy]

Am Montag, 30. Oktober 2017 22:19:31 UTC+1 schrieb Ryan Sleevi:
> On Mon, Oct 30, 2017 at 3:50 PM, Kathleen Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > How do we get all auditors to start meeting our audit statement
> > requirements?
> >
> > Why haven't all included CAs communicated these requirements to their
> > auditors?
> >
> > Why am I seeing so many audit statements (particularly ETSI audit
> > statements) that do not meet our requirements?
> >
> > I will greatly appreciate thoughtful and constructive ideas on this.
> >
> > Thanks,
> > Kathleen
> >
> 
> Kathleen,
> 
> Thanks for raising this matter! I think it's an important highlighting of
> the very different approaches to auditing employed by WebTrust and ETSI,
> and the underlying reliability and assurance of those audits.
> 
> Below is my attempt to summarize my understanding so far:
> - ETSI EN 319 411-1 specifies generally applicable policy and security
> requirements for trust service providers (TSPs) - including website
> certificates.
> - The purpose of EN 319 411-1 is to provide a framework for assessment of a
> TSP, but does not specify how that assessment is to be caried out (c.f.
> Section 1 of EN 319 411-1)
> - EN 319 411-1 mentions EN 319 403 for guidance on such assessments
> - EN 319 403 provides the framework for conformity assessment bodies (CABs)
> to evaluate TSPs. It's based on/extends ISO/IEC 17065 specific to TSPs.
> - ISO/IEC 17065 is incorporated due to Regulation (EC) No 765/2008 to
> ensure consistency in CABs in evaluating TSPs
> 
> As noted within 319 403 (Introduction), several other documents are
> incorporated as well - ISO/IEC 17021 (common requirements for conformity
> assessment bodies evaluating management systems) and ISO/IEC 27006 (common
> requirements for CABs evaluating information security management systems),
> for example.
> 
> If we put the layer cake together and simplify:
> * ISO/IEC 17065 - Common requirements for conformity assessment bodies
> looking at products/services (e.g. "What should all auditors do")
> * ISO/IEC 17021 - Common requirements for conformity assessment bodies
> looking at management systems
> * ISO/IEC 27006 - Common requirements for conformity assessment bodies
> looking at information security management systems
> * EN 319 403 - Common requirements for conformity assessment bodies
> evaluating TSPs (e.g. "What makes an auditor qualified to be a CA auditor")
> * EN 319 411-1 - Common requirements on the TSP for websites (combined with
> EN 319 401, which 319 411-1 incorporates-and-builds-on)
> 
> In trying to understand why the reports are what they are, we need to look
> in particular at 17021 and 17065, and the framework they use for both audit
> engagements and reporting. 17065 describes a certification scheme.
> Reproducing a paragraph from the introduction:
> 
> """
> Certification of products, processes or services is a means of providing
> assurance that they comply with
> specified requirements in standards and other normative documents. Some
> product, process or service
> certification schemes may include initial testing or inspection and
> assessment of its suppliers' quality
> management systems, followed by surveillance that takes into account the
> quality management system and
> the testing or inspection of samples from the production and the open
> market. Other schemes rely on initial
> testing and surveillance testing, while still others comprise type testing
> only.
> """
> 
> 319 411-1 certification describes a system that is based on an initial
> testing or inspection, along with periodic surveillance. Importantly,
> within 17065 and 17021, the way of ensuring continued compliance is done
> based on contracts and reporting - that is, the client is responsible for
> reporting changes to their conformity assessment body, and the CAB may
> determine to revoke the certification or indicate corrective actions should
> be taken (see ISO/IEC 17065:2012(E) 4.1.2.2, ISO/IEC 17021:2006(E) 8.6.3).
> ISO/IEC 17065:2012(E), Section 7.7 describes the general reporting: the
> name of the CAB, the date the certification is granted, the name and
> address of the client, the scope of the certification, the validity
> period/expiration date of the certificate, and anything else required by
> the certification scheme (319 411-1).
> 
> Within the WebTrust scheme, the reports are based on either US (AICPA)
> Standards of AT101, Canadian (CPA Canada) Standards of Section 5025, or
> IFAC's ISAE3000 standards. What is important and notable about these is
> that they are reports over information, with a scope and norm (e.g.
> WebTrust for CAs) applied. This is why there's a consistent period of time
> - information is collected and the auditor evaluates, on the basis of that
> information, the level of assurance that is being met.
> 
> I'm still working to have a better understanding here (and this is all in a
> personal capacity), but my 

Re: ETSI audits not listing audit periods

[Arno Fiedler via dev-security-policy]

Hello Kathleen,

there is a problem with the auditor qualification and the national 
accreditation of some auditing bodies.
We´ll ask ACABc to suggest a solution to take care about proper education of 
"qualified" auditors and "good practise" audit statements as suggested by 
Mozilla, maybe we need "white list" of qualified audit bodies.

Best regards

Arno Fiedler


Am Montag, 30. Oktober 2017 22:19:31 UTC+1 schrieb Ryan Sleevi:
> On Mon, Oct 30, 2017 at 3:50 PM, Kathleen Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > How do we get all auditors to start meeting our audit statement
> > requirements?
> >
> > Why haven't all included CAs communicated these requirements to their
> > auditors?
> >
> > Why am I seeing so many audit statements (particularly ETSI audit
> > statements) that do not meet our requirements?
> >
> > I will greatly appreciate thoughtful and constructive ideas on this.
> >
> > Thanks,
> > Kathleen
> >
> 
> Kathleen,
> 
> Thanks for raising this matter! I think it's an important highlighting of
> the very different approaches to auditing employed by WebTrust and ETSI,
> and the underlying reliability and assurance of those audits.
> 
> Below is my attempt to summarize my understanding so far:
> - ETSI EN 319 411-1 specifies generally applicable policy and security
> requirements for trust service providers (TSPs) - including website
> certificates.
> - The purpose of EN 319 411-1 is to provide a framework for assessment of a
> TSP, but does not specify how that assessment is to be caried out (c.f.
> Section 1 of EN 319 411-1)
> - EN 319 411-1 mentions EN 319 403 for guidance on such assessments
> - EN 319 403 provides the framework for conformity assessment bodies (CABs)
> to evaluate TSPs. It's based on/extends ISO/IEC 17065 specific to TSPs.
> - ISO/IEC 17065 is incorporated due to Regulation (EC) No 765/2008 to
> ensure consistency in CABs in evaluating TSPs
> 
> As noted within 319 403 (Introduction), several other documents are
> incorporated as well - ISO/IEC 17021 (common requirements for conformity
> assessment bodies evaluating management systems) and ISO/IEC 27006 (common
> requirements for CABs evaluating information security management systems),
> for example.
> 
> If we put the layer cake together and simplify:
> * ISO/IEC 17065 - Common requirements for conformity assessment bodies
> looking at products/services (e.g. "What should all auditors do")
> * ISO/IEC 17021 - Common requirements for conformity assessment bodies
> looking at management systems
> * ISO/IEC 27006 - Common requirements for conformity assessment bodies
> looking at information security management systems
> * EN 319 403 - Common requirements for conformity assessment bodies
> evaluating TSPs (e.g. "What makes an auditor qualified to be a CA auditor")
> * EN 319 411-1 - Common requirements on the TSP for websites (combined with
> EN 319 401, which 319 411-1 incorporates-and-builds-on)
> 
> In trying to understand why the reports are what they are, we need to look
> in particular at 17021 and 17065, and the framework they use for both audit
> engagements and reporting. 17065 describes a certification scheme.
> Reproducing a paragraph from the introduction:
> 
> """
> Certification of products, processes or services is a means of providing
> assurance that they comply with
> specified requirements in standards and other normative documents. Some
> product, process or service
> certification schemes may include initial testing or inspection and
> assessment of its suppliers' quality
> management systems, followed by surveillance that takes into account the
> quality management system and
> the testing or inspection of samples from the production and the open
> market. Other schemes rely on initial
> testing and surveillance testing, while still others comprise type testing
> only.
> """
> 
> 319 411-1 certification describes a system that is based on an initial
> testing or inspection, along with periodic surveillance. Importantly,
> within 17065 and 17021, the way of ensuring continued compliance is done
> based on contracts and reporting - that is, the client is responsible for
> reporting changes to their conformity assessment body, and the CAB may
> determine to revoke the certification or indicate corrective actions should
> be taken (see ISO/IEC 17065:2012(E) 4.1.2.2, ISO/IEC 17021:2006(E) 8.6.3).
> ISO/IEC 17065:2012(E), Section 7.7 describes the general reporting: the
> name of the CAB, the date the certification is granted, the name and
> address of the client, the scope of the certification, the validity
> period/expiration date of the certificate, and anything else required by
> the certification scheme (319 411-1).
> 
> Within the WebTrust scheme, the reports are based on either US (AICPA)
> Standards of AT101, Canadian (CPA Canada) Standards of Section 5025, or
> IFAC's ISAE3000 standards. What is important and notable about these is
> that they are 

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

[Arno Fiedler via dev-security-policy]

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

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

[Arno Fiedler via dev-security-policy]

Am Dienstag, 15. August 2017 16:21:03 UTC+2 schrieb Gervase Markham:
> 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

We really genuinely regret the delayed reaction, today we add the non-personal 
contact email
"rootsto...@d-trust.net"
that should improve the process.

Arno 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Arno Fiedler via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Arno Fiedler via dev-security-policy]

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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Arno Fiedler via dev-security-policy]

We´ll talk with the Management and the Certification Audit Body and will 
give feedback.


Arno


Am 10.08.2017 um 15:57 schrieb Ryan Sleevi:

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-security-policy@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

arno.fied...@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:jonat...@titanous.com]
Gesendet: Dienstag, 8. August 2017 19:12
An: Fiedler, Arno
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Betreff: Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with
short SerialNumber



On Aug 8, 2017, at 08:58, Fiedler, Arno via dev-security-policy <

dev-security-policy@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=cablint

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

Thanks,

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


.



--
Arno Fiedler
Nimbus Technologieberatung GmbH
Reichensteiner Weg 17
14195 Berlin
Mobil:  0049-(0)172-3053272
Fax:0049-(0)30-89745-777
E-Mail: arno.fied...@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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Arno Fiedler via dev-security-policy]

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

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

Tel. :+ 49 30 25 98 - 3009
Mobil: + 49 172 3053272
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: dNSName containing '/' / low serial number entropy

[Arno Fiedler via dev-security-policy]

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



Am Mittwoch, 19. Juli 2017 00:26:16 UTC+2 schrieb Charles Reiss:
> https://crt.sh/?id=174827359 is a certificate issued by D-TRUST SSL 
> Class 3 CA 1 2009 containing the DNS SAN 
> 'www.lbv-gis.brandenburg.de/lbvagszit' (containing a '/') with a 
> notBefore in April 2017.
> 
> The certificate also seems to have a short certificate serial number, 
> which cannot include 64 bits of entropy. Many certificates issued by 
> this CA appears to use large serial numbers (e.g. [1]). But there are 
> certificates with much shorter sequential-looking serial numbers with 
> notBefores shortly before [2] and after [3] this certificate's and as 
> recent as 4 July 2017 [4].
> 
> [1] https://crt.sh/?id=137090990 , https://crt.sh/?id=124715040
> [2] 
> https://censys.io/certificates/4445455caca3e9cf2ab2b673304487cb220871aa6d5ac1bf03827f74609c3646
> [3] 
> https://censys.io/certificates/8d08033efe732e8fb6c2f3257c52b500af991bd1f363ffd6e29ec1812a943cd9
> [4] https://crt.sh/?id=173758922
> 
> 
> I did a cursory check on censys.io to see if there were other cases of 
> short serial numbers in certificates with recent notBefores that are 
> trusted by Mozilla:
> 
> - Digidentity Services CA - G2 (https://crt.sh/?caid=868 ; chains to 
> Staat der Nederlanden Root CA - G2) has issued certificates which serial 
> numbers that appear to be of the form 0x1000 + sequential counter 
> with notBefores as recent as 8 June 2017.
> 
> - Siemens Issuing CA Internet Server 2016 (https://crt.sh/?caid=26087 ; 
> chains to QuoVadis Root CA 2 G3) has issued certificates with 4-byte 
> serial numbers with notBefores as recent as 11 July 2017, though they do 
> not appear to be assigned sequentially.
> 
> D-Trust and QuoVadis both indicated no problems complying with version 
> 2.4.1 of Mozilla's certificate policies (which requires, among other 
> things, 64 bits of serial number entropy) by 1 June 2017 when they 
> replied to Mozilla's April CA communication. The Government of the 
> Netherlands indicated they needed a delay for CPS translation only.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy