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

Traitement de certificat d'extensions multi objets de messagerie Internet sécurisée (S/MIME) version 4.0

Résumé
Le présent document spécifie les conventions pour l'usage des certificats X.509 par les agents d'extension de messagerie Internet multi objets sécurisés (S/MIME, Secure/Multipurpose Internet Mail Extensions) v4.0. S/MIME donne une méthode pour envoyer et recevoir des messages MIME sûrs, et les certificats font partie intégrante du traitement d'agent S/MIME. Les agents S/MIME valident les certificats comme décrit dans la RFC 5280, "Profil de certificat d'infrastructure de clé publique X.509 et de liste de révocation de certificat (CRL) pour l'Internet". Les agents S/MIME doivent satisfaire les exigences de traitement de certificat du présent document ainsi que celles de la RFC 5280. Le présent document rend obsolète la RFC 5750.

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). Plus d'informations sur les normes de l'Internet sont disponibles à la Section 2 de la RFC  7841.

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

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

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

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.
Table des matières
1. Introduction	2
1.1 Définitions	2
1.2 Conventions utilisées dans le document	3
1.3 Compatibilité avec la pratique antérieure de S/MIME	3
1.4 Changements de S/MIME v3 à S/MIME v3.1	3
1.5 Changements de S/MIME v3.1 à S/MIME v3.2	4
1.6 Changements depuis S/MIME 3.2	4
2. Options de CMS	5
2.1 Liste de révocation de certificats	5
2.2 Choix de certificat	5
2.3 Certificats inclus	5
3. Utilisation des noms distinctifs pour la messagerie Internet	6
4. Traitement de certificat	7
4.1 Liste de révocation de certificats	7
4.2 Validation de chemin de certificat	7
4.3 Algorithmes de signature et tailles de clé de certificat et de CRL	8
4.4 Extensions de certificat PKIX	8
5. Considérations relatives à l'IANA	10
5. Considérations sur la sécurité	10
7. Références	11
7.1 Conventions de référence	11
7.2 Références normatives	11
7.3 Références pour information	12
Appendice A. Considérations historiques	14
A.1 Algorithmes de signature et tailles de clés	14
Appendice B. Passage du traitement de certificat S/MIME v2 au statut de Historique	14
Remerciements	15
Adresse des auteurs	15

 	1.	Introduction

Les extensions multi objets de messagerie Internet sécurisée (S/MIME, Secure/Multipurpose Internet Mail Extensions) v4.0, décrites dans la [RFC8551], fournissent une méthode pour envoyer et recevoir des messages MIME sûrs. Avant d'utiliser une clé publique pour fournir des services de sécurité, l'agent S/MIME DOIT vérifier que la clé publique est valide. Les agents S/MIME DOIVENT utiliser les certificats PKIX pour valider les clés publiques comme décrit dans la [RFC5280] ("Profil de certificat d'infrastructure de clé publique X.509 et de liste de révocation de certificat (CRL) pour l'Internet"). Les agents S/MIME DOIVENT satisfaire les exigences de traitement de certificat spécifiées dans le présent document en plus de celles déclarées dans la [RFC5280].

La présente spécification est compatible avec la syntaxe de message cryptographique (CMS, Cryptographic Message Syntax) [RFC5652] en ce qu'elle utilise les types de données définis par la CMS. Elle hérite aussi de toutes les variantes d'architectures pour la gestion de clé fondée sur le certificat prises en charge par la CMS.

Le présent document rend obsolète la [RFC5750]. Le changement le plus significatif concerne les recommandations sur les algorithmes de chiffrement utilisés par la spécification. Plus de détails figurent au paragraphe 1.6.

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

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

Certificat d'attribut (AC, Attribute Certificate) : un AC X.509 est une structure séparée de la clé publique d'un certificat X.509 de sujet. Un sujet peut avoir plusieurs AC X.509 associés à chacun de ses certificat X.509 de clé publique. Chaque AC X.509 lie un ou plusieurs attributs à un des certificats X.509 de clé publique du sujet. La syntaxe d'AC X.509 est définie dans la [RFC5755].

Certificat : type qui lie le nom d'une entité à une clé publique avec une signature numérique. Ce type est défini dans la [RFC5280]. Ce type contient aussi le nom distinctif du producteur du certificat (le signataire) un numéro de série spécifique du producteur, l'identifiant d'algorithme de signature du producteur, une période de validité, et des extensions aussi définies dans le présent document.

Liste de révocation de certificat (CRL, Certificate Revocation List) : type qui contient des informations sur les certificats dont la validité a été révoquée prématurément par le producteur. L'information consiste en un nom de producteur, le moment de la production, le prochain moment de production prévu, une liste de numéros de série de certificats et leur moment de révocation associé, et des extensions comme définies dans la [RFC5280]. La CRL est signée par le producteur. Le type prévu par la présente spécification est celui défini dans la [RFC5280].

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 objets de CMS S/MIME, des parties de corps MIME qui contiennent des objets de CMS, ou les deux.

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

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

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

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

L'Appendice A contient des informations sur les algorithmes qui étaient utilisés pour les versions antérieures de S/MIME mais ne sont plus considérés satisfaire les critères modernes de sécurité. La prise en charge de ces algorithmes peut être nécessaire pour prendre en charge des articles S/MIME historiques comme des messages ou fichiers mais NE DEVRAIENT PAS être utilisés pour de nouveaux articles.

 	1.4	Changements de S/MIME v3 à S/MIME v3.1
Ce paragraphe reflète les changements qui ont été faits lors de la livraison de S/MIME v3.1. Le langage de la RFC 2119 ("DOIT", "DEVRAIT", etc.) utilisé pour S/MIME v3 peut avoir été remplacé dans les versions ultérieures.

-	Les CRL de version 1 et version 2 DOIVENT être prises en charge.

-	Plusieurs certificats d'autorité de certification (CA, Certification Authority) avec le même sujet et clé publique, mais avec des périodes de validité qui se chevauchent, DOIVENT être pris en charge.

