Private Certificate Validation Using Segmented CRLs
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In Public Key Infrastructure (PKI), relying parties face challenges in verifying the status of digital certificates across different domains, particularly when revocation requests are submitted from a different domain than the issuing Certificate Authority, leading to potential untrustworthy transactions and susceptibility to denial of service attacks due to delays in revocation processing.
Innovation Solution
Implementing a private certificate status list managed by the relying party domain, which allows for independent validation of digital certificates against a private Certificate Revocation List (CRL) separate from the public CRL managed by the issuing CA, using a Private CRL (P-CRL) and Private CRL Distribution Point (P-CRL-DP) extension to ensure timely and secure validation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If relying parties use public CRL managed by issuing CA for certificate validation, then certificate validation follows standard PKI procedures, but there are delays in revocation processing when revocation requests are submitted from different domains, leading to potential untrustworthy transactions
Solution Approach 1:
The patent divides the certificate validation process into two independent segments: (1) public CRL validation against the issuing CA's public CRL, and (2) private CRL validation against the relying party domain's private P-CRL. This segmentation allows simultaneous execution of both validation paths, with the private P-CRL providing immediate revocation status without waiting for public CRL updates, thereby reducing overall validation time while maintaining reliability
Solution Approach 2:
The relying party domain pre-generates and maintains a private Certificate Revocation List (P-CRL) containing revocation information before it is published in the public CRL by the issuing CA. This preliminary action ensures that revocation status is available immediately within the relying party domain, eliminating the delay caused by waiting for public CRL updates while maintaining validation reliability
2Reliability
If relying parties wait for timely revocation updates from issuing CA, then certificate status accuracy is maintained, but transactions may be delayed or denied during the waiting period, increasing susceptibility to denial of service attacks
Solution Approach 1:
The patent introduces a private P-CRL as an intermediary validation mechanism that operates independently of the public CRL update process. The private P-CRL serves as a local cache or mirror of revocation information that can be updated and validated immediately within the relying party domain, allowing transactions to proceed without waiting for public CRL updates while maintaining certificate status accuracy through cryptographic verification of the P-CRL signature
3Reliability
If relying parties implement independent validation against private P-CRL, then timely detection of compromised certificates is achieved, but system complexity increases due to additional validation infrastructure
Solution Approach 1:
The patent merges the public CRL validation and private P-CRL validation into a unified certificate validation process. The validation logic is integrated to execute both validation paths sequentially or in parallel, combining their results to determine final certificate validity. This merging approach consolidates the infrastructure requirements and simplifies the overall system architecture while maintaining the ability to detect compromised certificates timely through the private P-CRL
Data Source
AI summary
Methods and apparatuses for validating the status of digital certificates include a relying party receiving at least one digital certificate and determining if the at least one digital certificate is to be validated against a private certificate status database. The relying party accesses the private certificate status database and cryptographically validates the authenticity of data in the private certificate status database. The relying party also validates the at least one digital certificate based on information in at least one of the private certificate status database and a public certificate status database.