Week 07 - PKI & Digital Signatures

Key Terms

Term	Definition	Exam Context/Example
Public Key ($\mathbf{pk}$)	A key that can be distributed publicly and is used primarily to verify signatures,. In public-key encryption, it is used by Alice to encrypt a message $m$ for Bob.	In digital signature schemes, anyone can use the public key to verify the correctness of the tag ($\sigma$) generated by the signer’s private key.
Private Key / Secret Key ($\mathbf{sk}$ or $\mathbf{d}$)	The key that must be kept secret by the owner,. It is used to sign a message or to efficiently compute the inverse of a one-way function.	In RSA, the secret key includes the decryption exponent $d$, which is used to decrypt a ciphertext or generate a digital signature.
Digital Signatures	The digital counterpart of a handwritten signature, where the signature depends on the message and a secret known only to the signer. They are publicly verifiable, transferable, and provide non-repudiation.	Unlike MACs, digital signatures allow an unbiased third party to verify the signature without access to the signer’s secret key.
Non-repudiation	A property of digital signatures meaning the signer cannot truthfully deny or repudiate having signed the message once the signature checks out,.	MACs do not have this property because the verifier (Bob) could have created the tag himself if he knows the shared secret key ($k$).
One-way function	A family of functions ($E_{pk}$) computable by an efficient algorithm, but for which computing pre-images (finding $m$ from $c=E_{pk}(m)$) is practically infeasible.	The RSA function $RS{A}_{n,e}:x\mapsto x^e$ is an example of a one-way function, provided the factors $p$ and $q$ of $n$ are not known.
Trapdoor function	A one-way function where some secret information (the trapdoor information, $sk$) enables the efficient computation of the function’s inverse.	The RSA function is a trapdoor function, with the trapdoor information being the decryption exponent $d$.
Hash and Sign	A generic construction method that takes a signature scheme that works on “short messages” and a collision-resistant hash function to create a signature scheme that works on “long messages”,.	It is the solution to problems with basic schemes (like Textbook RSA), where the signer computes ${\text{Sign}}_d(m)=H(m{)}^d(\mathrm{mod}N)$ instead of signing $m$ directly,.
Textbook RSA Signatures	A basic digital signature scheme where signing is $m^d\mathrm{mod}N$ and verification is ${\sigma }^e=m\mathrm{mod}N$.	This scheme is vulnerable to a no-message attack: an adversary selects a random signature $\sigma$ and computes the corresponding message $m={\sigma }^e\mathrm{mod}N$.
Full-domain hash function	A hash function ($h$) whose output values range through the full set $Z_n=0,\dots ,n-1$ of the RSA function’s domain.	Full-domain-hash RSA signatures are provably secure in the random oracle model.
Random oracle model	A theoretical model where a hash function ($h$) is assumed to operate as a random function, and the adversary must call an oracle (a “black box”) to obtain hash values.	This model is used to develop security proofs by reduction for cryptographic schemes.
PKI (Public Key Infrastructure)	A set of policies and procedures designed to manage (create, distribute, store, revoke) digital certificates.	A PKI can be based on Certificate Authorities (CAs), Web of Trust (PGP/GnuPG), or Blockchain.
Digital Certificate	A data structure that binds an identity and a purpose to a public key,.	Certificates include parameters like the issuer, the expiration date, and the purpose of the public key.
Certification Authority (CA)	An entity that checks a user’s identity (ID) and issues a certificate signed with the CA’s private key.	Anyone who trusts the CA (and knows its public key) can verify that a public key belongs to the claimed identity.
X.509	An ITU standard that defines the structure of certificates and how certificate validation works.	This standard is used in protocols such as SSL/TLS, IPSec, S/MIME, and SSH.
Certificate Chain	A sequence of certifications where one party certifies the key of another, who certifies the key of a third, and so on,.	This structure is necessary when Alice needs to trust Wilma’s key, but only knows Bob, who certified Wilma’s key.
Certificate revocation lists (CRL)	A list maintained by every certificate authority detailing revoked certificates.	Necessary if a private key is lost or compromised. A major problem is that CRLs only work if the user is online.
Time stamping authority (TSA)	A trusted service (often provided by CAs) that certifies that an electronic document existed at a given point in time.	Used to prove that a signature is valid even after the certificate’s expiration date, provided the document was signed before that date.
Homomorphic Encryption	Encryption algorithms where an operation performed on the plaintexts corresponds to an operation performed on the ciphertexts.	ElGamal encryption is homomorphic with respect to the multiplication of plaintexts and ciphertexts. Paillier encryption is also homomorphic.
OAEP (Optimal Asymmetric Encryption Padding)	A randomized preprocessing scheme used with public-key encryption schemes (like RSA) to protect against attacks.	Using OAEP prevents attacks such as Bleichenbacher’s 1-Million-Chosen-Ciphertext Attack and prevents the small-message-space attack because it is probabilistic,.
Chosen-ciphertext attack (CCA)	An attack where an adversary (Eve) can access the decryption device to obtain plaintexts for ciphertexts she chooses, in an attempt to decrypt a target ciphertext.	Basic RSA encryption is vulnerable to this attack. An adaptive CCA allows the adversary to modify their choices based on prior decryption results.
Elliptic Curve Discrete Logarithm Problem (ECDLP)	The problem of computing the integer $k$ from a given point $P$ in a cyclic subgroup $⟨Q⟩$, such that $P=kQ$.	The security of Elliptic Curve Cryptography (ECC) schemes, such as ECDSA, is based on the assumption that solving the ECDLP is practically infeasible,.
Domain parameters (ECC)	The parameters defining an elliptic curve scheme: the base field ($F_q$), curve coefficients ($a,b$), base point ($Q$) of order $n$, and the cofactor $h$.	These parameters must be publicly known for ECC protocols, such as the Diffie–Hellman key agreement protocol,.