-	Les certificats d'attribut de version 2 DEVRAIENT être pris en charge, et les certificats d'attribut de version 1 NE DOIVENT PAS être utilisés.

-	L'utilisation de l'algorithme de résumé MD2 pour les signatures de certificat est déconseillée, et le langage de sécurité a été ajouté.

-	On a précisé l'usage des adresses de messagerie dans les certificats. Les certificats qui ne contiennent pas une adresse de messagerie n'ont pas d'exigence pour vérifier l'adresse de messagerie associée au certificat.

-	Les agents receveurs DEVRAIENT afficher les informations de certificat quand ils affichent le résultat de la vérification de signature.

-	Les agents receveurs NE DOIVENT PAS accepter une signature faite avec un certificat qui n'a pas au moins un des bits digitalSignature ou nonRepudiation établi.

-	Ajout de précisions pour l'interprétation de l'usage de clé et des extensions d'usage de clé étendu.

 	1.5	Changements de S/MIME v3.1 à S/MIME v3.2
Ce paragraphe reflète les changements qui ont été faits lors de la livraison de S/MIME v3.2. Le langage de la RFC 2119 ("DOIT", "DEVRAIT", etc.) utilisé pour S/MIME v3 peut avoir été remplacé dans les versions ultérieures.

Noter que les numéros de section mentionnés ici (par exemple, "Section 6") sont ceux de la [RFC5750].

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

-	Paragraphe 1.1 : mise à jour de la définition et de la référence d'ASN.1.

-	Paragraphe 1.3 : ajout du texte sur les RFC de v3.1.

-	Section 3 : alignement du texte sur l'adresse de messagerie avec la RFC 5280.  Mise à jour de la note pour indiquer que la limite supérieure de la IA5String emailAddress est 255 caractères. Ajout du texte sur la confrontation des adresses de messagerie.

-	Paragraphe 4.2 : ajout du texte pour indiquer comment les agents S/MIME localisent le certificat d'utilisateur correct.

-	Paragraphe 4.3 : RSA avec SHA-256 (PKCS n°1 v1.5) ajouté comme DOIT ; 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+. Mise à jour des tailles de clé et changement du pointeur sur les RFC PKIX.

-	Paragraphe 4.4.1 : Alignement sur PKIX sur l'utilisation de l'extension basicConstraints dans les certificats de CA. Précisé quelle extension est utilisée pour contraindre les entités d'extrémité à utiliser leurs clés pour effectuer des opérations de production d'autorité.

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

-	Section 6 : déplacement des références de l'Appendice A de la RFC 3850 à cette section. Mise à jour des références.

-	Section 7 : Déplacement des références de l'Appendice B à la Section 6. Mise à jour des références.

-	Appendice A : Déplacement de l'Appendice A à l'Appendice B. Ajout de l'Appendice A pour passer le traitement de certificat S/MIME v2 au statut de Historique.

 	1.6	Changements depuis S/MIME 3.2
Ce paragraphe reflète les changements qui ont été faits lors de la livraison de S/MIME v4.0. Le langage de la RFC 2119 ("DOIT", "DEVRAIT", etc.) utilisé pour S/MIME v3.2 peut avoir été remplacé par S/MIME v4.0 et peut être remplacé dans les versions ultérieures.

-	Section 3 : la prise en charge des adresses de messagerie internationalisées est exigée.

-	Paragraphe 4.3 : prise en charge obligatoire de l'algorithme de signature numérique à courbe elliptique (ECDSA, Elliptic Curve Digital Signature Algorithm) avec P-256 et de l'algorithme de signature numérique à courbe de Edwards  (EdDSA, Edwards-curve Digital Signature Algorithm) avec curve25519 [RFC8410]. Les algorithmes SHA-1 et MD5 sont marqués comme historiques, car ils ne sont plus considérés comme sûrs. Comme l'algorithme de signature numérique (DSA, Digital Signature Algorithm) a été remplacé par les versions à courbe elliptique, la prise en charge de DSA est maintenant considérée comme historique. Les limites inférieures des tailles de clé RSA ont été augmentées.

-	Appendice A : ajout de l'Appendice A sur les algorithmes qui sont maintenant considérés comme historiques.

 	2.	Options de CMS

Le format de message de CMS permet une grande variété d'options de prise en charge de contenus et d'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. La plus grande partie du format de CMS pour les messages S/MIME est définie dans la [RFC8551].

 	2.1	Liste de révocation de certificats
Les agents receveurs DOIVENT prendre en charge le format de liste de révocation de certificat (CRL, Certificate Revocation List) défini dans la [RFC5280]. Si les agents envoyeurs incluent des CRL dans les messages sortants, le format de CRL défini dans la [RFC5280] DOIT être utilisé. 

Tous les agents DOIVENT être capables d'effectuer les vérifications de révocation en utilisant les CRL comme spécifié dans la [RFC5280]. Tous les agents DOIVENT effectuer la vérification d'état de révocation en accord avec la [RFC5280]. Les agents receveurs DOIVENT reconnaître les CRL dans les messages S/MIME reçus.

Les agents DEVRAIENT mémoriser les CRL reçues dans les messages pour les utiliser dans le traitement des messages ultérieurs.

 	2.2	Choix de certificat
Les agents receveurs DOIVENT prendre en charge les certificats v1 X.509 et v3 X.509 conformément au profil de la [RFC5280]. Les certificats d'entité d'extrémité PEUVENT inclure une adresse de messagerie Internet, comme décrit à la Section 3.

Les agents receveurs DEVRAIENT prendre en charge les certificats d'attribut X.509 version 2. Voir dans la [RFC5755] les détails sur le profil pour les certificats d'attribut.

 	2.2.1	Note historique sur les certificats de CMS
Le format de message de CMS accepte un choix de formats de certificat pour les types de contenu de clé publique : PKIX, certificats étendus PKCS n° 6 [PKCS6], et certificats d'attribut PKIX.

