Aller au contenu principal

RFC 8555 — Résumé des chapitres 9 à 12

Note : Ce document fournit un résumé des points clés des chapitres 9 à 12 de la RFC 8555. Pour les détails techniques complets, veuillez consulter le document officiel RFC 8555.

9. Considérations IANA​

9.1 Enregistrement de type de média​

  • application/pem-certificate-chain : Format PEM pour les chaînes de certificats

9.2 URI Well-Known​

  • /.well-known/acme-challenge : Chemin standard pour le défi HTTP

9.3 Champs d'en-tête HTTP​

  • Replay-Nonce : Champ d'en-tête nonce anti-relecture

9.4-9.5 Paramètres d'en-tête JWS​

  • url : Paramètre URL dans JWS
  • nonce : Paramètre nonce dans JWS

9.6 Espace de noms URN​

  • urn:ietf:params:acme : Espace de noms URN pour le protocole ACME

9.7 Nouveaux registres​

L'IANA a créé les registres suivants pour ACME :

  1. Account Object Fields (Champs d'objet de compte)
  2. Order Object Fields (Champs d'objet de commande)
  3. Authorization Object Fields (Champs d'objet d'autorisation)
  4. Error Types (Types d'erreurs)
  5. Resource Types (Types de ressources)
  6. Directory Metadata Fields (Champs de métadonnées du répertoire)
  7. Identifier Types (Types d'identifiants)
  8. Validation Methods (Méthodes de validation)

10. Considérations de sécurité​

10.1 Modèle de menace​

Les deux principaux objectifs de sécurité d'ACME :

  1. Seule l'entité contrôlant un identifiant peut obtenir une autorisation pour cet identifiant
  2. Après autorisation, l'autorisation d'une clé de compte ne peut pas être utilisée de manière abusive par un autre compte

Canaux de communication :

  • Canal ACME : Requêtes HTTPS entre le client et le serveur
  • Canal de validation : Canal par lequel le serveur effectue les requêtes de validation

10.2 Intégrité des autorisations​

Liaison de clé : Tous les défis lient la clé privée du compte aux requêtes de validation via l'autorisation de clé.

Attaques potentielles :

  • Attaque MitM : Les CDN ou proxys inverses peuvent devenir des intermédiaires
  • Attaques DNS : Un attaquant peut influencer la validation via le détournement DNS
  • Risques des hébergeurs : Les fournisseurs d'hébergement peuvent falsifier la validation

Mesures défensives :

  • Utiliser des résolveurs avec validation DNSSEC
  • Interroger le DNS depuis plusieurs emplacements réseau
  • Appliquer des protections DNS (comme DNS0x20)

10.3 Considérations sur le déni de service​

Les CA devraient mettre en œuvre :

  • Des limites de débit
  • Des quotas de ressources
  • Des délais d'expiration pour les requêtes de validation

10.4 Falsification de requête côté serveur (SSRF)​

Le défi HTTP-01 peut être utilisé pour des attaques SSRF. Les CA devraient :

  • Rejeter les adresses IP privées
  • Limiter les redirections
  • Définir des délais d'expiration raisonnables

10.5 Considérations de politique des CA​

Les CA devraient établir des politiques concernant :

  • Le choix des méthodes de validation
  • La durée de validité des certificats
  • Les conditions de révocation

11. Considérations opérationnelles​

11.1 Sélection des clés​

Types de clés recommandés :

  • ECDSA P-256 ou P-384
  • RSA 2048 bits ou plus

11.2 Sécurité DNS​

Lors de l'utilisation du défi DNS-01 :

  • S'assurer que l'infrastructure DNS est sécurisée
  • Envisager l'utilisation de DNSSEC
  • Protéger les interfaces de gestion DNS

11.3 Entropie des jetons​

Les jetons de défi doivent avoir une entropie suffisante :

  • Au moins 128 bits d'entropie
  • Utiliser un générateur de nombres aléatoires cryptographiquement sécurisé

11.4 Chaînes de certificats malformées​

Les clients devraient :

  • Vérifier l'intégrité de la chaîne de certificats téléchargée
  • Vérifier la période de validité des certificats
  • Valider le chemin de confiance de la chaîne de certificats

12. Références​

12.1 Références normatives (liste partielle)​

  • RFC2119 : Définition des mots-clés (MUST, SHOULD, MAY, etc.)
  • RFC5280 : Certificats X.509 et configuration CRL
  • RFC7515 : JSON Web Signature (JWS)
  • RFC7518 : JSON Web Algorithms (JWA)
  • RFC8259 : Format de données JSON
  • RFC2818 : HTTPS
  • RFC3339 : Format de date et d'heure
  • RFC7807 : Détails de problème pour les API HTTP

12.2 Références informatives (liste partielle)​

  • RFC3552 : Guide des considérations de sécurité pour les protocoles Internet
  • RFC6844 : Enregistrement de ressource DNS CAA (Certification Authority Authorization)
  • RFC7525 : Recommandations pour l'utilisation sécurisée de TLS et DTLS

Annexes​

Remerciements (Acknowledgements)​

Le développement de la RFC 8555 a bénéficié des contributions de nombreux membres de la communauté IETF.

Adresses des auteurs (Authors' Addresses)​

Auteurs principaux :

  • Richard Barnes (Cisco)
  • Jacob Hoffman-Andrews (EFF)
  • Daniel McCarney (Let's Encrypt)
  • James Kasten (University of Michigan)

Ressources connexes​

Dernière mise à jour le