Équipe d'ingénierie de l'Internet (IETF)	B. Ramsdell, Brute Squad Labs	
Request for Comments : 8551	J. Schaad, August Cellars	
RFC rendue obsolète : 5751	S. Turner, sn3rd	
Catégorie : sur la voie de la normalisation	avril 2019	
ISSN: 2070-1721	Traduction Claude Brière de L'Isle	

Spécification du message d'extensions multi objets de messagerie Internet sécurisée (S/MIME) version 4.0

Résumé
Le présent document définit les extensions multi objets de messagerie Internet sécurisée (S/MIME, Secure/Multipurpose Internet Mail Extensions) version 4.0. S/MIME fournit un moyen cohérent pour envoyer et recevoir des données MIME sécurisées. Les signatures numériques assurent l'authentification, l'intégrité de message, et la non répudiation avec preuve d'origine. Le chiffrement assure la confidentialité des données. La compression peut être utilisée pour réduire la taille des données. Le présent document rend obsolète la RFC 5751.

Statut de ce mémoire
Ceci est un document de l’Internet sur la voie de la normalisation.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC7841.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc8551.

Notice de droits de reproduction
Copyright (c) 2019 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF () en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.
Table des matières
1. Introduction	2
1.1 Vue d'ensemble de la spécification	3
1.2 Définitions	3
1.3 Conventions utilisées dans le document	4
1.4 Compatibilité avec la pratique antérieure de S/MIME	4
1.5 Changements de S/MIME v3 à S/MIME v3.1	5
1.6 Changements de S/MIME v3.1 à  S/MIME v3.2	5
1.7 Changements pour S/MIME v4.0	6
2. Options de CMS	7
2.1 DigestAlgorithmIdentifier	7
2.2 SignatureAlgorithmIdentifier	7
2.3 KeyEncryptionAlgorithmIdentifier	7
2.4 Syntaxe générale	8
2.5 Attributs et type SignerInfo	8
2.6 Type SignerInfo SignerIdentifier	11
2.7 ContentEncryptionAlgorithmIdentifier	11
3. Création des messages S/MIME	12
3.1 Préparation de l'entité MIME à la signature, l'enveloppement, ou la compression	13
3.2 Type de support application/pkcs7-mime	15
3.3 Création d'un message Enveloped-Only	17
3.4 Création d'un message authentifié seulement enveloppé	17
3.5 Création d'un message Signed-Only	18
3.6 Création d'un message Compressed-Only	21
3.8 Opérations multiples	21
3.7 Création d'un message de gestion de certificat	22
3.9 Demandes d'enregistrement	22
3.10 Identification d'un message S/MIME	22
4. Traitement du certificat	23
4.1 Génération de paire de clés	23
4.2 Génération de signature	23
4.3 Vérification de signature	23
4.4 Chiffrement	24
4.5 Déchiffrement	24
5. Considérations relatives à l'IANA	24
5.1 Type de support pour application/pkcs7-mime	24
5.2 Type de support pour application/pkcs7-signature	25
5.3 authEnveloped-data smime-type	25
5.4 Mise à jour de référence	25
6. Considérations sur la sécurité	25
7. Références	27
7.1 Conventions de référence	27
7.2 Références normatives	28
7.3 Références pour information	29
Appendice A. Module ASN.1	31
Appendice B. Considérations sur l'historique de la messagerie	32
B.1 DigestAlgorithmIdentifier	33
B.2 Algorithmes de signature	33
B.3 ContentEncryptionAlgorithmIdentifier	34
B.4 KeyEncryptionAlgorithmIdentifier	34
Appendice C. Passage de la spécification de message S/MIME v2 au statut de Historique	34
Appendice C. Remerciements	34
Adresse des auteurs	35

 	1.	Introduction

Les extensions multi objets de messagerie Internet sécurisée (S/MIME, Secure/Multipurpose Internet Mail Extensions) donnent un moyen cohérent pour envoyer et recevoir des données MIME sécurisées. Sur la base de la norme MIME très répandue dans l'Internet, S/MIME fournit les services de sécurité cryptographiques suivants pour les applications de messagerie électronique : authentification, intégrité du message et non répudiation de l'origine (en utilisant des signatures numériques) et confidentialité des données (en utilisant le chiffrement). Comme complément de service, S/MIME fournit la compression de message.

S/MIME peut être utilisé par les agents d'utilisateur de messagerie (MUA, Mail User Agent) traditionnels pour ajouter des services de sécurité cryptographiques aux messages envoyés, et pour interpréter les services de sécurité cryptographiques dans les messages reçus. Cependant, S/MIME ne se restreint pas à la messagerie ; il peut être utilisé avec tout mécanisme de transport qui transporte des données MIME, comme HTTP ou SIP. À ce titre, S/MIME tire parti des caractéristiques fondées sur l'objet de MIME et permet que des messages sûrs soient échangés dans des systèmes de transport mixtes.

De plus, S/MIME peut être utilisé dans des agents de transfert de message automatisés utilisant des services de sécurité cryptographiques qui n'exigent aucune intervention humaine, comme de signer les documents générés par le logiciel et le chiffrement des messages FAX envoyés sur l'Internet.

Le présent document définit la version 4.0 de la spécification de message S/MIME. À ce titre, le présent document rend obsolète la version 3.2 de la spécification de message S/MIME [RFC5751].

La présente spécification contient un certain nombre de références à des documents qui ont été rendus obsolètes ou remplacés. Ceci est intentionnel, car les documents mis à jour ne contiennent souvent pas les mêmes informations ou exigences de protocole.

 	1.1	Vue d'ensemble de la spécification
Le présent document décrit un protocole pour ajouter des services de signature cryptographique et de chiffrement aux données MIME. La norme MIME [MIME] donne une structure générale pour le contenu des messages Internet et permet des extensions pour de nouvelles applications fondées sur le type de contenu.

La présente spécification définit comment créer une partie de corps MIME qui a été cryptographiquement améliorée conformément à la syntaxe de message cryptographique (CMS, Cryptographic Message Syntax) [RFC5652], qui est dérivée de PKCS n° 7 [RFC2315]. La présente spécification définit aussi le type de support application/pkcs7-mime, qui peut être utilisé pour transporter des parties de corps.

Le présent document discute aussi comment utiliser le type de support multipart/signed défini dans la [RFC1847] pour transporter les messages S/MIME signés. "multipart/signed" est utilisé en conjonction avec le type de support application/pkcs7-signature, qui est utilisé pour transporter une signature S/MIME détachée.

Afin de créer des messages S/MIME, un agent S/MIME DOIT suivre les spécifications du présent document, ainsi que les spécifications mentionnées dans les [RFC3370], [RFC3560], [RFC4056], [RFC5652], et [RFC5754].

Dans la présente spécification, il y a des exigences et recommandations sur comment les agents receveurs traitent les messages entrants. Il y a des exigences et recommandations séparées sur comment les agents envoyeurs créent les messages sortants. En général, la meilleure stratégie est de suivre le principe de robustesse (être libéral dans ce qu'on reçoit et prudent dans ce qu'on envoie). La plupart des exigences portent sur le traitement des messages entrants, tandis que les recommandations sont surtout sur la création des messages sortants.

La séparation des exigences entre agents receveurs et agents envoyeurs découle aussi de la probabilité que des systèmes S/MIME impliquent un logiciel autre que le client traditionnel de messagerie Internet. S/MIME peut être utilisé avec tout système qui transporte des données MIME. Un processus automatisé qui envoie un message chiffré pourrait, par exemple, n'être pas capable de recevoir du tout un message chiffré. Donc, les exigences et recommandations pour les deux types d'agents sont mentionnées séparément quand c'est approprié.

 	1.2	Définitions
Pour les besoins de la présente spécification, les définitions suivantes s'appliquent .

ASN.1 (Abstract Syntax Notation One) : notation de syntaxe abstraite n° 1, comme définie dans les Recommandations UIT-T X.680, X.681, X.682, et X.683 [ASN.1].

Agent envoyeur : logiciel qui crée des types de contenu de CMS S/MIME, des parties de corps MIME qui contiennent des types de contenu de CMS, ou les deux.

Agent receveur : logiciel qui interprète et traite les objets de CMS S/MIME, les parties de corps MIME qui contiennent des types de contenu de CMS, ou les deux.

Agent S/MIME : logiciel d'utilisateur qui est un agent receveur, un agent envoyeur, ou les deux.

BER (Basic Encoding Rules) : règles de codage de base pour l'ASN.1, comme définies dans la Recommandation UIT-T X.690 [X.690].

Certificat : type qui lie le nom d'une entité à une clé publique avec une signature numérique.

Codage de transfert : transformation réversible faite sur des données afin que les données en 8 bits ou binaires puissent être envoyées via un canal qui transmet seulement des données en 7 bits.

Confidentialité des données : propriété que les données ne sont pas divulguées aux entités du système si elles n'ont pas été autorisée à les connaître [RFC4949].

DER (Distinguished Encoding Rules) : règles de codage distinctives pour l'ASN.1, comme définies dans la Recommandation UIT-T X.690 [X.690].

Données en 7 bits : données de texte avec des lignes de moins de 998 caractères, où aucun des caractères n'a le 8ième bit établi, et où il n'y a pas de caractère NUL. Les <CR> et <LF> surviennent seulement au titre d'un délimiteur <CR><LF> de fin de ligne.

Données en 8 bits : données de texte avec des lignes de moins de 998 caractères, où aucun des caractères n'est un caractère NUL. <CR> et <LF> surviennent seulement au titre d'un délimiteur <CR><LF> de fin de ligne.

Données binaires : données arbitraires.

Service d'intégrité des données : service de sécurité qui protège contre les changements non autorisés aux données en s'assurant sue les changements aux données sont détectables [RFC4949].

 	1.3	Conventions utilisées dans le document
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119], [RFC8174] quand, et seulement quand ils apparaissent tout en majuscules, comme montré ci-dessus.

On définit les nicveaux d'exigence supplémentaires :

DEVRAIT+ : ce terme signifie la même chose que DEVRAIT. Cependant, les auteurs s'attendent à ce qu'une exigence marquée DEVRAIT+ sera promue à l'avenir à être un DOIT.

DEVRAIT- : ce terme signifie la même chose que DEVRAIT. Cependant, les auteurs s'attendent à ce qu'une exigence marquée DEVRAIT- sera dégradée à un PEUT dans une future version de ce document.

DOIT- : ce terme signifie la même chose que DOIT. Cependant, les auteurs s'attendent à ce que cette exigence ne soit plus un DOIT dans un futur document. Bien que son statut doive être déterminé plus tard, il est raisonnable de s'attendre à ce que si une future révision d'un document altère le statut d'une exigence DOIT-, elle va rester au moins un DEVRAIT ou un DEVRAIT-.

Le terme "RSA" dans le présent document se réfère presque toujours aux algorithmes de signature ou de chiffrement RSA PKCS n°1 v1.5 [RFC2313] même quand ils ne sont pas qualifiés comme tels. Il ya quelques endroits où il se réfère à l'opération générale de chiffrement RSA ; cela peut être déterminé d'après le contexte d'utilisation.

 	1.4	Compatibilité avec la pratique antérieure de S/MIME
Les agents S/MIME version 4.0 devraient tenter d'avoir la plus grande interopérabilité possible avec les agents de versions antérieures de S/MIME.
- S/MIME version 2 est décrit dans les RFC 2311 à RFC 2315 inclus [SMIMEv2].
- S/MIME version 3 est décrit dans les RFC 2630 à RFC 2634 inclus et la RFC 5035 [SMIMEv3].
- S/MIME version 3.1 est décrit dans les RFC 2634, RFC 3850, RFC 3851, RFC 3852, et RFC 5035 [SMIMEv3.1].
- S/MIME version 3.2 est décrit dans les RFC 2634, RFC 5035, RFC 5652, RFC 5750, et RFC 5751 [SMIMEv3.2].
- La RFC 2311 a aussi des informations historiques sur le développement de S/MIME.

 	1.5	Changements de S/MIME v3 à S/MIME v3.1
Ce paragraphe décrit les changements entre S/MIME v3 et S/MIME v3.1. Noter que les niveaux d'exigences indiqués par les mots-clés en majuscules ("DOIT", "DEVRAIT", etc.) peuvent avoir changé dans des versions ultérieures de S/MIME.

-	L'algorithme de clé publique RSA a été changé en un DOIT mettre en œuvre. L'algorithme d'enveloppe de clé, et l'algorithme Diffie-Hellman (DH) ont été changés en DEVRAIT mettre en œuvre.

-	L'algorithme AES de chiffrement symétrique a été inclus comme DEVRAIT mettre en œuvre.

-	L'algorithme de clé publique RSA a été changé en un DOIT mettre en œuvre d'algorithme de signature.

-	Le langage ambigu sur l'utilisation de messages SignedData "vides" pour transmettre des certificats a été précisé pour refléter que la transmission de listes de révocation de certificats est aussi permise.

-	L'utilisation de codage binaire pour certaines entités MIME est maintenant explicitement discuté.

-	La protection d'en-tête par l'utilisation du type de support message/rfc822 a été ajoutée.

-	L'utilisation du type de CMS CompressedData est permis, avec le type de support exigé et l'ajout d'extension de fichier.

 	1.6	Changements de S/MIME v3.1 à S/MIME v3.2
Ce paragraphe décrit les changements entre S/MIME v3.1 et S/MIME v3.2. Noter que les niveaux d'exigences indiqués par les mots-clés en majuscules ("DOIT", "DEVRAIT", etc.) peuvent avoir changé dans des versions ultérieures de S/MIME. Noter que les numéros de paragraphe mentionnées ici (par exemple, 3.4.3.2) proviennent de la [RFC5751].

-	Des changements rédactionnels, par exemple, remplacement de "type MIME" par "type de support", content-type par Content-Type.

-	Déplacement de "Conventions utilisées dans ce document" au paragraphe 1.3. Ajout des définitions pour DEVRAIT+, DEVRAIT-, et DOIT-.

-	Au paragraphe 1.1 et à l'Appendice A : ajout de références aux RFC pour les algorithmes de CMS RSASSA-PSS, RSAES-OAEP, et SHA2. Ajout de la précision de CMS multi signataires à la référence de CMS.

-	Au paragraphe 1.2 : Mise à jour des références à l'ASN.1 de X.680 et du BER et DER de X.690.

-	Au paragraphe 1.4 : Ajout des références aux RFC de S/MIME v3.1.

-	Au paragraphe 2.1 (algorithme de résumé) : SHA-256 ajouté comme DOIT, SHA-1 et MD5 rendus DEVRAIT-.

-	Au paragraphe 2.2 (algorithmes de signature) : RSA avec SHA-256 ajouté comme DOIT, et DSA avec SHA-256 ajouté comme DEVRAIT+, RSA avec SHA-1, DSA avec SHA-1, et RSA avec MD5 changés en DEVRAIT-, et RSASSA-PSS avec SHA-256 ajouté comme DEVRAIT+. Ajout aussi d'une note sur quels clients S/MIME v3.1 prend en charge.

-	Au paragraphe 2.3 (chiffrement de clé) : DH changé en DEVRAIT-, et RSAES-OAEP ajouté comme DEVRAIT+. Exigences développées pour l'algorithme d'enveloppe de clé.

-	Au paragraphe 2.5.1 : Ajout de l'exigence que les agents receveurs DOIVENT prendre en charge GeneralizedTime et UTCTime.

-	Au paragraphe 2.5.2 : Remplacé la référence "sha1WithRSAEncryption" par "sha256WithRSAEncryption", "DES-3EDE-CBC" par "AES-128 CBC", et suppression de l'exemple RC5.

-	Au paragraphe 2.5.2.1 : suppression du paragraphe entier (sur RC2 qui est déconseillé).

-	Aux paragraphes 2.7, 2.7.1, Appendice A : suppression des références à RC2/40.

-	Au paragraphe 2.7 (chiffrement de contenu) : AES-128 CBC ajouté comme DOIT, AES-192 et AES-256 CBC comme DEVRAIT+, tripleDES est maintenant un DEVRAIT-.