Le format PKCS n° 6 n'est pas largement utilisé. De plus, les extensions de certificat PKIX visent la même fonction et souplesse que celles visées dans les extensions de certificat PKCS n° 6. Donc, les agents envoyeurs et receveurs NE DOIVENT PAS utiliser les certificats PKCS n° 6 étendu. Les agents receveurs DOIVENT être capables d'analyser et traiter un message contenant des certificats PKCS n° 6 étendu, bien que ignorer ces certificats soit le comportement attendu.

Les certificats d'attribut X.509 version 1 sont aussi assez peu largement mis en œuvre, et ont ont été supplantés par les certificats d'attribut de version 2. Les agents envoyeurs NE DOIVENT PAS envoyer de certificats d'attribut de version 1.

 	2.3	Certificats inclus
Les agents receveurs DOIVENT être capables de traiter un nombre arbitraire de certificats de relation arbitraire avec l'envoyeur du message et avec chaque autre dans un ordre arbitraire. Dans de nombreux cas, les certificats inclus dans un message signé peuvent représenter une chaîne de certification allant de l'envoyeur à une racine particulière. Il peut cependant y avoir des situations où les certificats dans un message signé peuvent être sans relation et inclus par facilité.

Les agents envoyeurs DEVRAIENT inclure tous les certificats pour la ou les clés publiques de l'utilisateur et les certificats de producteur associés. Cela augmente la probabilité que le receveur prévu puisse établir la confiance dans la ou les clés publiques du générateur. Ceci est particulièrement important quand on envoie un message à des receveurs qui peuvent n'avoir pas accès à la clé publique de l'envoyeur par d'autres moyens ou quand on envoie un message signé à un nouveau receveur. L'inclusion de certificats dans les messages sortants peut être omise si les objets S/MIME sont envoyés au sein d'un groupe de correspondants qui ont établi l'accès aux certificats de chacun des autres par des moyens comme un répertoire partagé ou une distribution manuelle de certificats. Les agents S/MIME receveurs DEVRAIENT être capables de traiter les messages sans certificat en utilisant une base de données ou un schéma de recherche dans un répertoire pour les trouver.

Un agent envoyeur DEVRAIT inclure au moins une chaîne de certificats jusqu'à, non incluse, une autorité de certification  (CA, certification authority) dont il pense que le receveur peut lui faire confiance comme étant d'autorité. Un agent receveur DOIT être capable de traiter un nombre arbitrairement grand de certificats et de chaînes.

Les agents PEUVENT envoyer des certificats de CA, c'est-à-dire, des certificats croisés, des certificats auto produits, et des certificats auto-signés. Noter que les agents receveurs NE DEVRAIENT PAS faire simplement confiance à tout certificat auto signé comme étant une CA valide, mais DEVRAIENT utiliser un autre mécanisme pour déterminer si c'est une CA qui devrait être de confiance. Noter aussi que quand des certificats contiennent des clés publiques de l'algorithme de signature numérique (DSA, Digital Signature Algorithm) les paramètres peuvent être situés dans le certificat racine. Cela exigerait que le receveur possède à la fois le certificat d'entité d'extrémité et le certificat racine pour effectuer une vérification de signature, et c'est un exemple valide de cas où la transmission du certificat racine peut être requise.

Les agents receveurs DOIVENT prendre en charge la chaînage fondé sur les champs de nom distinctif. D'autres méthodes de construction de chaînes de certificats PEUVENT être prises en charge.

Les agents receveurs DEVRAIENT prendre en charge le décodage des certificats d'attribut X.509 inclus dans des objets de CMS. Toutes les autres questions concernant la génération et l'utilisation des certificats d'attribut X.509 sortent du domaine d'application de la présente spécification. Une spécification qui traite de l'utilisation du certificat d'attribut est définie dans la [RFC3114].

 	3.	Utilisation des noms distinctifs pour la messagerie Internet

Les certificats d'entité d'extrémité PEUVENT contenir une adresse de messagerie Internet. Les adresses de messagerie restreintes aux caractères ASCII à 7 bits utilisent l'identifiant d'objet (OID, object identifier) pkcs-9-at-emailAddress (voir ci-dessous) et sont codés comme décrit dans la [RFC5280], paragraphe 4.2.1.6. Les noms d'adresse de message internationalisés utilisent l'OID défini dans la [RFC8398] et sont codés comme il y est décrit. L'adresse de messagerie électronique DEVRAIT être dans l'extension subjectAltName, et NE DEVRAIT PAS être dans le nom distinctif de sujet.

Les agents receveurs DOIVENT reconnaître et accepter les certificats qui ne contiennent pas d'adresse de messagerie. Il est permis aux agents de fournir un autre mécanisme pour associer une adresse de messagerie à un certificat qui ne contient pas d'adresse de messagerie, comme par l'utilisation du carnet d'adresses de l'agent, si il est disponible. Les agents receveurs DOIVENT reconnaître aussi bien les adresses de messagerie ASCII que internationalisées dans l'extension subjectAltName. Les agents receveurs DOIVENT reconnaître les adresses de messagerie dans le champ Nom distinctif dans l'attribut emailAddress de PKCS n° 9 [RFC2985] :

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

Noter que cet attribut DOIT être codé comme IA5String et a une limite supérieure de 255 caractères. La comparaison des adresses de messagerie est pleine de périls. La [RFC8398] définit la procédure pour faire la comparaison des adresses de messagerie internationalisées. Pour les adresses de messagerie ASCII, le composant domaine (côté droit du "@") DOIT être comparé en utilisant une fonction insensible à la casse. Le composant nom local (côté gauche du "@") DEVRAIT être comparé en utilisant une fonction insensible à la casse. Certains lieux peuvent effectuer d'autres transformations sur le composant de nom local avant de faire la comparaison ; cependant, un client S/MIME ne peut pas savoir quel lieu spécifique le fait.

