Équipe d'ingénierie de l'Internet (IETF)	B. Ramsdell, Brute Squad Labs	
Request for Comments : 5751	S. Turner, IECA	
RFC rendue obsolète : 3851	janvier 2010	
Catégorie : sur la voie de la normalisation		
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 3.2

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 3.2. 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 3851.
(La présente traduction incorpore les errata 2143 et 2708)

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 RFC5741.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à 

Notice de droits de reproduction
Copyright (c) 2010 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	2
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	4
1.6 Changements depuis S/MIME v3.1	4
2. Options de CMS	5
2.1 DigestAlgorithmIdentifier	5
2.2 SignatureAlgorithmIdentifier	6
2.3 KeyEncryptionAlgorithmIdentifier	6
2.4 Syntaxe générale	6
2.5 Attributs et type SignerInfo	7
2.6 Type SignerInfo SignerIdentifier	9
2.7 ContentEncryptionAlgorithmIdentifier	9
3. Création des messages S/MIME	11
3.1 Préparation de l'entité MIME à la signature, l'enveloppement, ou la compression	11
3.2 Type de prise en charge application/pkcs7-mime	13
3.3 Création d'un message Enveloped-Only	15
3.4 Création d'un message Signed-Only	16
3.5 Création d'un message Compressed-Only	17
3.6 Opérations multiples	18
3.7 Création d'un message de gestion de certificat	18
3.8 Demandes d'enregistrement	19
3.9 Identification d'un message S/MIME	20
4. Traitement du certificat	20
4.1 Génération de paire de clés	20
4.2 Génération de signature	21
4.3 Vérification de signature	21
4.4 Chiffrement	21
4.5 Déchiffrement	21
5. Considérations relatives à l'IANA	21
5.1 Type de prise en charge pour application/pkcs7-mime	21
5.2 Type de prise en charge pour application/pkcs7-signature	22
6. Considérations sur la sécurité	22
7. Références	23
7.1 Conventions de référence	23
7.2 Références normatives	23
7.3 Références pour information	25
Appendice A. Module ASN.1	26
Appendice B. Passage de la spécification de message S/MIME v2 au statut de Historique	27
Appendice C. Remerciements	27
Adresse des auteurs	27

 	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.

 	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 prise en charge application/pkcs7-mime qui peut être utilisé pour transporter des parties de corps.

Le présent document discute aussi comment utiliser le type de prise en charge 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 prise en charge 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 le document [RFC5652], les [RFC3370], [RFC3560], [RFC4056], 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 "ê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 la Recommandation UIT-T X.680 [X.680].

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.

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.

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.

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 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 S/MIME : logiciel d'utilisateur qui est un agent receveur, un agent envoyeur, ou les deux.

 	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].

On définit ici quelques termes 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-.

 	1.4	Compatibilité avec la pratique antérieure de S/MIME
Les agents S/MIME version 3.2 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], et S/MIME version 3.1 est décrit dans les RFC 3850, RFC 3851, RFC 3852, RFC 2634, et RFC 5035 [SMIMEv3.1]. 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
L'algorithme de clé publique RSA a été changé en un DOIT mettre en œuvre un algorithme d'enveloppe de clé, et l'algorithme Diffie-Hellman (DH) a été changé 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 prise en charge de message/rfc822 a été ajoutée.

L'utilisation du type de CMS CompressedData est permis, avec le type de prise en charge exigée et l'ajout d'extension de fichier.

 	1.6	Changements depuis S/MIME v3.1
Des changements rédactionnels, par exemple, remplacement de "type MIME" par "type de prise en charge", 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 S/MIME de MSG 3.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 prendre 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 AES-128 CBC oid.

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 prise en charge 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.

 	2.	Options de CMS

La CMS permet de prendre en charge une grande variété d'options 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 agents envoyeurs et receveurs DOIVENT prendre en charge SHA-256 [RFC5754] et DEVRAIENT- prendre en charge SHA-1 [RFC3370]. Les agents receveurs DEVRAIENT- prendre en charge MD5 [RFC3370] pour assurer la rétro compatibilité avec les objets SignedData S/MIME v2 résumés avec MD5.

 	2.2	SignatureAlgorithmIdentifier
