Certificate Revocation List (CRL) - Redirect HTTP -> HTTPS

CIE
1

L’indirizzo presente nei CDP di certificati prodotti dall’issuer

C = IT
O = Ministero dell’Interno
OU = Direz. Centr. per i Servizi Demografici - CNSD
CN = Issuing sub CA for the Italian Electronic Identity Card - SUBCA002

è attualmente http://ldap.cie.interno.gov.it/ciesubca002.crl.

Tuttavia, quell’indirizzo è, in realtà, un redirect all’indirizzo https://ldap.cie.interno.gov.it/ciesubca002.crl. Notare la “s” in più nel protocollo.

Perché ritengo non sia corretto:

  1. effettuare un redirect automatico da HTTP a HTTPS o viceversa è tipicamente considerato un problema di sicurezza. Ad esempio, le API standard di Java lo impediscono, mentre ovviamente si può fare per il medesimo protocollo;
  2. le normative relative ai certificati X509 indicano di utilizzare il protocollo HTTP invece che HTTPS, anche concettualmente per evitare situazioni uovo-gallina nella validazione del certificato SSL, con ricorsioni “infinite”. Il fatto che sia HTTP, ma diventi HTTPS mi sembra solo un modo per aggirare la questione:

ETSI EN 319 412-2 V2.1.1 (2016-02) (https://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.01.01_60/en_31941202v020101p.pdf):

"At least one of the present references shall use either http (http://) IETF RFC 7230-7235 [3] or ldap (ldap://) IETF
RFC 4516 [4] scheme. "

RFC 5280 (https://www.rfc-archive.org/getrfc.php?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."

CNS (https://www.agid.gov.it/sites/default/files/repository_files/documentazione_trasparenza/strutturacertificatoautenticazionecns_v1.1_.pdf)

“Lo schema da utilizzare per l’URI DEVE essere l’http oppure l’ldap (IETF RFC 1778 [2] e
RFC 2255 [5]) e consentire il download anonimo della CRL.”

  1. è la prima volta in circa 15 anni che mi capita un indirizzo di CRL che si comporti in questo modo, quindi già questo può essere un indicatore di una pratica sbagliata.

Stesso discorso varrebbe per il protocollo LDAP.