Certificate Validation Method with Extension of Certificate Status Assertion Lifetime
Original Publication Date: 2015-Jul-16
Included in the Prior Art Database: 2015-Jul-16
Metke, Tony: INVENTOR [+2]
A method of extending a certificate status lifetime which relies on a set of conditions that when satisfied allow a service provider to extend the age of a certificate status assertion by an amount less than or equal to a preset threshold. In one embodiment the length of the threshold is extended proportionally to the duration during which the said conditions are met. Specifically, we propose a method of allowing a service provider to accept a certificate as valid if the signature on the certificate itself can be validated, the certificate issuer is trusted, the certificate has not expired, and the certificate status lifetime is current or expired but the time since the certificate status has expired is less than a threshold and one of the following is true, the service provider cannot reach the certificate status server, or the service provider has been administratively put into disaster mode, or both of the above are true. In the event that a disaster continues for an extended duration, it is convenient for the threshold to automatically be extended. This would allow the system to operate without requiring the users to obtain new certificate status assertions, or without requiring an authorized administrator from going around to various locations and manually extending the threshold values. It is also unwise to simply begin with lengthy threshold values. This would allow a advisory to trick the service provider into accepting very old certificate status assertions by simply brining down the link between the service provider and the certificate status server. Finally an automatically extending threshold would allows system administrators to issue relatively short lived certificate status assertions during normal times but treat those assertions as though they had a longer lifetime during disasters. One way of calculating the threshold duration is to use the following formula. Threshold = ( Disaster Duration * A ) + T1 Where; Disaster Duration is the amount of time since the service provider last transitioned to disaster mode, A is a preconfigured constant (between 0 and 1), and T1 is a preconfigured constant (greater than 0). Note that A, B and T1 may be system wide constants or they may be determined by various certificate or certificate status assertion attributes. The units of the Disaster Duration and T1 would normally be in Days, and the value A is a unit-less number. By setting A to 1, a certificate status assertion which was valid at the time at which the service provider entered disaster mode would remain valid for the duration of the disaster. By setting A to 0, the certificate status assertion is extended for a fixed time equal to T1 irrespective of the duration of the disaster. Notice that we never extend the lifetime of the certificates themselves. Such a behavior would either result in unnecessary complexity of the PKI (such as keeping revoked certificates on the CRL until the PKI is sure that no entity would accept this certificate any longer), or unnecessary and excessive risk of not being able to determine if a certificate has been revoked. Instead we only extend the lifetime of the certificate status assertion, which does not incur the same level or risk. Indeed this method does incur some additional level of risk. However, some risk must be incurred if the authoritative certificate status server is not reachable, and the service is to be provided. Other methods of enabling users to access the service providers during the disaster might incur much higher risk, such as lowering the authentication requirements by opening the system of using a common credential. This method provides a good balance between increased risk and availability in the face of a wide spread long lasting disaster.
By Author’s Tony Metke, and Steve Gilbert
Motorola Solutions, Inc.
A method of extending a certificate status lifetime which relies on a set of conditions that when satisfied allow a service provider to extend the age of a certificate status assertion by an amount less than or equal to a preset threshold. In one embodiment the length of the threshold is extended proportionally to the duration during which the said conditions are met.
When large networks experience a significant number of component failures, such as might occur during a disaster or power outage, it not uncommon for portions of the original network to continue to operate while being segmented from other portions of the network. Traditional means of avoiding such partitioning involve implementing multiple redundant links. However, if the disaster is large enough network partitioning is unavoidable.
When partitioning occurs various users may be able to access resources that are available within the partition to which they are connected, but not to other resources. Some of these resources may rely on Authentication Servers or Identity Management servers not located in the same partition of the user. This would almost certainly be the case when the user is attempting to access a resource from a visited agency.
A system is needed that will allow users or devices to access network resources when the user/device and the resources are separated from the needed authentication server (AS).
Existing means of solving this problem rely on the reachability of some type of AS. Whether the authentication protocol is based on EAP, RADIUS, Kerberos, EPS-AKA or SMAL, etc., in each case the user/device provides a credential which is verified by an AS. If the AS is not reachable the credential cannot be verified.
Certificate based authentication such as TLS offer a potential path to a solution to this problem. Certificate based authentication provides a credential that can potentially be verified without requiring an AS to be involved. Further a digital certificate can include roles and other attributes that can be used by the service provider to make an authorization decision for the requested service. Traditionally the service provider would need to verify the revocation status of the certificate before trusting the validity of the certificate, however methods to address this also exist such as OSCP Stapling and SCVP Stapling. These methods allow a certificate subject (user of device) to obtain a certificate status assertion from an authorized server and present it at a later time with the certificate, so that the service provider will not need to obtains certificate status at the time the subject is presenting its certificate. These assertions are of course signed by the trusted server. To improve the security of such a feature the lifetime of the certificate status assertions is typically ke...