Groupe de travail Réseau	P. Gutmann, University of Auckland	
Request for Comments : 3274	juin 2002	
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle	

Type de contenu Données compressées pour la syntaxe de message cryptographique (CMS)

Statut du présent Mémo
La présente RFC spécifie un protocole de normalisation pour la communauté Internet et appelle à des discussions et suggestions pour son amélioration. Prière de se reporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémo n’est pas soumise à restriction.

Déclaration de Copyright
Copyright (C) The Internet Society (2002).  Tous droits réservés.

Résumé
Le présent document définit un format pour utiliser des données compressées comme type de contenu de syntaxe de message cryptographique (CMS, Cryptographic Message Syntax). La compression de données avant la transmission procure un certain nombre d'avantages, parmi lesquels l'élimination des données redondantes qui pourraient aider à une attaque, l'accélération du traitement par la réduction de la quantité de données à traiter aux étapes ultérieures (telles que la signature ou le chiffrement), et la réduction de la taille globale du message. Bien qu'il y ait eu des propositions d'ajout de la compression à d'autres niveaux (par exemple au niveau MIME ou SSL), elles ne règlent pas le problème de la compression du contenu CMS sauf si la compression est fournie par un moyen externe (par exemple en entremêlant MIME et CMS).

1.	Introduction

Le présent document décrit un type de contenu de données compressées pour CMS. Ceci est mis en œuvre comme un nouveau type ContentInfo et est une extension aux types actuellement définis dans CMS [RFC2630]. Les mises en œuvre de CMS DEVRAIENT inclure la prise en charge du type de contenu CompressedData.

Le format des messages est décrit en ASN.1 [ASN1].

Dans le présent document, les mots clé "DOIT", "NE DOIT PAS", "EXIGE", "DEVRAIT" NE DEVRAIT PAS", "RECOMMANDE", "NON RECOMMANDE", "PEUT", et "FACULTATIF" doivent être interprétés comme décrit dans le BCP 14, RFC 2119.

1.1	Type de contenu Données compressées

Le type de contenu compressed-data consiste en un type quelconque de contenu, compressé en utilisant un algorithme spécifié. L'identifiant d'objet suivant identifie le type de contenu des données compressées :

id-ct-compressedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
        us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 9 }

Le type de contenu compressed-data doit avoir un type ASN.1 CompressedData :

CompressedData ::= SEQUENCE {
	version CMSVersion,
	compressionAlgorithm CompressionAlgorithmIdentifier,
	encapContentInfo EncapsulatedContentInfo
	}

Les champs du type CompressedData ont la signification suivante :

version est le numéro de version de la syntaxe. Il DOIT être 0. Les détails du type CMSVersion sont exposés au paragraphe 10.2.5 de la [RFC2630], CMS.

compressionAlgorithm est un identifiant d'algorithme de compression, comme défini à la Section 2.

encapContentInfo est le contenu qui est compressé. Les détails du type EncapsulatedContentInfo sont exposés au paragraphe 5.2 de CMS [RFC2630].

Les mises en œuvre DEVRAIENT utiliser l'attribut SMIMECapabilities pour indiquer leur capacité à traiter les types de contenu compressés. Les détails de SMIMECapabilities sont exposés au paragraphe 2.5.2 de MSG [RFC2633].

Une capacité SMIME de compression comporte l'AlgorithmIdentifier pour l'algorithme de compression pris en charge. Dans le cas de l'algorithme spécifié dans le présent document, il s'agit de id-alg-zlibCompression, comme précisé à la Section 2. Autrement, l'utilisation de la compression peut être réglée par un arrangement préalable (par exemple au titre d'un profil d'interopérabilité).

La séquence SMIMECapability qui représente la capacité à traiter le contenu compressé avec l'algorithme identifié par id-alg- zlibCompression DOIT être codé en DER selon la chaîne hexadécimale suivante :

30 0D 06 0B 2A 86 48 86 F7 0D 01 09 10 03 08

(mais voir aussi la note de mise en œuvre du paragraphe 2.1).

2.	Types de compression

Les mises en œuvre de CMS qui prennent en charge le type de contenu CompressedData DOIVENT inclure la prise en charge de l'algorithme de compression ZLIB [RFC1950] [RFC1951], qui est librement disponible, portable et d'une mise en œuvre efficace qui fait référence. L'identifiant d'objet suivant identifie ZLIB :

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

Cet algorithme n'a pas de paramètres. Le champ paramètres DEVRAIT être codé comme omis, mais PEUT être codé comme NULL (voir la note de mise en œuvre du paragraphe 2.1).