Les agents envoyeurs DEVRAIENT faire correspondre l'adresse dans l'en-tête From ou Sender dans un message électronique à l'adresse de messagerie Internet dans le certificat du signataire. Les agents receveurs DOIVENT vérifier que l'adresse dans l'en-tête From ou Sender d'un message électronique correspond à une adresse de messagerie dans le certificat du signataire, si des adresses de messagerie sont présentes dans le certificat. Un agent receveur DEVRAIT fournir un processus de remplacement explicite du message si cette comparaison échoue ; cela pourrait être fait en affichant ou en enregistrant un message qui montre les adresses de messagerie du receveur dans le certificat ou autre détail de certificat.

Un agent receveur DEVRAIT afficher un nom de sujet ou autre détail de certificat quand il affiche une indication de succès ou d'échec de vérification de signature.

Tous les noms de sujet et de producteur DOIVENT être remplis (c'est-à-dire, pas de SEQUENCE vide) dans les certificats X.509 conformes à S/MIME, sauf que le nom distinctif (DN, distinguished name) de sujet dans un certificat d'utilisateur (c'est-à-dire, une entité d'extrémité) PEUT être une SEQUENCE vide, et dans ce cas l'extension subjectAltName va inclure l'identifiant du sujet et DOIT être marquée comme critique.

 	4.	Traitement de certificat

Les agents S/MIME ont besoin de fournir un mécanisme de restitution de certificat afin d'obtenir l'accès aux certificats pour les receveurs d'enveloppes numériques. Il y a de nombreuses façons de mettre en œuvre les mécanismes de restitution de certificat. Le service de répertoire [X.500] est un excellent exemple de mécanisme de restitution seule de certificat qui est compatible avec les noms distinctifs X.500 classiques. L'IETF a publié la [RFC8162], qui décrit un protocole expérimental pour restituer les certificats provenant du système des noms de domaine (DNS, Domain Name System). Jusqu'à ce que de tels mécanismes soient largement utilisés, leur utilité peut être limitée par le petit nombre de certificats de correspondants qui peuvent être restitués. Au minimum, pour un déploiement S/MIME initial, un agent d'utilisateur pourrait générer automatiquement un message à un receveur prévu pour demander le certificat du 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. Dans de nombreux environnements, il peut être souhaitable de lier ensemble les mécanismes de restitution/mémorisation de certificat dans une sorte de base de données de certificats. Dans sa plus simple forme, une base de données de certificats serait locale pour un utilisateur particulier et fonctionnerait d'une façon similaire à un "carnet d'adresses" qui mémorise les correspondants fréquents d'un utilisateur. De cette façon, le mécanisme de restitution de certificat serait limité aux certificats qu'un utilisateur a mémorisés (probablement de messages entrants). Une solution complète de restitution/mémorisation de certificats peut combiner deux mécanismes ou plus pour permettre la plus grande souplesse et utilité à l'utilisateur. Par exemple, un agent de messagerie Internet sûr peut revenir à vérifier dans un mécanisme de restitution de certificat centralisé pour un certificat si il ne peut pas être trouvé dans la base de données de restitution/mémorisation de certificats de l'utilisateur.

Les agents receveurs et envoyeurs DEVRAIENT fournir un mécanisme pour l'importation et l'exportation de certificats, en utilisant un message de CMS certs-only. Cela permet l'importation et l'exportation de pleines chaînes de certificats par opposition à juste un seul certificat. Ceci est décrit dans la [RFC5751].

Les agents DOIVENT traiter les certificats multiples d'autorité de certification valides contenant le même nom de sujet et les mêmes clés publiques mais avec des intervalles de validité qui se chevauchent.

 	4.1	Liste de révocation de certificats
En général, il est toujours meilleur d'obtenir les dernières informations de CRL d'une CA plutôt que de prendre les informations mémorisées dans un message entrant. Un agent receveur DEVRAIT avoir accès à un mécanisme de restitution de CRL afin d'obtenir l'accès aux informations de révocation de certificat quand il valide les chemins de certification. Un agent receveur ou envoyeur DEVRAIT aussi fournir un mécanisme pour permettre à un utilisateur de mémoriser des informations de révocation de certificat entrantes pour les correspondants de façon à garantir leur restitution ultérieure.

Les agents receveurs et envoyeurs DEVRAIENT restituer et utiliser les informations de CRL chaque fois qu'un certificat est vérifié au titre de la validation d'un chemin de certification si le certificat a déjà été vérifié dans le passé. Cependant, dans de nombreux cas (comme d'une vérification hors ligne) l'accès aux dernières informations de CRL peut être difficile ou impossible. L'utilisation d'informations de CRL, peut donc être dicté par la valeur de l'information à protéger. La valeur des informations de CRL dans un contexte particulier sort du domaine d'application de la présente spécification mais peut être gouvernée par les politiques associées à des chemins de certification particuliers.

Tous les agents DOIVENT être capables d'effectuer des vérifications de révocation en utilisant les CRL comme spécifié dans la [RFC5280]. Tous les agents DOIVENT effectuer les vérifications d'état de révocation en accord avec la [RFC5280].  Les agents receveurs DOIVENT reconnaître les CRL dans les messages S/MIME reçus.

 	4.2	Validation de chemin de certificat
La création d'un agent d'utilisateur pour sécuriser la messagerie, la validation de certificat, de CRL, et de chemin de certification devrait être largement automatisée tout en agissant au mieux des intérêts de l'utilisateur. La validation de certificat, de CRL, et de chemin DOIT être effectuée conformément à la [RFC5280] quand on valide la clé publique d'un correspondant. Ceci est nécessaire avant d'utiliser une clé publique pour fournir des services de sécurité comme de vérifier la signature, le chiffrement d'une clé de chiffrement de contenu (par exemple, RSA) ou de former une paire de clés symétriques (par exemple, Diffie-Hellman) à utiliser pour chiffrer ou déchiffrer une clé de chiffrement de contenu.

Les certificats et les CRL sont rendus disponibles à la procédure de validation de chemin de deux façons : a) les messages entrants, et b) les mécanismes de restitution de certificat et de CRL. Les certificats et les CRL dans les messages entrants ne sont pas obligés d'être dans un ordre particulier ni d'être en aucune façon en relation avec l'envoyeur ou le receveur du message (bien que dans la plupart des cas ils soient en relation avec l'envoyeur). Les certificats et CRL entrants DEVRAIENT être mis en antémémoire pour être utilisés dans la validation de chemin et facultativement mémorisés pour une utilisation ultérieure. Cette antémémoire temporaire de certificats et CRL DEVRAIT être utilisée pour augmenter tout autre mécanisme de restitution de certificat et CRL pour la validation de chemin sur les messages signés entrants.