Digital Signature

The process of generating and verifying a digital signature leverages the inherent separation and unique functions of public and private key pairs, ensuring authenticity and non-repudiation.

The Process of Generating and Verifying a Digital Signature

Signing

To create a digital signature ($\sigma$) for a message ($m$), the signer (Alice) uses her private key ($\mathbf{sk}$), which must be kept secret. The signing function, $\text{Sign}(\mathbf{sk},m)$, computes a tag ($\sigma$) based on the message and Alice’s secret key.

For large messages, the common practice is to use the Hash and Sign paradigm: Alice first applies a collision-resistant hash function ($H$) to the message ($m$) to create a hash value, and then she applies her signing algorithm (which is based on her private key) to that hash value. For example, in RSA, the signature is $\sigma =H(m{)}^d(\mathrm{mod}N)$, where $d$ is the secret decryption exponent. The signature generated depends entirely on the message and the secret key known only to the signer.

Signing Key Used	Context
Sender’s Private Key ($\mathbf{sk}$ or $\mathbf{d}$)	The secret key is used to compute the digital signature/tag ($\sigma$), which is unique to the signer and the message.

Verification

To verify the signed message $(m,\sigma )$, the recipient (Bob) uses the signer’s (Alice’s) public key ($\mathbf{pk}$), which can be distributed publicly. The verification process, $\text{Vrfy}(\mathbf{pk},m,\sigma )$, checks the correctness of the tag against the message using the public key.

In the case of Hash and Sign RSA, Bob computes $H(m)$ from the message, and then uses Alice’s public key exponent ($e$) to check if ${\sigma }^e=H(m)(\mathrm{mod}N)$. If the equation holds true, the signature is accepted. The verification step must be possible for an unbiased third party without needing access to the signer’s secret key, making digital signatures publicly verifiable.

Verification Key Used	Context
Sender’s Public Key ($\mathbf{pk}$ or $\mathbf{e}$)	The public key is used to verify the correctness of the signature ($\sigma$).

Digital signatures provide properties like non-repudiation, meaning the signer cannot truthfully deny having signed the message if the signature checks out, because only the secret key could have produced it, and that key is known only to the signer.

Comparison: Digital Signatures vs. Encryption Key Usage

Public-key cryptography typically involves key pairs where the keys perform inverse operations. Digital signatures use the keys in the inverse order compared to public-key encryption to achieve their respective goals—authenticity versus confidentiality.

In public-key encryption:

• Encryption (Confidentiality) uses the recipient’s public key ($\mathbf{pk}$) to encrypt the message, $c=E_{\mathbf{pk}}(m)$.
• Decryption (Confidentiality) uses the recipient’s private key ($\mathbf{sk}$) to recover the plaintext, $m=E_{\mathbf{sk}}^{-1}(c)$.

In digital signatures:

• Signing (Authenticity/Non-repudiation) uses the signer’s private key ($\mathbf{sk}$).
• Verification (Authenticity/Non-repudiation) uses the signer’s public key ($\mathbf{pk}$).

