In Hinsicht auf die Gestaltung der Infrastruktur zur Bereitstellung der Sperrinformationen – also der Sperrlistenverteilungspunkte (CRL Distribution Point, CSP) sowie der Online Responder (Online Certificate Status Protocol, OCSP) kommt die Frage auf, ob man diese über Secure Sockets Layer (SSL) bzw. Transport Layer Security (TLS) „absichern“ sollte.
Il est parfois nécessaire qu'un certificat délivré par une autorité de certification soit retiré avant sa date d'expiration. Pour ce faire, une autorité de certification tient à jour une liste de révocation. Il s'agit d'un fichier signé avec une date d'expiration relativement courte, qui est utilisé en combinaison avec le certificat pour vérifier sa validité.
Le Online Responder (Online Certificate Status Protocol, OCSP) est une autre manière de fournir des informations sur le statut de révocation des certificats. Grâce à l'OCSP, les entités qui souhaitent vérifier le statut de révocation d'un certificat ne doivent pas télécharger la liste complète de tous les certificats révoqués, mais peuvent adresser une demande ciblée au répondeur en ligne pour le certificat concerné. Pour une description plus détaillée, voir l'article "Principes de base du répondeur en ligne (Online Certificate Status Protocol, OCSP)„ .
Oft sind Unternehmen auch aufgrund von Compliance-Richtlinien angehalten, alle HTTP-basierten Verbindungen über SSL/TLS abzubilden. Somit kommt auch die Frage auf, ob und wie dies für die CDPs oder OCSP umgesetzt werden sollte, da beide Methoden auf unverschlüsseltes und somit vermeintlich unsicheres HTTP setzen.
Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.
Um diese Frage zu beantworten, werfen wir zunächst einen Blick in die einschlägigen RFCs zu diesem Thema. Für die Sperrlistenverteilpunkte wäre dies das RFC 5280:
When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced. The relying party is forced to perform an additional path validation in order to obtain the CRL required to complete the initial path validation! Circular conditions can also be created with an https URI (or similar scheme) in the authorityInfoAccess or subjectInfoAccess extensions. At worst, this situation can create unresolvable dependencies. CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes in extensions. CAs that include an https URI in one of these extensions MUST ensure that the server’s certificate can be validated without using the information that is pointed to by the URI. Relying parties that choose to validate the server’s certificate when obtaining information pointed to by an https URI in the cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess extensions MUST be prepared for the possibility that this will result in unbounded recursion.
RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Für das Online Certificate Status Protocol finden wir die entsprechende Passage im RFC 6960:
Where privacy is a requirement, OCSP transactions exchanged using HTTP MAY be protected using either Transport Layer Security/Secure Socket Layer (TLS/SSL) or some other lower-layer protocol.
RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP
Conclusion
Beide RFCs verbieten nicht, SSL/TLS zu verwenden. Das RFC 5280 warnt jedoch explizit davor. Der Grund ist folgender:
Setzt man SSL/TLS für die Sperrinformationen ein, benötigt man ein entsprechendes Zertifikat. Dieses wird wiederum Sperrinformationen beinhalten, die geprüft werden müssen, damit das Zertifikat als gültig anerkannt werden wird.
Damit schafft man sich eine (möchte man durchgehend SSL/TLS einsetzen) nicht auflösbare Abhängigkeit. Die einzige Möglichkeit, diese aufzulösen ist, dass der letzte Sperrlistenverteilungspunkt in der Kette wieder ohne HTTPS abgebildet wird.
Somit entfallen die vermeintlichen Vorteile von HTTPS in diesem Fall.
Da die Sperrinformationen sowohl bei der Verwendung von Sperrlisten als auch OCSP jedoch ohnehin durch die Zertifizierungsstelle bzw. den Onlineresponder signiert und somit vor Manipulation geschützt sind, gibt es aber auch abseits des Problems mit den unauflösbaren Abhängigkeiten keinen Grund für den Einsatz von HTTPS in diesem Fall.
Liens complémentaires :
Sources externes
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (Internet Engineering Task Force)
- RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP (Internet Engineering Task Force)
Français 
Deutsch 
English
Les commentaires sont fermés.