10. Considérations sur le profilage des applications

10. Considérations sur le profilage des applications

Ce document est conçu pour fournir un ensemble de services de sécurité mais pas pour imposer des exigences de mise en œuvre d'algorithmes pour une utilisation spécifique. Les exigences d'interopérabilité sont fournies pour la façon dont chacun des services individuels est utilisé et comment les algorithmes doivent être utilisés pour l'interopérabilité. Les exigences concernant les algorithmes et les services nécessaires sont reportées à chaque application.

Un exemple de profil peut être trouvé dans [RFC8613], où un profil a été développé pour transporter du contenu en combinaison avec des en-têtes CoAP.

Il est prévu qu'un profil de ce document soit créé qui définit les exigences d'interopérabilité pour cette application spécifique. Cette section fournit un ensemble de directives et de sujets qui doivent être pris en compte lors du profilage de ce document.

• Les applications doivent déterminer l'ensemble des messages définis dans ce document qu'elles utiliseront. L'ensemble des messages correspond assez directement à l'ensemble nécessaire de services de sécurité et de niveaux de sécurité.

• Les applications peuvent définir de nouveaux paramètres d'en-tête pour un usage spécifique. Les applications choisiront souvent des paramètres d'en-tête spécifiques à utiliser ou à ne pas utiliser. Par exemple, une application indiquerait normalement une préférence pour l'utilisation du paramètre d'en-tête IV ou Partial IV. Si le paramètre d'en-tête Partial IV est spécifié, alors l'application doit également définir comment la partie fixe de l'IV est déterminée.

• Lorsque les applications utilisent des données authentifiées définies de manière externe, elles doivent définir comment ces données sont encodées. Ce document suppose que les données seront fournies sous forme de chaîne d'octets. Plus d'informations peuvent être trouvées dans la section 4.3.

• Les applications doivent déterminer l'ensemble des algorithmes de sécurité à utiliser. Lors de la sélection des algorithmes à utiliser comme ensemble obligatoire à mettre en œuvre, il convient de prendre en considération le choix de différents types d'algorithmes lorsque deux sont choisis pour un usage spécifique. Un exemple de ceci serait de choisir HMAC-SHA512 et AES-CMAC (Cipher-Based Message Authentication Code) comme différents algorithmes MAC ; la construction est très différente entre ces deux algorithmes. Cela signifie qu'un affaiblissement d'un algorithme aurait peu de chances de conduire à un affaiblissement des autres algorithmes. Bien sûr, ces algorithmes ne fournissent pas le même niveau de sécurité et peuvent donc ne pas être comparables pour la fonctionnalité de sécurité souhaitée. Des conseils supplémentaires peuvent être trouvés dans [BCP201].

• Les applications peuvent avoir besoin de fournir un certain type de méthode de négociation ou de découverte si plusieurs algorithmes ou structures de message sont autorisés. La méthode peut aller de quelque chose d'aussi simple que d'exiger une préconfiguration de l'ensemble d'algorithmes à la fourniture d'une méthode de découverte intégrée au protocole. S/MIME a fourni un certain nombre de façons différentes d'aborder le problème que les applications pourraient suivre :

  • Publicité dans le message (capacités S/MIME) [RFC8551].

  • Publicité dans le certificat (extension de capacités) [RFC4262].

  • Exigences minimales pour S/MIME, qui ont été mises à jour au fil du temps [RFC2633] [RFC3851] [RFC5751] [RFC8551]. (Notez que [RFC2633] a été rendu obsolète par [RFC3851], qui a été rendu obsolète par [RFC5751], qui a été rendu obsolète par [RFC8551].)