Quand on vérifie une signature et les certificats qui sont inclus dans le message, si un attribut signingCertificate de la RFC 2634 [ESS] ou un attribut signingCertificateV2 de la RFC 5035 [ESS] est trouvé dans un message S/MIME, il DEVRA être utilisé pour identifier le certificat du signataire. Autrement, le certificat est identifié dans un message S/MIME, en utilisant soit (1) le issuerAndSerialNumber, qui identifie le certificat du signataire par le nom distinctif du producteur et le numéro de série du certificat, soit (2) le subjectKeyIdentifier, qui identifie le certificat du signataire par un identifiant de clé.

Quand on déchiffre un message chiffré, si un attribut SMIMEEncryptionKeyPreference est trouvé dans des SignedData encapsulantes, il DEVRA être utilisé pour identifier le certificat du générateur trouvé dans les OriginatorInfo. Voir dans la [RFC5652] les champs de CMS qui font référence aux certificats du générateur et du receveur.

 	4.3	Algorithmes de signature et tailles de clé de certificat et de CRL
Les certificats et listes de révocation de certificat (CRL) sont signés par le producteur du certificat. Les agents receveurs :
-	DOIVENT prendre en charge ECDSA avec courbe P-256 avec SHA-256.
-	DOIVENT prendre en charge EdDSA avec curve25519 en utilisant le mode PureEdDSA.
-	DOIVENT- prendre en charge RSA PKCS n° 1 v1.5 avec SHA-256.
-	DEVRAIENT prendre en charge le schéma de signature probabiliste RSA (RSASSA-PSS, RSA Probabilistic Signature Scheme) avec SHA-256.

Les mises en œuvre DEVRAIENT utiliser la génération déterministe du paramètre "k" pour ECDSA comme mentionné dans la [RFC6979]. EdDSA est défini pour générer ce paramètre de façon déterministe.

Voici les exigences pour les tailles de clé RSA et RSASSA-PSS pour les agents receveurs S/MIME durant la vérification de signature de certificat et de CRL :