-	Au paragraphe 2.7.1: mise à jour des pointeurs de 2.7.2.1 à 2.7.2.4 en 2.7.1.1 à 2.7.1.2.

-	Au paragraphe 3.1.1 : suppression du texte sur les jeux de caractères MIME.

-	Aux paragraphes 3.2.2 et 3.6 : remplacement de "chiffré" par "enveloppé". Mise à jour de l'exemple d'OID pour utiliser l'OID CBC AES-128

-	Au paragraphe 3.4.3.2 : Remplacement du paramètre "micalg" pour SHA-1 par "sha-1".

-	À la Section 4 : mise à jour de la référence à CERT v3.2.

-	Au paragraphe 4.1 : mise à jour de la discussion de taille de clé RSA et DSA. Déplacement des quatre dernières phrases dans les considérations sur la sécurité. Mise à jour de la référence aux exigences d'aléa pour la sécurité.

-	À la Section 5 : Ajout des gabarits d'enregistrement IANA pour mettre à jour le registre de type de support pour pointer sur le présent document plutôt que la RFC 2311.

-	À la Section 6 : mise à jour des considérations sur la sécurité.

-	À la Section 7 : déplacé les références de l'Appendice B à cette section. Mise à jour des références. Ajout des références pour information à SMIMEv2, SMIMEv3, et SMIMEv3.1.

-	À l'Appendice B : Ajout de l'Appendice B pour passer S/MIME v2 au statut de Historique.

 	1.7	Changements pour S/MIME v4.0
Ce paragraphe décrit les changements faits entre S/MIME v3.2 et S/MIME v4.0.

-	Ajout de l'utilisation de AuthEnvelopedData, y compris la définition et l'enregistrement d'une valeur smime-type (paragraphes 2.4.4 et 3.4).

-	Mise à jour des algorithmes de chiffrement de contenu (paragraphes 2.7 et 2.7.1.2) : ajout du mode AES-256 Galois/mode compteur (GCM), ajout de ChaCha20-Poly1305, suppression de la mention de AES-192 en mode de chaînage de bloc de chiffrement (CBC, Cipher Block Chaining) et marquage de tripleDES comme historique.

-	Mise à jour de l'ensemble d'algorithmes de signature (paragraphe 2.2) : ajout de l'algorithme de signature numérique à courbe de Edwards (EdDSA, Edwards-curve Digital Signature Algorithm), ajout de l'algorithme de signature numérique à courbe elliptique (ECDSA, Elliptic Curve Digital Signature Algorithm), et marqué DSA comme historique.

-	Mise à jour de l'ensemble d'algorithmes de résumé (paragraphe 2.1) : ajout de SHA-512, et marqué SHA-1 comme historique.

-	Mise à jour de la taille des clés à utiliser pour le chiffrement RSA et la signature RSA (Section 4).

-	Création d'un Appendice B, qui discute des considérations traitant de l'historique des messages électroniques.

 	2.	Options de CMS

La CMS permet de prendre en charge une grande variété d'options de prise en charge de contenu, attributs, et algorithmes. Cette section met en avant un certain nombre d'exigences et recommandations de prise en charge afin de réaliser un niveau de base d'interopérabilité parmi toutes les mises en œuvre de S/MIME. Les [RFC3370] et [RFC5754] donnent des détails supplémentaires concernant l'utilisation des algorithmes de chiffrement. [ESS] donne des détails supplémentaires sur l'utilisation des attributs.

 	2.1	DigestAlgorithmIdentifier
Les algorithmes sont utilisés ici pour résumer le corps du message et ne sont pas les mêmes que les algorithmes de résumé utilisés au titre des algorithmes de signature. Leur résultat est placé dans l'attribut message-digest des attributs signés. Il est RECOMMANDÉ que l'algorithme utilisé pour réumer le corps du message soit de force similaire ou supérieure à celle de l'algorithme de signature.

Les agents envoyeurs et receveurs : 
-	DOIVENT prendre en charge SHA-256.
-	DOIVENT prendre en charge SHA-512.

La [RFC5754] donne les détails pour utiliser ces algorithmes avec S/MIME.

 	2.2	SignatureAlgorithmIdentifier
Des ensembles d'exigences différents pèsent sur les agents receveurs et envoyeurs. Une interopérabilité maximale est réalisé en ayant ces ensembles d'exigences différents, car cela permet une protection spécialisée du matériel de clé privé mais une validation maximale de signature.

Les agents receveurs :
- DOIVENT prendre en charge ECDSA avec courbe P-256 et SHA-256.
- DOIVENT prendre en charge EdDSA avec courbe 25519 utilisant le mode PureEdDSA [RFC8419].
- DOIVENT prendre en charge RSA PKCS n° 1 v1.5 avec SHA-256.
- DEVRAIENT prendre en charge le schéma de signature RSA probabiliste (RSASSA-PSS) avec SHA-256.

Les agents envoyeurs:
- DOIVENT prendre en charge au moins un des algorithmes suivants : ECDSA avec courbe P-256 et SHA-256, EdDSA avec courbe 25519 utilisant le mode PureEdDSA.
- DOIVENT- prendre en charge RSA PKCS #1 v1.5 avec SHA-256.
- DEVRAIENT prendre en charge RSASSA-PSS avec SHA-256.

Voir au paragraphe 4.1 les informations sur la taille de clé et les références d'algorithme.

 	2.3	KeyEncryptionAlgorithmIdentifier
Agents receveurs et envoyeurs :
- DOIVENT prendre en charge le mode statique éphémère de courbe elliptique Diffie-Hellman (ECDH, Elliptic Curve Diffie-Hellman) pour P-256, comme spécifié dans la [RFC5753].
- DOIVENT prendre en charge le mode statique éphémère pour X25519 en utilisant HKDF-256 (HKDF, HMAC-based Key Derivation Function) pour la KDF, comme spécifié dans la [RFC8418].
- DOIVENT prendre en charge le chiffrement RSA, comme spécifié dans la [RFC3370].
- DEVRAIENT+ prendre en charge le schéma de chiffrement RSA - bourrage optimal de chiffrement asymétrique (RSAES-OAEP, Optimal Asymmetric Encryption Padding), comme spécifié dans la [RFC3560].

