Certificate and Validation Authorities Certificate and Validation Authorities

  • Slides: 27
Download presentation
Certificate and Validation Authorities

Certificate and Validation Authorities

Certificate and Validation Authorities • • A certificate authority (CA) is an independent trusted

Certificate and Validation Authorities • • A certificate authority (CA) is an independent trusted third party that issues and maintains digital certificates. Online business transactions also require quick and reliable confirmation that – a certificate is valid. – It was issued to the appropriate entity. – It grants permissions appropriate to the application. • • Certificate can be accept with confidence. A validation authorities (VA) can perform these functions. Exact functional descriptions and boundaries of a CA are still debated topic that's undergoing constant definition and understanding. This is primarily due to the fact that any aspect of the CA can also be outsourced, – Should be treated as a separate entity, which changes the trust relationship.

Certificate and Validation Authorities Figure 5. 1 attempts to show the interaction between the

Certificate and Validation Authorities Figure 5. 1 attempts to show the interaction between the various roles that comprise a certificate authority and its relationship to the PKI.

Functional Roles Policy Authority • The policy authority is responsible for – – –

Functional Roles Policy Authority • The policy authority is responsible for – – – • establishing, distributing, maintaining, promoting, and enforcing the policies and procedures for all of the functional entities. The policy authority is responsible for – – the authorization or accreditation of entities to perform a functional role under the established policies. Specifications for • • • the content and intended usage of certificates by relying parties, the registration process for the subject of certificates, the certificate revocation process, for managing the root and all subordinate CA certificates fall under the auspices of the policy authority. The policy authority is chartered to resolve or enable resolution of disputes related to the policies and procedures, – therefore must remain current regarding • • • potential security threats, policy inadequacies, regulatory requirements.

Functional Roles Certificate Issuer • The certificate issuer – distributes the certificates generated by

Functional Roles Certificate Issuer • The certificate issuer – distributes the certificates generated by the certificate manufacturer, – manages the brand name associated with the certificate. • providing a means for subscribers to – request certificate revocation, – granting and revoking certificates, – managing the certificate revocation list. Certificate Manufacturer • The certificate manufacturer – – generates and manages the certificate signature asymmetric key pairs consistent with the policies and procedures provided by the policy authority. may also distribute the root public key(s) and do the actual signing of certificates.

Functional Roles • • the certificate manufacturer provides the out of band notification to

Functional Roles • • the certificate manufacturer provides the out of band notification to a subscriber that a certificate has been generated. If more than one certificate issuer is hosted, the certificate manufacturer establishes and maintains separation between the different issuers. Revocation Manufacturer • The revocation manufacturer – generates and manages the revocation signature asymmetric key pairs consistent with the policies and procedures provided by the policy authority. Therefore, the revocation manufacturer may also distribute the root public key(s). – provides the out of band notification to a subscriber that a revocation has been generated. – If more than one certificate issuer is hosted, the revocation manufacturer establishes and maintains separation between the different issuers.

Functional Roles Registration Authority • • sometimes referred to as a registrar, is essentially

Functional Roles Registration Authority • • sometimes referred to as a registrar, is essentially the front end for the subscriber to all of the other functional entities, providing – certificate registration, – certificate status, – and revocation services. • The registration authority – obtains a public key from the subscriber or, optionally, if non repudiation is not intended, generates an asymmetric key pair on behalf of the subscriber. – Before the registration authority forwards the certificate request to the certificate manufacturer, the subscriber is authenticated according to the policy and procedures established by the policy authority. – The registration authority determines that the subscriber holds the , public key's corresponding asymmetric private key.

Functional Roles Authentication Service • • • The authentication service validates a subscriber's credentials

Functional Roles Authentication Service • • • The authentication service validates a subscriber's credentials for the registration authority prior to the registration authority submitting the subscriber's public key and identity to the certificate manufacturer. The subscriber's credentials are presented to the registration authority and validated by the authentication service in accordance to the policies and procedures established by the policy authority. Credentials can range from anything as simplistic as an e mail address to photo identification (e. g. , driver's license, passport) and letters of introduction on company letterhead signed by an officer of that company. Repository • The repository is an online database – storing and distributing all public key certificates, – information on certificate status (such as CRLs), – and other PKI related information (e. g. , certificate policy). – In some instances, the repository also maintains regulatory and financial information about each functional role.

Functional Roles Subscriber • • The subscriber is the subject of the certificate, whose

