Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
Les Internet-Drafts sont signés
suivant les règles du RFC 5485, afin qu'une
lectrice ou un lecteur puissent vérifier qu'un Internet-Draft n'a pas été
modifié en cours de route. Ce nouveau RFC
modifie légèrement le RFC 5485 sur un seul
point : la signature d'Internet-Drafts qui sont écrits en
Unicode.
En effet, depuis le RFC 7997, les
RFC ne sont plus forcément en
ASCII, ils peuvent intégrer des caractères
Unicode. Le premier RFC publié avec ces caractères
a été le RFC 8187, en septembre 2017. Bientôt, cela sera également
possible pour les Internet-Drafts. Cela affecte forcément les règles de
signature, d'où cette légère mise à
jour.
Le RFC 5485 normalisait l'utilisation de
CMS (RFC 5652) pour
le format des signatures. Vous pouvez télécharger ces signatures sur
n'importe lequel des sites
miroirs. CMS utilise ASN.1,
avec l'obligation d'utiliser l'encodage
DER, le seul encodage d'ASN.1 qui ne soit
pas ambigu (une seule façon de représenter un texte).
Les Internet-Drafts sont actuellement tous en texte
brut, limité à ASCII. Mais cela
ne va pas durer (RFC 7990). Les signatures des
Internet-Drafts sont détachées de l'Internet-Draft (section 2 de notre RFC), dans un fichier portant le même
nom auquel on ajoute l'extension .p7s
(RFC 5751). Par exemple avec wget, pour
récupérer un Internet-Draft et sa signature :
% wget https://www.ietf.org/id/draft-bortzmeyer-dname-root-05.txt
% wget https://www.ietf.org/id/draft-bortzmeyer-dname-root-05.txt.p7s
(Ne le faites pas avec un
Internet-Draft trop récent, les signatures
n'apparaissent qu'au bout de quelques jours, la clé privée n'est pas
en ligne.)
La signature est au format CMS (RFC 5652). Son adaptation aux RFC et Internet-Drafts est
normalisée dans le RFC 5485. Le champ
SignedData.SignerInfo.EncapsulatedContentInfo.eContentType
du CMS identifie le type d'Internet-Draft signé. Les valeurs
possibles figurent dans un registre
IANA. Il y avait déjà des valeurs comme
id-ct-asciiTextWithCRLF
qui identifiait
l'Internet-Draft classique en texte brut en ASCII, notre RFC ajoute (section
5) id-ct-utf8TextWithCRLF
(texte brut en
UTF-8),
id-ct-htmlWithCRLF
(HTML) et id-ct-epub
(EPUB). Chacun de ces types a un
OID, par exemple le texte brut en UTF-8
sera 1.2.840.113549.1.9.16.1.37
.
Maintenant, passons à un morceau délicat, la canonicalisation
des Internet-Drafts. Signer
nécessite de canonicaliser, autrement, deux textes identiques aux
yeux de la lectrice
pourraient avoir des signatures différentes. Pour le texte brut en
ASCII,
le principal problème est celui des fins de ligne, qui peuvent
être représentées différemment selon le système
d'exploitation. Nous utilisons donc la
canonicalisation traditionnelle des fichiers texte sur l'Internet,
celle de FTP : le saut de ligne est
représenté par deux caractères, CR et
LF. Cette forme est souvent connue sous le
nom de NVT (Network
Virtual Terminal) mais, bien que très ancienne, n'avait
été formellement décrite qu'en 2008, dans l'annexe B du RFC 5198, qui traitait pourtant un autre sujet.
Pour les Internet-Drafts au format XML, notre RFC
renvoie simplement au W3C et à sa norme
XML, section 2.11 de la cinquième
édition, qui dit qu'il faut translating both the
two-character sequence #xD #xA and any #xD that is not followed by
#xA to a single #xA character. La canonicalisation
XML (telle que faite par xmllint
--c14n
) n'est pas prévue.
Les autres formats ne subissent aucune opération particulière
de canonicalisation. Un fichier EPUB, par
exemple, est considéré comme une simple suite d'octets. On notera que le texte brut en
Unicode ne subit pas de normalisation Unicode. C'est
sans doute à cause du fait que le RFC 7997,
dans sa section 4,
considère que c'est hors-sujet. (Ce qui m'a toujours semblé une
drôle d'idée, d'autant plus qu'il existe une norme Internet sur la
canonicalisation du texte brut en Unicode, RFC 5198, qui impose la normalisation
NFC.)
À l'heure actuelle, les Internet-Drafts sont signés, les outils doivent
encore être adaptés aux nouvelles règles de ce RFC, mais elles
sont simples et ça ne devrait pas être trop dur. Pour vérifier les
signatures, la procédure (qui est documentée)
consiste d'abord à installer le logiciel
de canonicalisation :
% wget https://www.ietf.org/id-info/canon.c
% make canon
Puis à télécharger les certificats
racine :
% wget https://www.ietf.org/id-info/verifybundle.pem
Vous pouvez examiner ce groupe de certificats avec :
% openssl crl2pkcs7 -nocrl -certfile verifybundle.pem | openssl pkcs7 -print_certs -text
Téléchargez ensuite des
Internet-Drafts par exemple en
https://www.ietf.org/id/
:
% wget https://www.ietf.org/id/draft-ietf-isis-sr-yang-03.txt
% wget https://www.ietf.org/id/draft-ietf-isis-sr-yang-03.txt.p7s
On doit ensuite canonicaliser l'
Internet-Draft :
% ./canon draft-ietf-isis-sr-yang-03.txt draft-ietf-isis-sr-yang-03.txt.canon
On peut alors vérifier les signatures :
% openssl cms -binary -verify -CAfile verifybundle.pem -content draft-ietf-isis-sr-yang-03.txt.canon -inform DER -in draft-ietf-isis-sr-yang-03.txt.p7s -out /dev/null
Verification successful
Si vous avez à la place :
Verification failure
139818719196416:error:2E09A09E:CMS routines:CMS_SignerInfo_verify_content:verification failure:../crypto/cms/cms_sd.c:819:
139818719196416:error:2E09D06D:CMS routines:CMS_verify:content verify error:../crypto/cms/cms_smime.c:393:
c'est sans doute que vous avez oublié l'option
-binary
.
Si vous trouvez la procédure compliquée, il y a un script qui
automatise tout ça idsigcheck
:
% ./idsigcheck --setup
% ./idsigcheck draft-ietf-isis-sr-yang-03.txt
Si ça vous fait
bad interpreter: /bin/bash^M
,
il faut recoder les sauts de ligne :
% dos2unix idsigcheck
dos2unix: converting file idsigcheck to Unix format...
Ce script appelle OpenSSL mais pas avec les bonnes options à
l'heure actuelle, vous risquez donc d'avoir la même erreur que ci-dessus.