Les agents receveurs :
- DOIVENT prendre en charge RSA avec SHA-256.
- DEVRAIENT+ prendre en charge DSA avec SHA-256.
- DEVRAIENT+ prendre en charge RSASSA-PSS avec SHA-256.
- DEVRAIENT- prendre en charge RSA avec SHA-1.
- DEVRAIENT- prendre en charge DSA avec SHA-1.
- DEVRAIENT- prendre en charge RSA avec MD5.

Les agents envoyeurs:
- DOIVENT prendre en charge RSA avec SHA-256.
- DEVRAIENT+ prendre en charge DSA avec SHA-256.
- DEVRAIENT+ prendre en charge RSASSA-PSS avec SHA-256.
- DEVRAIENT- prendre en charge RSA avec SHA-1 ou DSA avec SHA-1.
- DEVRAIENT- prendre en charge RSA avec MD5.

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

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. Noter que les clients S/MIME v3 pourraient seulement mettre en œuvre de signer ou de vérifier la signature en utilisant id-dsa-with-sha1, et pourraient aussi utiliser id-dsa comme un identifiant d'algorithme dans ce champ. Les clients receveurs DEVRAIENT reconnaître id-dsa comme équivalent à id-dsa-with-sha1, et les clients envoyeurs DOIVENT utiliser id-dsa-with-sha1 si ils utilisent cet algorithme. Noter aussi que 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.

 	2.3	KeyEncryptionAlgorithmIdentifier
Agents receveurs et envoyeurs :
- DOIVENT prendre en charge le chiffrement RSA, comme spécifié dans la [RFC3370].
- DEVRAIENT+ prendre en charge RSAES-OAEP, comme spécifié dans la [RFC3560].
- DEVRAIENT- prendre en charge le mode DH éphémère statique, comme spécifié dans la [RFC3370] et [SP800-57].

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 CBC AES-128 est l'algorithme de chiffrement de contenu de mise en œuvre obligatoire, l'algorithme d'enveloppe de clé AES-128 DOIT aussi être pris en charge quand le mode DH éphémère statique est utilisé.

Noter que les clients S/MIME v3.1 pourraient ne mettre en œuvre que le chiffrement et déchiffrement de clé en utilisant l'algorithme rsaEncryption. Noter que les clients S/MIME v3 pourraient ne mettre en œuvre que le chiffrement et déchiffrement de clé utilisant l'algorithme Diffie-Hellman. Noter aussi que les clients S/MIME v2 sont seulement capables de déchiffrer les clés de chiffrement de contenu en utilisant l'algorithme rsaEncryption.

 	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, et CompressedData sont courramment 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 id-data et le type de prise en charge 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.4.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 à 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. 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 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.6 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.

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 à 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 générateur d'un message et donc n'est pas plus fiable que le générateur.

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") et des algorithmes de chiffrement de clé (comme "rsaEncryption"). Il y a aussi plusieurs identifiants qui indiquent la prise en charge d'autres caractéristiques facultatives comme le codage binaire et la compression. 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 ; il NE DOIT PAS être un UnsignedAttribute. La CMS définit SignedAttributes comme un ENSEMBLE d'attributs. Le SignedAttributes dans un signerInfo NE DOIT PAS inclure plusieurs instances 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. Il NE DOIT PAS y avoir zéro ou plusieurs instances de AttributeValue présentes dans le attrValues ENSEMBLE DE AttributeValue.

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 (OID, object identifier) 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 en DER pour la SMIMECapability pour AES-128 CBC DOIT être identiquement codée sans considération de la mise en œuvre. À 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.