The table below contrasts the key usage for achieving confidentiality (Encryption) and authenticity/non-repudiation (Digital Signatures):

Goal	Key Used (Sender’s Perspective)	Key Used (Receiver’s Perspective)
Encryption (Confidentiality)	Uses Recipient’s Public Key ($\mathbf{pk}$) to encrypt the message.	Uses Recipient’s Private Key ($\mathbf{sk}$) to decrypt the ciphertext.
Digital Signature (Authenticity)	Uses Sender’s Private Key ($\mathbf{sk}$) to sign the message.	Uses Sender’s Public Key ($\mathbf{pk}$) to verify the signature.

This inverse relationship in key usage is fundamental: the signature mechanism ensures that only the secret key holder could have signed a message, while the encryption mechanism ensures that only the secret key holder can read the message. You can think of digital signing as a reversal of the encryption process: instead of locking a box with a public key and unlocking it with a private key (encryption), you “lock” a document with a private key, and anyone can “unlock” it using the public key to confirm the unique origin (signing).

Why we sign the Hash of a message rather than the message itself.

The practice of signing the hash of a message, rather than the message itself, is a fundamental technique known as Hash and Sign or the hash-then-decrypt paradigm. This construction is used to overcome performance limitations, provide enhanced security against forgery attacks, and ensure the cryptographic properties of the signature scheme are maintained.

The Hash and Sign approach is a generic construction that takes a signature scheme designed for “short messages” (like RSA) and a collision-resistant hash function, and transforms it into a signature scheme that works reliably on “long messages”.

The two primary reasons for using a cryptographic hash function ($H$) are performance and security. The signer computes $H(m)$ and then generates the signature $\sigma$ using their secret key, such that $\sigma =H(m{)}^d(\mathrm{mod}N)$ (in the context of RSA signatures).

Performance: Why is signing a large file directly slow?

Digital signature schemes based on public-key cryptography, such as RSA, operate on numbers that are typically restricted in size by the modulus ($N$).

• Size Restriction: Basic RSA signature schemes can only sign messages ($m$) that, when encoded as numbers, are less than the modulus $N$. Typically, if $N$ is a 1024-bit number, the message $m$ must be at most 128 ASCII characters long. Most documents are much larger, making it impossible to sign them directly with the basic scheme.
• Computational Efficiency: Cryptographic signature algorithms, such as RSA, involve computationally intensive modular exponentiation (e.g., $m^d\mathrm{mod}N$). If the message $m$ were large, performing this exponentiation would be extremely slow, as the runtime complexity of exponentiation is related to the size of the numbers being operated on.
• Hash Function Advantage: The hash function reduces a message of arbitrary length to a short digital fingerprint of less than 100 bytes. Since the signer only performs the exponentiation on this short, fixed-length hash value ($H(m)$), the signing process remains efficient regardless of the original message size.

Integrity: How does this ensure the message hasn’t been changed?

The use of a collision-resistant hash function ensures that any alteration to the original message ($m$) will be detected during verification.

• Binding the Signature to the Message: The signature $\sigma$ is created specifically for the hash value $H(m)$. When verifying, the recipient (Bob) recomputes the hash of the received message ($m$) and checks if the recovered value from the signature (${\sigma }^e$) matches the recomputed hash value.
• Collision Resistance: If an adversary were to modify the message to $m^{\prime }$ (where $m^{\prime }\ne m$), the output hash value $H(m^{\prime })$ would almost certainly be different from $H(m)$ because the hash function is collision-resistant. Since the original signature $\sigma$ was created based on $H(m)$, $\sigma$ will not be a valid signature for the new message $m^{\prime }$. This prevents an attacker from taking a signed message $(m,\sigma )$ and using $\sigma$ as a valid signature for a modified message $m^{\prime }$.

Non-Repudiation: Explain how this prevents the sender from denying they sent the message.

The combination of the private key (for signing) and the integrity properties of the hash function ensures non-repudiation.