2.1	Notes de mise en œuvre

ZLIB permet un nombre de niveaux de compression allant de bonne compression mais lente, à moins bonne compression mais rapide. Le niveau de compression est toujours compatible avec l'algorithme de décompression, de sorte qu'il n'est pas besoin de spécifier le niveau de compression comme paramètre de l'algorithme.

Il y a deux codages possibles pour le champ paramètres ZLIB null qui viennent du fait que lorsque la syntaxe de 1988 pour AlgorithmIdentifier a été traduite dans la syntaxe de 1997, le FACULTATIF associé au paramètre AlgorithmIdentifier a été perdu. Il a été récupéré plus tard via un rapport de défaut, mais à ce moment, tout le monde pensait que les paramètres d'algorithme étaient obligatoires. À cause de cela, certaines mises en œuvre coderont les paramètres nuls comme un élément ASN.1 NULL et certaines les omettent entièrement (voir par exemple la Section 12 de CMS [RFC2630]). Bien que le codage correct soit d'omettre le champ paramètres, les mises en œuvre peuvent rencontrer des codages qui utilisent un élément ASN.1 NULL pour les paramètres.

3.	Considérations pour la sécurité

La présente RFC n'est pas concernée parla sécurité, excepté par le fait que la compression des données avant le chiffrement peut améliorer la sécurité fournie par les autres étapes de traitement en réduisant la quantité du libellé connu disponible pour un attaquant. Cependant, les mises en œuvre devraient être conscientes des menaces possibles contre la sécurité en combinant du matériel sensible à la sécurité avec des données éventuellement douteuses avant la compression et le chiffrement. Ceci parce que des informations sur les données sensibles peuvent être inférées de la connaissance des données douteuses et du taux de compression.

4.	Considérations relatives à l'IANA

Le type de contenu CompressedData et les algorithmes de compression sont identifiés par des identifiants d'objet (OID). Les OID ont été alloués à partir d'un arc fourni par RSA Security au groupe de travail S/MIME. Si des algorithmes de compression additionnels devaient être introduits, les défenseurs de tels algorithmes devraient allouer les OID nécessaires à partir de leurs propres arcs. Aucune action de l'IANA n'est nécessaire pour le présent document ou une de ses futures mises à jour.

Références

[ASN1]	Recommandation UIT-T X.208 : Spécification de la Notation de syntaxe abstraite n° 1 (ASN.1), 1988.
[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, RFC 2119, mars 1997.
[RFC1950]	P. Deutsch et J-L Gailly, "Spécification du format ZLIB de données compressées, version 3.3", RFC 1950, mai 1996.
[RFC1951]	P. Deutsch, "Spécification du format DEFLATE de données compressées, version 1.3", RFC 1951, mai 1996.
[RFC2630]	R. Housley, "Syntaxe de message cryptographique", RFC 2630, juin 1999.
[RFC2633]	B. Rmasdell, "Spécification de message S/MIME version 3", RFC 2633, juin 1999.

Appendice A	Module ASN.1

CompressedDataContent
     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
       smime(16) modules(0) compress(11) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS
     CMSVersion, EncapsulatedContentInfo FROM CryptographicMessageSyntax
       { iso(1) member-body(2) us(840) rsadsi(113549)
         pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
     AlgorithmIdentifier FROM AuthenticationFramework
       { joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 3 };

CompressedData ::= SEQUENCE {
     version CMSVersion,	-- Toujours réglé à 0
     compressionAlgorithm CompressionAlgorithmIdentifier,
     encapContentInfo EncapsulatedContentInfo
     }

CompressionAlgorithmIdentifier ::= AlgorithmIdentifier

-- Identifiants d'algorithme

id-alg-zlibCompress OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 8 }

-- Identifiants d'objet Type de contenu

id-ct-compressedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 9 }

END

Adresse de l'auteur

Peter Gutmann
University of Auckland
Private Bag 92019
Auckland, New Zealand
mél : pgut001@cs.auckland.ac.nz

Déclaration de copyright

Copyright (C) The Internet Society (2002). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent et paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de copyright ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de copyright définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et LE CONTRIBUTEUR, L’ORGANISATION QU’IL OU ELLE REPRÉSENTE OU QUI LE/LA FINANCE (S’IL EN EST), LA INTERNET SOCIETY ET LA INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES, EXPRIMÉES OU IMPLICITES, Y COMPRIS MAIS NON LIMITÉES À TOUTE GARANTIE QUE L’UTILISATION DES INFORMATIONS CI-ENCLOSES NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.

Remerciement
Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.