Rapporto sui risultati

means is more generic than token since a means just implies that it can be used for the purpose instead of token, which implies a physical presence.

- We are missing the HelpDesk. This role also requires privileged access to be able to support end users. The terms trusted and privileged should be aligned.

- IdP: This abbreviation is wrongly explained. Posta presenta nel suo parere la spiegazione di IdP contenuta in Wikipedia.

Posta segnala che i commenti fatti sono solo questioni terminologiche e chiede per tutti gli aspetti illustrati: Use properly defined terms that avoid confusion.

3 Security Problem Definition

Posta scrive riguardo alla tabella 3: CredentialHandling: The wording is geared towards smart card use. Se non si modifica non si potrà utilizzare mTAN. Chiede di riprendere le definizioni dell’ISO 29115, capitolo 3.3. SCH osserva riguardo al CredentialHandling che se l’utente può revocare autonomamente le sue credenziali, non è necessaria una comunicazione con il service desk dell’IdP. L’ultima frase alla tabella 3, sotto CredentialHandling, deve essere completata alla fine nel modo seguente: «[…] appropriate channels or that the claimant is able to revoke/reset his device/token through appropriate means”. Riguardo al numero 3.2, SCH vuole la seguente aggiunta sulla 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 […]». Riguardo al P.TrustedCommunityEndpoint si dovrebbe aggiungere: «[…] as defined in section 6.3 or 6.4».

4 Security Objectives

Posta osserva riguardo all’O.Confidentiality nella tabella del numero 4.1: Please note that all references to public keys in the user data conflict with this requirement. Public keys are made for dissemination. Si tratta di una questione meramente terminologica. Proposta: modify the definition of user data. Segnala inoltre riguardo all’O.Authentication: The explanation in the second paragraph should be aligned with ISO 29115. Ciò è rilevante per l’accettazione di mTAN. Proposta: use the term «authentication factor». In merito al numero 4.2, Posta fa il seguente commento sull’OE.User Security Awareness: This paragraph contains references to smart card registration processes. Se non si modifica, non sarà più possibile utilizzare mTAN. Si chiede quindi di riprendere le definizioni dell’ISO 29115, capitolo 3.3. HIN segnala riguardo al numero 4.3.1 che la colonna «OE. SecureAreas and Equipment» non è collegata a nessuna riga e lo stesso vale per la riga «A.Physical». Il punto deve essere corretto o completato.

5 Security Requirements

Posta scrive riguardo al numero 5.2.12, FCS_COP.1(1) quanto segue: 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. Se non si modifica, la sicurezza rimane ferma ai livelli attuali, mentre con i riferimenti si evolve automaticamente. Posta chiede di non definire degli algoritmi, ma di far riferimento alle raccomandazioni dell’ufficio tedesco Bundesamt für Sicherheit in der Informationstechnik (BSI) o del National Institute of Standards and Technology (NIST). Inoltre precisa: The referenced standard FIPS PUB 180-3 was superseded by FIPS PUB 180-4 in March 2012. Su questo punto rimanda agli standard attuali¹⁷².

6 Appendix

OFAC scrive riguardo al SAML nel numero 6.4 che questa restrizione tecnologica non è accettabile. SAML non è né universale, né immortale. Il funzionamento degli IdP e dei token d’identificazione deve