1. Unique Origin: Digital signatures, unlike Message Authentication Codes (MACs), are based on a public/private key pair. The signature $\sigma$ can only be generated by the secret key ($\mathbf{sk}$) known only to the signer (Alice).
2. Verifiability: The signature is publicly verifiable using Alice’s public key ($\mathbf{pk}$). Any third party (like a judge or Bob) can verify that the signature $\sigma$ corresponds to the specific content defined by the hash value $H(m)$.
3. Preventing Denial (Repudiation): Because only Alice possesses the secret key necessary to generate $\sigma$, if the signature verification checks out, Alice cannot truthfully deny having signed the message (or its hash).
4. Security against Forgery: If the basic signature scheme were used without a hash function, it could be vulnerable to attacks where an adversary could forge a signature for a “random” message (a no-message attack on Textbook RSA) or create signatures by combining existing ones. By signing the hash value (using the Hash and Sign paradigm), these structural attacks are prevented, ensuring that a signature found to be valid must have genuinely originated from the secret key holder for that specific message.

Therefore, the non-repudiation property holds because the secret key is uniquely associated with the signer, and the hash function ensures that the unique signature is inextricably linked to the specific message content.

---

Analogy: You can think of a digital signature as a seal made from custom wax. To sign a large contract (the message), you wouldn’t pour your custom wax over the entire document (which would be slow and bulky). Instead, you crumple the contract into a small ball, take a fixed-size photograph of that ball (the hash value), and then stamp the photograph with your unique private seal (signing with the private key). Anyone can look at the photograph and confirm the seal is genuine using your public seal (publicly verifiable). Because the photograph (hash) captures the unique state of the contract, if anyone changes the contract content, the picture (hash) instantly changes, and the original seal (signature) is no longer valid for the modified contract. This confirms both authenticity and integrity.

Public Key Infrastructure

Roles in a Public Key Infrastructure (PKI)

A Public Key Infrastructure (PKI) is defined as a set of policies and procedures designed to manage digital certificates, including their creation, distribution, storage, and revocation.

Role	Definition/Function
Certificate Authority (CA)	The CA is the entity that checks a user’s identity (ID) and issues a certificate. The certificate is signed using the CA’s private key, effectively certifying that a specific public key belongs to the claimed identity. Anyone who trusts the CA and knows the CA’s public key can verify the authenticity of the user’s public key.
Registration Authority (RA)	The sources provided do not explicitly define the role of a Registration Authority (RA).

Root vs. Intermediate CA: Explaining the Hierarchy

The PKI can be based on a model of multiple CAs, which often forms a hierarchy known as a Certificate Chain.

• Hierarchy via Certificate Chains: A certificate chain involves a sequence of certifications where one party certifies the key of another, who certifies the key of a third, and so on. This is necessary when, for example, Alice needs to trust Wilma’s public key, but Alice only directly trusts Bob, and Bob has certified Wilma’s key.
• Root CA (Implied): In a certificate chain, trust originates from the top. While the term “Root CA” is used in the context of revocation, the concept refers to the highest-level authority in the chain whose public key is pre-configured and trusted (e.g., in a web browser’s certificate store). Root certificates are self-signed, meaning the private key corresponding to the public key being certified is used to sign the issued certificate.
• Intermediate/Subordinate CAs (Implied): The source refers to Delegated CAs or a chain of trust (P1 certifying P2, P2 certifying P3, etc.). Delegated CAs are CAs whose public keys are configured in a system and are authorized to issue certificates or recommend other CAs.

Consequences of a Compromised Root CA

The compromise of any CA, particularly a high-level one like a root or delegated CA, has severe consequences for the PKI’s security model.

• Complete Compromise: The sources note that a major problem with X.509/CA-based PKIs is that the compromise of any one CA suffices to forge fraudulent certificates and leads to a complete compromise of the system.
• Revocation Necessity: If a private key (including that of a Root CA) is lost or stolen, the corresponding certificate must be revoked. However, the sources note that revocation of root certificates is a specific challenge that is not addressed easily.
• Removing Trust: To revoke trust in a compromised root certificate, the certificate must be manually removed from the operating system’s and web browser’s trust store.

The compromise of a Root CA means that all certificates signed below it in the hierarchy could potentially be forged, invalidating the trust relationship for all users relying on that Root CA’s public key.

The Certificate Lifecycle

1. Issuance (Creation): A user (Alice) generates a public/private key pair. She submits her identity (ID) and public key ($\mathbf{pk}$) to a Certificate Authority (CA). The CA checks Alice’s ID and then issues a certificate that is signed with the CA’s private key. This certificate binds Alice’s identity and purpose to her public key. The certificate includes parameters such as the issuer, the purpose of the public key, and an expiration date.
2. Distribution and Use: Alice can distribute her public key or digital signatures along with the certificate she received from the CA. Recipients verify the certificate using the CA’s publicly known public key.
3. Validation: Recipients must check the validity period to ensure that the certificate has not expired.
4. Revocation: If the private key associated with the certificate is lost or stolen, the certificate must be revoked.