taille de clé ≤ 2047 : NE DEVRAIT PAS (voir l'Appendice A)
2048 ≤ taille de clé ≤ 4096 : DOIT (voir les considérations sur la sécurité)
taille de clé > 4096 : PEUT (voir les considérations sur la sécurité)

Les OID d'algorithme de signature pour RSA PKCS n° 1 v1.5 et RSASSA-PSS avec SHA-256 en utilisant des clés publiques de 1024 à 3072 bits sont spécifiés dans la [RFC4055], et la définition de l'algorithme de signature se trouve dans [FIPS186-2] avec notice de changement 1.

Les OID d'algorithme de signature pour RSA PKCS n° 1 v1.5 et RSASSA-PSS avec SHA-256 utilisant des clés publiques de 4096 bits sont spécifiés dans la [RFC4055], et la définition de l'algorithme de signature se trouve dans la [RFC3447].

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

Pour ECDSA, voir les [RFC5758] et [RFC6090]. 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. Des courbes autres que la courbe P-256 PEUVENT aussi être utilisées.

Pour EdDSA, voir les [RFC8032] et [RFC8410]. 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. Des courbes autres que curve25519 PEUVENT aussi être utilisées.

 	4.4	Extensions de certificat PKIX
PKIX décrit un cadre extensible dans lequel les informations de certificat de base peuvent être étendues et décrit comment de telles extensions peuvent être utilisées pour contrôler le processus de production et de validation des certificats. Le groupe de travail LAMPS a des travaux en cours pour identifier et créer des extensions qui soient utiles dans des environnements de certification particuliers. De plus, des travaux sont activement poursuivis pour produire des certificats PKIX pour les besoins des affaires. Le présent document identifie l'ensemble minimum requis d'extensions de certificat qui ont la plus grande valeur dans l'environnement de S/MIME. La syntaxe et la sémantique de toutes les extensions identifiées sont définies dans la [RFC5280].

Les agents receveurs et envoyeurs DOIVENT traiter correctement les extensions de certificat de contraintes de base, d'usage de clé, d'identifiant de clé d'autorité, l'identifiant de clé de sujet, et de nom de remplacement de sujet quand elles apparaissent dans des certificats d'entité d'extrémité et de CA. Un mécanisme DEVRAIT exister pour traiter en douceur les autres extensions de certificat quand elles apparaissent dans des certificats d'entité d'extrémité et de CA.

Les certificats produits pour l'environnement S/MIME NE DEVRAIENT PAS contenir d'extension critique (les extensions qui ont le champ Critique réglé à VRAI) autres que celles mentionnées ici. Ces extensions DEVRAIENT être marquées comme non critiques sauf si le traitement approprié de l'extension est réputé critique pour l'interprétation correcte du certificat associé. D'autres extensions peuvent être incluses, mais ces extensions NE DEVRAIENT PAS être marquées comme critiques.

L'interprétation et la syntaxe pour toutes les extensions DOIVENT suivre la [RFC5280], sauf mention contraire.

 	4.4.1	Contraintes de base
L'extension basicConstraints sert à délimiter le rôle et la position qu'un certificat d'autorité productrice ou d'entité d'extrémité joue dans un chemin de certification.

Par exemple, les certificats produits aux CA et aux CA subordonnées contiennent une extension basicConstraint qui les identifie comme des certificats d'autorité productrice. Les certificats d'entité d'extrémité contiennent l'extension d'usage de clé qui restreint les entités d'extrémité à utiliser la clé quand elles effectuent des opérations d'autorité productrice (voir le paragraphe 4.4.2).

Conformément à la [RFC5280], les certificats DOIVENT contenir une extension basicConstraints dans les certificats de CA, et NE DEVRAIENT PAS contenir cette extension dans les certificats d'entité d'extrémité.

 	4.4.2	Extension d'usage de clé
L'extension d'usage de clé sert à limiter l'objet technique pour lequel une clé publique mentionnée dans un certificat valide peut être utilisée. Les certificats d'autorité productrice peuvent contenir une extension d'usage de clé qui restreint la clé aux certificats de signature, listes de révocation de certificat, et autres données.

Par exemple, une autorité de certification peut créer des certificats de producteur subordonné qui contiennent une extension d'usage de clé qui spécifie que la clé publique correspondante peut être utilisée pour signer des certificats d'utilisateur final et des CRL.

Si une extension d'usage de clé est incluse dans un certificat PKIX, elle DOIT alors être marquée comme critique.

Les agents S/MIME receveurs NE DOIVENT PAS accepter la signature d'un message si il a été vérifié en utilisant un certificat qui contient l'extension d'usage de clé sans au moins le bit digitalSignature ou nonRepudiation établi. Parfois S/MIME est utilisé comme transport de messages sûr pour des applications qui vont au delà de la messagerie interpersonnelle ; dans ce cas, l'application à capacité S/MIME peut spécifier des exigences supplémentaires concernant les bits digitalSignature ou nonRepudiation dans cette extension.

Si l'extension d'usage de clé n'est pas spécifiée, les clients receveurs DOIVENT présumer que les deux bits digitalSignature et nonRepudiation sont établis.

 	4.4.3	Nom de sujet de remplacement
L'extension Nom de remplacement de sujet est utilisée dans S/MIME comme moyen préféré de porter la ou les adresses de messagerie qui correspondent à l'entité pour ce certificat. Si la portion locale de l'adresse de messagerie est en ASCII, elle DOIT être codée en utilisant le CHOIX rfc822Name de type GeneralName comme décrit au paragraphe 4.2.1.6 de la [RFC5280]. Si la portion locale de l'adresse de messagerie n'est pas en ASCII, elle DOIT être codée en utilisant le CHOIX otherName du type GeneralName comme décrit à la Section 3 de la [RFC8398]. Comme le type SubjectAltName est une SEQUENCE DE GeneralName, plusieurs adresses de messagerie PEUVENT être présentes.

 	4.4.4	Extension Usage de clé étendu
L'extension Usage de clé étendu sert aussi à limiter l'objet technique pour lequel une clé publique mentionnée dans un certificat valide peut être utilisée. L'ensemble d'objets techniques pour le certificat est donc l'intersection des usages indiqués dans l'usage de clé et les extensions d'usage de clé étendu.

Par exemple, si le certificat contient une extension d'usage de clé indiquant une signature numérique et une extension d'usage de clé étendu qui inclut l'OID id-kp-emailProtection, alors le certificat peut être utilisé pour signer mais pas pour chiffrer les messages S/MIME. Si le certificat contient une extension d'usage de clé indiquant une signature numérique mais pas d'extension d'usage de clé étendu, alors le certificat peut aussi être utilisé pour signer mais pas chiffrer les messages S/MIME.

Si l'extension d'usage de clé étendu est présent dans le certificat, alors les agents S/MIME receveurs de messages interpersonnels DOIVENT vérifier qu'il contient l'OID id-kp-emailProtection ou anyExtendedKeyUsage comme défini dans la [RFC5280]. Les utilisations S/MIME autres que de messagerie interpersonnelle PEUVENT exiger la présence explicite de l'extension d'usage de clé étendu, la présence d'autres OID dans l'extension, ou les deux.

 	5.	Considérations relatives à l'IANA

Le présent document ne donne lieu à aucune action de l'IANA.

 	5.	Considérations sur la sécurité

Tous les problèmes de sécurité posés à toute application cryptographique doivent aussi être posés à un agent S/MIME. Parmi ces problèmes figurent la protection de la clé privée de l'utilisateur, empêcher diverses attaques, et aider l'utilisateur à éviter des fautes comme de chiffrer par inadvertance un message pour le mauvais receveur. La liste entière des problèmes de sécurité sort du domaine d'application du présent document, mais certains problèmes significatifs sont mentionnés ici.

Quand on traite les certificats, il y a de nombreuses situations où le traitement pourrait échouer. Parce que le traitement peut être fait par un agent d'utilisateur, une passerelle de sécurité, ou un autre programme, il n'y a pas une seule façon de traiter de telles défaillances. Ce n'est pas parce que on n'a pas fait la liste des méthodes pour traiter les défaillances que le lecteur devrait supposer qu'elles ne sont pas importantes. C'est le contraitre qui est vrai : si un certificat n'est paas prouvé valide et associé au message, le logiciel de traitement devrait prendre des mesures immédiates et remarquables pour en informer l'utilisateur final.

Certains des endroits où la vérification de signature et de certificat pourraient échouer incluent :
- aucune adresse de messagerie Internet dans un certificat ne correspond à l'envoyeur d'un message, si le certificat contient au moins une adresse de messagerie,
- aucune chaîne de certificat ne conduit à une CA de confiance,
- aucune capacité de vérifier la CRL pour un certificat n'est mise en œuvre,
- une CRL invalide a été reçue,
- la CRL à vérifier est obsolète,
- le certificat a expiré,
- le certificat a été révoqué.

Il y a certainement d'autres instances où un certificat peut être invalide, et il est de la responsabilité du logiciel de traitement de les vérifier attentivement, et de décider quoi faire si la vérification échoue.

Il est possible qu'il y ait plusieurs CRL non expirées pour une CA. Si un agent consulte les CRL pour la validation de certificat, il DEVRAIT s'assurer que la CRL la plus récemment produite pour cette CA est consultée, car un envoyeur de message S/MIME pourraient délibérément inclure une CRL plus ancienne non expirée dans un message S/MIME. Cette CRL plus ancienne pourrait ne pas inclure des certificats récemment révoqués ; ce scénario pourrait conduire un agent à accepter un certificat qui a été révoqué dans une CRL suivante.

Quand on détermine l'heure d'une vérification de validité d'un certificat, les agents doivent être attentifs à utiliser une heure fiable. Sauf si elle provient d'un agent de confiance, cette heure NE DOIT PAS être l'attribut SigningTime trouvé dans un message S/MIME. Dans la plupart des cas, l'heure utilisée DEVRAIT être l'heure courante. Des exceptions à cela pourraient être :
-	l'heure à laquelle le message a été reçu est mémorisée de manière sûre et est utilisée ultérieurement pour valider le message ;
-	l'heure dans un attribut SigningTime est trouvée dans un attribut countersignature [RFC5652] qui a été validé avec succès.

Pour la plupart des agents envoyeurs, l'attribut signingTime pourrait être délibérément réglé à une heure où l'agent receveur va (1) utiliser une CRL qui ne contient pas de révocation pour le certificat de signature ou (2) utiliser un certificat qui a expiré ou n'est pas encore valide. Cela pourrait être fait par (1) l'envoyeur du message ou (2) un attaquant qui a compromis la clé de l'envoyeur.

En plus des considérations sur la sécurité identifiées dans la [RFC5280], des précautions devraient être prises quand on traite des certificats qui n'ont pas été d'abord validés à une ancre de confiance. Des certificats pourraient être fabriqués par des sources malveillantes dans le but de monter des attaques de déni de service ou autres attaques. Par exemple, des clés choisies pour exiger un traitement cryptographique excessif, ou des listes extensives de points de distribution de CRL (CDP, CRL Distribution Point) et/ou des adresses d'accès à des informations d'autorité (AIA, Authority Information Access) dans le certificat, pourraient être utilisées pour monter des attaques de déni de service. De même, des CDP et/ou adresses d'AIA spécifiées par l'attaquant pourraient être incluses dans des certificats falsifiés pour permettre à l'origine de détecter la réception du message même si la vérification de signature échoue.

Les clés RSA et DSA de moins de 2048 bits sont maintenant considérées par de nombreux experts comme cryptographiquement non sûres (du fait des avancées de la puissance de calcul) et ne devraient plus être utilisées pour signer les certificats ou les CRL. 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 chiffrés peut exiger de traiter des certificats ou CRL signés avec des 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 l'acceptation de certificats et CRL avec de plus petites tailles de clés (par exemple, des certificats falsifiés) contre le coût d'un déni de service. Si une mise en œuvre accepte la vérification de certificats ou CRL générés avec des clés RSA et DSA de moins de 2048 bits, elle DOIT avertir l'utilisateur. Les mises en œuvre devraient envisager de fournir un plus fort avertissement pour des signatures faibles sur des certificats et CRL associés à des nouveaux messages reçus que celui fourni pour les certificats et CRL associés à des messages mémorisés précédemment. Les mises en œuvre de serveur (par exemple, les serveurs de liste de messagerie sécurisée) où les avertissements d'utilisateur ne sont pas appropriés DEVRAIENT rejeter les messages avec un chiffrement faible.

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

 	7.	Références
 	7.1	Conventions de référence
[ESS] se réfère à la [RFC2634] et la [RFC5035].
[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].
[SMIMEv3.2] se réfère aux [RFC2634], [RFC5035], [RFC5652], [RFC5750],et [RFC5751].
[SMIMEv4] se réfère aux [RFC2634], [RFC5035], [RFC5652], [RFC8551], et au présent document.

 	7.2	Références normatives

[FIPS186-2]	National Institute of Standards et Technology (NIST), "Digital Signature Standard (DSS)", FIPS Publication 186-2, janvier 2000. [avec amendement 1]. <https://csrc.nist.gov/publications/detail/fips/186/2/archive/2000-01-27>.

[FIPS186-3]	National Institute of Standards et Technology (NIST), FIPS Publication 186-3, "Digital Signature Standard (DSS)", juin 2009. <https://csrc.nist.gov/csrc/media/publications/fips/186/3/archive/2009-06-25/documents/fips_186-3.pdf>.

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

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

[RFC2985]	M. Nystrom et B. Kaliski, "PKCS n° 9 : Classes d'objet et types d'attribut choisis, version 2.0", novembre 2000, DOI 10.17487/RFC2985.

[RFC3279]	L. Bassham, W. Polk et R. Housley, "Algorithmes et identifiants pour le profil de certificat d'infrastructure de clé publique X.509 et de liste de révocation de certificat (CRL) pour l'Internet", DOI 10.17487/RFC3279, avril 2002.

[RFC3447]	J. Jonsson et B. Kaliski, "Normes de cryptographie à clés publiques (PKCS) n° 1 : Spécifications de la cryptographie RSA version 2.1", DOI 10.17487/RFC3447, février 2003. (Obsolète, remplacée par RFC8017) (Information)

[RFC4055]	J. Schaad et autres, "Algorithmes et identifiants supplémentaires pour la cryptographie RSA à utiliser dans le profil de certificat d'infrastructure de clé publique X.509 et de liste de révocation de certificat (CRL) pour l'Internet", DOI 10.17487/RFC4055, juin 2005.

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

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

[RFC5280]	D. Cooper et autres, "Profil de certificat d'infrastructure de clé publique X.509 et de liste de révocation de certificat (CRL) pour l'Internet", DOI 10.17487/RFC5280, mai 2008. (Remplace les RFC3280, RFC4325, RFC4630) (P.S. ; MàJ par RFC8398, 8399)

[RFC5652]	R. Housley, "Syntaxe de message cryptographique (CMS)", STD70, DOI 10.17487/RFC5652, 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", DOI 10.17487/RFC5750, janvier 2010. (P. S. ; remplace RFC3850; remplacée par RFC8550)

[RFC5755]	S. Farrell, R. Housley, S. Turner, "Profil de certificat d'attribut Internet pour l'autorisation", DOI 10.17487/RFC5755, janvier 2010. (Remplace RFC3281). (P. S.)

[RFC5758]	Q. Dang, S. Santesson, K. Moriarty, D. Brown, T. Polk, "Infrastructure de clés publiques X.509 sur Internet : Algorithmes et identifiants supplémentaires pour DSA et ECDSA", DOI 10.17487/RFC5758, janvier 2010. (MàJ RFC3279). (P. S.)

[RFC6979]	T. Pornin, "Utilisation déterministe de l’algorithme de signature numérique (DSA) et de l’algorithme de signature numérique à courbe elliptique (ECDSA)", DOI 10.17487/RFC6979, août 2013. (Information)

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

[RFC8398]	A. Melnikov, W. Chuang, "Adresses de messagerie électronique internationalisées dans les certificats X.509", DOI 10.17487/RFC8398, mai  2018. (P.S. ; MàJ RFC5280)

[RFC8551]	J. Schaad, B. Ramsdell, S. Turner, "Spécification du message d'extensions de messagerie Internet multi objet sûres (S/MIME) version 4.0", DOI 10.17487/RFC8551, avril 20190. (P.S. ; Remplace RFC5751)

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

 	7.3	Références pour information

[PKCS6]	RSA Laboratories, "PKCS #6: Extended-Certificate Syntax Standard", November 1993.

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

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

[RFC2313]	B. Kaliski, "PKCS n° 1 : Chiffrement RSA version 1.5", DOI 10.17487/RFC2314, 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", DOI 10.17487/RFC2315, 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", DOI 10.17487/RFC2631, 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.)