Les OID qui correspondent aux algorithmes DEVRAIENT utiliser le même OID que l'algorithme réel, sauf dans le cas où l'usage de l'algorithme est ambigu d'après l'OID. 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 ; il NE DOIT PAS être un UnsignedAttribute. La CMS définit SignedAttributes comme un ENSEMBLE DE Attribute. Les SignedAttributes dans un signerInfo NE DOIVENT PAS inclure plusieurs instances de l'attribut SMIMEEncryptionKeyPreference. La CMS définit la syntaxe ASN.1 pour Attribute pour inclure un ENSEMBLE DE AttributeValue de attrValues. Un attribut SMIMEEncryptionKeyPreference DOIT seulement inclure une instance de AttributeValue. Il NE DOIT PAS y avoir zéro ou plusieurs instances de AttributeValue présentes dans l'ENSEMBLE DE AttributeValue de attrValues .

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 DEVRAIT 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 de 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 v3.2 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 CBC [RFC3565].
- DEVRAIT+ prendre en charge le chiffrement et le déchiffrement avec AES-192 CBC et AES-256 CBC [RFC3565].
- DEVRAIT- prendre en charge le chiffrement et le déchiffrement avec DES EDE3 CBC, ci-après appelé "tripleDES" [RFC3370].

 	2.7.1	Décision de la méthode de chiffrement
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 n'a pas connaissance des capacités de chiffrement du receveur, et
-	l'agent envoyeur n'a pas connaissance de la version de S/MIME du receveur,
alors l'agent envoyeur DEVRAIT utiliser AES-128 parce que c'est un algorithme plus fort et qu'il est exigé par S/MIME v3.2. Si l'agent envoyeur choisit de ne pas utiliser AES-128 dans cette étape, il DEVRAIT utiliser tripleDES.

 	2.7.2	Choix d'un chiffrement faible
Tous les algorithmes qui utilisent des clés de 40 bits sont considérés par beaucoup comme un chiffrement faible. 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 DES ou AES.

 	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. Le document sur les services de sécurité améliorée pour S/MIME [ESS] fournit des descriptions 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. Une entité MIME peut être une ou des sous-parties d'un message, ou tout le message avec toutes ses sous-parties. 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 RFC-822. 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. Si la protection par l'en-tête RFC-822 est requise, l'utilisation du type de prise en charge message/rfc822 est expliquée plus loin dans cette section.

L'entité MIME qui est sécurisée et 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 des types de contenu de CMS est décrit dans les paragraphes 3.2, 3.4, et ailleurs.

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é.

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 prise en charge 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ées 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.

Les mises en œuvre de S/MIME DEVRAIENT cependant 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 pas possible si l'entité MIME originale était de données seulement 7-bit.

Les mises en œuvre de S/MIME qui "savent" que tous les receveurs prévus sont capables de traiter les objets MIME binaires internes (mais sauf les 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) étendrait sans nécessité la taille de message. Les mises en œuvre PEUVENT "savoir" que les mises en œuvre receveuses sont capables de traiter les entités MIME binaires internes en interprétant l'attribut id-cap-preferBinaryInside SMIMECapabilities, par accord préalable, ou 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 tranfert 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'US-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 prise en charge application/pkcs7-mime
Le type de prise en charge 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 prise en charge application/pkcs7-mime.

L'objet de CMS porté contient toujours une entité MIME qui est prête 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 prise en charge.

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 prise en charge	Extension de fichier
application/pkcs7-mime (SignedData, EnvelopedData)	.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 prise en charge 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-seulement	SignedData	id-data
compressed-data	CompressedData	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 deux valeurs de smime-type DEVRAIENT être allouées, "signed-*" 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" ou "enveloped" sans avoir à tunneler dans la charge utile de CMS.

 	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. 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 pour chaque receveur, une copie de la clé de chiffrement de contenu 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; smime-type=enveloped-data; name=smime.p7m
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename=smime.p7m

      rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
      7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
      f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
      0GhIGfHfQbnj756YT64V

 	3.4	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.4.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.4.2	Signature utilisant application/pkcs7-mime avec SignedData