Quand DH éphémère statique est utilisé, un algorithme d'enveloppe de clé est aussi spécifié dans le KeyEncryptionAlgorithmIdentifier (identifiant d'algorithme de chiffrement de clé) [RFC5652]. Les fonctions sous-jacentes de chiffrement pour l'algorithme d'enveloppe de clé et de chiffrement de contenu ([RFC3370] et [RFC3565]) et les tailles de clé pour les deux algorithmes DOIVENT être les mêmes (par exemple, algorithme d'enveloppe de clé AES-128 avec algorithme de chiffrement de contenu AES-128). Comme les deux modes AES-128 et AES-256 sont des algorithmes de chiffrement de contenu de mise en œuvre obligatoire (paragraphe 2.7) les deux algorithmes d'enveloppe de clé AES-128 et AES-256 DOIVENT aussi être pris en charge quand le mode ECDH éphémère statique est utilisé. Les receveurs PEUVENT appliquer cela mais DOIVENT utiliser le plus faible des deux au titre de tout calcul de force cryptographique qu'ils pourraient faire.

L'Appendice B donne des informations sur la prise en charge d'algorithme dans les anciennes versions de S/MIME.

 	2.4	Syntaxe générale
Il y a plusieurs types de contenu de CMS. Parmi eux, seuls les types de contenu Data, SignedData, EnvelopedData, AuthEnvelopedData, et CompressedData sont couramment utilisés pour S/MIME.

 	2.4.1	Type de contenu Data
Les agents envoyeurs DOIVENT utiliser l'identifiant de type de contenu id-data pour identifier le contenu "interne" de message MIME. Par exemple, quand on applique une signature numérique aux données MIME, le eContentType CMS SignedData encapContentInfo DOIT inclure l'identifiant d'objet (OID, object identifier) id-data et le type de support DOIT être mémorisé dans la CHAINE D'OCTETS SignedData encapContentInfo eContent (sauf si l'agent envoyeur utilise multipart/signed, et dans ce cas le eContent est absent, selon le paragraphe 3.5.3 du présent document). Pour un autre exemple, quand on applique le chiffrement aux données MIME, le type de contenu CMS EnvelopedData encryptedContentInfo DOIT inclure l'identifiant d'objet id-data et le contenu MIME chiffré DOIT être mémorisé dans la CHAINE D'OCTETS EnvelopedData encryptedContentInfo encryptedContent.

 	2.4.2.	Type de contenu SignedData
Les agents envoyeurs DOIVENT utiliser le type de contenu SignedData à appliquer à une signature numérique dans un message ou, dans un cas marginal où il n'y a pas d'informations de signature, pour porter les certificats. Appliquer une signature à un message assure l'authentification, l'intégrité du message, et la non répudiation de l'origine.

 	2.4.3	Type de contenu EnvelopedData
Ce type de contenu est utilisé pour appliquer la confidentialité des données à un message. Afin de distribuer la clé symétrique, un envoyeur a besoin d'avoir accès à une clé publique pour chaque receveur de message prévu qui va utiliser ce service.

 	2.4.4	Type de contenu AuthEnvelopedData
Ce type de contenu est utilisé pour appliquer la confidentialité des données et l'intégrité de message à un message. Ce type de contenu n'assure pas l'authentification ni la non répudiation. Afin de distribuer la clé symétrique, un envoyeur a besoin d'avoir accès à une clé publique pour chaque receveur de message prévu qui va utiliser ce service.

 	2.4.5	Type de contenu CompressedData
Ce type de contenu est utilisé pour appliquer la compression des données à un message. Ce type de contenu n'assure pas l'authentification, l'intégrité du message, la non répudiation, ni la confidentialité des données, et est seulement utilisé pour réduire la taille du message.

Voir au paragraphe 3.7 des indications sur l'utilisation de ce type en conjonction avec d'autres types de CMS.

 	2.5	Attributs et type SignerInfo
Le type SignerInfo permet l'inclusion d'attributs non signés et signés avec une signature.

Ces attributs peuvent être exigés pour le traitement des messages (par exemple, résumé de message) pour des informations fournies par le signataire (par exemple, les capacités SMIME) qui pourraient être traitées, ou des attributs qui ne sont pas pertinents pour la situation  en cours (par exemple, mlExpansionHistory [RFC2634] pour le visionnage de messages).

Les agents receveurs DOIVENT être capables de traiter zéro ou une instance de chacun des attributs signés mentionnés ici. Les agents envoyeurs DEVRAIENT générer une instance de chacun des attributs signés suivants dans chaque message S/MIME :
- Heure de signature (paragraphe 2.5.1 de ce document)
- Capacités SMIME (paragraphe 2.5.2 de ce document)
- Préférence de clé de chiffrement (paragraphe 2.5.3 de ce document)
- Résumé de message (paragraphe 11.2 de la [RFC5652])
- Type de contenu (paragraphe 11.1 de la [RFC5652])

De plus, les agents receveurs DEVRAIENT être capables de traiter zéro ou une instance des attributs signés signingCertificate et signingCertificatev2, comme défini respectivement à la Section 5 de la RFC 2634 [ESS] et à la Section 3 de la RFC  5035 [ESS].

Les agents envoyeurs DEVRAIENT générer une instance de l'attribut signé signingCertificate ou signingCertificatev2 dans chaque structure SignerInfo.

Des attributs et valeurs supplémentaires pour ces attributs pourraient être définis à l'avenir. Les agents receveurs DEVRAIENT+ traiter avec douceur les attributs ou valeurs qu'ils ne reconnaissent pas.

Les agents envoyeurs interactifs qui incluent des attributs signés qui ne sont pas mentionnés ici DEVRAIENT afficher ces attributs à l'utilisateur, afin que l'utilisateur sache toutes les données signées.

 	2.5.1	Attribut signing-time
L'attribut signing-time est utilisé pour porter l'heure de signature d'un message. L'heure de signature va très probablement être créée par le signataire d'un message et donc n'est pas plus fiable que le signataire.

Les agents envoyeurs DOIVENT coder l'heure de signature avec l'année 2049 comme UTCTime ; les heures de signature en 2050 ou après DOIVENT être codées comme GeneralizedTime. Quand le CHOIX UTCTime est utilisé, les agents S/MIME DOIVENT interpréter le champ année (AA) comme suit :

Si AA est supérieur ou égal à 50, l'année est interprétée comme 19AA ; si AA est inférieur à 50, l'année est interprétée comme 20AA.

Les agents receveurs DOIVENT être capables de traiter les attributs signing-time qui sont codés en UTCTime ou GeneralizedTime.

 	2.5.2	Attribut SMIMECapabilities
L'attribut SMIMECapabilities inclut des algorithmes de signature (comme "sha256WithRSAEncryption") des algorithmes symétriques (comme "AES-128 CBC") des algorithmes symétriques authentifiés (comme "AES-128 GCM"), et des algorithmes de chiffrement de clé (comme "rsaEncryption"). La présence d'un attribut SMIMECapability contenant un algorithme implique que l'envoyeur peut traiter l'algorithme ainsi que comprendre les structures ASN.1 associées à cet algorithme. Il y a aussi plusieurs identifiants qui indiquent la prise en charge d'autres caractéristiques facultatives comme le codage binaire et la compression. L'attribut SMIMECapabilities a été conçu comme souple et extensible afin que, à l'avenir, un moyen d'identifier d'autres capacités et préférences comme des certificats puisse être ajouté d'une façon qui ne cause pas de défaillance des clients actuels.

Si il est présent, l'attribut SMIMECapabilities DOIT être un SignedAttribute. La CMS définit les SignedAttribute comme un ENSEMBLE d'attributs. Le SignedAttribute dans un signerInfo DOIT inclure une seule instance de l'attribut SMIMECapabilities. La CMS définit la syntaxe ASN.1 pour Attribute comme incluant des attrValues ENSEMBLE DE AttributeValue. Un attribut SMIMECapabilities DOIT seulement inclure une seule instance de AttributeValue. Si une signature est détectée comme violant ces exigences, la signature DEVRAIT être traitée comme défaillante.

La sémantique de l'attribut SMIMECapabilities spécifie une liste partielle que le client qui annonce les SMIMECapabilities peut prendre en charge. Un client n'a pas à faire la liste de toutes les capacités qu'il prend en charge, et n'a pas besoin de faire la liste de toutes ses capacités afin que la liste de capacités ne soit pas trop longue. Dans un attribut SMIMECapabilities, les identifiants d'objet sont mentionnés dans l'ordre de leur préférence, mais DEVRAIENT être séparés logiquement le long des lignes de leur catégorie (algorithmes de signature, algorithmes symétriques, algorithmes de chiffrement de clé, etc.).

La structure de l'attribut SMIMECapabilities est destinée à faciliter de simples recherches dans les tableaux et les comparaisons binaires afin de déterminer des correspondances. Par exemple, le codage pour la SMIMECapability pour  sha256WithRSAEncryption inclut plutôt qu'il omet le paramètre NULL. À cause de l'exigence de codage identique, les individus qui documentent les algorithmes à utiliser dans l'attribut SMIMECapabilities DEVRAIENT explicitement documenter la séquence d'octets correcte pour les cas courants.

Pour toute capacité, les paramètres associés pour l'OID DOIVENT spécifier tous les paramètres nécessaires pour différencier deux instances du même algorithme.

Le même OID qui est utilisé pour identifier un algorithme DEVRAIT aussi être utilisé dans le SMIMECapability pour cet algorithme. Il y a des cas où un seul OID peut correspondre à plusieurs algorithmes. Dans ces cas, un seul algorithme DOIT être alloué au SMIMECapability en utilisant cet OID. Des OID supplémentaires provenant le l'arborescence d'OID smimeCapabilities sont alors alloués pour les autres usages des algorithmes. Par exemple, dans une spécification antérieure, rsaEncryption était ambigu parce que il pouvait se référer à un algorithme de signature ou à un algorithme de chiffrement de clé. Au cas où un OID est ambigu, cela doit être arbitré par celui qui tient la liste enregistrée de SMIMECapabilities sur quel type d'algorithme va utiliser l'OID, et un nouvel OID DOIT être alloué sous l'OID smimeCapabilities pour respecter les autres utilisations de l'OID.

La liste enregistrée de SMIMECapabilities spécifie les paramètres pour les OID qui en ont besoin, en particulier les longueurs de clé dans le cas de chiffrements symétriques de longueur variable. Dans le cas où il n'y a pas de paramètres différentiateurs pour un OID particulier, les paramètres DOIVENT être omis, et NE DOIVENT PAS être codés comme NUL. Des valeurs supplémentaires pour l'attribut SMIMECapabilities pourraient être définies à l'avenir. Les agents receveurs DOIVENT traiter de manière douce un objet SMIMECapabilities dont ils ne reconnaîssent pas les valeurs.

Le paragraphe 2.7.1 explique une stratégie pour mettre les capacités en antémémoire.

 	2.5.3	Attribut Préférence de clé de chiffrement
L'attribut de préférence de clé de chiffrement permet au signataire de décrire sans ambiguïté quel certificat du signataire a la clé de chiffrement préférée du signataire. Cet attribut est destiné à améliorer le comportement d'interopération avec les clients qui utilisent des clés séparés pour le chiffrement et la signature. Cet attribut est utilisé pour signifier à tous ceux qui voient l'attribut lequel des certificats mentionnées est approprié pour chiffrer une clé de session pour les futurs messages chiffrés.

Si il est présent, l'attribut SMIMEEncryptionKeyPreference DOIT être un SignedAttribute. La CMS définit les SignedAttributes comme un ENSEMBLE DE Attribute. Les SignedAttributes dans un signerInfo DOIVENT inclure une seule instance de l'attribut SMIMEEncryptionKeyPreference. La CMS définit la syntaxe ASN.1 pour Attribute pour inclure  attrValues ENSEMBLE DE AttributeValue. Un attribut SMIMEEncryptionKeyPreference DOIT seulement inclure une instance de AttributeValue. Si une signature est détectée comme violant ces exigences, la signature DEVRAIT être traitée comme défaillante.

L'agent envoyeur DEVRAIT inclure le certificat référencé dans l'ensemble de certificats inclus dans le message signé si cet attribut est utilisé. Le certificat PEUT être omis si il a été précédemment rendu disponible à l'agent receveur. Les agents envoyeurs DEVRAIENT utiliser cet attribut si le certificat de chiffrement couramment utilisé ou préféré n'est pas le même que le certificat utilisé pour signer le message.

Les agents receveurs DEVRAIENT mémoriser les données de préférence si la signature sur le message est valide et si l'heure de signature est supérieure à la valeur actuellement mémorisée. (Comme avec SMIMECapabilities, le biais d'horloge DEVRAIT être vérifié et les données ne devraient pas être utilisées si le biais d'horloge est trop grand.) Les agents receveurs DEVRAIENT respecter l'attribut de préférence de clé de chiffrement de l'envoyeur si possible. Ceci, représente cependant seulement une préférence et l'agent receveur peut utiliser tout certificat valide en réponse à l'envoyeur.

Le paragraphe 2.7.1 explique une stratégie de mise en antémémoire des données de préférence.

 	2.5.3.1	Choix d'un certificat de gestion de clé de receveur
Afin de déterminer le certificat de gestion de clé à utiliser quand on envoie un futur message de CMS EnvelopedData pour un receveur particulier, les étapes suivantes DEVRAIENT être suivies :

- Si un attribut SMIMEEncryptionKeyPreference est trouvé dans un objet SignedData reçu du receveur désiré, cela identifie le certificat X.509 qui DEVRAIT être utilisé comme certificat de gestion de clé X.509 pour le receveur.

- Si un attribut SMIMEEncryptionKeyPreference n'est pas trouvé dans un objet SignedData reçu du receveur désiré, l'ensemble de certificats X.509 DEVRAIT être examiné pour chercher un certificat X.509 avec le même nom de sujet que le signataire d'un certificat X.509 qui puisse être utilisé pour la gestion de clé.

- Ou utiliser une autre méthode pour déterminer la clé de gestion de clé de l'utilisateur. Si un certificat X.509 de gestion de clés n'est pas trouvé, le chiffrement ne peut alors pas être fait avec le signataire du message. Si plusieurs certificats de gestion de clé X.509 sont trouvés, l'agent S/MIME peut faire un choix arbitraire entre eux.

 	2.6	Type SignerInfo SignerIdentifier
Les mises en œuvre de S/MIME v4.0 DOIVENT prendre en charge issuerAndSerialNumber et subjectKeyIdentifier. Les messages qui utilisent le choix subjectKeyIdentifier ne peuvent pas être lus par les clients S/MIME v2.

Il est important de comprendre que certains certificats utilisent une valeur pour subjectKeyIdentifier qui ne convient pas pour identifier un certificat de façon univoque. Les mises en œuvre DOIVENT être prêtes à avoir plusieurs certificats pour des entités potentiellement différentes ayant la même valeur pour subjectKeyIdentifier, et DOIVENT être prêtes à essayer chaque certificat correspondant durant la vérification de signature avant d'indiquer une condition d'erreur.

 	2.7	ContentEncryptionAlgorithmIdentifier
Les agents envoyeurs et receveurs :
- DOIVENT prendre en charge le chiffrement et le déchiffrement avec AES-128 GCM et AES-256 GCM [RFC5084].
- DOIVENT- prendre en charge le chiffrement et le déchiffrement avec AES-128 CBC [RFC3565].
- DEVRAIENT+ prendre en charge le chiffrement et le déchiffrement avec ChaCha20-Poly1305 [RFC7905].

 	2.7.1	Décision de la méthode de chiffrement à utiliser
Quand un agent envoyeur crée un message chiffré, il doit décider quel type de chiffrement utiliser. Le processus de décision  implique d'utiliser les informations obtenues des listes de capacités incluses dans les messages reçus du receveur, ainsi que des informations hors bande comme des accords privés, des préférences d'utilisateur, des restrictions légales, et ainsi de suite.

Le paragraphe 2.5.2 définit une méthode par laquelle un agent envoyeur peut facultativement annoncer, entre autre choses, ses capacités de déchiffrement dans l'ordre de préférence. La méthode suivante de traitement et de mémorisation des attributs de capacités de chiffrement dans les messages signés entrants DEVRAIT être utilisée.

-	Si l'agent receveur n'a pas encore créé une liste de capacités pour la clé publique de l'envoyeur, alors, après avoir vérifié la signature sur le message entrant et vérifié l'horodatage, l'agent receveur DEVRAIT créer une nouvelle liste contenant au moins l'heure de signature et les capacités symétriques.

-	Si une telle liste existe déjà, l'agent receveur DEVRAIT vérifier que l'heure de signature dans le message entrant est supérieure à l'heure de signature mémorisée dans la liste et que la signature est valide. Si elle l'est, l'agent receveur DEVRAIT mettre à jour l'heure de signature et les capacités de la liste. Les valeurs de l'heure de signature qui sont loin dans le futur (c'est-à-dire, une discordance supérieure à un biais d'horloge raisonnable) ou une liste de capacités dans des messages dont la signature ne pourrait pas être vérifiée, NE DOIVENT PAS être acceptées.

La liste de capacités DEVRAIT être mémorisée pour une utilisation future de création de messages.

Avant d'envoyer un message, l'agent envoyeur DOIT décider si il veut utiliser un chiffrement faible pour les données particulières dans le message. Si l'agent envoyeur décide qu'un chiffrement faible n'est pas acceptable pour ces données, alors l'agent envoyeur NE DOIT PAS utiliser un algorithme faible. La décision d'utiliser ou non un chiffrement faible outrepasse toute autre décision dans ce paragraphe sur quel algorithme de chiffrement utiliser.

Les paragraphes 2.7.1.1 à 2.7.1.2 décrivent les décisions qu'un agent envoyeur DEVRAIT utiliser pour décider quel type de chiffrement va être appliqué au message. Ces règles sont ordonnées, de sorte que l'agent envoyeur DEVRAIT prendre sa décision dans l'ordre donné.

 	2.7.1.1	Règle 1 : capacités connues
Si l'agent envoyeur a reçu un ensemble de capacités du receveur pour le message que l'agent est sur le point de chiffrer, alors l'agent envoyeur DEVRAIT utiliser ces informations en choisissant la première capacité dans la liste (c'est-à-dire, la capacité préférée par le receveur prévu) que l'agent envoyeur sait comment chiffrer. L'agent envoyeur DEVRAIT utiliser une des capacités de la liste si l'agent s'attend raisonnablement à ce que le receveur soit capable de déchiffrer le message.

 	2.7.1.2	Règle 2 : capacités inconnues, version de S/MIME inconnue
Si les deux conditions suivantes sont satisfaites, l'agent envoyeur DEVRAIT utiliser AES-256 GCM, car AES-256 GCM est un algorithme plus fort et est exigé par S/MIME v4.0 :
-	l'agent envoyeur n'a pas connaissance des capacités de chiffrement du receveur ;
-	l'agent envoyeur n'a pas connaissance de la version de S/MIME utilisée ou prise en charge par le receveur.

Si l'agent envoyeur choisit de ne pas utiliser AES-128 dans cette étape, étant donnée la présomption qu'un client qui met en œuvre AES-GCM aurait AES-256 et AES-128, il DEVRAIT utiliser AES-128 CBC.

 	2.7.2	Choix d'un chiffrement faible
Les algorithmes comme RC2 sont considérés comme des algorithmes de chiffrement faibles. Les algorithmes comme TripleDES ne sont plus au goût du jour et sont considérés comme plus faibles que AES. Un agent envoyeur qui est contrôlé par un humain DEVRAIT permettre à un envoyeur humain de déterminer les risques de l'envoi de données en utilisant un algorithme de chiffrement faible avant d'envoyer les données, et éventuellement de permettre à l'humain d'utiliser une méthode de chiffrement plus forte comme triple AES GCM ou AES CBC même si il est possible que le receveur ne soit pas capable de traiter cet algorithme.

 	2.7.3	Receveurs multiples
Si un agent envoyeur compose un message chiffré à un groupe de receveurs où les capacités de chiffrement de certains des receveurs ne se recouvrent pas, l'agent envoyeur est forcé d'envoyer plus d'un message. Noter que si l'agent envoyeur choisit d'envoyer un message chiffré avec un algorithme fort, et ensuite envoie le même message chiffré avec un algorithme faible, quelqu'un qui surveille le canal de communication pourrait apprendre le contenu du message à chiffrement fort simplement en déchiffrant le message à chiffrement faible.

 	3.	Création des messages S/MIME

Cette Section décrit les formats de message S/MIME et comment ils sont créés. Les messages S/MIME sont une combinaison de corps MIME et de types de contenu de CMS. Plusieurs types de supports ainsi que plusieurs types de contenu de CMS sont utilisés. Les données à sécuriser sont toujours une entité MIME canonique. L'entité MIME et les autres données, comme des certificats et des identifiants d'algorithme, sont données aux facilités de traitement de CMS qui produisent un objet de CMS. Finalement, l'objet de CMS est enveloppé dans MIME. Les documents sur les services de sécurité améliorée pour S/MIME [ESS] fournissent une description de la façon de formater les messages S/MIME incorporés. ESS fournit une description de comment un message S/MIME à triple enveloppe est formaté en utilisant multipart/signed et application/pkcs7-mime pour les signatures.

S/MIME fournit un format pour les données seulement enveloppées, plusieurs formats pour les données seulement signées, et plusieurs formats pour les données signées et enveloppées. Plusieurs formats sont nécessaires pour s'accommoder de plusieurs environnements, en particulier pour les messages signés. Les critères pour choisir entre ces formats sont aussi décrits.

Le lecteur de cette section est supposé comprendre MIME comme décrit dans [MIME] et la [RFC1847].

 	3.1	Préparation de l'entité MIME à la signature, l'enveloppement, ou la compression
S/MIME est utilisé pour sécuriser les entités MIME. Un message MIME se compose d'un en-tête MIME et d'un corps MIME. Un corps peut consister en une seule entité MIME ou une arborescence d'entités MIME (dont la racine est un multipart). S/MIME peut être utilisé pour sécuriser une seule entité MIME ou une arborescence d'entités MIME. Ces entités peuvent être localisées ailleurs qu'à la racine. S/MIME peut être appliqué plusieurs fois à différentes entités dans un seul message. Une entité MIME qui est tout le message inclut seulement les en-têtes de message MIME et le corps MIME, et n'inclut pas d'en-tête rfc822. Noter que S/MIME peut aussi être utilisé pour sécuriser des entités MIME utilisées dans des applications autres que de messagerie Internet. Dans les cas où la protection par l'en-tête rfc822 est requise, l'utilisation du type de support message/rfc822 est expliquée plus loin dans cette section.

L'entité MIME qui est sécurisée et est décrite dans cette section peut être vue comme l'entité MIME de "l'intérieur". C'est-à-dire, elle est l'objet "le plus interne" dans ce qui est éventuellement un message MIME plus grand. Le traitement des entités MIME "externes" dans les types de contenu de CMS EnvelopedData, CompressedData, and AuthEnvelopedData est décrit dans les paragraphes 3.2 et 3.5. D'autres documents définissent des types de contenu de CMS supplémentaires ; ces documents devraint être consultés pour le traitement de ces types de contenu de CMS.

La procédure pour préparer une entité MIME est donnée dans [MIME]. La même procédure est utilisée ici avec des restrictions supplémentaires quant à la signature. La description des procédures provenant de [MIME] est répétée ici, mais il est suggéré que le lecteur se réfère à ces documents pour la procédure exacte. Cette section décrit aussi des exigences supplémentaires.

Une seule procédure est utilisée pour créer des entités MIME auxquelles sont appliquées toute combinaison de signature, d'enveloppe, et de compression. Des étapes supplémentaires sont recommandées pour se défendre contre les corruptions connues qui peuvent se produire durant le transport de messagerie et qui sont d'une importance particulière pour la signature en clair qui utilise le format "multipart/signed". Il est recommandé que ces étapes supplémentaires soient effectuées sur le message enveloppé, ou le message signé et enveloppé, afin que le message puisse être transmis dans tout environnement sans modification.

Ces étapes sont descriptives plutôt que prescriptives. La mise en œuvre est libre d'utiliser toute procédure tant que le résultat est le même.

Étape 1 : l'entité MIME est préparée conformément aux conventions locales.

Étape 2 : les parties d'extrémité de l'entité MIME sont converties en forme canonique.

Étape 3 : le codage de transfert approprié est appliqué aux extrémités de l'entité MIME.

Quand un message S/MIME est reçu, les services de sécurité sur le message sont traités, et le résultat est l'entité MIME. Cette entité MIME est normalement passée à un agent d'utilisateur à capacité MIME où il est encore décodé et présenté à l'utilisateur ou à l'application receveuse.

Afin de protéger les champs d'en-tête externes du message, sans relation au contenu (par exemple, les champs "Subject", "To", "From", et "Cc") le client envoyeur PEUT envelopper un message MIME complet dans une enveloppe message/rfc822 afin d'appliquer les services de sécurité S/MIME à ces champs d'en-tête. Il appartient au client receveur de décider comment présenter cet en-tête "interne" avec l'en-tête "externe" non protégé. Étant donnée la différence de sécurité entre les en-têtes, il est RECOMMANDÉ que le client receveur fournisse une distinction entre les champs d'en-tête selon l'endroit où ils sont situés.

Quand un message S/MIME est reçu, si l'entité MIME protégée de niveau supérieur a un type de contenu de message/rfc822, on peut supposer que l'intention était de fournir une protection de l'en-tête. Cette entité DEVRAIT être présentée comme le message de niveau supérieur, en prenant en compte les problèmes de fusion d'en-têtes discutés précédemment.

 	3.1.1	Canonisation
Chaque entité MIME DOIT être convertie en une forme canonique représentable de façon univoque et sans ambiguïté dans l'environnement où la signature est créée et dans l'environnement où la signature va être vérifiée. Les entités MIME DOIVENT être canonisées pour l'enveloppement et la compression ainsi que pour la signature.

Les détails exacts de la canonisation dépendent du type réel de prise en charge et du sous type d'une entité, et ne sont pas décrits ici. On DEVRAIT plutôt consulter la norme pour le type de support particulier. Par exemple, la canonisation du type text/plain est différente de celle de audio/basic. À part les types de texte, la plupart des types ont seulement une représentation sans considération de la plate-forme ou environnement de calcul qui peut examiner leur représentation canonique.

En général, la canonisation va être effectuée par la partie non sécurité de l'agent envoyeur plutôt que de la mise en œuvre S/MIME.

La canonisaation la plus courante et importante est pour le texte, qui est souvent représenté différemment dans des environnements différents. Les entités MIME de type "text" majeur DOIVENT avoir canonisés leurs terminaisons de ligne et leurs jeux de caractères. La terminaison de ligne DOIT être la paire de caractères <CR><LF>, et le jeu de caractères DEVRAIT être enregistré [CHARSETS]. Les détails de la canonisation sont spécifiés dans [MIME].

Noter que certains jeux de caractères comme ISO-2022 ont plusieurs représentations pour le même caractère. Quand on prépare un tel texte pour la signature, la représentation canonique spécifiée pour le jeu de caractères DOIT être utilisée.

 	3.1.2	Codage de transfert
Quand on génère une des entités MIME sécurisées ci-dessous, sauf pour la signature utilisant le format multipart/signed, aucun codage de transfert n'est exigé. Les mises en œuvre de S/MIME DOIVENT être capables de traiter les objets MIME binaires. Si aucun champ d'en-tête Content-Transfer-Encoding n'est présent, le codage de transfert est présumé être 7BIT.

En règle générale, les mises en œuvre de S/MIME DEVRAIENT utiliser le codage de transfert décrit au paragraphe 3.1.3 pour toutes les entités MIME qu'elles sécurisent. La raison pour sécuriser seulement les entités MIME 7-bit, même pour les données enveloppées qui ne sont pas exposées au transport, est que cela permet que l'entité MIME soit traitée dans tout environnement sans la changer. Par exemple, une passerelle de confiance pourrait supprimer l'enveloppe, mais pas la signature, d'un message, et ensuite transmettre le message signé au receveur final afin qu'il puisse vérifier directement les signatures. Si le transport interne au site n'est pas du pur 8-bit, comme sur un réseau de large zone avec une seule passerelle de messagerie, vérifier la signature ne sera possible que si l'entité MIME originale était de données seulement 7-bit.

Dans le cas où les mises en œuvre de S/MIME peuvent déterminer que tous les receveurs prévus sont capables de traiter les objets MIME binaires internes (à l'exclusion des plus externes) DEVRAIENT utiliser le codage binaire par opposition au codage de transfert sans 7-bit pour les entités internes. L'utilisation d'un codage sans 7-bit (comme le base64) augmenterait sans nécessité la taille de message. Les mises en œuvre PEUVENT déterminer que les receveurs sont capables de traiter les entités MIME binaires internes en (1) interprétant l'attribut id-cap-preferBinaryInside SMIMECapabilities, (2) par accord préalable, ou (3) par d'autres moyens.

Si un ou plusieurs receveurs prévus ne sont pas capables de traiter les objets MIME binaires internes, ou si cette capacité n'est pas connue pour un des receveurs prévus, les mises en œuvre de S/MIME DEVRAIENT utiliser le codage de transfert décrit au paragraphe 3.1.3 pour toutes les entités MIME qu'elles sécurisent.

 	3.1.3	Codage de transfert pour signature avec multipart/signed
Si une entité multipart/signed est à transmettre sur l'infrastructure standard Internet de SMTP ou sur un autre transport qui est contraint à du texte en 7-bit, elle DOIT appliquer le codage de transfert afin qu'il soit représenté comme texte en 7-bit. Les entités MIME qui sont déjà avec des données en 7-bit n'ont pas besoin de codage de transfert. Les entités comme du texte 8-bit et de données binaires peuvent être codées avec un codage de transfert quoted-printable ou base-64.

La principale raison de l'exigence de 7-bit est que l'infrastructure de transport de la messagerie Internet ne peut pas garantir le transport de données en 8-bit ou binaire. Même si maintenant de nombreux segments de l'infrastructure de transport traitent le 8-bit et même les données binaires, il est parfois impossible de savoir si le chemin de transport est tout en 8-bit. Si un message électronique avec des données en 8-bit devait rencontrer un agent de transfert de message qui ne peut pas transmettre des données en 8-bit ou binaire, l'agent a trois options, dont aucune n'est acceptable pour un message en clair signé :
-	L'agent pourrait changer le codage de transfert ; cela invaliderait la signature.
-	L'agent pourrait transmettre quand même les données, ce qui aurait très probablement pour résultat la corruption du huitième bit ; cela va aussi invalider la signature.
-	L'agent pourrait retourner le message à l'envoyeur.

La [RFC1847] interdit à un agent de changer le codage de transfert de la première partie d'un message multipart/signed. Si un agent conforme qui ne peut pas transmettre des données en 8-bit ou binaire rencontre un message multipart/signed avec des données 8-bit ou binaires dans la première partie, il va devoir retourner le message à l'envoyeur comme non livrable.

 	3.1.4	Exemple d'entité MIME canonique
Cet exemple montre un message multipart/mixed avec plein codage de transfert. Ce message contient une partie texte et une pièce jointe. L'exemple de message text inclut des caractères qui ne sont pas de l'ASCII et doivent donc être codés pour le transfert. Bien que ce ne soit pas montré ici, la fin de chaque ligne est <CR><LF>. Les fins de ligne des en-têtes MIME, du texte, et des parties codées pour le transfert, DOIVENT toutes être <CR><LF>.

Noter que cet exemple n'est pas d'un message S/MIME.

Content-Type: multipart/mixed; boundary=bar

--bar
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

=A1Hola Michael!

Comment trouves tu la nouvelle spécification S/MIME ?

C'est généralement une bonne idée de coder les lignes qui commencent avec From=20 parce que certains agents de transport de messagerie vont insérer un signe "supérieur à" (>), invalidant ainsi la signature.

Aussi, dans certains cas, il serait souhaitable de coder toute espace =20
en queue qui apparaît sur les lignes afin de s'assurer =20
que la signature de message n'est pas invalidée quand elle passe =20
une passerelle qui modifie de telles espaces (comme BITNET). =20

--bar
Content-Type: image/jpeg
Content-Transfer-Encoding: base64

iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI=

--bar--

 	3.2	Type de support application/pkcs7-mime
Le type de support application/pkcs7-mime est utilisé pour porter des types de contenu de CMS incluant EnvelopedData, SignedData, et CompressedData. Les détails de construction de ces entités sont décrits dans les paragraphes qui suivent. Ce paragraphe décrit les caractéristiques générales du type de support application/pkcs7-mime.

L'objet de CMS porté contient toujours une entité MIME qui est préparée comme décrit au paragraphe 3.1 si le eContentType est id-data. D'autres contenus PEUVENT être portés quand le eContentType contient des valeurs différentes. Voir dans [ESS] un exemple de cela avec des récépissés signés.

Comme les types de contenu de CMS sont des données binaires, dans la plupart des cas le codage de transfert base-64 est approprié, en particulier, quand il est utilisé avec le transport SMTP. Le codage de transfert utilisé dépend du transport sur lequel l'objet est à envoyer, et n'est pas une caractéristique du type de support.

Noter que cette discussion se réfère au codage de transfert de l'objet de CMS ou de l'entité MIME "extérieure". Il est complètement distinct, et sans relation avec le codage de transfert de l'entité MIME sécurisée par l'objet de CMS, l'objet "intérieur", qui est décrit au paragraphe 3.1.

Parce qu'il y a plusieurs types d'objets application/pkcs7-mime, un agent envoyeur DEVRAIT faire tout son possible pour aider un agent receveur à savoir le contenu d'un objet sans forcer l'agent receveur à décoder l'ASN.1 pour l'objet. Le champ d'en-tête Content-Type de tous les objets application/pkcs7-mime DEVRAIT inclure le paramètre facultatif "smime-type", comme décrit dans les paragraphes qui suivent.

 	3.2.1	Paramètres "name" et "filename"
Pour application/pkcs7-mime, les agents envoyeurs DEVRAIENT émettre le paramètre facultatif "name" dans le champ Content-Type pour la compatibilité avec les systèmes plus anciens. Les agents envoyeurs DEVRAIENT aussi émettre le champ facultatif Content-Disposition [RFC2183] avec le paramètre "filename". Si un agent envoyeur émet les paramètres ci-dessus, la valeur des paramètres DEVRAIT être un nom de fichier avec l'extension appropriée :

Type de support	Extension de fichier
application/pkcs7-mime (SignedData, EnvelopedData, AuthEnvelopedData)	.p7m
application/pkcs7-mime (message de gestion de certificat SignedData dégénéré) 	.p7c
application/pkcs7-mime (CompressedData)	.p7z
application/pkcs7-signature (SignedData) 	.p7s

De plus, le nom de fichier DEVRAIT être limité aux huit caractères suivis par une extension de trois lettres. La base de huit caractères du nom de fichier peut être tout nom distinct ; l'utilisation du nom de fichier de base "smime" DEVRAIT servir à indiquer que l'entité MIME est associée à S/MIME.

Inclure un nom de fichier a deux objets. Cela facilite l'utilisation des objets S/MIME comme fichiers sur un disque. Cela peut aussi porter des informations de type à travers des passerelles. Quand une entité MIME de type application/pkcs7-mime (par exemple) arrive à une passerelle qui n'a pas de connaissance particulière de S/MIME, elle va prendre par défaut le type de support de l'entité de application/octet-stream et le traiter comme une pièce jointe générique, perdant donc les informations de type. Cependant, le nom de fichier suggéré pour une pièce jointe est souvent porté à travers une passerelle. Cela permet souvent aux systèmes receveurs de déterminer l'application appropriée pour traiter la pièce jointe, dans ces cas, une application de traitement S/MIME autonome. Noter que ce mécanisme est fourni gracieusement aux mises en œuvre dans certains environnements. Une mise en œuvre S/MIME appropriée DOIT utiliser les types de supports et NE DOIT PAS s'appuyer sur les extensions de fichier.

 	3.2.2	Paramètre smime-type
Le type de contenu application/pkcs7-mime définit le paramètre facultatif "smime-type". L'intention de ce paramètre est de porter les détails sur la sécurité appliquée (signée ou enveloppée) ainsi que les informations sur le contenu. La présente spécification définit les types smime suivants.

Nom	Type de CMS	Contenu interne
enveloped-data	EnvelopedData	id-data
signed-data	SignedData	id-data
certs-only	SignedData	id-data
compressed-data	CompressedData	id-data
authEnveloped-data	AuthEnvelopedData	id-data

Afin d'être cohérent avec de futures spécifications, les lignes directrices suivantes DEVRAIENT être respectées pour l'allocation de nouveaux paramètres smime-type.

1.	Si la signature et le chiffrement peuvent tous deux être appliqués au contenu, alors trois valeurs de smime-type DEVRAIENT être allouées, "signed-*", "authEnv-*", et "enveloped-*". Si une opération peut être allouée, cela peut alors être omis. Donc, comme "certs-only" peut seulement être signé, "signed-" est omis.

2.	Une chaîne commune pour un OID de contenu DEVRAIT être allouée. On utilise "data" pour l'OID de contenu id-data quand MIME est le contenu interne.

3.	Si aucune chaîne commune n'est allouée, alors la chaîne commune de "OID.<oid>" est recommandée (par exemple, "OID.2.16.840.1.101.3.4.1.2" serait CBC AES-128).

L'intention explicite est que ce champ soit un conseil convenable pour que les applications de client de messagerie indiquent si un message est "signed", "authEnveloped", ou "enveloped" sans avoir à tunneler dans la charge utile de CMS.

Un registre des valeurs de paramètre smime-type supplémentaires a été défini dans la [RFC7114].

 	3.3	Création d'un message Enveloped-Only
Ce paragraphe décrit le format d'enveloppement d'une entité MIME sans la signer. Il est important de noter qu'envoyer des messages enveloppés mais non signés n'assure aucune protection de l'intégrité des données. La structure "enveloped-only" ne prend pas en charge les algorithmes symétriques authentifiés. On utilise la structure "authentifié enveloppé" pour ces algorithmes. Donc, il est possible de remplacer le texte chiffré d'une façon telle que le message traité soit encore valide, mais que sa signification puisse être altérée.

Étape 1. L'entité MIME à envelopper est préparée conformément au paragraphe 3.1.

Étape 2. L'entité MIME et les autres données requises sont traitées dans un objet de CMS de type EnvelopedData. En plus du chiffrement d'une copie de la clé de chiffrement de contenu (CEK, content-encryption key) pour chaque receveur, une copie de la CEK DEVRAIT être chiffrée pour l'origine et incluse dans les EnvelopedData (voir la [RFC5652], Section 6).

Étape 3. L'objet EnvelopedData est enveloppé dans un objet de CMS ContentInfo.

Étape 4. L'objet ContentInfo est inséré dans une entité MIME application/pkcs7-mime.

Le paramètre smime-type pour les messages enveloped-only est "enveloped-data". L'extension de fichier pour ce type de message est ".p7m".

Un exemple de message serait :

Content-Type: application/pkcs7-mime; name=smime.p7m; smime-type=enveloped-data
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename=smime.p7m

   MIIBHgYJKoZIhvcNAQcDoIIBDzCCAQsCAQAxgcAwgb0CAQAwJjASMRAwDgYDVQQDEw
   dDYXJsUlNBAhBGNGvHgABWvBHTbi7NXXHQMA0GCSqGSIb3DQEBAQUABIGAC3EN5nGI
   iJi2lsGPcP2iJ97a4e8kbKQz36zg6Z2i0yx6zYC4mZ7mX7FBs3IWg+f6KgCLx3M1eC
   bWx8+MDFbbpXadCDgO8/nUkUNYeNxJtuzubGgzoyEd8Ch4H/dd9gdzTd+taTEgS0ip
   dSJuNnkVY4/M652jKKHRLFf02hosdR8wQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBA
   gtaMXpRwZRNYAgDsiSf8Z9P43LrY4OxUk660cu1lXeCSFOSOpOJ7FuVyU=

 	3.4	Création d'un message authentifié seulement enveloppé
Ce paragraphe décrit le format pour envelopper une entité MIME sans la signer. Les messages authentifiés enveloppés fournissent la confidentialité et l'intégrité des données. Il est important de noter que l'envoi de messages authentifiés enveloppés ne fournit pas de preuve d'origine quand on utilise S/MIME. Il est possible à un tiers de remplacer du texte chiffré d'une façon telle que le message traité soit encore valide, mais que sa signification soit altérée. Cependant, ceci est substantiellement plus difficile que pour un message seulement enveloppé, car l'algorithme ne fournit pas de niveau d'authentification. Tout receveur pour qui le message est chiffré peut le remplacer sans être détecté.

Étape 1. L'entité MIME à envelopper est préparée conformément au paragraphe 3.1.

Étape 2. L'entité MIME et les autres données requises sont traitées dans un objet de CMS de type AuthEnvelopedData. En plus de chiffrer une copie de la CEK pour chaque receveur, une copie de la CEK DEVRAIT être chiffrée pour l'origine et incluse dans les AuthEnvelopedData (voir la [RFC5083]).

Étape 3. L'objet AuthEnvelopedData est enveloppé dans un objet de CMS ContentInfo.

Étape 4. L'objet ContentInfo est inséré dans une entité application/pkcs7-mime MIME.

Le paramètre smime-type pour les messages authentifiés seulement enveloppés est "authEnveloped-data". L'extension de fichier pour ce type of message est ".p7m".

Un échantillon de message serait :

Content-Type: application/pkcs7-mime; smime-type=authEnveloped-data; name=smime.p7m
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7m

   MIIDWQYLKoZIhvcNAQkQARegggNIMIIDRAIBADGBvjCBuwIBADAmMBIxEDAO
   BgNVBAMTB0NhcmxSU0ECEEY0a8eAAFa8EdNuLs1dcdAwCwYJKoZIhvcNAQEB
   BIGAgyZJo0ERTxA4xdTri5P5tVMyh0RARepTUCORZvlUbcUlaI8IpJZH3/J1
   Fv6MxTRS4O/K+ZcTlQmYeWLQvwdltQdOIP3mhpqXzTnOYhTK1IDtF2zx75Lg
   vE+ilpcLIzXfJB4RCBPtBWaHAof4Wb+VMQvLkk9OolX4mRSH1LPktgAwggJq
   BgkqhkiG9w0BBwEwGwYJYIZIAWUDBAEGMA4EDGPizioC9OHSsnNx4oCCAj7Y
   Cb8rOy8+55106newEJohC/aDgWbJhrMKzSOwa7JraXOV3HXD3NvKbl665dRx
   vmDwSCNaLCRU5q8/AxQx2SvnAbM+JKcEfC/VFdd4SiHNiUECAApLku2rMi5B
   WrhW/FXmx9d+cjum2BRwB3wj0q1wajdB0/kVRbQwg697dnlYyUog4vpJERjr
   7KAkawZx1RMHaM18wgZjUNpCBXFS3chQi9mTBp2i2Hf5iZ8OOtTx+rCQUmI6
   Jhy03vdcPCCARBjn3v0d3upZYDZddMA41CB9fKnnWFjadV1KpYwv80tqsEfx
   Vo0lJQ5VtJ8MHJiBpLVKadRIZ4iH2ULC0JtN5mXE1SrFKh7cqbJ4+7nqSRL3
   oBTud3rX41DGshOjpqcYHT4sqYlgZkc6dp0g1+hF1p3cGmjHdpysV2NVSUev
   ghHbvSqhIsXFzRSWKiZOigmlkv3R5LnjpYyP4brM62Jl7y0qborvV4dNMz7m
   D+5YxSlH0KAe8z6TT3LHuQdN7QCkFoiUSCaNhpAFaakkGIpqcqLhpOK4lXxt
   kptCG93eUwNCcTxtx6bXufPR5TUHohvZvfeqMp42kL37FJC/A8ZHoOxXy8+X
   X5QYxCQNuofWlvnIWv0Nr8w65x6lgVjPYmd/cHwzQKBTBMXN6pBud/PZL5zF
   tw3QHlQkBR+UflMWZKeN9L0KdQ27mQlCo5gQS85aifxoiiA2v9+0hxZw91rP
   IW4D+GS7oMMoKj8ZNyCJJsyf5smRZ+WxeBoolb3+TiGcBBCsRnfe6noLZiFO
   6Zeu2ZwE

 	3.5	Création d'un message Signed-Only
Il y a deux formats pour les messages signés définis pour S/MIME :
- application/pkcs7-mime avec SignedData.
- multipart/signed.

En général, la forme multipart/signed est préférée pour l'envoi, et les agents receveurs DOIVENT être capables de traiter les deux.

 	3.5.1	Choix d'un format pour les messages Signed-Only
Il n'y a pas de règles pures et dures sur quand un format particulier de signed-only est choisi. Cela dépend des capacités de tous les receveurs et de l'importance relative des receveurs avec les facilités de S/MIME capables de vérifier la signature par rapport à l'importance des receveurs sans un logiciel S/MIME capable de voir le message.

Les messages signés en utilisant le format multipart/signed peuvent toujours être vus par le receveur qu'il ait ou non le logiciel S/MIME. Ils peuvent aussi être vus si ils utilisent un agent d'utilisateur MIME natif ou si les messages sont traduits par une passerelle. Dans ce contexte, "être vu" signifie la capacité de traiter le message essentiellement comme si ce n'était pas un message signé, incluant toute autre structure MIME que le message pourrait avoir.

Les messages signés en utilisant le format SignedData ne peuvent pas être vus par un receveur qui n'a pas les facilités S/MIME. Cependant, le format SignedData protège le contenu du message contre le changement par des agents intermédiaires bénins. De tels agents pourraient faire des sauts à la ligne ou des changements de codage de transfert de contenu qui casseraient la signature.

 	3.5.2	Signature utilisant application/pkcs7-mime avec SignedData
Ce format de signature utilise le type de support application/pkcs7-mime. Les étapes pour créer ce format sont :

Étape 1. L'entité MIME est préparée en accord avec le paragraphe 3.1.

Étape 2. L'entité MIME et les autres données requises sont traitées dans un objet de CMS de type SignedData.

Étape 3. L'objet SignedData est enveloppé dans un objet de CMS ContentInfo.

Étape 4. L'objet ContentInfo est inséré dans une entité MIME application/pkcs7-mime.

Le paramètre smime-type pour les messages qui utilisent application/pkcs7-mime avec SignedData est "signed-data". L'extension de fichier pour ce type de message est ".p7m".

Un exemple de message serait :

Content-Type: application/pkcs7-mime; smime-type=signed-data; name=smime.p7m
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename=smime.p7m

   MIIDmQYJKoZIhvcNAQcCoIIDijCCA4YCAQExCTAHBgUrDgMCGjAtBgkqhkiG9w0BBw
   GgIAQeDQpUaGlzIGlzIHNvbWUgc2FtcGxlIGNvbnRlbnQuoIIC4DCCAtwwggKboAMC
   AQICAgDIMAkGByqGSM44BAMwEjEQMA4GA1UEAxMHQ2FybERTUzAeFw05OTA4MTcwMT
   EwNDlaFw0zOTEyMzEyMzU5NTlaMBMxETAPBgNVBAMTCEFsaWNlRFNTMIIBtjCCASsG
   ByqGSM44BAEwggEeAoGBAIGNze2D6gqeOT7CSCij5EeT3Q7XqA7sU8WrhAhP/5Thc0
   h+DNbzREjR/p+vpKGJL+HZMMg23j+bv7dM3F9piuR10DcMkQiVm96nXvn89J8v3UOo
   i1TxP7AHCEdNXYjDw7Wz41UIddU5dhDEeL3/nbCElzfy5FEbteQJllzzflvbAhUA4k
   emGkVmuBPG2o+4NyErYov3k80CgYAmONAUiTKqOfs+bdlLWWpMdiM5BAI1XPLLGjDD
   HlBd3ZtZ4s2qBT1YwHuiNrhuB699ikIlp/R1z0oIXks+kPht6pzJIYo7dhTpzi5dow
   fNI4W4LzABfG1JiRGJNkS9+MiVSlNWteL5c+waYTYfEX/Cve3RUP+YdMLRgUpgObo2
   OQOBhAACgYBc47ladRSWC6l63eM/qeysXty9txMRNKYWiSgRI9k0hmd1dRMSPUNbb+
   VRv/qJ8qIbPiR9PQeNW2PIu0WloErjhdbOBoA/6CN+GvIkq1MauCcNHu8Iv2YUgFxi
   rGX6FYvxuzTU0pY39mFHssQyhPB+QUD9RqdjTjPypeL08oPluKOBgTB/MAwGA1UdEw
   EB/wQCMAAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFHBEPoIub4feStN14z0g
   vEMrk/EfMB0GA1UdDgQWBBS+bKGz48H37UNwpM4TAeL945f+zTAfBgNVHREEGDAWgR
   RBbGljZURTU0BleGFtcGxlLmNvbTAJBgcqhkjOOAQDAzAAMC0CFFUMpBkfQiuJcSIz
   jYNqtT1na79FAhUAn2FTUlQLXLLd2ud2HeIQUltDXr0xYzBhAgEBMBgwEjEQMA4GA1
   UEAxMHQ2FybERTUwICAMgwBwYFKw4DAhowCQYHKoZIzjgEAwQuMCwCFD1cSW6LIUFz
   eXle3YI5SKSBer/sAhQmCq7s/CTFHOEjgASeUjbMpx5g6A==

 	3.5.3	Signature utilisant le format multipart/signed
Ce format est un format de signature en clair. Les receveurs sans aucune facilité de traitement S/MIME ou de CMS sont capables de voir le message. Il utilise le type de support multipart/signed décrit dans la [RFC1847]. Le type de support multipart/signed a deux parties. La première partie contient l'entité MIME qui est signée ; la seconde partie contient l'objet "signature détachée" SignedData de CMS dans lequel le champ encapContentInfo eContent est absent.

 	3.5.3.1	Type de support application/pkcs7-signature
Ce type de support contient toujours des ContentInfo de CMS contenant un seul objet de CMS de type SignedData. Le champ eContent encapContentInfo de SignedData DOIT être absent. Le champ signerInfos contient les signatures pour l'entité MIME.

L'extension de fichier pour les messages signed-only qui utilisent application/pkcs7-signature est ".p7s".

 	3.5.3.2	Création d'un message multipart/signed
Étape 1. L'entité MIME à signer est préparée en accord avec le paragraphe 3.1, en portant une attention particulière à la signature en clair.

Étape 2. L'entité MIME est présentée au traitement de CMS afin d'obtenir un objet de type SignedData dans lequel le champ encapContentInfo eContent est absent.

Étape 3. L'entité MIME est insérée dans la première partie d'un message multipart/signed sans traitement autre que celui décrit au paragraphe 3.1.

Étape 4. Le codage de transfert est appliqué à l'objet "signature détachée" de CMS SignedData, et il est inséré dans une entité MIME de type application/pkcs7-signature.

Étape 5. L'entité MIME de l'application/pkcs7-signature est insérée dans la seconde partie de l'entité multipart/signed.

Le type de contenu multipart/signed a deux paramètres exigés : le paramètre de protocole et le paramètre micalg.

Le paramètre de protocole DOIT être "application/pkcs7-signature". Noter que des guillemets sont exigés autour du paramètre de protocole parce que MIME exige que le caractère "/" dans la valeur de paramètre DOIT être entre guillemets.

Le paramètre micalg permet un traitement en une fois quand la signature est vérifiée. La valeur du paramètre micalg dépend du ou des algorithmes de résumé de message utilisés dans le calcul de la vérification de l'intégrité du message. Si plusieurs algorithmes de résumé de message sont utilisés, ils DOIVENT être séparés par des virgules conformément à la [RFC1847].  Les valeurs à placer dans le paramètre micalg DEVRAIT être parmi les suivantes :

Algorithme	Valeur utilisée
MD5*	md5
SHA-1*	sha-1
SHA-224	sha-224
SHA-256	sha-256
SHA-384	sha-384
SHA-512	sha-512
Tout autre	(défini séparément dans le profil d'algorithme ou "inconnu" si il n'est pas défini)

*Note : MD5 et SHA-1 sont historiques et ne sont plus considérés être sûrs. Voir les détails à l'Appendice B.

(Note historique : certaines mises en œuvre précoces de S/MIME émettaient et attendaient "rsa-md5", "rsa-sha1", et "sha1" pour le paramètre micalg.) Les agents receveurs DEVRAIENT être capables de récupérer en douceur d'une valeur de paramètre micalg qu'ils ne reconnaissent pas. Les futures valeurs pour ce paramètre seront prises dans le registre IANA "Noms textuels de fonction de hachage".

 	3.5.3.3	Exemple de message multipart/signed
Content-Type: multipart/signed;
       micalg=sha-256;
       boundary="----=_NextBoundary____Fri,_06_Sep_2002_00:25:21";
       protocol="application/pkcs7-signature"

Ceci est un message multipart en format MIME.

--boundary42
       Content-Type: text/plain

Ceci est un message signé en clair.

------=_NextBoundary____Fri,_06_Sep_2002_00:25:21

Ceci est un exemple de contenu.
------=_NextBoundary____Fri,_06_Sep_2002_00:25:21
   Content-Type: application/pkcs7-signature; name=smime.p7s
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7s

   MIIBJgYJKoZIhvcNAQcCoIIBFzCCARMCAQExADALBgkqhkiG9w0BBwExgf4w
   gfsCAQIwJjASMRAwDgYDVQQDEwdDYXJsUlNBAhBGNGvHgABWvBHTbi7EELOw
   MAsGCWCGSAFlAwQCAaAxMC8GCSqGSIb3DQEJBDEiBCCxwpZGNZzTSsugsn+f
   lEidzQK4mf/ozKqfmbxhcIkKqjALBgkqhkiG9w0BAQsEgYB0XJV7fjPa5Nuh
   oth5msDfP8A5urYUMjhNpWgXG8ae3XpppqVrPi2nVO41onHnkByjkeD/wc31
   A9WH8MzFQgSTsrJ65JvffTTXkOpRPxsSHn3wJFwP/atWHkh8YK/jR9bULhUl
   Mv5jQEDiwVX5DRasxu6Ld8zv9u5/TsdBNiufGw==

   ------=_NextBoundary____Fri,_06_Sep_2002_00:25:21--

Le contenu qui est résumé (la première partie du multipart/signed) consiste en les octets :

54 68 69 73 20 69 73 20 73 6f 6d 65 20 73 61 6d 70 6c 65 20 63 6f 6e 74 65 6e 74 2e 0d 0a

 	3.6	Création d'un message Compressed-Only
Ce paragraphe décrit le format pour compresser une entité MIME. Noter que les versions de S/MIME avant la version 3.1 ne spécifiaient aucun usage de CompressedData, et ne vont pas le reconnaître. L'utilisation d'une capacité pour indiquer la capacité de recevoir des CompressedData est décrite dans la [RFC3274] et est la méthode préférée pour la compatibilité.

Étape 1. L'entité MIME à compresser est préparée conformément au paragraphe 3.1.

Étape 2. L'entité MIME et les autres données requises sont traitées dans un objet de CMS de type CompressedData.

Étape 3. L'objet CompressedData est enveloppé dans un objet de CMS ContentInfo.

Étape 4. L'objet ContentInfo est inséré dans une entité MIME application/pkcs7-mime.

Le paramètre smime-type pour les messages compressed-only est "compressed-data". L'extension de fichier pour ce type de message est ".p7z".

Un exemple de message serait :

Content-Type: application/pkcs7-mime; smime-type=compressed-data; name=smime.p7z
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7z

   eNoLycgsVgCi4vzcVIXixNyCnFSF5Py8ktS8Ej0AlCkKVA==

 	3.8	Opérations multiples
Les formats MIME signed-only, enveloped-only, et compressed-only peuvent être incorporés. Cela fonctionne parce que ces formats sont tous des entités MIME qui encapsulent d'autres entités MIME.

Une mise en œuvre de S/MIME DOIT être capable de recevoir et traiter du S/MIME incorporé arbitrairement dans des limites de ressources raisonnables de l'ordinateur receveur.

Il est possible d'appliquer une des opérations de signature, chiffrement, et compression dans n'importe quel ordre. Il appartient à la mise en œuvre et à l'utilisateur de choisir. Quand on signe en premier, les signataires sont cachés de façon sûre par l'enveloppe. Quand on enveloppe d'abord, les signataires sont exposés, mais il est possible de vérifier les signatures sans retirer l'enveloppe. Cela peut être utile dans un environnement où la vérification automatique de signature est désirée, car aucun matériel de clé privée n'est exigé pour vérifier une signature.

Il y a des ramifications de sécurité dans le choix de signer ou de chiffrer d'abord. Le receveur d'un message qui est chiffré et ensuite signé peut valider que le bloc chiffré n'est pas altéré, mais ne peut pas déterminer de relation entre le signataire et le contenu non chiffré du message. Le receveur d'un message qui est signé puis chiffré peut supposer que le message signé lui-même n'a pas été altéré, mais qu'un attaquant attentif pourrait avoir changé les portions non authentifiées du message chiffré.

Quand on utilise la compression, on devrait garder en mémoire les lignes directrices suivantes :
-	La compression de données chiffrées transférées comme du binaire est déconseillée, car cela ne va pas donner de compression significative. Des données chiffrées transférées comme base64 pourraient très bien en bénéficier.
-	Si un algorithme de compression à pertes est utilisé avec la signature, on va devoir compresser d'abord, puis signer.

 	3.7	Création d'un message de gestion de certificat
Le message ou entité MIME de gestion de certificat est utilisé pour transporter des certificats et/ou des listes de révocation de certificat (CRL) comme en réponse à une demande d'enregistrement.

Étape 1. Les certificats et/ou listes de révocation de certificat sont rendus disponibles au processus de génération de CMS qui crée un objet de CMS de type SignedData. Le champ eContent encapContentInfo de SignedData DOIT être absent et le champ signerInfos DOIT être vide.

Étape 2. L'objet SignedData est enveloppé dans un objet ContentInfo de CMS.

Étape 3. L'objet ContentInfo est inclus dans une entité MIME application/pkcs7-mime.

Le paramètre smime-type pour un message de gestion de certificat est "certs-only". L'extension de fichier pour ce type de message est ".p7c".

 	3.9	Demandes d'enregistrement
Un agent envoyeur qui signe des messages DOIT avoir un certificat pour la signature afin qu'un agent receveur puisse vérifier la signature. Il y a de nombreuses façons d'obtenir des certificats, comme par un échange avec une autorité de certification, par un jeton ou disquette matériel, et ainsi de suite.

S/MIME v2 [SMIMEv2] spécifiait une méthode pour "enregistrer" les clés publiques auprès des autorités de certification en utilisant une partie de corps application/pkcs10. Depuis ce moment, le groupe de travail PKIX de l'IETF a développé d'autres méthodes pour demander des certificats. Cependant, S/MIME v4.0 n'exige pas de mécanisme particulier de demande de certificat.

 	3.10	Identification d'un message S/MIME
Parce que S/MIME prend en compte l'interopération dans des environnements non MIME, plusieurs mécanismes différents sont employés pour porter les informations de type, et il devient un peu difficile d'identifier les messages S/MIME. Le tableau suivant fait la liste des critères pour déterminer si un message est ou non un message S/MIME. Un message est considéré comme un message S/MIME si il correspond à un des critères mentionnés ci-dessous.

Le suffixe de fichier dans le tableau ci-dessous vient du paramètre "name" dans le champ d'en-tête Content-Type, ou du paramètre "filename" dans le champ d'en-tête Content-Disposition. Les paramètres MIME qui portent le suffixe de fichier ne sont pas mentionnés ci-dessous.

Type de support	Paramètre	Suffixe de fichier
application/pkcs7-mime	N/A	N/A
multipart/signed	protocol= "application/pkcs7-signature"	N/A
application/octet-stream	N/A	p7m, p7s, p7c, p7z

 	4.	Traitement du certificat

Un agent receveur DOIT fournir un mécanisme de restitution de certificat afin d'obtenir l'accès aux certificats pour les receveurs d'enveloppes numériques. La présente spécification ne couvre pas la façon dont les agents S/MIME traitent les certificats -- seulement ce qu'ils font après qu'un certificat a été validé ou rejeté. Les questions de certificat S/MIME sont traitées dans la [RFC5750].

Au minimum, pour un déploiement S/MIME initial, un agent d'utilisateur pourrait générer automatiquement un message à un receveur prévu demandant le certificat de ce receveur dans un message de retour signé. Les agents receveurs et envoyeurs DEVRAIENT aussi fournir un mécanisme pour permettre à un utilisateur de "mémoriser et protéger" les certificats pour leurs correspondants de telle façon que cela garantisse leur restitution ultérieure.

 	4.1	Génération de paire de clés
Toutes les paires de clés DOIVENT être générées à partir d'une bonne source d'entrée aléatoire non déterministe [RFC4086] et la clé privée DOIT être protégée de façon sûre.

Un agent d'utilisateur S/MIME NE DOIT PAS générer des clés asymétriques de moins de 2048 bits à utiliser avec un algorithmes de signature RSA.

Pour RSA à 512 bits avec SHA-1, voir la [RFC3370] et [FIPS186-2] sans la notice de changement 1 ; pour RSA à 512 bits avec SHA-256, voir la [RFC5754] et [FIPS186-2] sans la notice de changement 1 ; et pour RSA à 1024 bits jusqu'à 2048 bits avec SHA-256, voir la [RFC5754] et [FIPS186-2] avec la notice de changement 1. La première référence donne l'identifiant d'objet de l'algorithme de signature, et la seconde donne la définition de l'algorithme de signature.

Pour RSA de 2048 bits à 4096 bits avec SHA-256, voir la [RFC5754] et [FIPS186-4]. La première référence donne l'OID de l'algorithme de signature, et la seconde donne la définition de l'algorithme de signature.

Pour RSASSA-PSS avec SHA-256, voir la [RFC4056]. Pour RSAES-OAEP, voir la [RFC3560].

 	4.2	Génération de signature
Voici les exigences pour les signatures RSA et RSASSA-PSS générées par un agent S/MIME :

taille de clé ≤ 2047 : NE DEVRAIT PAS (Note 2)
2048 ≤ taille de clé ≤ 4096 : DEVRAIT (Note 1)
taille de clé > 4096 : PEUT (Note 1)

Note 1 : voir les considérations sur la sécurité à la Section 6.
Note 2 : voir les considérations historiques sur la messagerie à l'Appendice B.

Les tailles de clé pour ECDSA et EdDSA sont fixées par la courbe.

 	4.3	Vérification de signature
Voici les exigences pour les agents S/MIME receveurs durant la vérification des signatures RSA et RSASSA-PSS :

taille de clé ≤ 2047 : NE DEVRAIT PAS (Note 2)
2048 ≤ taille de clé ≤ 4096 : DOIT (Note 1)
taille de clé > 4096 : PEUT  (Note 1)

Note 1 : voir les considérations sur la sécurité à la Section 6.
Note 2 : voir les considérations historiques sur la messagerie à l'Appendice B.

Les tailles de clé pour ECDSA et EdDSA sont fixées par la courbe.

 	4.4	Chiffrement
Voici les exigences pour un agent S/MIME quand il établit les clés pour le chiffrement de contenu en utilisant les algorithmes RSA et RSA-OAEP :

taille de clé ≤ 2047 : NE DEVRAIT PAS (Note 2)
2048 ≤ taille de clé ≤ 4096 : DEVRAIT (Note 1)
taille de clé > 4096 : PEUT (Note 1)

Note 1 : voir les considérations sur la sécurité à la Section 6.
Note 2 : voir les considérations historiques sur la messagerie à l'Appendice B.

Les tailles de clé pour ECDH sont fixées par la courbe.

 	4.5	Déchiffrement
Voici les exigences pour un agent S/MIME quand il établit les clés pour le déchiffrement de contenu en utilisant les algorithmes RSA et RSAES-OAEP :

taille de clé ≤ 2047 : PEUT (Note 2)
2048 ≤ taille de clé ≤ 4096 : DOIT (Note 1)
taille de clé > 4096 : PEUT (Note 1)

Note 1 : voir les considérations sur la sécurité à la Section 6.
Note 2 : voir les considérations historiques sur la messagerie à l'Appendice B.

Les tailles de clé pour ECDH sont fixées par la courbe.

 	5.	Considérations relatives à l'IANA

Cette Section (1) met à jour les enregistrements de type de support pour application/pkcs7-mime et application/pkcs7-signature pour qu'ils se réfèrent au présent document plutôt qu'à la RFC 5751, (2) ajoute authEnveloped-data à la liste des valeurs pour smime-type, et (3) met à jour les références à la RFC 5751 sur le présent document en général.

Noter que d'autres documents peuvent définir des types de supports MIME supplémentaires pour S/MIME.

 	5.1	Type de support pour application/pkcs7-mime
Nom de type : application
Nom de sous type : pkcs7-mime
Paramètres exigés : aucun
Paramètres facultatifs : smime-type, name
Considérations de codage : voir la Section 3 de ce document
Considérations de sécurité : voir la Section 6 de ce document
Considérations d'interopérabilité : voir les Sections 1 à 6 de ce document
Spécification publiées : RFC 2311, RFC 2633, RFC 5751, et le présent document
Applications qui utilisent ce type de support : applications de sécurité
Informations supplémentaires :
Noms d'alias déconseillés pour ce type : N/A
Numéro magique : N/A
Extensions de fichier : voir le paragraphe 3.2.1 de ce document
Code de type de fichier Macintosh : N/A
Personne & messagerie à contacter pour plus d'informations :  IESG <iesg@ietf.org>
Usage prévu : COMMUN
Restrictions d'usage : aucune
Auteur : Sean Turner
Contrôleur des changements : groupe de travail LAMPS sur délégation de l'IESG

 	5.2	Type de support pour application/pkcs7-signature
Nom de type : application
Nom de sous type : pkcs7-signature
Paramètres exigés : aucun
Paramètres facultatifs : aucun
Considérations de codage : voir la Section 3 de ce document
Considérations de sécurité : voir la Section 6 de ce document
Considérations d'interopérabilité : voir les Sections 1 à 6 de ce document
Spécification publiées : RFC 2311, RFC 2633, RFC 5751, et le présent document
Considérations d'identifiant de fragment : N/A
Applications qui utilisent ce type de support : applications de sécurité
Informations supplémentaires :
Noms d'alias déconseillés pour ce type : N/A
Numéro magique : N/A
Extensions de fichier : voir le paragraphe 3.2.1 de ce document
Code de type de fichier Macintosh : N/A
Personne & messagerie à contacter pour plus d'informations :  IESG <iesg@ietf.org>
Usage prévu : COMMUN
Restrictions d'usage : aucune
Auteur : Sean Turner
Contrôleur des changements : groupe de travail LAMPS sur délégation de l'IESG

 	5.3	authEnveloped-data smime-type
L'IANA a enregistré la valeur suivante dans le registre "Valeurs de paramètres pour smime-type".

Valeur de smime-type : authEnveloped-data
Référence : RFC 8551, paragraphe 3.2.2

 	5.4	Mise à jour de référence
L'IANA met à jour toutes les références à la RFC 5751 avec leprésent document. Les registres connus à mettre à jour sont "Formats de contenu de CoAP" et "Types de supports".

 	6.	Considérations sur la sécurité

Les algorithmes de chiffrement seront cassés ou affaiblis au fil du temps. Les mises en œuvre et les utilisateurs doivent vérifier que les algorithmes de chiffrement mentionnés dans le présent document continuent de fournir le niveau attendu de sécurité. L'IETF peut produire de temps en temps des documents qui traitent de l'état de l'art actuel. Par exemple :
- L'attaque du million de messages décrite dans la [RFC3218].
- L'attaque du "petit sous groupe" Diffie-Hellman décrite dans la [RFC2785].
- Les attaques contre les algorithmes de hachage décrites dans la [RFC4270].

La présente spécification utilise les technologies de cryptographie à clé publique. On suppose que la clé privée est protégée pour assurer que des parties non autorisées n'y accèdent pas ou ne l'ont pas altérée.

Il est impossible pour la plupart des gens ou des logiciels d'estimer la valeur du contenu d'un message. De plus, il est impossible pour la plupart des gens ou des logiciels d'estimer le coût réel de la récupération du contenu d'un message chiffré qui est chiffré avec une clé d'une taille particulière. De plus, il est assez difficile de déterminer le coût de l'échec d'un déchiffrement si un receveur ne peut pas traiter un contenu de message. Donc, choisir entre différentes tailles de clé (ou choisir de juste utiliser le texte en clair) est aussi impossible pour la plupart des gens ou des logiciels. Cependant, des décisions fondées sur ces critères sont prises tout le temps, et donc, la présente spécification donne un cadre pour utiliser ces estimations dans le choix des algorithmes.

Le choix de 2048 bits comme taille de clé RSA asymétrique dans la présente spécification est fondé sur le désir de fournir au moins 100 bits de sécurité. Les tailles de clé qui doivent être prises en charge pour se conformer à la présente spécification semblent appropriées pour l'Internet sur la base de la [RFC3766]. Bien sûr, il y a des environnements, comme ceux des systèmes financiers et médicaux, qui peuvent choisir des tailles de clé différentes. Pour cette raison, une mise en œuvre PEUT prendre en charge des tailles de clé au delà de celles recommandées dans la présente spécification.

Les agents receveurs qui valident les signatures et les agents envoyeurs qui chiffrent les messages doivent être attentifs à l'usage du traitement cryptographique quand ils valident des signatures et chiffrent des messages en utilisant des clés plus longues que ce qui est exigé dans la présente spécification. Un attaquant pourrait envoyer des certificats avec des clés qui résulteraient en un traitement cryptographique excessif, par exemple, des clés plus longues que ce qui est exigé dans la présente spécification, qui pourraient submerger l'élément de traitement. Les agents qui utilisent de telles clés sans valider d'abord le certificat auprès d'une ancre de confiance seraient avisés d'avoir une sorte de système de gestion de resssource cryptographique pour empêcher de telles attaques.

Certains algorithmes de chiffrement comme RC2 offrent peu de sécurité réelle de plus que l'envoi en clair. D'autres algorithmes comme TripleDES fournissent de la sécurité mais ne sont plus considérés comme répondant à l'état de l'art. S/MIME exige l'utilisation d'algorithmes conformes à l'état de l'art actuel comme AES et qui fournissent la capacité d'annoncer les capacités cryptographiques aux parties avec lesquelles on communique. Cela permet à l'envoyeur de créer des messages qui peuvent utiliser le plus fort algorithme de chiffrement courant. Utiliser des algorithmes comme RC2 n'est jamais recommandé sauf si la seule alternative est pas de chiffrement.

Les clés RSA et DSA de moins de 2048 bits sont maintenant considérées par de nombreux experts comme cryptographiquement non sûres (du fait des avancées de la puissance de calcul) et ne devraient plus être utilisées pour protéger les messages. De telles clés étaient précédemment considérées comme sûres, de sorte que le traitement de messages antérieurement reçus signés et chifrés va souvent résulter en l'utilisation de clés faibles. Les mises en œuvre qui souhaitent prendre en charge d'anciennes versions de S/MIME ou traiter de vieux messages doivent examiner les risques de sécurité qui résultent de plus petites tailles de clé (par exemple, des messages contrefaits) par rapport au coût d'un déni de service. Si une mise en œuvre prend en charge la vérification des signatures numériques générées avec des clés RSA et DSA de moins de 1024 bits, elle DOIT avertir l'utilisateur. Les mises en œuvre devraient envisager de fournir des avertissements différents pour les nouveaux messages reçus et les messages précédemment mémorisés. Les mises en œuvre de serveur (par exemple, les serveurs de liste de messagerie sécurisée) où les avertissements à l'utilisateur ne sont pas appropriés DEVRAIENT rejeter les messages avec des signatures faibles.

Les mises en œuvre DEVRAIENT avoir conscience que plusieurs paires de clés actives peuvent être associées à une seule personne. Par exemple, une paire de clés peut être utilisée pour prendre en charge la confidentialité, tandis qu'une paire de clés différente peut être utilisée pour les signatures numériques.

Si un agent envoyeur envoie le même message en utilisant des forces de chiffrement différentes, un attaquant qui observe le canal de communications pourrait être capable de déterminer le contenu des messages à chiffrement fort en déchiffrant la version à chiffrement faible. En d'autres termes, un envoyeur NE DEVRAIT PAS envoyer de copie d'un message en utilisant une cryptographie plus faible que celle qu'il aurait utilisé pour l'original du message.

La modification du texte chiffré peut rester indétectée si l'authentification n'est pas aussi utilisée, ce qui est le cas quand on envoie des EnvelopedData sans les envelopper dans des SignedData ou sans enclore des SignedData dedans. C'est une des raisons pour le passage de EnvelopedData à AuthEnvelopedData, car les algorithmes de chiffrement authentifié fournissent l'authentification sans avoir besoin de la couche SignedData.

Si une mise en œuvre est concernée par la conformité aux recommandations de l'Institut National des normes et de la technologie (NIST, National Institute of Standards and Technology) sur la taille de clés, voir alors [SP800-57].

Si les environnements de messagerie utilisent le fait qu'un message est signé pour changer le comportement de traitement de message (des exemples seraient les règles courantes ou des conseils d'affichage UI) sans vérifier d'abord que le message est réellement signé et sans connaître l'état de la signature, cela peut conduire à un traitement incorrect du message. Des indicateurs visuels sur les messages peuvent devoir avoir le code de validation de signature vérifié périodiquement si l'indicateur est supposé donner des informations sur l'état actuel d'un message.

De nombreuses personnes supposent que l'utilisation d'un algorithme de chiffrement authentifié est tout ce qui est nécessaire pour que l'envoyeur du message soit authentifié. Dans presque tous les cas, ce n'est pas exact. Il y a un certain nombre de préconditions qui doivent tenir pour qu'un algorithme de chiffrement authentifié fournisse ce service :

-	La clé de départ doit être liée à une seule entité. L'utilisation d'une clé de groupe permet seulement de déclarer qu'un message a été envoyé par une des entités qui détiennent la clé mais ne va pas identifier une entité spécifique.

- 	Le message doit avoir exactement un envoyeur et un receveur. Avoir plus d'un receveur permettrait que le second receveur crée un message que le premier receveur croirait provenir de l'envoyeur en supprimant du message le second receveur.

-	Un chemin direct doit exister de la clé de départ à la clé utilisée comme CEK. Ce chemin doit garantir qu'aucun tiers n'a pu voir la CEK résultante. Cela signifie qu'on a besoin d'utiliser un algorithme appelé de "chiffrement direct" ou "d'accord de clé direct" dans d'autres contextes. Cela signifie que la clé de départ est (1) utilisée directement comme CEK ou (2) utilisée pour créer un secret qui est ensuite transformé en CEK via une étape de KDF.

Les mises en œuvre de S/MIME utilisent presque universellement un accord de clé éphémère-statique plutôt que statique-statique et n'utilisent pas de secret partagé pour le chiffrement. Cela signifie que la première précondition n'est pas satisfaite. La [RFC6278] définit comment utiliser l'accord de clé statique-statique avec la CMS, afin que la première précondition puisse être satisfaite. Actuellement, toutes les méthodes d'accord de clé S/MIME déduisent une clé de chiffrement de clé (KEK, Key-Encryption Key) et enveloppent une CEK. Cela viole la troisième précondition ci-dessus. De nouveaux algorithmes d'accord de clé qui créent directement la CEK sans créer de KEK intermédiaire devraient être définis.

Même quand toutes les préconditions sont satisfaites et que l'origine d'un message est établie par l'utilisation d'un algorithme de chiffrement authentifié, les utilisateurs doivent avoir conscience qu'il n'y a aucun moyen de prouver cela à un tiers. C'est parce que l'une ou l'autre des parties peut réussir à créer le message (ou juste altérer le contenu) sur la base du fait que la CEK va être connue des deux parties. Donc, l'origine est toujours fondée sur la présomption que "Je ne me suis pas envoyé ce message moi-même".

Tous les algorithmes de chiffrement authentifié dans le présent document utilisent le mode compteur pour la portion chiffrement de l'algorithme. Cela signifie que la longueur du texte en clair va toujours être connue, car la longueur du texte chiffré est toujours la même que celle du texte en clair. Cette information peut permettre à des observateurs passifs de déduire des informations sur la seule base de la longueur du message. Les applications pour lesquelles cela pose un problème doivent fournir un type de bourrage pour que la longueur du message ne fournisse pas cette information.

Quand la compression est utilisée avec le chiffrement, il y a une possibilité de fournir une couche de sécurité supplémentaire. Cependant, il faut faire attention quand on conçoit un protocole qui s'appuie sur l'utilisation de la compression, afin de ne pas créer un oracle de compression. Les attaques d'oracle de compression exigent une entrée adaptative au processus et attaquent le contenu inconnu d'un message sur la base de la longueur du résultat compressé. Cela signifie qu'aucune attaque sur la clé de chiffrement n'est nécessaire.

Un article récent sur la sécurité de S/MIME et de la messagerie OpenPGP [Efail] a souligné un certain nombre de problèmes des spécifications S/MIME actuelles et la façon dont les gens ont mis en œuvre les clients de messagerie. Du fait de la nature du fonctionnement du mode CBC, les modes permettent la malléabilité des textes en clair. Cette malléabilité permet à des attaquants de faire des changements dans le texte chiffré et, si des parties du texte en clair sont connues, créer des blocs arbitraires de texte en clair. Ces changements peuvent être faits sans déclencher la vérification d'intégrité faible en mode CBC. Ce type d'attaque peut être empêché par l'utilisation d'un algorithme de chiffrement authentifié avec données associées (AEAD) avec une vérification d'intégrité plus robuste sur le processus de déchiffrement. Il est donc recommandé que les systèmes de messagerie migrent aussi rapidement que possible à l'utilisation de AES-GCM et que le contenu déchiffré ne fasse l'objet d'aucun traitement avant la fin de la vérification d'intégrité.

L'autre attaque soulignée dans [Efail] est due à une erreur sur la façon dont les clients de messagerie traitent les messages HTML et multipart/mixed. Les clients DOIVENT exiger qu'un type de contenu text/html soit un document HTML complet (selon la [RFC1866]). Les clients DEVRAIENT traiter chacune des différentes pièces de la construction multipart/mixed comme étant d'origines différentes. Les clients DOIVENT traiter chaque pièce chiffrée ou signée d'un message MIME comme étant d'origine différente à la fois du contenu non protégé et les unes des autes.

 	7.	Références
 	7.1	Conventions de référence
[ASN.1] se réfère à [X.680], [X.681], [X.682], et [X.683].
[CMS] se réfère aux [RFC5083] et [RFC5652].
[ESS] se réfère à la [RFC2634] et la [RFC5035].
[MIME] se réfère aux [RFC2045], [RFC2046], [RFC2047], [RFC2049], [RFC4289], et [RFC6838].
[SMIMEv2] se réfère aux [RFC2311], [RFC2312], [RFC2313], [RFC2314], et [RFC2315].
[SMIMEv3] se réfère aux [RFC2630], [RFC2631], [RFC2632], [RFC2633], [RFC2634], et [RFC5035].
[SMIMv3.1] se réfère aux [RFC2634], [RFC5035], [RFC5652], [RFC5750], et [RFC5751].
[SMIMEv3.2] se réfère aux [RFC2634], [RFC3850], [RFC3851], [RFC3852], et [RFC5035].
[SMIMEv4] se réfère aux [RFC2634], [RFC5035], [RFC5652], [RFC8550], et au présent document.

 	7.2	Références normatives

[CHARSETS]	Jeux de caractères alloués par l'IANA. http://www.iana.org/assignments/character-sets 

[FIPS186-4]	National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication 186-4, DOI 10.6028/NIST.FIPS.186-4, juillet 2013, <https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.186-4.pdf>.

[RFC1847]	J. Galvin, S. Murphy, S. Crocker, N. Freed, "Sécurité multiparties pour MIME : multipartie/signée et multipartie/chiffrée", octobre 1995. (P.S.)

[RFC2045]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D. S., MàJ par 2184, 2231, 5335.)