[RFC3114]	W. Nicolls "Mise en œuvre de la politique de classement d'entreprise avec l'étiquette de sécurité S/MIME", DOI 10.17487/RFC3114, mai 2002. (Info.)

[RFC3850]	B. Ramsdell, éd., "Traitement de certificat d'extensions multi-objets/sécurisées de messagerie Internet (S/MIME) version  3.1", DOI 10.17487/RFC3850, 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", DOI 10.17487/RFC3851, juillet 2004. (Obsolète, voir RFC5751)

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

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

[RFC6090]	D. McGrew, K. Igoe, M. Salter, "Algorithmes fondamentaux de cryptographie par courbe élliptique", DOI 10.17487/RFC6090, février 2011. (Info.)

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

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

[RFC8032]	S. Josefsson, I. Liusvara, "Algorithme de signature numérique Edwards-Curve", DOI 10.17487/RFC8032, janvier 2017. (Information)

[RFC8162]	P. Hoffman, J. Schlyter, "Utilisation du DNS sécurisé pour associer les certificats aux noms de domaines pour S/MIME", DOI 10.17487/RFC8162, mai 2017. (Expérimental)

[RFC8410]	S. Josefsson, J. Schaad, "Identifiants d'algorithmes Ed25519, Ed448, X25519, et X448 à utiliser dans l'infrastructure de clé publique Internet X.509", DOI 10.17487/RFC8410, août 2018. (P.S. ; MàJ par 9295)

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