Certificate Revocation List (CRL)

A Certificate Revocation List (CRL) is a list maintained by every certificate authority (CA) that details certificates which have been revoked.

• Purpose: The CRL is necessary to announce that a certificate is no longer trustworthy, typically because the associated private key has been lost or compromised.
• Limitation: A major drawback of CRLs is that they only work if the user is online.

Online Certificate Status Protocol (OCSP)

The sources do not contain any information regarding the Online Certificate Status Protocol (OCSP).

Why a Certificate Might Be Revoked Before It Expires

Certificates are issued with an expiration date specifically to reduce the risk that a private key is compromised and then abused for an indefinite amount of time.

However, revocation may be necessary before the expiration date for security reasons.

• Loss or Compromise of the Private Key: If the owner’s private key ($\mathbf{sk}$) is lost or stolen, the corresponding certificate must immediately be revoked. If the private key is compromised, an attacker could successfully forge signatures or decrypt confidential data intended for the legitimate user, rendering the certificate useless and dangerous for future use.

Key Fields Found in an X.509 Digital Certificate

X.509 is an ITU standard that defines the structure of digital certificates and how certificate validation works. The key fields found in an X.509 certificate include:

• Subject Name: Names the user whose public key is certified.
• Subject Public-Key Info: Identifies the algorithm and the user’s public key.
• Issuer Name: Names the Certificate Authority (CA) that created the certificate.
• Serial Number: A unique identifier for each CA.
• Algorithm: An identifier for the algorithm used to sign the certificate.
• Validity Period (or Expiration Date): Certificates include an expiration date. A recipient must check this period to ensure the certificate has not expired.
• Purpose of the Public Key: Certificates bind an identity and purpose to a public key.
• Signature: This field contains the hash of all the other fields, signed with the CA’s signing key.

The Binding: How the Certificate Binds a Public Key to a Specific Identity

A digital certificate serves as a data structure that binds an identity (and purpose) to a public key. This binding addresses the core problem in public-key cryptography: establishing the authenticity of a public key.

For instance, if Bob receives a document signed by Alice’s public key ($\mathbf{pk}$), he needs assurance that $\mathbf{pk}$ truly belongs to Alice and was not fraudulently created. The certificate solves this by:

1. Certification Authority (CA) Verification: A trusted entity, the Certificate Authority (CA), checks the user’s identity (ID).
2. Creation of the Binding: The CA then issues a certificate containing the user’s identity (the Subject Name) and their public key (Subject Public-Key Info).
3. Authentication: By signing the certificate data with its own private key, the CA vouches for the link between that public key and the stated identity.

Anyone who trusts the CA and knows the CA’s public key can verify the certificate, thereby confirming that the public key belongs to the claimed identity.

The Signature: Who Signs the Certificate Itself?

The certificate is signed by the Issuer/Certification Authority (CA).

• The CA uses its own private key ($\mathbf{sk}$) to sign the certificate after checking the user’s ID.
• The signature field in the X.509 certificate contains the hash of all the other non-signature fields, which is then signed with the CA’s signing key.
• To validate the certificate, the recipient needs to know the authority’s public key and trust that authority. The recipient verifies the CA’s signature by computing the hash of the certificate fields and checking that it matches the signed hash.

In the case of a Root Certificate, which sits at the top of the trust hierarchy, the certificate is self-signed, meaning the private key corresponding to the public key being certified is used to sign the issued certificate.

Exam Style Questions

Short Answer Exam Questions

