10. Considerazioni sulla profilazione dell'applicazione

10. Considerazioni sulla profilazione dell'applicazione

Questo documento è progettato per fornire una serie di servizi di sicurezza ma non per imporre requisiti di implementazione dell'algoritmo per un utilizzo specifico. I requisiti di interoperabilità sono forniti per come viene utilizzato ciascuno dei singoli servizi e come devono essere utilizzati gli algoritmi per l'interoperabilità. I requisiti su quali algoritmi e quali servizi sono necessari sono rinviati a ciascuna applicazione.

Un esempio di profilo può essere trovato in [RFC8613], dove ne è stato sviluppato uno per il trasporto di contenuti in combinazione con intestazioni CoAP.

Si intende creare un profilo di questo documento che definisca i requisiti di interoperabilità per quella specifica applicazione. Questa sezione fornisce una serie di linee guida e argomenti che devono essere considerati durante la profilazione di questo documento.

• Le applicazioni devono determinare l'insieme di messaggi definiti in questo documento che utilizzeranno. L'insieme di messaggi corrisponde abbastanza direttamente all'insieme necessario di servizi di sicurezza e livelli di sicurezza.

• Le applicazioni possono definire nuovi parametri di intestazione per uno scopo specifico. Le applicazioni sceglieranno spesso parametri di intestazione specifici da utilizzare o non utilizzare. Ad esempio, un'applicazione indicherebbe normalmente una preferenza per l'utilizzo del parametro di intestazione IV o Partial IV. Se viene specificato il parametro di intestazione Partial IV, l'applicazione deve anche definire come viene determinata la porzione fissa dell'IV.

• Quando le applicazioni utilizzano dati autenticati definiti esternamente, devono definire come tali dati sono codificati. Questo documento presuppone che i dati saranno forniti come una stringa di byte. Maggiori informazioni possono essere trovate nella Sezione 4.3.

• Le applicazioni devono determinare l'insieme di algoritmi di sicurezza da utilizzare. Quando si selezionano gli algoritmi da utilizzare come insieme obbligatorio da implementare, si dovrebbe prendere in considerazione la scelta di diversi tipi di algoritmi quando ne vengono scelti due per uno scopo specifico. Un esempio di ciò sarebbe la scelta di HMAC-SHA512 e AES-CMAC (Cipher-Based Message Authentication Code) come diversi algoritmi MAC; la costruzione è molto diversa tra questi due algoritmi. Ciò significa che un indebolimento di un algoritmo difficilmente porterebbe a un indebolimento degli altri algoritmi. Naturalmente, questi algoritmi non forniscono lo stesso livello di sicurezza e quindi potrebbero non essere comparabili per la funzionalità di sicurezza desiderata. Ulteriori indicazioni possono essere trovate in [BCP201].

• Le applicazioni potrebbero dover fornire un qualche tipo di metodo di negoziazione o scoperta se sono consentiti più algoritmi o strutture di messaggio. Il metodo può variare da qualcosa di semplice come richiedere la preconfigurazione dell'insieme di algoritmi alla fornitura di un metodo di scoperta integrato nel protocollo. S/MIME ha fornito una serie di modi diversi per approcciare il problema che le applicazioni potrebbero seguire:

  • Pubblicità nel messaggio (funzionalità S/MIME) [RFC8551].

  • Pubblicità nel certificato (estensione delle funzionalità) [RFC4262].

  • Requisiti minimi per S/MIME, che sono stati aggiornati nel tempo [RFC2633] [RFC3851] [RFC5751] [RFC8551]. (Si noti che [RFC2633] è stato reso obsoleto da [RFC3851], che è stato reso obsoleto da [RFC5751], che è stato reso obsoleto da [RFC8551].)