[RFC2046]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 2 : Types de prise en charge", novembre 1996. (D. S., MàJ par 2646, 3798, 5147, 6657, 8098)

[RFC2047]	K. Moore, "MIME (Extensions de messagerie Internet multi-objets) Partie trois : extensions d'en-tête de message pour texte non ASCII", novembre 1996. (MàJ par RFC2184, RFC2231) (D.S.)

[RFC2049]	N. Freed, N. Borenstein, "Extensions multi-objets de la messagerie Internet (MIME) Partie cinq : critères de conformité et exemples", novembre 1996. (Remplace RFC1521, RFC1522, RFC1590) (D.S.)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2183]	R. Troost, S. Dorner, K. Moore, éd., "Communication des informations de présentation dans les messages Internet : le champ d'en-tête Contenu-disposition", août 1997. (MàJ par RFC2184, RFC2231) (P.S.)

[RFC2634]	P. Hoffman, éd., "Services de sécurité améliorés pour S/MIME", juin 1999. (MàJ par RFC5035) (P.S.)

[RFC3274]	P. Gutmann, "Type de contenu Données compressées pour la syntaxe de message cryptographique (CMS)", juin 2002. (P.S.)

[RFC3370]	R. Housley, "Algorithmes de syntaxe de message cryptographique (CMS)", août 2002. (P.S. ; MàJ par RFC8702)