Ce format de signature utilise le type de prise en charge 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

      567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
      77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
      HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
      6YT64V0GhIGfHfQbnj75

 	3.4.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 prise en charge multipart/signed décrit dans la [RFC1847]. Le type de prise en charge 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" de CMS SignedData dans lequel le champ encapContentInfo eContent est absent.

 	3.4.3.1	Type de prise en charge application/pkcs7-signature
Ce type de prise en charge contient toujours un ContentInfo contenant un seul objet de CMS de type SignedData. Le champ SignedData encapContentInfo eContent 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.4.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 "de 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 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 futurs noms pour ce paramètre seront cohérents avec le registre IANA "Noms textuels de fonction de hachage".

 	3.4.3.3	Exemple de message multipart/signed
Content-Type: multipart/signed;
          protocol="application/pkcs7-signature";
          micalg=sha-1; boundary=boundary42

--boundary42
       Content-Type: text/plain

Ceci est un message signé en clair.

--boundary42
       Content-Type: application/pkcs7-signature; name=smime.p7s
       Content-Transfer-Encoding: base64
       Content-Disposition: attachment; filename=smime.p7s

       ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
       4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
       n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
       7GhIGfHfYT64VQbnj756

--boundary42--

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

   43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69
   6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69
   67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a

 	3.5	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

   rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
   7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
   f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
   0GhIGfHfQbnj756YT64V

 	3.6	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. Un receveur d'un message qui est chifré 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 codées en binaire est déconseillée, car cela ne va pas donner de compression significative. Des données chiffrées en 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 de gestion de certificat ou entité MIME est utilisé pour transporter des certificats et/ou des listes de révocation de certificat, 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 SignedData encapContentInfo eContent 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-seulement". L'extension de fichier pour ce type de message est ".p7c".

 	3.8	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 v3.2 n'exige pas de mécanisme particulier de demande de certificat.

 	3.9	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. Ces paramètres qui donnent le suffixe de fichier ne sont pas mentionnés ci-dessous au titre de la section de paramètre.

Type de prise en charge :  application/pkcs7-mime
paramètres :  any
suffixe de fichier : any

Type de prise en charge :  multipart/signed
paramètres :  protocol="application/pkcs7-signature"
suffixe de fichier : any

Type de prise en charge :  application/octet-stream
paramètres :  any
suffixe de fichier : 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 traite pas de la façon dont les agents S/MIME traitent les certificats, seulement de 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 générées DOIVENT l'être à 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 512 bits à utiliser avec les algorithmes de signature RSA ou DSA.

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 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 ; pour DSA à 1024 bits et au dessus avec SHA-256, voir la [RFC5754] et [FIPS186-3]. 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 RSASSA-PSS avec SHA-256, voir la [RFC4056]. Pour DH à 1024 bits, voir la [RFC3370]. Pour DH à 1024 bits et au dessus, voir [SP800-56A] ; néanmoins, utiliser la KDF, qui vient de X9.42, spécifiée dans la [RFC3370]. Pour RSAES-OAEP, voir la [RFC3560].

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

taille de clé ≤ 1023 : NE DEVRAIT PAS (voir les considérations sur la sécurité)
1024 ≤ taille de clé ≤ 2048 : DEVRAIT (voir les considérations sur la sécurité)
taille de clé > 2048 : PEUT (voir les considérations sur la sécurité)

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

taille de clé ≤ 1023 : PEUT (voir les considérations sur la sécurité)
1024 ≤ taille de clé ≤ 2048 : DOIT (voir les considérations sur la sécurité)
taille de clé > 2048 : PEUT (voir les considérations sur la sécurité)

 	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, RSA-OAEP, et DH :

taille de clé ≤ 1023 : NE DEVRAIT PAS (voir les considérations sur la sécurité)
1024 ≤ taille de clé ≤ 2048 : DEVRAIT (voir les considérations sur la sécurité)
taille de clé > 2048 : PEUT (voir les considérations sur la sécurité)

 	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, RSAES-OAEP, et DH :

taille de clé ≤ 1023 : PEUT (voir les considérations sur la sécurité)
1024 ≤ taille de clé ≤ 2048 : DOIT (voir les considérations sur la sécurité)
taille de clé > 2048 : PEUT (voir les considérations sur la sécurité)

 	5.	Considérations relatives à l'IANA

