PGP Public Key Update Process for Encryption Services

This document outlines the mandatory process to update PGP public keys used for Encryption Services. It ensures consistent handling, proper tracking through security Change Requests (CRs), and validation against enterprise security policies.

1. Preparation: Generate a PGP Public Key

Use an OpenPGP-compliant tool (e.g., GnuPG, Symantec Encryption Desktop) to generate a key pair.

gpg --full-generate-key

This creates:

Private key (keep secret): Used to decrypt data sent to you
Public key (to be submitted): Used by the sender to encrypt data for you.

OpenPGP Public Key Format: Ensure the key is exported in ASCII-armored format.

-----BEGIN PGP PUBLIC KEY BLOCK----- 
... [Base64 Data] ... 
-----END PGP PUBLIC KEY BLOCK-----

Key Requirements:

Algorithm: RSA (minimum 4096-bit).
Expiration: Keys must have an expiration date (max 2 years recommended).
Do not submit binary keys or private keys.

2. Calculate the Public Key Fingerprint

Generate the fingerprint to ensure key integrity and traceability. The fingerprint allows the security team to verify the key via a secondary channel (out-of-band verification).

Command Example:

gpg --fingerprint [KeyID]

Output Example:

pub 4096R/ABC12345 2024-01-01 [expires: 2026-01-01] 
Key fingerprint = 5D96 6D12 A35B 9D8C 2F01 7E44 ABC1 2345 6789 0DEF

3. Open a Security Change Request (CR)

Submit a CR in the appropriate ITSM/change management system with the following content:

Title: PGP Public Key Update for Encryption Services – [User/Service Name]
Requester: Requester’s full name and contact information
PGP Public Key: Full key block in OpenPGP ASCII-armored format
Key Type: (e.g., RSA 4096)
Fingerprint: Full hexadecimal fingerprint (as shown in Step 2)
Affected Systems/Accounts: List of encryption flows or service accounts
Justification: Reason for key update (e.g., annual rotation, expiry, compromise)
Effective Date/Time: Requested implementation window
Implementation Steps: Including validation and rollback plan

IMPORTANT: If multiple keys are used for the same account, the fingerprints of all associated keys must be included in the Change Request (CR).

4. Emergency Revocation Process (Key Compromise)

In the event that a private key is suspected to be lost, stolen, or compromised, immediate action is required to prevent unauthorized data decryption.

Step 1: Immediate Notification Send an urgent email to the Security Architecture Team (SAT) immediately.

Email: [email protected]
Subject: URGENT: PGP Key Compromise – [User/Service Name]
Content: You must include the Key ID, the Fingerprint, and an explicit request to immediately suspend encryption services for this key.

Step 2: Remediation Once the compromised key has been disabled, follow the standard procedure (Sections 1 through 3) to generate and register a new key pair.

5. Trusted Signatory Requirement

IMPORTANT: The CR must be reviewed and signed by designated security personnel listed in the current Trusted Source List (TSL). This ensures that only authorized personnel can approve changes affecting secure service access mechanisms. If the CR is submitted without a valid signature from a TSL entity, it will be rejected.

6. Security Review & Approval

The security team will review the CR, verifying:

Valid key format (OpenPGP ASCII-Armored mandatory)
Accuracy of fingerprint against the submitted key
Compliance with key strength policies (e.g., no RSA 1024-bit keys)

7. Implementation: Secure Access for Encryption Users

When onboarding new encryption keys, administrators must record the PGP public key fingerprint and ensure it matches pre-shared values delivered through trusted channels before activating access. This process is not optional; regulatory requirements mandate that the correct fingerprint must be verified to comply with security controls and maintain certifications such as ISO/IEC 27001 and NIST compliance.