Ergebnisbericht

„[…] appropriate channels or that the claimant is able to revoke/reset his device/token through appropriate means”. Weiter wünscht SCH im Rahmen von Ziffer 3.2 folgende Ergänzungen zur Policy P.Assertion: „SAMLID-Token has to comply with the specification given in section 6.3 or 6.4. The IdP information processing system shall contain a component to generate unique reference identifiers. A time restricted SAMLID-Token issued […]”. Bezüglich P.TrustedCommunityEndpoint sei zudem folgendes anzufügen: “[…] as defined in section 6.3 or 6.4”.

4 Security Objectives

Die Post schreibt bezüglich O.Confidentiality in der Tabelle von Ziffer 4.1 folgendes: Please note that all references to public keys in the user data conflict with this requirement. Public keys are made for dissemination. Das sei eine reine Frage der Terminologie. Antrag: modify the definition of user data. Weiter gibt sie bezüglich O.Authentication folgendes zu Protokoll: The explanation in the second paragraph should be aligned with ISO 29115. Das sei relevant für Akzeptierung von mTAN. Antrag: use the term "authentication factor". Weiter schreibt die Post unter Ziffer 4.2 bezüglich OE.User Security Awareness: This paragraph contains references to smart card registration processes. Wenn das nicht geändert werde, dann sei mTAN nicht möglich. Es wird beantragt, dass die Definitionen aus ISO 29115, Kapitel 3.3, übernommen werden. HIN weist bezüglich Ziffer 4.3.1 darauf hin, dass die Spalte „OE. SecureAreas and Equipment“ mit keiner Zeile verknüpft sei. Gleiches gelte für die Zeile „A.Physical“. Dies sei zu korrigieren resp. ergänzen.

5 Security Requirements

Die Post schreibt bezüglich Ziffer 5.2.12, FCS_COP.1(1), folgendes: Elliptic Curve keys are way smaller than RSA/DH/EG keys with comparable security¹⁷⁰. Requiring an elliptic curve keys to be 2k in size makes no sense. Wenn das nicht geändert wird, dann werde die Sicherheit stehen bleiben. Mit den Referenzen entwickle sich das automatisch weiter. Es wird beantragt, dass Algorithmen nicht definiert werden, sondern die Empfehlungen des BSI oder des NIST referenziert werden. Weiter fügt die Post folgendes an: The referenced standard FIPS PUB 180-3 was superseded by FIPS PUB 180-4 in March 2012. Sie verweist an dieser Stelle auf die aktuellen Standards¹⁷¹.

6 Appendix

Die OFAC schreibt bezüglich SAML in Ziffer 6.4, dass diese technische Restriktion nicht akzeptabel sei. SAML sei weder universal, noch unvergänglich. Der Betrieb der IDP und der Identifikationstoken müsse in Bezug auf die grundsätzlichen Anforderungen beschrieben werden und nicht zu technisch und einschränkend. SCH macht darauf aufmerksam, dass im vorliegenden Dokument ausschliesslich das SAML-Protokoll für die Authentisierung erwähnt werde. Es würden weitere etablierte Protokolle wie OpenID Connect basierend auf OAuth 2.0 existieren. Die Interoperabilität der IDM müsse sich auf die Formate der Personenidentifizierungsdaten beschränken. Die Protokolle zwischen Relying Party und IdP und die Authentisierungsverfahren sollten jedoch vom Markt her geregelt werden. Es wird beantragt, dass zusätzlich zur „SAML Specification“ auch eine „OpenID Connect/ OAuth 2.0 Specification“ erstellt werden. Zudem sollten die Verordnungen/Anhänge so gestaltet werden, dass weitere Protokolle hinzugefügt werden können. Folgender Vorschlag ist zudem in ihrer Stellungnahme enthalten: 6.5 OpenID Connect/OATH 2.0 Specification; Note: The specification will be drafted during or subsequently to appraisal.