Les informations suivantes mettent à jour l'enregistrement de type de prise en charge pour application/pkcs7-mime et application/pkcs7-signature pour qu'il se réfère au présent document plutôt qu'à la RFC 2311.

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

 	5.1	Type de prise en charge pour application/pkcs7-mime
Nom de type : application
Nom de sous type : pkcs7-mime
Paramètres exigés : aucun
Paramètres facultatifs : smime-type/signed-data, smime-type/enveloped-data, smime-type/compressed-data, smime-type/certs-only, 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, et le présent document
Applications qui utilisent ce type de prise en charge : applications de sécurité
Informations supplémentaires : aucune
Personne & messagerie à contacter pour plus d'informations : groupe de travail S/MIME à smime-chairs@tools.ietf.org
Usage prévu : COMMUN
Restrictions d'usage : aucune
Auteur : Sean Turner
Contrôleur des changements : groupe de travail S/MIME sur délégation de l'IESG

 	5.2	Type de prise en charge 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, et le présent document
Applications qui utilisent ce type de prise en charge : applications de sécurité
Informations supplémentaires : aucune
Personne & messagerie à contacter pour plus d'informations : groupe de travail S/MIME à smime-chairs@tools.ietf.org
Usage prévu : COMMUN
Restrictions d'usage : aucune
Auteur : Sean Turner
Contrôleur des changements : groupe de travail S/MIME sur délégation de l'IESG

 	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.

Utiliser un chiffrement faible dans S/MIME offre peu de sécurité réelle par rapport à l'envoi de texte en clair. Cependant, d'autres caractéristiques de S/MIME, comme la spécification de AES et la capacité d'annoncer de plus fortes capacités cryptographiques aux parties avec lesquelles on communique, permet aux envoyeurs de créer des messages qui utilisent un chiffrement fort. Utiliser un chiffrement faible n'est jamais recommandé sauf si la seule alternative est pas de chiffrement.

Les clés RSA et DSA de moins de 1024 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 faiblement chiffrée. 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.

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.

 	7.	Références
 	7.1	Conventions de référence
[ESS] se réfère à la [RFC2634] et la [RFC5035].
[MIME] se réfère aux [RFC2045], [RFC2046], [RFC2047], [RFC2049], [RFC4288], et [RFC4289].
[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], [RFC3850], [RFC3851], [RFC3852], et [RFC5035].

 	7.2	Références normatives

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

[FIPS186-2]	National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", FIPS Publication 186-2, janvier 2000. [avec amendement 1].

[FIPS186-3]	National Institute of Standards and Technology (NIST), FIPS Publication 186-3, "Digital Signature Standard", juin 2009.

[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.)

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

[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)

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

[SP800-56A]	National Institute of Standards and Technology (NIST), Special Publication 800-56A: "Recommendation Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", mars 2007.

[X.680]	Recommandation UIT-T X.680 (2002) | 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".

[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)".

 	7.3	Références pour 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)

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

[SP800-57]	National Institute of Standards and Technology (NIST), Special Publication 800-57: "Recommendation for Key Management", août 2005.

 	Appendice A.	Module ASN.1

Note : Le module ASN.1 contenu ici est inchangé de la RFC 3851 [SMIMEv3.1] à l'exception d'un changement au commentaire ASN.1 à prefersBinaryInside. 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.	Passage de la spécification de message S/MIME v2 au statut de Historique

Les documents [SMIMEv3], [SMIMEv3.1], et v3.2 (le présent document) 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.

 	Appendice C.	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, ni v3.2.

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, John Pawling, et Jim Schaad.

 	Adresse des auteurs

Sean Turner	Blake Ramsdell	
IECA, Inc.	Brute Squad Labs, Inc.	
3057 Nutley Street, Suite 106	mél : blaker@gmail.com 	
Fairfax, VA 22031		
USA		
mél : turners@ieca.com