Ch 6 - Public Key Infrastructure


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • The components work together to allow communication using public key cryptography and symmetric keys for digital signatures, data encryption, and integrity.
  • A certificate is also suspended if the administrator suspects that a private key has been compromised.
  • A company archives keys to ensure that if a person is unavailable to decrypt important company information, the company can still obtain the required data.
  • In the figure, all the users and devices in trust domain 1 trust their own CA 1, which is their trust anchor. All users and devices in trust domain 2 have their own trust anchor, CA 2. The two CAs have exchanged certificates and trust each other, but they do not have a common trust anchor between them.
  • The end-entities look to the issuing CA as their trusted anchor. Different CAs do not have an agreed-upon anchor. The two different CAs certify the public key for each other, which creates a bidirectional trust.
  • If there was one root CA certifying all the intermediate CAs, scalability would not be as much of an issue.
  • Ch 6 - Public Key Infrastructure

    1. 1. Lesson 6-Public Key Infrastructure
    2. 2. PKI infrastructure <ul><li>Public key infrastructures (PKIs) are central security foundation for organizations using symmetric and asymmetric cryptographic technologies . </li></ul><ul><li>Most organizations use a PKI (public key infrastructure) for their digital signatures and the certificates that embody the signatures. A PKI implementation includes: </li></ul><ul><ul><li>a certificate authority (CA), a third party that manages the storage, deployment and signing of certificates </li></ul></ul><ul><ul><li>one or more registration authorities (RA) delegated by the CA to validate individual groups or users being issued a certificate </li></ul></ul><ul><ul><li>software tools that manage certificate issuance, validation, renewal or revocation </li></ul></ul><ul><ul><li>directories for the public keys, certificates, links to user directories and certificate-management data </li></ul></ul><ul><ul><li>key-management software for the database where the archived, escrowed, revoked and other keys are stored </li></ul></ul><ul><ul><li>applications, such as e-mail clients and user authentication programs, that use certificates of both local and authenticated users from outside the organization </li></ul></ul><ul><ul><li>trust models that build on the issued certificates to extend safe communications beyond the organization, to its direct partners and the issuing CA </li></ul></ul><ul><ul><li>policies for managing certificates, including models for deploying certificates, responsibility for proper handling, standards to describe their contents, and the legal responsibilities for those using (and abusing) them. </li></ul></ul>
    3. 3. Basics of Public Key Infrastructures <ul><li>PKI involves entities called registration authorities and certificate authorities . </li></ul><ul><ul><li>Registration authority requires proof of identity </li></ul></ul><ul><ul><li>The registration authority then advises the certificate authority (CA) to generate a certificate, analogous to a driver's license. </li></ul></ul><ul><ul><li>The certificate authority digitally signs the certificate using its private key. </li></ul></ul><ul><li>Third Party Trusts - Two people can implicitly trust each other if they share a relationship with a common third party who vouches for them. </li></ul>
    4. 4. Registration Authority <ul><li>The registration authority (RA) is the component that accepts a request for a digital certificate. Minimum 3 types : </li></ul><ul><ul><li>A Class 1 certificate verifies an individual's identity through e-mail . </li></ul></ul><ul><ul><ul><li>Public/private key pair digitally signs e-mail and encrypt message contents. </li></ul></ul></ul><ul><ul><ul><li>May only require name, email and physical address </li></ul></ul></ul><ul><ul><li>A Class 2 certificate is used for software signing . </li></ul></ul><ul><ul><ul><li>Software can be digitally signed to provide integrity for the vendor. </li></ul></ul></ul><ul><ul><ul><li>May require driver’s license, passport etc. </li></ul></ul></ul><ul><ul><li>A Class 3 certificate is used by a company to set up its own certificate authority. </li></ul></ul><ul><ul><ul><li>May have to go to register’s office personnally </li></ul></ul></ul><ul><li>A local registration authority (LRA) performs the same functions as an RA, but the LRA is closer to end users (within a company). </li></ul>
    5. 5. Certificate Authorities and CPS <ul><li>The certificate authority (CA) is the trusted authority for certifying an individual's identity and creating an electronic document ( digital certificate ). </li></ul><ul><li>A digital certificate is an electronic &quot;credit card&quot; that establishes your credentials when doing business or other transactions on the Web. </li></ul><ul><li>Every CA should have a certification practices statement (CPS), which outlines: </li></ul><ul><ul><li>How identities are verified. </li></ul></ul><ul><ul><li>The steps the CA follows to generate, maintain, and transmit certificates. </li></ul></ul><ul><ul><li>Why the CA can be trusted to fulfill its responsibilities. </li></ul></ul><ul><ul><li>How keys are secured. </li></ul></ul><ul><ul><li>What data is placed within a digital certificate. </li></ul></ul><ul><ul><li>How revocations will be handled. </li></ul></ul>
    6. 6. Obtaining a Digital Certificate Steps for obtaining a digital certificate
    7. 7. Digital Signature
    8. 8. Storing a Certificate <ul><li>Often certificates are stored in a repository and must be available to whoever requires them. </li></ul><ul><li>The security requirements for repositories, and their hardware and software, are not as high as the actual CAs. </li></ul><ul><ul><li>The public can review the CA's CPS to find out what type of data will and will not be included within the certificates. </li></ul></ul><ul><ul><li>Since each certificate is digitally signed by the CA, if a certificate stored in the certificate repository is modified, the recipient would be able to detect this change and not accept the certificate as valid. </li></ul></ul>Some key stores can be shared by different applications. Microsoft apps stores keys and certs in a users profile
    9. 9. Distinguished Names <ul><li>CAs use distinguished names to identify the owners of specific certificates. </li></ul><ul><li>A distinguished name is a label that follows the X.500 standard. </li></ul><ul><ul><li>This standard defines a naming convention that can be employed so that each subject within an organization has a unique name. </li></ul></ul><ul><ul><li>An example is {Country = US, Organization = IBM, Organizational Unit = R&D, Location = Washington}. </li></ul></ul>
    10. 10. Trust and Certificate Verification <ul><li>When users trust a CA, they will download that CA's digital certificate and public key, to be stored on their local computer. </li></ul><ul><ul><li>Most browsers have a list of CAs configured to be trusted by default. </li></ul></ul><ul><ul><li>The list can be edited. </li></ul></ul><ul><li>Free certificates are available. Check out . </li></ul>
    11. 11. Verifying Authenticity and Integrity of a Certificate <ul><li>To verify the authenticity and integrity of a certificate: </li></ul><ul><ul><li>Compare the CA that digitally signed the certificate to a list of CAs that has already been loaded into the receiver’s computer </li></ul></ul><ul><ul><li>Calculate a message digest for the certificate. </li></ul></ul><ul><ul><li>Use the CA’s public key to decrypt the digital signature and recover what is claimed to be the original message digest embedded within the certificate </li></ul></ul><ul><ul><li>Compare the two resulting message digest values to ensure the integrity of the certificate. </li></ul></ul><ul><ul><li>Review the identification information within the certificate </li></ul></ul><ul><ul><li>Review the validity dates. </li></ul></ul><ul><ul><li>Check a revocation list at the CA to see if the certificate has been revoked. </li></ul></ul>
    12. 12. Digital Certificate Standard Fields <ul><li>Version Number </li></ul><ul><ul><li>Identifies the version of the X.509 standard that was followed to create the certificate. </li></ul></ul><ul><ul><li>The version number indicates the format and fields that can be used. </li></ul></ul><ul><li>Subject </li></ul><ul><ul><li>Specifies the owner of the certificate and can be a network device , an application, a department, a company, or a person. </li></ul></ul><ul><li>Public key </li></ul><ul><ul><li>Contains the public key being bound to the certified subject, which also identifies the algorithm used to create the private/public key pair. </li></ul></ul><ul><li>Issuer </li></ul><ul><ul><li>Identifies the CA that generated and digitally signed the certificate. </li></ul></ul><ul><li>Serial number </li></ul><ul><ul><li>Contains a unique number identifying a specific certificate issued by a particular CA. </li></ul></ul><ul><li>Validity </li></ul><ul><ul><li>Specifies the dates through which the certificate is valid for use. </li></ul></ul><ul><li>Certificate usage </li></ul><ul><ul><li>Specifies the approved use of a certificate, which dictates the use of this public key. </li></ul></ul><ul><li>Signature algorithm </li></ul><ul><ul><li>Identifies the hashing algorithm and the digital signature algorithm used to digitally sign the certificate. </li></ul></ul><ul><li>Extensions </li></ul><ul><ul><li>Allow additional data to be encoded into the certificate to expand the functionality </li></ul></ul>
    13. 13. X.509 <ul><li>This certificate is created and formatted based on the X.509 standard, which outlines the necessary fields of a certificate and the possible values that can be inserted into the fields. </li></ul><ul><li>The CA used MD5 to create the message digest value, and signed with its private key using the RSA algorithm . </li></ul><ul><li>The actual CA that issued the certificate is Root SGC Authority </li></ul>The version of this certificate is V3 (X.509 v3) with the unique serial number
    14. 14. CA Certificates <ul><li>CA certificates are certificates that are issued by a CA to itself or to a second CA for the purpose of creating a defined relationship between the two CAs. </li></ul><ul><li>A certificate that is issued by a CA to itself is referred to as a trusted root certificate , because it is intended to establish a point of ultimate trust for a CA hierarchy. </li></ul><ul><li>Once the trusted root has been established, it can be used to authorize subordinate CAs to issue certificates on its behalf. </li></ul>
    15. 15. 4 types of Certificate Attributes <ul><li>End-entity certificates are issued by a CA to a specific subject such as Joyce, the accounting department, or a firewall. </li></ul><ul><li>Standalone - certificate may be self-signed in case of a stand-alone or root CA, or it may be issued by a superior CA within a hierarchical model. </li></ul><ul><li>Cross-certification - are used when independent CAs establish peer-to-peer trust relationships allowing its users to trust another CA. </li></ul><ul><li>Policy - a mechanism to provide centrally controlled policy information to PKI clients. This is often done by creating a policy certificate. </li></ul>End-entity and CA certificates
    16. 16. Certificate Extensions <ul><li>Certificate extensions allow further information to be inserted within the certificate and provide functionality in a PKI implementation. </li></ul><ul><li>Certificate extensions can be standard or private. Examples: </li></ul><ul><ul><li>DigitalSignature </li></ul></ul><ul><ul><ul><li>The key is used to verify a digital signature. </li></ul></ul></ul><ul><ul><li>KeyEncipherment </li></ul></ul><ul><ul><ul><li>The key is used to encrypt other keys used for secure key distribution. </li></ul></ul></ul><ul><ul><li>DataEncipherment </li></ul></ul><ul><ul><ul><li>The key is used to encrypt data and cannot be used to encrypt other keys. </li></ul></ul></ul><ul><ul><li>CRLSign </li></ul></ul><ul><ul><ul><li>The key is used to verify a CA signature on a revocation list. </li></ul></ul></ul><ul><ul><li>KeyCertSign </li></ul></ul><ul><ul><ul><li>The key is used to verify CA signatures on certificates. </li></ul></ul></ul><ul><ul><li>NonRepudiation </li></ul></ul><ul><ul><ul><li>The key is used when a nonrepudiation service is being provided. </li></ul></ul></ul>
    17. 17. Additional Requirements <ul><li>The sender's digital signature can be verified and then signed by the notary providing nonrepudiation service </li></ul><ul><li>T rusted time source - provides a secure, certifiable, and auditable time stamp on any electronic entity for accountability purposes. </li></ul><ul><ul><li>Without trusted time source, no activity carried out within a PKI environment can be truly proven because it is very easy to change system and software time settings. </li></ul></ul><ul><li>Certificate Lifecycles - Keys and certificates should have lifetimes set. This involves administrating and managing each of these phases, including registration, certificate and key generation, renewal, and revocation. </li></ul><ul><ul><li>The lifetime of the key should be long enough that continual renewal will not negatively affect productivity, but short enough to ensure that the key cannot be successfully compromised. </li></ul></ul>
    18. 18. PKI Implementations <ul><li>In most modern PKI implementations, users have two key pairs. </li></ul><ul><ul><li>One key pair is generated by a central server and used for encryption and key transfers. The corporate PKI retains a copy of the encryption key pair for recovery, requiring secure transmission of the keys to the user. </li></ul></ul><ul><ul><li>The second key pair, a digital signature key pair, is generated by the user, who has a copy of the private key and stored locally (workstation or smart card). </li></ul></ul><ul><li>Proof of Possession - the act of verifying that an individual has the corresponding private key for a given public key. </li></ul><ul><ul><li>If a key pair is used for encryption, the RA can send a challenge value to the individual, who, in turn, can use the private key to encrypt that value and return it to the RA. </li></ul></ul>
    19. 19. Key Size <ul><li>When the key pair is first generated, the administrator chooses the algorithm used to generate the key pair and the key size . </li></ul><ul><ul><li>The specific algorithm will be chosen for its strength and interoperability </li></ul></ul><ul><ul><li>The key size will depend upon the sensitivity of the data being protected. </li></ul></ul><ul><li>The RSA algorithm is the de facto standard for asymmetric key </li></ul><ul><ul><li>For sensitive date, 128 bit is minimum, takes 105 computers five minutes, key size of 1024 takes 114 computers with 170GB of memory 3,000,000 years </li></ul></ul>
    20. 20. Renewal and Revocation <ul><li>A renewal process is different from the registration phase. </li></ul><ul><ul><li>Since the individual has successfully completed one registration round, the original key and certificate can be used to provide the necessary authentication and proof of identity </li></ul></ul><ul><li>Reasons a certificate can be revoked: </li></ul><ul><ul><li>A user loses a laptop or a smart card that stored a private key. </li></ul></ul><ul><ul><li>An improper software implementation has been uncovered that directly affected the security of a private key. </li></ul></ul><ul><ul><li>A user has fallen victim to a social engineering attack and inadvertently given up a private key. </li></ul></ul><ul><ul><li>Data held within the certificate no longer applies to the specified individual. </li></ul></ul><ul><ul><li>An employee has left a company and should not be identified as a member of an in-house PKI. </li></ul></ul>
    21. 21. Certificate Revocation List <ul><li>The CA can provide protection by maintaining a certificate revocation list (CRL). </li></ul><ul><li>The CA: </li></ul><ul><ul><li>Is responsible for the status of the certificates it generates. </li></ul></ul><ul><ul><li>Must be informed of a revocation. </li></ul></ul><ul><ul><li>Must provide this information to others. </li></ul></ul><ul><ul><li>Is responsible for maintaining the revocation list and posting it in a publicly available directory. </li></ul></ul><ul><ul><li>indicates why individual certificates were revoked and the date of revocation </li></ul></ul><ul><ul><li>contains all certificates that have been revoked within the lifetime of the CA. </li></ul></ul><ul><li>The CRL's integrity needs to be protected to ensure data isn’t modified. </li></ul><ul><ul><li>The mechanism used to protect the integrity of a CRL is a digital signature. </li></ul></ul>
    22. 22. CRL Distribution <ul><li>CRL files may be requested by individuals who want to verify and validate a newly received certificate. Files can be pushed down by the CA or checked via an online service that can query the lists. </li></ul><ul><ul><li>One of the protocols used for online revocation services is Online Certificate Status Protocol (OCSP). </li></ul></ul><ul><ul><li>It is a request and response protocol that obtains the serial number of the cert that is being validated, reviews revocation lists, and reports the status of the certificate back to the client. </li></ul></ul>
    23. 23. Suspension <ul><li>Instead of being revoked, a certificate is sometimes suspended and the CRL indicates a hold state in the revocation field. Examples: </li></ul><ul><ul><li>there has been a loss, theft, modification, unauthorised disclosure, or other compromise of the private key of the certificate's subject, </li></ul></ul><ul><ul><li>the certificate's subject has breached a material obligation under this CPS, </li></ul></ul><ul><ul><li>the performance of a person's obligations under this CPS has been delayed or prevented by an act of God; natural disaster; computer or communications failure; change in statute, regulation, or other law; official government action, including but not limited to acts by agencies responsible for export control administration; or other cause beyond the person's reasonable control, and as a result another person's information has been or may be materially threatened or compromised, or </li></ul></ul><ul><ul><li>the subscriber (or authorized representative) has duly requested it. </li></ul></ul>
    24. 24. Key Destruction <ul><li>Key destruction is dictated by the level of protection required within the environment. In most environments, just allowing the applications that created the keys is sufficient. </li></ul><ul><li>In environments requiring higher levels of protection (government and military agencies), the media that holds the keys may need to go through a “ zeroization ” process. </li></ul><ul><ul><li>The media that holds the cryptographic key is overwritten. </li></ul></ul><ul><ul><li>A software tool writes NULL values to the sectors until that media holds no remnants of the original key. </li></ul></ul><ul><li>Key history maintenance - In modern PKIs, encryption key pairs must be retained long after they expire so that users can decrypt information that was encrypted with the old keys. </li></ul>
    25. 25. Random Number Generators <ul><li>Keys are generated in a central server or local computer manner, depending on key size and how resource intensive. </li></ul><ul><li>A central server may include a hardware-based random number generator creating numbers that work as seed values for the algorithm. </li></ul><ul><li>They extract values from the surroundings. </li></ul><ul><ul><li>If the starting values are predictable, the numbers they generate cannot be random. </li></ul></ul><ul><ul><li>An example of a true random number generator would be a system that collects radiation from a radioactive item because elements escape from the radioactive item in an unpredictable manner </li></ul></ul><ul><ul><li>There are a wide variety of schemes for getting random number seeds based on unpredictable external real-world events such as the time between keystrokes, the air temperature, or how often network packets arrive. </li></ul></ul>
    26. 26. Hardware Storage Devices <ul><li>To provide true authenticity and nonrepudiation, a public/private key pair for digital signatures should not be stored on a centralized server </li></ul><ul><ul><li>The server needs to be available and provide a single point of failure. </li></ul></ul><ul><ul><li>It must have fault tolerance or redundancy mechanism. </li></ul></ul><ul><ul><li>If the central key server is compromised, the whole environment is compromised. </li></ul></ul><ul><li>There are other hardware components that can be implemented within a PKI to hold users' private key information. </li></ul><ul><ul><li>Smart cards </li></ul></ul><ul><ul><li>USB tokens </li></ul></ul><ul><ul><li>Fortezza cards - popular with government agencies, especially the military. </li></ul></ul><ul><li>If a company uses smart cards to hold users' private keys, the private key often has to be generated on the card itself and cannot be copied for archiving purposes. </li></ul><ul><ul><li>Some applications create their own public/private key pairs and do not allow other keys to be imported and used. </li></ul></ul><ul><li>In most situations, hardware key-storage solutions are only used for the most critical and sensitive key. </li></ul>
    27. 27. Maintaining Key Privacy <ul><li>The following list sums up the characteristics and requirements of proper private key use: </li></ul><ul><ul><li>The key size should provide the necessary level of protection for the environment. </li></ul></ul><ul><ul><li>The lifetime of the key should correspond with how often it is used and the sensitivity of the data it is protecting. </li></ul></ul><ul><ul><li>The key should be changed and not used past its allowed lifetime. </li></ul></ul><ul><ul><li>Where appropriate, the key should be properly destroyed at the end of its lifetime. </li></ul></ul><ul><ul><li>The key should never be exposed in clear text. </li></ul></ul><ul><ul><li>No copies of the private key should be made if it is being used for digital signatures. </li></ul></ul><ul><ul><li>The key should not be shared. </li></ul></ul><ul><ul><li>The key should be stored securely. </li></ul></ul><ul><ul><li>Authentication should be required before it can be used. </li></ul></ul><ul><ul><li>The key should be transported securely. </li></ul></ul>
    28. 28. Key archiving, recovery and escrow <ul><li>Key archiving will generally back up only the key pairs used to encrypt data, and not the key pairs used to generate digital signatures </li></ul><ul><li>When a key recovery is required, at least two people (separation of duties) are required to authenticate (dual control) by the key recovery software before the recovery procedure is performed. </li></ul><ul><ul><li>All key recovery procedures should be audited. </li></ul></ul><ul><ul><li>The audit logs should capture at least what keys were recovered, who was involved in the process, and the time and date. </li></ul></ul><ul><li>Key escrow is a process of giving keys to a third party ( specifically the government ) so that they can decrypt and read sensitive information when required. </li></ul>
    29. 29. Certificate Policy <ul><li>The CP is generated and owned by an individual company that uses an external CA, and it allows the company to enforce its security decisions and control how certificates are used with its applications. </li></ul><ul><li>This policy allows the company to decide the certification classes. </li></ul><ul><ul><li>This is different from the CPS, which explains how the CA </li></ul></ul><ul><ul><ul><li>verifies entities, </li></ul></ul></ul><ul><ul><ul><li>generates certificates, </li></ul></ul></ul><ul><ul><ul><li>and maintains these certificates. </li></ul></ul></ul>
    30. 30. Public and in house CA <ul><li>The decision to use a public or an in-house CA depends upon: </li></ul><ul><ul><li>The expansiveness of the PKI within the organization. </li></ul></ul><ul><ul><li>How integrated it will be with different business needs and goals. </li></ul></ul><ul><ul><li>The number of individuals who will be participating in the decision-making process. </li></ul></ul><ul><ul><li>How it works with outside entities. </li></ul></ul><ul><li>A public CA is a company that specializes in verifying individuals’ identities and creating and maintaining their certificates. </li></ul><ul><ul><li>They are easily accessible since most Web browsers have a list of public CAs installed along with their corresponding root certificates. </li></ul></ul><ul><ul><li>They have the necessary equipment, skills, and technologies.. </li></ul></ul><ul><li>In-house CA are implemented, maintained, and controlled by the company. </li></ul><ul><ul><li>It gives more control over the registration and generation process and allows them to configure items specifically for their own needs. </li></ul></ul>
    31. 31. Outsourced Certificate Authorities <ul><li>An outsourced CA is different from a public CA. </li></ul><ul><li>Outsourced services need to be analyzed: </li></ul><ul><ul><li>to determine level of trust and level of risk </li></ul></ul><ul><ul><li>The liabilities the service provider is willing to accept </li></ul></ul><ul><ul><li>the surrounding legal issues need to be examined </li></ul></ul><ul><li>Some large vertical markets have their own outsourced PKI environments set up because they share similar needs and usually have the same requirements. </li></ul><ul><ul><li>This allows several companies within the same market to split the costs of the necessary equipment and set standards. </li></ul></ul>A PKI service provider (represented by the four boxes) can offer different PKI components to companies.
    32. 32. Trust Models <ul><li>More than one CA may be needed for a specific PKI to work properly. </li></ul><ul><li>Trust Domain – construct of systems, personnel, applications, protocols, technologies and policies, and all components work together seamlessly </li></ul><ul><li>The different trust domains: </li></ul><ul><ul><li>Are managed by different administrators. </li></ul></ul><ul><ul><li>Have different security policies. </li></ul></ul><ul><ul><li>Restrict outsiders from privileged access. </li></ul></ul>A trust anchor (CA) is the agreed-upon trusted third party. Trust anchors need to be identified, and a communication channel must be constructed and maintained.
    33. 33. Establishing Trust <ul><li>If the two CAs have exchanged certificates and trust each other, they do not have a common trust anchor. </li></ul><ul><li>The trust models describe and outline the trust relationships between the different CAs and different environments </li></ul><ul><li>The trust path can be unidirectional or bidirectional </li></ul>A trust relationship can be built between two trust domains to set up a communication channel.
    34. 34. The Certificate Path <ul><li>When a user in one trust domain needs to communicate with another user in another trust domain, one user will need to validate the other's certificate. </li></ul><ul><ul><li>This means each certificate for each CA, up to a shared trusted anchor, needs to be validated. </li></ul></ul><ul><li>Following the certificate path refers to when software has traversed the hierarchy to track and collect certificates until it comes upon a self-signed certificate. </li></ul>Verifying each certificate in a certificate path
    35. 35. Hierarchical Trust Model <ul><li>The first type of trust model is a basic hierarchical structure that contains a root CA, intermediate CAs, leaf CAs, and end-entities. </li></ul>The hierarchical trust model outlines trust paths.
    36. 36. Hierarchical Trust Anchor <ul><li>The root CA is the ultimate trust anchor for all other entities in this infrastructure. </li></ul><ul><ul><li>It generates certificates for the intermediate CAs, which in turn generate certificates for the leaf CAs, and the leaf CAs generate certificates for the end-entities (users, network devices, applications). </li></ul></ul><ul><ul><li>There are no bidirectional trusts. They are all unidirectional trusts. </li></ul></ul>
    37. 37. Hierarchical Trust Anchor <ul><li>Since no other entity can certify and generate certificates for the root CA, it creates a self-signed certificate. </li></ul><ul><ul><li>The certificate's issuer and subject fields hold the same information. </li></ul></ul><ul><ul><li>Both represent the root CA. </li></ul></ul><ul><ul><li>The root CA's public key is used to verify this certificate. </li></ul></ul><ul><li>The root CA certificate and public key are distributed to all entities within this trust model. </li></ul>
    38. 38. Cross Certification - Peer-to-Peer Model <ul><li>In peer-to-peer trust models, one CA is not subordinate to another, and there is no established trusted anchor </li></ul><ul><li>In the peer-to-peer model, the two CAs will certify the public key for each other, which creates a bidirectional trust. </li></ul><ul><li>One of the main drawbacks of this model is scalability. </li></ul><ul><ul><li>Each CA must certify every other CA that is participating, and a bidirectional trust path must be implemented. </li></ul></ul>Cross certification creates a peer-to-peer PKI model.
    39. 39. Hybrid Trust Model <ul><li>In a hybrid trust model, the two companies have their own internal hierarchical models and are connected through a peer-to-peer model using cross certification. </li></ul><ul><li>Hybrid configuration is implemented through a bridge CA. </li></ul><ul><li>A bridge CA is responsible for issuing cross-certificates to all connected CAs and trust domains. </li></ul><ul><li>The bridge is not considered a root or trust anchor, it is just an entity to generate and maintain cross certification for the connected environments. </li></ul>A bridge CA can control the cross-certification procedures.
    40. 40. Complexity <ul><li>The diagram represents fully connected mesh architecture, meaning each CA is directly connected to and has a bidirectional trust relationship with every other CA. </li></ul>Scalability is a drawback in cross-certification models.