[RFC3560]	R. Housley, "Utilisation de l'algorithme de transport de clé RSAES-OAEP dans la syntaxe de message cryptographique (CMS)", juillet 2003. (P.S.)

[RFC3565]	J. Schaad, "Utilisation de l'algorithme de chiffrement de la norme de chiffrement évolué (AES) dans la syntaxe de message cryptographique (CMS)", juillet 2003. (P.S.)

[RFC4056]	J. Schaad, "Utilisation de l'algorithme de signature RSASSA-PSS dans la syntaxe de message cryptographique (CMS)", juin 2005. (P.S.)

[RFC4086]	D. Eastlake 3rd, J. Schiller, S. Crocker, "Exigences d'aléa pour la sécurité", juin 2005. (Remplace RFC1750) (BCP0106)

[RFC4288]	N. Freed et J. Klensin, "Spécifications du type de support et procédures d'enregistrement", BCP 13, décembre 2005.

[RFC4289]	N. Freed, J. Klensin, "Extensions multi-objet de messagerie Internet (MIME) Partie quatre : Procédures d'enregistrement", décembre 2005. (Remplace RFC2048) (BCP0013)

[RFC5035]	J. Schaad, "Mise à jour des services de sécurité améliorée (ESS) : ajout du choix d'algorithme CertID", août 2007. (P.S.)

