Hi Kim, I appreciate that you've reported this to m.d.s.p despite the certificates not chaining to an NSS-trusted path. However, since you've called it an "incident report" and said you would treat this as an incident as if it were related to NSS trust, I feel I need to point out that this doesn't appear to contain the information the community would want to see out of an incident report.
The details here are related overwhelmingly to German and EU law, and do not contain concrete information about how the weaknesses were introduced, how and when they were resolved, and what (if anything) D-Trust is doing differently as a result. You may have felt these were implied or not that important, given that German smart cards are now less relevant post-eIDAS, but I think for this to qualify as an incident report, you should make those details explicit. -- Eric On Thu, Oct 19, 2017 at 6:45 AM, Kim Nguyen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Incident Report D-Trust certificates with ROCA fingerprints > > A list of certificates showing a ROCA fingerprint was posted by Rob > Stradling at Mozilla.dev.security.policy on 2017/10/18 available at > https://misissued.com/batch/28/ > This contains among other certificates a number of D-Trust related > certificates that all show a ROCA fingerprint. > > All of these certificates are not related to WebPKI, i.e. are not chaining > to a root trusted by NSS, but were part of the German qualified signature > scheme under the supervision of the German supervisory body > Bundesnetzagentur (BNetzA). The German qualified signature scheme mandated > the sole use of specific smartcards under a specific German scheme > (“Bestätigung nach Signaturgesetz (SigG)” for the operation of a qualified > PKI infrastructure according to this scheme. Qualified TSPs were bound to > this by law. > Smartcards in the German scheme were required to fulfill both a composite > Common Criteria certification according to the relevant protection profiles > as well as a specific qualification according to the German scheme. All > components used by D-Trust during the applicability of the German > Signaturgesetz met these requirements as confirmed by yearly audits by the > accredited conformity assessment body TüvIT. > > The German qualified signature scheme was superseded by the EU eIDAS > regulation, which overrules national signature law in the EU. The eIDAS > regulation became mandatory at the 1st of July 2017 after a one year > transition period. Therefore all certificates related to D-Trust at > https://misissued.com/batch/28/ where deactivated during June 2017 and > revoked later in order to comply with the new eIDAS requirements which > include an eIDAS conformity assessment as well as various technical > adaptions. The trust status of these certificates can be validated in the > German Trusted List (TSL) located at https://www.nrca-ds.de/ which is the > centeal point of trust according to the eIDAS regulation and where the > respective status is shown as withdrawn. > > In the course of this transition smart cards were abandoned as the new > eIDAS regulation now allows for a HSM based infrastructure inside a > qualified TSP (contrary to the former situation according to the German > Signature law). > > Therefore all mentioned D-Trust related certificates at > https://misissued.com/batch/28/ are now deactived and revoked and the > related services are shown as withdrawn in the German TSL. Please note that > a considerable part of these certificates were derived from a root operated > by the supervisory body BNetzA as they were part of the so-called > accredited qualified signature scheme as mandated by national German > signature law. > > Please note that all WebPKI related systems within D-Trust are not > affected by the issue of weak RSA key generation in Infineon components as > all of these systems are HSM based. > > Kim Nguyen, D-Trust > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
