Browse Prior Art Database

PRIORITIZING OCSP RESPONSES

IP.com Disclosure Number: IPCOM000126836D
Publication Date: 2005-Aug-15
Document File: 1 page(s) / 8K

Publishing Venue

The IP.com Prior Art Database

Abstract

System and Method for Prioritizing Status Responses Based on Trust Using various certificate status protocols, it is found that certain situations will arise where the inventor(s) want(s) to prioritize the results from each protocol and server in such a manner as to choose the best one. The current device expects only one status back from the MDS and as such, one is required to pick the best one on the MDS. To solve this problem, the inventor(s) created two levels of priorities with respect to the status returned from each protocol and server. The first level is based on the actual status. Priority of each value is the ordering of: UNKNOWN, GOOD, and REVOKED. If they have the same status, then one goes to the second level. This level indicates that trust that one associates with the source of that status. The inventors(s) came up with four possible values, which are in terms of priority: OCSP with Issuer, CRL Verified, CRL Unverified, OCSP Stand Alone. OCSP with Issuer indicates that the response came from an OCSP server where the issuing certificate was the same as the issuer of the certificate in which we are checking the status. CRL Verified means that a CRL was downloaded, and the signature on the CRL was verified. CRL Unverified is the same as CRL Verified, except that the signature was not verified (not because the verification failed, but because user does not have the issuer’s key). OCSP Stand Alone indicates that the OCSP response came from a server that is unrelated to the certificate in question.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 92% of the total text.

Page 1 of 1

            PRIORITIZING OCSP RESPONSES System and Method for Prioritizing Status Responses Based on Trust Disclosed Anonymously

Using various certificate status protocols such as OCSP and CRL, it is found that certain situations will arise where the inventor(s) want(s) to prioritize the results from each protocol and server in such a manner as to choose the best one.

The current device expects only one status back from a Mobile Data Service (MDS) and as such, one is required to pick the best one on the MDS. To solve this problem, the inventor(s) created two levels of priorities with respect to the status returned from each protocol and server. The first level is based on the actual status.

Priority of each value is the ordering of: UNKNOWN, GOOD, and REVOKED. If they have the same status, then one goes to the second level. This level indicates that trust that one associates with the source of that status. The inventors(s) came up with four possible values, which are in terms of priority: OCSP with Issuer, CRL Verified, CRL Unverified, OCSP Stand Alone.

OCSP with Issuer indicates that the response came from an OCSP server where the issuing certificate was the same as the issuer of the certificate in which we are checking the status. CRL Verified means that a CRL was downloaded, and the signature on the CRL was verified. CRL Unverified is the same as CRL Verified, except that the signature was not verified (not because the verification failed, but because user does not have t...