[RFC5083]	R. Housley, "Type de contenu Authenticated-Enveloped-Data dans la syntaxe de message cryptographique (CMS)", novembre 2007. (P.S. ; MàJ RFC3852)

[RFC5084]	R. Housley, "Utilisation des chiffrements authentifiés AES-CCM et AES-GCM dans la syntaxe de message cryptographique (CMS)", novembre 2007. (P.S.)

[RFC5652]	R. Housley, "Syntaxe de message cryptographique (CMS)", STD70, septembre 2009. (Remplace RFC3852)

[RFC5753]	S. Turner, D. Brown, "Utilisation des algorithmes de cryptographie à courbe elliptique (ECC) dans la syntaxe de message cryptographique (CMS)", janvier 2010. (Remplace RFC3278) (Information)

[RFC5754]	S. Turner, "Utilisation des algorithmes SHA2 avec la syntaxe de message cryptographique", janvier 2010. (MàJ RFC3370). (P. S.)

[RFC6838]	N. Freed, J. Klensin et T. Hansen, "Spécifications de type de support et procédures d’enregistrement", BCP 13, janvier   2013.

[RFC8174]	B. Leiba, "Ambiguïté des mots clés en majuscules ou minuscules dans la RFC2119", DOI 10.17487/RFC8174, mai 2017. BCP14. (MàJ RFC2119)