[X.500]	Recommandation UIT-T X.500 / ISO/CEI 9594-1:2017, "L'annuaire - Partie 1 : aperçu général des concepts, modèles et services", 2017.<https://www.itu.int/rec/T-REC-X.500>

 	Appendice A.	Considérations historiques
 	A.1	Algorithmes de signature et tailles de clés
La validation de certificats sur des messages suffisamment historiques pose un certain nombre de problèmes. Pour cette raison, il est fortement suggéré que les agents d'utilisateurs traitent ces certificats différemment des messages courants. Ces problèmes incluent :

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

-	Les clés RSA et DSA de moins de 2048 bits sont maintenant considérées par de nombreux experts comme cryptographiquement non sûres (du fait des avancées de la puissance de calcul) 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 chiffré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.

[SMIMEv3.2] règle la limite inférieure de taille de clé suggérée pour la création et la validation à 1024 bits. [SMIMEv3.1] règle la limite inférieure à 768 bits. Avant cela, la limite inférieure de taille de clé était à 512 bits.

-	Les fonctions de hachage utilisées pour valider les signatures sur les messages historiques ne peuvent plus être considérées comme sûres (voir ci-dessous). Bien qu'il n'y ait aucune attaque pratique connue actuellement de pré-image ou de seconde pré-image contre MD5 ou SHA-1, le fait qu'ils ne soient plus considérés comme résistants aux collisions implique que les niveaux de sécurité de toute signature créée avec ces algorithmes de hachage devraient aussi être considérés comme suspects.

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

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

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

-	La prise en charge de DSA avec SHA-256 a été abandonnés dans [SMIMEv4]. DSA a été abandonné au titre d'un mouvement général de champs finis au profit de courbes elliptiques. Les problèmes relatifs au traitement de génération non déterministe du paramètre "k" ont été soulevés (voir la [RFC6979]).

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

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

 	Appendice B.	Passage du traitement de certificat S/MIME v2 au statut de Historique

Les spécifications [SMIMEv3], [SMIMEv3.1], et [SMIMEv3.2] sont rétro compatibles avec la spécification de traitement de certificat 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 [RFC2312] soit passée au statut de Historique.

 	Remerciements

Tous nos remerciements aux autres auteurs de la RFC de traitement de certificat S/MIME v2 : Steve Dusse, Paul Hoffman, et Jeff Weinstein. Sans la v2, il n'y aurait pas eu de v3, v3.1, v3.2, ni v4.0.

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 : Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Alfred Hoenes, Paul Hoffman, Russ Housley, David P. Kemp, Michael Myers, John Pawling, et Denis Pinkas.

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

 	Adresse des auteurs

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