Why HTTP for CRL/OCSP?
Certification Authorities provide validation services (CRL/OCSP) via plain HTTP,
which often raises security concerns and the "why not HTTPS?" question.
The
information being transferred is not sensitive (although OCSP has privacy implications), and the fact that those interfaces are
exposed via HTTP instead of HTTPS is precisely due to Security concerns.
This setup is coming from the Security considerations in 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."
Therefore CAs implement HTTP endpoints for the extensions mentioned above.
Comments
Post a Comment