[RFC8418]	R. Housley, "Utilisation de l'algorithme d'accord de clé Diffie-Hellman à courbe elliptique avec X25519 et X448 dans la CMS", DOI 10.17487/RFC8418, août 2018. (P.S.)

[RFC8419]	R. Housley, "Utilisation de l'algorithme de signature numérique à courbe elliptique dans la CMS", DOI 10.17487/RFC8419, août 2018. (P.S.)

[RFC8550]	J. Schaad, B. Ramsdell, S. Turner, "Traitement de certificat d'extensions de messagerie Internet multi objet sûres (S/MIME) version 4.0",  DOI 10.17487/RFC8550, avril 20190. (P.S. ; Remplace RFC5750)

[X.680]	Recommandation UIT-T X.680 | ISO/CEI 8824-1:2002. "Technologie de l'information - Notation de syntaxe abstraite numéro un (ASN.1) : spécification de la notation de base".<https://www.itu.int/rec/T-REC-X.680>

[X.681]	Recommandation UIT-T X.681 | ISO/CEI 8824-2:2015, "Technologie de l'information - Notation de syntaxe abstraite numéro un (ASN.1) : spécification de l'objet d'information", août 2015, <https://www.itu.int/rec/T-REC-X.681>.

[X.682]	Recommandation UIT-T X.682 | ISO/CEI 8824-3:2015, "Technologie de l'information - Notation de syntaxe abstraite numéro un (ASN.1) : spécification des contraintes", août 2015, <https://www.itu.int/rec/T-REC-X.682>.

[X.683]	Recommandation UIT-T X.683 | ISO/CEI 8824-4:2015, "Technologie de l'information - Notation de syntaxe abstraite numéro un (ASN.1) : paramètres des spécifications d'ASN.1", août 2015, <https://www.itu.int/rec/T-REC-X.683>.

[X.690]	Recommandation UIT-T X.690 (2002) | ISO/CEI 8825-1:2002."Technologie de l'information - règles de codage ASN.1 : spécification des règles de codage de base (BER), des règles de codage canonique (CER) et des règles de codage distinctivees (DER)". <https://www.itu.int/rec/T-REC-X.690>

 	7.3	Références pour information

[Efail]	Poddebniak, D., Dresen, C., Muller, J., Ising, F., Schinzel, S., Friedberger, S., Somorovsky, J., and J. Schwenk, "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels", UsenixSecurity 2018, August 2018, <https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-poddebniak.pdf>.

[FIPS186-2]	National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS) (also with Change Notice 1)", Federal Information Processing Standards Publication 186-2, January 2000, <https://csrc.nist.gov/publications/detail/fips/186/2/archive/2000-01-27>.

[RFC1866]	T. Berners-Lee, D. Connolly, "Langage de balisage Hypertext - 2.0", novembre 1995. (Obsolète, voir RFC2854) (Hist.)

[RFC2268]	R. Rivest, "Description de l'algorithme de chiffrement RC2(r)", mars 1998. (Information)

[RFC2311]	S. Dusse et autres, "Spécification de message S/MIME, version 2", mars 1998. (Information) 

[RFC2312]	S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein, "Traitement de certificat S/MIME version 2", mars 1998. (Info.)

[RFC2313]	B. Kaliski, "PKCS n° 1 : Chiffrement RSA version 1.5", mars 1998.

[RFC2314]	B. Kaliski, "PKCS n° 10 : Syntaxe de demande de certification, version 1.5", mars 1998. (Obs., voir RFC2986) (Info.)

[RFC2315]	B. Kaliski, "PKCS n° 7 : Syntaxe de message cryptographique, version 1.5", mars 1998. (Information)

[RFC2630]	R. Housley, "Syntaxe de message cryptographique", juin 1999. (Obsolète, voir 3369, 3370) (P.S.)

[RFC2631]	E. Rescorla, "Méthode d'accord de clé Diffie-Hellman", juin 1999. (P.S.)

[RFC2632]	B. Ramsdell, éd., "Traitement de certificat S/MIME version 3", juin 1999. (Obsolète, voir RFC3850) (P.S.)

[RFC2633]	B. Rmasdell, "Spécification de message S/MIME version 3", juin 1999. (Obsolète, voir RFC3851) (P.S.)

[RFC2785]	R. Zuccherato, "Méthodes pour éviter les attaques de "petit sous-groupe" sur la méthode d'accord de clés Diffie-Hellman pour S/MIME", mars 2000. (Information)

[RFC3218]	E. Rescorla, "Empêcher l'attaque du million de messages sur la syntaxe de message cryptographique", janvier 2002. (Information)

[RFC3766]	H. Orman, P. Hoffman, "Détermination de la force des clés publiques utilisées pour l'échange de clés symétriques", avril   2004. (BCP0086)

[RFC3850]	B. Ramsdell, éd., "Traitement de certificat d'extensions multi-objets/sécurisées de messagerie Internet (S/MIME) version  3.1", juillet 2004. (P.S.) (Remplacée par RFC5750)

[RFC3851]	B. Ramsdell, "Spécification du message d'extensions de messagerie Internet multi-objets/sécurisé (S/MIME) version  3.1", juillet 2004. (Obsolète, voir RFC5751)

[RFC3852]	R. Housley, "Syntaxe de message cryptographique (CMS)", juillet 2004. (Obsolète, voir la RFC5652)

[RFC4134]	P. Hoffman, éd., "Exemples de messages S/MIME", juillet 2005. (Information)