Question	Answer	Source Citation
Q1: Digital signatures are said to possess the property of “non-repudiation.” Explain what this means and contrast it with the security property of Message Authentication Codes (MACs).	Non-repudiation means the signer cannot truthfully deny or repudiate having signed the message once the signature verifies as correct. MACs do not have this property because the verifier (Bob) shares a secret key ($k$) with the sender (Alice) and thus could have created the tag himself.	,
Q2: Describe the keys used in a digital signature scheme during the signing process versus the verification process.	The sender’s secret key ($\mathbf{sk}$) is used to compute the digital signature/tag ($\sigma$) on the message. The sender’s public key ($\mathbf{pk}$) is used by anyone to verify the correctness of the tag.	,
Q3: What is the primary motivation for employing the “Hash and Sign” paradigm in digital signature schemes, and what essential cryptographic tool is required for this approach?	Hash and Sign is a generic construction used to transform a signature scheme that works only on “short messages” into one that works on “long messages”. This process requires the use of a collision-resistant hash function ($H$).	,,
Q4: List three mandatory fields found in an X.509 digital certificate and state who is responsible for signing the certificate itself.	Key fields include the Subject Name (the user whose public key is certified), the Subject public-key info (identifies the algorithm and user’s public key), and the Validity Period (or expiration date). The certificate itself is signed by the Issuer Name or Certification Authority (CA) using the CA’s private key.	,,
Q5: Discuss one significant security flaw of Textbook RSA Signatures and how the adversary executes the attack.	Textbook RSA Signatures are vulnerable to a no-message attack. An adversary, knowing only the public key $(N,e)$, selects a random signature $\sigma$ and then computes the corresponding message $m={\sigma }^e\mathrm{mod}N$. Since $\sigma$ is the valid signature for $m$, the adversary has forged a signature on a random message.	,

Scenario-Based Long-Form Questions

Scenario Question 1: Key Usage and Non-Repudiation Contrast

Alice and Bob are establishing secure communications. Alice wishes to send a confidential message to Bob, and separately, Bob needs to sign a contract to send to Alice, guaranteeing that he cannot later deny signing it.

1. In the context of public-key encryption (for confidentiality), which key is used by Alice to encrypt the message, and which key is used by Bob to decrypt it?
2. In the context of digital signatures (for non-repudiation), which key is used by Bob to create the signature, and which key is used by Alice to verify it?
3. Explain, using the concept of digital signatures, why Bob is prevented from repudiating the signed contract, drawing a clear contrast between this system and a system using MACs (Message Authentication Codes).

Answer	Source Citation
1. Encryption (Confidentiality): To encrypt a message ($m$) for confidentiality, Alice uses Bob’s public key ($\mathbf{pk}$). Bob then uses his corresponding secret key ($\mathbf{sk}$) to recover the message.	,
2. Digital Signature (Non-repudiation): To create the signature ($\sigma$), the signer (Bob) must use his secret key ($\mathbf{sk}$). To verify the signature, the recipient (Alice) uses Bob’s corresponding public key ($\mathbf{pk}$).	,
3. Non-Repudiation Explanation: A digital signature provides the property of non-repudiation, meaning the signer (Bob) cannot truthfully deny having signed the message once the verification checks out. This is because the signature ($\sigma$) can only be generated using Bob’s secret key, which is assumed to be known only to him, making the signature uniquely attributable. This contrasts sharply with MACs, which do not provide non-repudiation. If Bob used a MAC to authenticate the contract, Alice could not trust the tag because, since she knows the secret key ($k$) required for verification, she could have created the tag herself. Digital signatures, conversely, are publicly verifiable, allowing an unbiased third party (like a judge) to verify the signature using only the public key without needing access to the signer’s secret.	,,

Scenario Question 2: Certificate Integrity and Revocation

A company issues a digital certificate for its new employee, David.

1. What is the purpose of the digital certificate in this context, and what key binding does it establish?
2. If David’s private key is later compromised, what mechanism must the issuing Certificate Authority (CA) use to communicate that the certificate should no longer be trusted, and what major operational limitation does this mechanism have?
3. Why is the CA’s signature field essential for the integrity of David’s certificate when a third party is validating it?

Answer	Source Citation
1. Certificate Purpose and Binding: A digital certificate is a data structure designed to bind an identity (and purpose) to a public key. This resolves the issue of authenticity by allowing anyone who trusts the CA to verify that a public key has genuinely been generated by the claimed user. The certificate is part of the overall Public Key Infrastructure (PKI), which manages certificate lifecycles.	,,
2. Revocation Mechanism and Limitation: If David’s private key is lost or stolen, the certificate must be revoked. The CA maintains a Certificate Revocation List (CRL), which details certificates that have been revoked. The major limitation of CRLs is that they work only if the user is online to check the list.	,
3. CA Signature and Integrity: The signature field of an X.509 certificate contains the hash of all the other fields, signed with the CA’s signing key. When a recipient validates the certificate, they compute the hash of the non-signature fields and check that it matches the signed hash. This ensures the certificate’s integrity, proving that the content (including David’s identity and public key) has not been tampered with since the CA issued and signed it.	,