Functional Roles Subscriber • • The subscriber is the subject of the certificate, whose identity and public key are implicitly bound together in the public key certificate. the subscriber is not part of the certificate authority, the subscriber is part of the PKI and is responsible for – generating asymmetric key pairs, – managing the proper access controls over the private key in accordance with the policy and procedures established by the policy authority. – any incidence of known or suspected compromise of the private key results in immediate notification of the registration authority.

Functional Roles Relying Party • • • The relying party is any entity using

Functional Roles Relying Party • • • The relying party is any entity using a subscriber's certificate, and whose trust of that certificate depends largely on the policies and procedures established by the policy authority. Although the relying party is not part of the certificate authority, the relying party is part of the PKI by using the public key in the subscriber's certificate for – authorized business applications – and appropriate cryptographic functions (e. g. , digital signature verification, key exchange, etc. ) in compliance with policies and procedures established by the policy authority.

Functional Roles Applications • • There is a significant distinction between technology applications (e.

Functional Roles Applications • • There is a significant distinction between technology applications (e. g. , electronic mail) and business applications. Technology applications are software products whose functions enable a business to operate. – For example, • the telephone is a technology application that enables sales agents to contact their customers. Thus, business applications are comprised of technology applications, people, and transactions. • In a PKI, the relationship to the certificate authority and a business application is that the PKI enabled technology applications used by the business application rely on the certificate authority to manage public key certificates. The importance of access controls over the asymmetric private key cannot be overly emphasized.

Cross-Certification • Clearly, all of the certificates for the population of the planet Earth,

Cross-Certification • Clearly, all of the certificates for the population of the planet Earth, not to mention all of the technology applications, cannot and would not be issued by a single certificate authority. Multiple CAs do and must exist. • The real question is, what are the business and technology relationships between multiple certificate authorities? • Let's look at three typical CAs, identified as CA 1, CA 2, and CA 3.

Cross-Certification • • Further assume that each CA has issued some number of certificates

Cross-Certification • • Further assume that each CA has issued some number of certificates to subscribers, labeled as Sl through Sn. Each CA has no direct relationship with another CA. In order to validate a certificate issued from any CA, each relying party would need to have the public key of all three certificate authorities. Other CA models aid in the interoperability for relying parties. Hierarchy Model • In the CA hierarchy model , CA 1 and CA 2 have submitted their public keys to a common CA referred to as a root CA. • The root CA can be defined as the highest level CA whose public key is usually contained in a self signed certificate.

Hierarchy Model • CA 1 and CA 2 by definition are designated as subordinate

Hierarchy Model • CA 1 and CA 2 by definition are designated as subordinate CAs. • Self signed certificates provide data integrity, but cannot provide authentication. • The root CA public certificate is distributed to all relying parties.

Hierarchy Model • This model requires that CA 1 and CA 2 establish a

Hierarchy Model • This model requires that CA 1 and CA 2 establish a business relationship with the root CA, and consequently a trust relationship that can be used by the subscribers and relying parties. • The existence of the root CA places a burden and reliance on maintaining the security over the root CA private key and its corresponding public key. • The root CA represents a potential single point of failure. – If the root CA private key is compromised, all certificates issued by and all subordinate CAs are suspect, and must therefore be revoked and reissued. • As the level of complexity increases, the dependency on the root CA and higher‑level subordinate CAs becomes critical. • The security policies and practices imposed by the root CA must address the roles and responsibilities of the subordinate CAs. • Thus, each subordinate is said to inherit the policy and practices of the higher level CA. • However, a root CA hierarchy is not the only means by which interoperability can be achieved.

Peer-to-Peer Model • Where certificate authorities operate on an equal basis, – one or

Peer-to-Peer Model • Where certificate authorities operate on an equal basis, – one or more CAs can cross certify each other in a peer to peer relationship. – Each pair of CAs mutually exchanges 7 public keys and issues a certificate to each other. – This enables a relying party to verify 1 a subscriber's certificate issued from any CA that has been cross certified with the CA ? for which the relying party holds and trusts that CA's public key.

Peer-to-Peer Model Figure 5. 4 shows the three certificate authorities CAl, CA 2, and

Peer-to-Peer Model Figure 5. 4 shows the three certificate authorities CAl, CA 2, and CA 3, – where the pairs CAl and CA 2, and CA 2 and CA 3 have cross certified. – Thus, CAI issues a certificate to CA 2, containing CA 2's public key, and signed by CA 1's private key. – Likewise, CA 2 issues a certificate to CAl, containing CA 1's public key, and signed by CA 2's private key. – Similarly, CA 2 and CA 3 have cross certified.

Peer-to-Peer Model • • In this model, each CA is essentially a root CA;

Peer-to-Peer Model • • In this model, each CA is essentially a root CA; however, no highest level root CA actually exists. Therefore, no burden is placed on a single point of failure. Each CA is responsible for its subscribers and for providing trust to its relying parties. Interestingly, the policy and practices of each CA are relatively independent of each other, and therefore as each cross certification is established, the policy and practices must be reviewed to ensure compatible operating rules.

Bridge Model • • • An alternative model has been proposed by the Federal

Bridge Model • • • An alternative model has been proposed by the Federal PKI Technical Working Group and endorsed by the Federal PKI Steering Committee. The hierarchical model – was seen as too restrictive, – and no one government agency could satisfactorily fulfill the role of a root CA for all other civil and defense agencies. Furthermore, a simple cross certification model – is prohibited by the total number of agencies, as this creates what is referred to as the N 2 (n squared) problem. – For N certificate authorities, it requires N 2 N/2 cross certifications. – So, for 300 CAs, it would require 44, 850 certificates just between all of the CAs. Figure 5. 5 shows a cross certification scheme using a central peer to peer CA, where CAI and CA 3 cross certify with just the bridge CA. – So, for 300 CAs, it would only require 300 cross certificates, or in general N cross certificates, a number substantially smaller than the so called N 2 problem. However, similar to the cross certification model, the policies and practices of each CA cross certifying with the bridge CA would need to be harmonized. Minimal policies and practices should be established, implemented, and verified.

Bridge Model

Bridge Model

Certificate Revocation Lists • • • A certificate revocation list (CRL) is a list

Certificate Revocation Lists • • • A certificate revocation list (CRL) is a list of revoked certificates with the time of revocation. The CRL is also digitally signed by the CA that issued the certificates, so it is tamper proof. CRLs from large, active CAs also have a tendency to get very large. – This is mainly because revoked certificates remain on the list until they expire, which can be a number of years. – The list can grow quite rapidly in active organizations with any reason ably sized deployment.

Certificate Revocation Lists • when a client has been presented with a certificate, –

Certificate Revocation Lists • when a client has been presented with a certificate, – it may require the client to download – and search through a large CRL to determine whether the certificate has been revoked It is quite common today to simply not to check the CRL. • However, there are better ways to address this problem. – One is to use the Online Client Status Protocol (OCSP), – which allows a client to submit a certificate serial number to an OCSP server and get a "valid/invalid" response that takes into account the certificate's revocation status. – The server may need to consult a CRL, but that may be much less onerous than forcing every client to download the full CRL. • The task of searching through the CRL can be facilitated by organizing the CRL into an efficient data structure, – such as a binary tree. Downloading the CRL may still be required, but the search should go faster.

Certificate Revocation Lists • It’s also possible to set up CRL Distribution Points (DPs),

Certificate Revocation Lists • It’s also possible to set up CRL Distribution Points (DPs), – which are CRLs that have been partitioned into more manageable, smaller pieces. – Instead of trying to download 1 a massive CRL to check individual certificates, clients get • small, • manageable updates that allow them to have a definitive copy of the CRL at all times.

Stages of Validation • The validation authority plays a critical role at several points

Stages of Validation • The validation authority plays a critical role at several points in an e. Business transaction: – Before trust is established – Prior to each transaction – During and after the transaction Before Trust Is Established • Before trust is established, – subscribers – and relying parties • need reliable information about CAs, in order to make informed decisions about where to buy certificates and which certificates to accept.

Stages of Validation • • CAs can easily reproduce in amount to the growth

Stages of Validation • • CAs can easily reproduce in amount to the growth of e. Business itself, and may increase considerably as deployment of Microsoft Windows 2000, which comes bundled with CA software, accelerates. As such, the question of which CAs are acceptable to the company becomes more important. Companies considering buying or accepting certificates from a CA need a central registry of trust information, where they can get the information needed to determine the trustworthiness of that CA.

Prior to Each Transaction • Issuing certificates establishes trust between subscribers and relying parties,

Prior to Each Transaction • Issuing certificates establishes trust between subscribers and relying parties, based on the relying parties' trust in the CA. • After trust is established, the certificate needs to be validated prior to each transaction. • The responsibility for insuring that the certificate is valid falls on the relying party. • A relying party that accepts an expired, revoked, or otherwise invalid certificate will generally have no legal recourse against the CA, in the event that the compromised credential resulted in damage or fraud. • The VA can provide this necessary certificate validation service.

During and After Each Transaction • Finally, high value transactions require that an audit

During and After Each Transaction • Finally, high value transactions require that an audit trail be maintained during the transaction, – and stored after the transaction for future dispute resolution. • The VA may act as a neutral, trusted third party involved in the transaction, and maintain an audit trail.