[RFC4270]	P. Hoffman, B. Schneier, "Attaques contre les hachages cryptographiques dans les protocoles Internet", nov. 2005. (Info.)

[RFC4949]	R. Shirey, "Version 2 du glossaire de la sécurité sur Internet", août 2007. (Remplace RFC2828) (FYI0036) (Info.)

[RFC5035]	J. Schaad, "Mise à jour des services de sécurité améliorée (ESS) : ajout du choix d'algorithme CertID", DOI 10.17487/RFC5035, août 2007. (P.S.)

[RFC5750]	B. Ramsdell, S. Turner, "Traitement du certificat des extensions de messagerie Internet multi objets sécurisée (S/MIME) version 3.2", janvier 2010. (Remplace RFC3850). (P. S. ; Remplacée par RFC8550)

[RFC5751]	B. Ramsdell, S. Turner, "Spécification du message des extensions de messagerie Internet multi objets sécurisée (S/MIME) version 3.2", janvier 2010. (Remplace RFC3851). (P. S. ; Remplacée par RFC8551)

[RFC6151]	S. Turner, L. Chen, "Mise à jour des considérations de sécurité pour les algorithmes de résumé de message MD5 et le HMAC-MD5", DOI 10.17487/RFC6151, mars 2011, (MàJ RFC1321, RFC2104) (Information)

[RFC6194]	T. Polk et autres, "Considérations sur la sécurité pour les algorithmes de résumé de message SHA-0 et SHA-1", DOI 10.17487/RFC6194, mars  2011. (Information)

[RFC6268]	J. Schaad, S. Turner, "Nouveaux modules ASN.1 supplémentaires pour la syntaxe de message cryptographique (CMS) et l’infrastructure de clé publique utilisant X.509 (PKIX)", juillet 2011. (MàJ la RFC5911) (Information)

[RFC6278]	J. Herzog, R. Khazan, "Utilisation d’accord de clés Diffie-Hellman à courbe élliptique statique-statique dans la syntaxe de message cryptographique", juin 2011. (Information)

[RFC7114]	B. Leiba, "Création d’un registre pour les valeurs de paramètre de type smime", DOI 10.17487/RFC7114, janvier 2014. (P.S.)

[RFC7905]	A. Langley, et autres, "Suites de chiffrement ChaCha20-Poly1305 pour TLS", DOI 10.17487/RFC7905, juin 2016. (P.S. ; MàJ 5246, 6347)

[SP800-56A]	National Institute of Standards and Technology (NIST), "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A Revision 2, DOI 10.6028/NIST.SP.800-56Ar2, mai 2013, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf>.

[SP800-57]	National Institute of Standards and Technology (NIST), "Recommendation for Key Management - Part 1: General", NIST Special Publication 800-57 Revision 4, DOI 10.6028/NIST.SP.800-57pt1r4, janvier 2016, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf>.

[TripleDES]	Tuchman, W., "Hellman Presents No Shortcut Solutions to the DES", IEEE Spectrum v. 16, n. 7, pp. 40-41, DOI 10.1109/MSPEC.1979.6368160, juillet 1979.

 	Appendice A.	Module ASN.1

Note : Le module ASN.1 contenu ici est inchangé de la RFC 5751 [SMIMEv2] et la RFC 3851 [SMIMEv3.1] à l'exception d'un changement au commentaire ASN.1 à prefersBinaryInside dans la RFC 3851 [SMIMEv3.1]. Si un module compatible avec l'ASN.1 standard actuel est nécessaire, on le trouvera dans la [RFC6268]. Ce module utilise la version 1988 de ASN.1.

SecureMimeMessageV3dot1 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }

ÉTIQUETTES IMPLICITES DE DÉFINITIONS ::=

DÉBUT

IMPORTE

-- Cryptographic Message Syntax [RFC5652]
      SubjectKeyIdentifier, IssuerAndSerialNumber,
      RecipientKeyIdentifier
          FROM  CryptographicMessageSyntax
              { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };

--  id-aa est l'arc avec tous les nouveaux attributs authentifiés et non authentifiés produits par le groupe de travail S/MIME

IDENTIFIANT D'OBJET id-aa ::= {iso(1) member-body(2) usa(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)}

-- Les capacités S/MIME donnent une méthode de diffusion des capacité symétriques comprises. Les algorithmes DEVRAIENT être rangés par préférence et groupés par type.

IDENTIFIANT D'OBJET smimeCapabilities ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}

   SMIMECapability ::= SEQUENCE {
      capabilityID IDENTIFIANT D'OBJET,
      paramètres ANY DEFINED BY capabilityID OPTIONAL }

   SMIMECapabilities ::= SEQUENCE OF SMIMECapability

-- La préférence de clé de chiffrement donnent une méthode de diffusion du certificat de chiffrement préféré.

IDENTIFIANT D'OBJET id-aa-encrypKeyPref ::= {id-aa 11}

   SMIMEEncryptionKeyPreference ::= CHOICE {
      issuerAndSerialNumber   [0] IssuerAndSerialNumber,
      receipentKeyId                 [1] RecipientKeyIdentifier,
      subjectAltKeyIdentifier    [2] SubjectKeyIdentifier
   }

-- receipentKeyId est épelé de façon incorrecte, mais conservé pour des raisons historiques.

IDENTIFIANT D'OBJET id-smime ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }

IDENTIFIANT D'OBJET id-cap  ::= { id-smime 11 }

-- L'OID preferBinaryInside indique la capacité de recevoir des messages avec un codage binaire à l'intérieur de l'enveloppe de CMS. le champ de valeur de l'attribut preferBinaryInside est ABSENT.

IDENTIFIANT D'OBJET id-cap-preferBinaryInside  ::= { id-cap 1 }

--  Ce qui suit fait la liste des OID à utiliser avec S/MIME V3
-- Algorithmes de signature qui ne se trouvent pas dans les [RFC3370], [RFC5754], [RFC4056], et [RFC3560]

--IDENTIFIANT D'OBJET md2WithRSAEncryption ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2}

-- Autres attributs signés
-- IDENTIFIANT D'OBJET signingTime ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 5}
-- Voir la [RFC5652] pour une description de comment  coder la valeur de l'attribut.

   SMIMECapabilitiesParametersForRC2CBC ::= ENTIER 	-- (longueur de clé RC2 (en nombre de bits))

FIN

 	Appendice B.	Considérations sur l'historique de la messagerie

Au fil des mises à jour des spécifications de S/MIME, l'ensemble d'algorithmes recommandés a été modifié chaque fois que les documents ont été mis à jour. Cela signifie que si un utilisateur a des messages historiques et si son agent d'utilisateur a été mis à jour pour ne plus prendre en charge que l'ensemble actuel d'algorithmes recommandés, certains de ces vieux messages ne vont plus être accessibles. Il est fortement suggéré que les agents d'utilisateur mettent en œuvre certains des algorithmes suivants pour traiter les messages historiques.

Cet appendice contient un certain nombre de références aux documents qui ont été rendus obsolètes ou remplacés. Ceci est intentionnel, car les documents mis à jour n'ont souvent pas en eux les mêmes informations.

 	B.1	DigestAlgorithmIdentifier
Les algorithmes suivants ont été convoqués pour un certain niveau de prise en charge par les précédentes spécifications S/MIME :

-	SHA-1 a été abandonné dans la [SMIMEv4]. SHA-1 n'est plus considéré comme sûr, car il n'est plus résistant aux collisions. La déclaration de l'IETF sur SHA-1 se trouve dans la [RFC6194], mais elle est dépassée par rapport aux avancées les plus récentes.

-	MD5 a été abandonné dans [SMIMEv4]. MD5 n'est plus considéré comme sûr, car il n'est plus résistant aux collisions. Les détails se trouvent dans la [RFC6151].

 	B.2	Algorithmes de signature
Il y a un certain nombre de problèmes avec la validation des signatures sur des messages suffisamment historiques. Pour cette raison, il est fortement suggéré que les agents d'utilisateur traitent ces signatures différemment de celles des messages courants. Ces problèmes incluent que :

-	Les autorités de certification ne sont pas obligées de garder les certificats sur les CRL au delà de une mise à jour après l'expiration d'un certificat. Cela signifie que sauf si les CRL sont gardées en antémémoire au titre du message, il n'est pas toujours possible de vérifier si un certificat a été révoqué. Le même problème existe avec les réponses du protocole d'état de certificat en ligne (OSCP, Online Certificate Status Protocol) car elles peuvent être fondées sur une CRL plutôt que sur la base de données de certificats.

-	Les clés RSA et DSA de moins de 2048 bits sont maintenant considérées par de nombreux experts comme cryptographiquement non sûres (du fait des avancées de la puissance de calcul). De telles clés étaient auparavant considérées comme sûres, de sorte  que le traitement de messages signés historiques va souvent résulter en l'utilisation de clés faibles. Les mises en œuvre qui souhaitent prendre en charge de versions précédentes de S/MIME ou traiter de vieux messages doivent examiner les risques pour la sécurité qui résultent de plus petites tailles de clé (par exemple, des messages falsifiés) par rapport au coût d'un déni de service.

[SMIMEv3.1] a réglé la limite inférieure de taille de clé suggérée pour créer et validaer à 1024 bits. Avant cela, la limite inférieure de taille de clé était 512 bits.

-	Les fonctions de hachage utilisées pour valider les signatures sur les messages historiques peuvent ne plus être considérées comme sûres (voir ci-dessous). Bien qu'il n'y ait aucune attaque pratique connue actuellement de pré-image ou de seconde pré-image contre MD5 ou SHA-1, le fait qu'ils ne soient plus considérés comme résistants aux collisions implique que les niveaux de sécurité des signatures sont généralement considérés comme suspects. Si un message est connu pour être historique et qu'il a été en la possession du client pendant un certain temps, il pourrait quand même être considéré comme sûr.

-	Les deux problèmes précédents s'appliquent aussi aux certificats utilisés pour valider le lien de la clé publique avec l'identité qui a signé le message.

Les algorithmes suivants ont été convoqués pour un certain niveau de prise en charge par les spécifications S/MIME précédentes :

-	RSA avec MD5 a été abandonné dans [SMIMEv4]. MD5 n'est plus considéré comme sûr, car il n'est plus résistant aux collisions. On trouvera les détails dans la [RFC6151].

-	RSA et DSA avec SHA-1 ont été abandonnés dans [SMIMEv4]. SHA-1n'est plus considéré comme sûr, car il n'est plus résistant aux collisions. La déclaration de l'IETF sur SHA-1 se trouve dans la [RFC6194], mais elle est dépassée par rapport aux avancées les plus récentes

-	DSA avec SHA-256 a été abandonné dans [SMIMEv4]. DSA a été remplacé par des versions à courbe elliptique.

Comme les exigences de "mise en œuvre obligatoire" ont changé au fil du temps, certains problèmes ont été créés qui peuvent causer des problèmes d'interopérabilité :

-	Les clients S/MIME v2 sont seulement obligés de vérifier les signatures numériques en utilisant l'algorithme rsaEncryption avec SHA-1 ou MD5 et pourraient ne pas mettre en œuvre du tout id-dsa-with-sha1 ou id-dsa.

-	Les clients S/MIME v3 pourraient seulement mettre en œuvre la signature ou la vérification de signature en utilisant id-dsa-with-sha1 et pourraient aussi utiliser id-dsa comme un AlgorithmIdentifier dans ce champ.

-	Noter que les clients S/MIME v3.1 prennent en charge la vérification de id-dsa-with-sha1 et rsaEncryption et pourraient ne pas mettre en œuvre sha256WithRSAEncryption.

Note : Les clients receveurs DEVRAIENT reconnaître id-dsa comme équivalent à id-dsa-with-sha1.

Pour RSA à 512 bits avec SHA-1, voir la [RFC3370] et [FIPS186-2] sans la notice de changement 1 ; pour RSA à 512 bits avec SHA-256, voir la [RFC5754] et [FIPS186-2] sans la notice de changement 1 ; et pour RSA de 1024 bits à 2048 bits avec SHA-256, voir la [RFC5754] et [FIPS186-2] avec la notice de changement 1. La première référence donne l'OID de l'algorithme de signature, et la seconde donne la définition de l'algorithme de signature.

Pour DSA à 512 bits avec SHA-1, voir la [RFC3370] et [FIPS186-2] sans la notice de changement 1 ; pour DSA à 512 bits avec SHA-256, voir la [RFC5754] et [FIPS186-2] sans la notice de changement 1 ; pour DSA à 1024 bits avec SHA-1, voir la [RFC3370] et [FIPS186-2] avec la notice de changement 1 ; et pour DSA à 1024 bits et au dessus, avec SHA-256, voir la [RFC5754] et [FIPS186-4]. La première référence donne l'OID de l'algorithme de signature, et la seconde donne la définition de l'algorithme de signature.

 	B.3	ContentEncryptionAlgorithmIdentifier
Les algorithmes suivants ont été convoqués pour un certain niveau de prise en charge par les spécifications S/MIME précédentes :

-	RC2/40 [RFC2268] a été abandonné dans [SMIMEv3.2]. L'algorithme est connu pour n'être pas sûr et, si il est pris en charge devrait n'être utilisé que pour déchiffrer les messages existants.

-	DES EDE3 CBC [TripleDES], aussi appelé "tripleDES", a été abandonné dans [SMIMEv4]. Cet algorithme est supprimé de la liste des algorithmes pris en charge parce que (1) il a une taille de bloc de 64 bits et (2) il offre moins de 128 bits de sécurité. Cet algorithme ne devrait être pris en charge que pour déchiffrer les messages existants ; il ne devrait pas être utilisé pour chiffrer de nouveaux messages.

 	B.4	KeyEncryptionAlgorithmIdentifier
Les algorithmes suivants ont été convoqués pour un certain niveau de prise en charge par les spécifications S/MIME précédentes :
-	DH en mode éphémère-statique, comme spécifié dans la [RFC3370] et [SP800-57], a été abandonné dans [SMIMEv4].
-	Les tailles de clé de RSA ont été augmentées au fil du temps. Déchiffrer les vieux messages avec de plus petites tailles de clés est raisonnable ; cependant, les nouveaux messages devraient utiliser les tailles de clé mises à jour.

Pour DH à 1024 bits, voir la [RFC3370]. PourDH à 1024 bit et plus, voir [SP800-56A] ; néanmoins, utiliser la KDF, qui vient de X9.42, spécifié dans [RFC3370].

 	Appendice C.	Passage de la spécification de message S/MIME v2 au statut de Historique

Les spécifications [SMIMEv3], [SMIMEv3.1], et [SMIMEv3.2] sont rétro compatibles avec la spécification de message S/MIME v2 [SMIMEv2], à l'exception des algorithmes (abandon de l'exigence de RC2/40 et ajout de l'exigence de DSA et RSASSA-PSS). Donc, il est recommandé que la [RFC2311] soit passée au statut de Historique.

 	Remerciements

Tous nos remerciements aux autres auteurs de la RFC de spécification du message de S/MIME version 2 : Steve Dusse, Paul Hoffman, Laurence Lundblade, et Lisa Repka. Sans la v2, il n'y aurait pas eu de v3, v3.1, v3.2, ni v4.0.

Certains des exemples dans ce document sont copiés de la [RFC4134]. Merci aux personnes qui ont écrit et vérifié les exemples dans le présent document.

Un certain nombre de membres du groupe de travail S/MIME ont aussi travaillé très dur et contribué au présent document. Toute liste de gens est réputée comporter des omissions, et pour cela nous présentons nos excuses. En ordre alphabétique, les personnes suivantes nous sont restées en mémoire à cause de contributions directes à ce document : Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway, et John Pawling.

La version 4 met à jour les documents S/MIME qui ont été faits sous les auspices du groupe de travail LAMPS.

 	Adresse des auteurs

Jim Schaad	Blake Ramsdell	Sean Turner	
August Cellars	Brute Squad Labs, Inc.	sn3rd	
mél : ietf@augustcellars.com	mél : blaker@gmail.com	mél : sean@sn3rd.com