ID: SECURITY-POL000269-STN00005 Driver: Peleus Uhley Classification: Internal

Version: 9.0
Cryptography Standard
# 1. Overview
Cryptography helps ensure the security and integrity of data managed by Adobe.
Where cryptography is used, this Standard defines the minimum requirements that
must be employed.
# 2. Scope
Except as otherwise noted, this Standard applies to all Adobe personnel, including
any regular employee, Adobe-paid temporary employee, or contingent worker
(including agency temporary employees, independent contractors, and vendor
employees), as well as interns of an Adobe group company.
There may be requirements in this Standard that apply only to those environments
that handle specific classifications of data, as described in the Data
Classification and Handling Standard, for which Adobe has unique obligations (for
example, cardholder data or electronic protected health information). If such
additional requirements are applicable, they will be called out separately within
this document. Any environment handling such data must comply with all generally
applicable requirements and any additional requirements specified for such data.
This Standard does not prescribe requirements for keys used for logical access.
Please refer to the Key Management Standard for such requirements.
Where cryptography is used to protect the confidentiality or integrity of sensitive
data, the relevant uses must be employed in accordance with this Standard. For
example, the protection of Restricted or Confidential data in transit or at rest.
# 3. Statement
Contents
1. Overview
2. Scope
3. Statement
3.1. Block Ciphers
3.2. Hash Functions
3.3. Random Number Generation
3.4. Asymmetric Key Algorithms
3.5. TLS
3.6. Certificates
3.7. Access, Distribution, Rotation, and Storage
3.8. Requirements Specific to Cardholder Data Environments
4. Violations
5. Exceptions
6. Definitions
7. Responsibilities
8. Governing Policy
9. References
10. Document Properties
11. Document History
## 3.1. Block Ciphers
3.1.1 Advanced Encryption Standard (AES) must be used exclusively when using block
ciphers to encrypt data.
3.1.2 The minimum key length is 128 bits.
3.1.3 Electronic Code Book (ECB) mode is prohibited. Galois/Counter (GCM), GCM-SIV,
Counter with CBC-MAC (CCM) and Encrypt-then-Authenticate-then-Translate (EAX) are
preferred. Counter (CTR) and Cipher Block Chaining (CBC) modes are acceptable if
needed.
3.1.4 Appropriate Initialization Vector (IV)/Nonce must be used, based on the mode.
For example, Random IV for CBC and Non-repeating Nonce for CTR/GCM.
3.1.5 Use of older standards or non-standard block ciphers is prohibited for
encrypting data. It is acceptable to use them for decrypting data.
## 3.2. Hash Functions
3.2.1 The Security Hashing Algorithm (SHA) SHA2 family of hash functions must be
used where collision resistance is required; for example, digital signatures.
3.2.2 SHA1 is acceptable to use in applications where collision resistance is not
required; for example, Hash-Based Message Authentication Code (HMAC) for certain
Transport Layer Security (TLS) ciphers.
3.2.3 Single iteration of unsalted hash functions is prohibited for password
storage in an authentication system. Slow hash functions like Password-Based Key
Derivation Function 2 (PBKDF2), bcrypt, or scrypt must be used.
## 3.3. Random Number Generation
3.3.1 Always use a cryptographically secure sources of random numbers. The sub-
items list examples:
a) Java/Android applications and services use java.security.SecureRandom.
b) Apple OS X (10.7+) / iOS (2.0+) applications and services use
SecRandomCopyBytes.
c) .Net Framework applications and services use RNGCryptoServiceProvider or RNGCng.
d) Windows applications and services use BCryptRandom.
e) On Unix-like systems use /dev/urandom or /dev/random.
## 3.4. Asymmetric Key Algorithms
3.4.1 Rivest, Shamir, and Adelman (RSA) algorithm may be used for encryption, key
exchange, and digital signatures. The minimum key length requirement is 2048 bits.
RSA encryption must use only OAEP or RSA-KEM padding modes with SHA2 as the
underlying KDF.
3.4.2 Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA) may be used for digital signatures. The minimum key length
requirement is 2048 bits for DSA and 256 bits minimum field size for EC version.
One of the three NIST approved curves (P256, P384, P521) must be used.
3.4.3 Elliptic-Curve Diffie Hellman (ECDH) may be used for key exchange only, with
256 bits minimum field size curve. One of the three NIST approved curves (P256,
P384, P521) must be used.
3.4.4 Diffie-Hellman may be used for key management only. The minimum key length
requirement is 2048 bits. Elliptic-Curve Diffie-Hellman is preferred if possible.
3.4.5 Asymmetric keys must be replaced when the paired certificate expiration date
is reached.
## 3.5. TLS
3.5.1 TLS 1.2 is the minimum required TLS version. Supporting TLS 1.3 (or newer) is
strongly suggested for existing services. New services must use only TLS 1.3 and
newer unless there is a strong reason to support 1.2. As an example, if Adobe has a
contractual requirement to support older desktop applications as a core dependency.
All SSL versions and all TLS versions prior to 1.2 must not be used. Services that
use TLS 1.2 must not use static RSA keys in the key exchange.
3.5.2 At least one Authenticated Encryption with Associated Data (AEAD) mode cipher
with a minimum key length of 128 bits must be supported.
3.5.3 Key exchange mechanisms must have at least 2048-bit RSA or equivalent (EC
field size >= 224 bits) security.
3.5.4 Known TLS vulnerabilities (such as POODLE or ROBOT) must be mitigated. All
new vulnerabilities disclosed in TLS must be addressed as per the timelines in the
Vulnerability Management Standard.
3.5.5 Applications, when acting as TLS clients, must validate the certificates from
the servers.
## 3.6. Certificates
3.6.1 Valid certificates must be used, that were signed by a certificate authority
(CA). Certificates must have the following minimum-security properties
a) Use an RSA/DSA encryption algorithm with a key size of at least 2048 bits
b) where applicable, the subject alternate name (SAN) or common name (CN) must be
specified
c) signed by a trusted CA, to ensure it can be verified directly or indirectly to a
root level CA certificate.
d) the certificate validity period is at most 398 days
3.6.2 Wildcards must only be used for genuine need, where individual certificates
would not be operationally feasible. A request for a wildcard certificate must be
approved by director level or above.
3.6.3 Certificates must be signed using the Adobe PKI service, except when used for
mutual TLS. For mutual TLS self-signed certificates are acceptable so long as they
are validated.
3.6.4 Certificate verification must not be disabled. All TLS sessions must validate
the authenticity of certificates against a trusted certificate authority chain.
They should also use OCSP or CRL checking to verify that the certificate has not
been revoked.
## 3.7. Access, Distribution, Rotation, and Storage
3.7.1 Access to key generation scripts, cryptographic keys, or cryptographic
procedures must be restricted to authorized personnel through the use of
requirements described in the Logical Access Policy and related Standards.
3.7.2 For distribution and management of keys, please refer to the Key Management
Standard.
3.7.3 Retired or revoked keys must be securely stored or destroyed.
3.7.4 A key does not need to be changed at a specified interval. However, the key
must be changed if compromised, suspected of being compromised, or at end of life.
3.7.5 Storage of private keys must meet at least one of the following criteria:
• The key-encrypting key is at least as strong as the data-encrypting key and is
tied separately from the data-encrypting key.
• Keys are stored as at least two full-length key components or key shares.
## 3.8. Requirements Specific to Cardholder Data Environments
Cardholder Data Environments (CDEs) must adhere to all requirements within this
document, including the requirements mentioned in this section. All other
environments are not required to adhere to the requirements in this section.
3.8.1 Currently, no additional requirements are needed.
# 4. Violations
Minor issues complying with this Standard are non-punitive and are part of Adobe’s
continual improvement. Minor non-compliance will be dealt with at the local team or
service level.
Major violations that involve violation of laws, violation of written agreements,
or willful disregard of the Standard may be subject to disciplinary action, after
careful review of the violation, including termination of employment or contract.
# 5. Exceptions
Exceptions are subject to approval and are granted based on having both a
legitimate business justification and having sufficient mitigating controls in
place. Exceptions are only ever temporary and never permanent. To request an
exception for consideration, please go to the Technology Policies and Standards
site and complete the exceptions request form.
# 6. Definitions
<table><tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Advanced Encryption Standard (AES)</td> <td> The Advanced Encryption
Standard, or AES, is a symmetric-key block cipher chosen by the U.S. government in
2001 to protect classified information and is implemented in software and hardware
throughout the world to encrypt sensitive data.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Authenticated Encryption with Associated Data (AEAD)</td> <td> A form of
encryption which simultaneously provides confidentiality, integrity, and
authenticity assurances on the data. These attributes are provided under a single,
easy to use programming interface.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Cardholder Data</td> <td> Refer to Cardholder Data Protection
Standard</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Cardholder Data Environment</td> <td> Refer to Cardholder Data Protection
Standard</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Cipher Block Chaining (CBC)</td> <td> Cipher Block Chaining, or CBC, is a
mode of operation for cryptographic block ciphers. CBC was introduced in 1980 and
is an encryption algorithm designed to provide confidentiality. The mode is defined
in the NIST publication FIPS 81.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Counter Mode (CTR)</td> <td> The Counter mode, or CTR, is a mode of
operation for cryptographic block ciphers. CTR was introduced in 1979 and is an
encryption algorithm designed to provide confidentiality. The mode is defined in
the NIST publication SP 800- 38A.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Counter with CBC-MAC (CCM)</td> <td> Mode of operation for cryptographic
block ciphers. It is an authenticated encryption algorithm designed to provide both
authentication and confidentiality.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Data Encryption Standard (DES)</td> <td> The Data Encryption Standard, or
DES, is a symmetric-key block cipher designed in 1975 and is now considered
insecure.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Diffie-Hellman</td> <td> Diffie-Hellman key exchange, or DH, is a method
of securely exchanging cryptographic keys over a public channel. DH was first
published in 1976. The scheme is defined in U.S. Patent 4,200,770 from 1977
(expired) and is now in the public domain.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Digital Signature Algorithm (DSA)</td> <td> The Digital Signature
Algorithm, or DSA, is a digital signature algorithm. DSA was introduced in 1991 and
published in the NIST publication FIPS 186. DSA is covered by U.S. Patent 5,231,668
and has been made available world-wide royalty free by the U.S. Government.</td>
</tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Electronic Code Book (ECB)</td> <td> Electronic Codebook, or ECB, is a
mode of operation for cryptographic block ciphers. EBC was introduced in 1980 and
is an encryption algorithm designed to provide confidentiality. The mode is defined
in the NIST publication FIPS 81.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Elliptic Curve Digital Signature Algorithm (ECDSA)</td> <td> Elliptic
Curve Digital Signature Algorithm, or ECDSA, is a variant of the Digital Signature
Algorithm (DSA) that uses elliptic curve cryptography. The algorithm is defined in
the NIST publication FIPS 186-2.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Elliptic-Curve Diffie Hellman (ECDH)</td> <td> Elliptic-curve Diffie-
Hellman, or ECDH, is an anonymous key agreement protocol that allows two parties,
each having an elliptic-curve public-private key pair, to establish a shared secret
over an insecure channel. ECDH is defined in the NIST publication SP 800-56A.</td>
</tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Encrypt-then- Authenticate-then-Translate (EAX)</td> <td> Encrypt-then-
Authenticate-then-Translate, or EAX, is a mode of operation for cryptographic block
ciphers. EAX was introduced in 2003 and is an encryption algorithm designed to
provide both confidentiality and authenticity as well as authentication assurances
on additional data.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Galois/Counter Mode (GCM)</td> <td> Galois/Counter Mode, or GCM, is a
mode of operation for cryptographic block ciphers. GCM was introduced in 2003 and
is an encryption algorithm designed to provide both confidentiality and
authenticity as well as authentication assurances on additional data. The mode is
defined in the NIS publication SP 800-38D.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Hash-Based Message Authentication Code (HMAC)</td> <td> A specific type
of message authentication code (MAC) involving a cryptographic hash function and a
secret cryptographic key. It may be used to simultaneously verify both the data
integrity and the authentication of a message, as with any MAC.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Initialization Vector (IV)</td> <td> An Initialization Vector (IV) is a
nonce that is associated with an invocation of authenticated encryption on a
particular plaintext and additional authenticated data.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> National Institute of Standards and Technology (NIST)</td> <td> The
National Institute of Standards and Technology (NIST) was founded in 1901 and is
now part of the U.S. Department of Commerce. NIST is one of the nation's oldest
physical science laboratories. NIST measurements support the smallest of
technologies to the largest and most complex of human-made creations.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Password-Based Key Derivation Function 2 (PBKDF2)</td> <td> Key
derivation function with a sliding computational cost, aimed to reduce the
vulnerability of encrypted keys to brute force attacks.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Rivest, Shamir and Adelman (RSA)</td> <td> RSA Data Security, Inc., is a
major developer and publisher of public key cryptography standards (PKCS). The
“RSA” in the name stands for the names of the company’s three developers and
owners: Rivest, Shamir, and Adleman. RSA is also used to refer to the RSA key
exchange algorithm.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Secure Has Algorithm (SHA)</td> <td> The Secure Hash Algorithm, or SHA,
is a hashing algorithm that generates a message digest. SHA is used with the
Digital Signature Algorithm (DSA), among other places. There are four varieties of
SHA: SHA-1, SHA-256, SHA-384, and SHA-512. SHA was developed by NIST and the
National Security Agency (NSA).</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Secure Socket Layer (SSL)</td> <td> The Secure Sockets Layer protocol, or
SSL, is a protocol for secure network communications using a combination of public
and secret key technologies. SSL is no longer considered secure.</td> </tr>
<tr> <th> Term</th> <th> Definitions</th> </tr>
<tr> <td> Transport Layer Security (TLS)</td> <td> The Transport Layer Security
protocol, or TLS, is a protocol that provides communications privacy and security
between two applications communicating over a network.</td> </tr></table>
# 7. Responsibilities
<table><tr> <th> Group</th> <th> Responsibilities</th> </tr>
<tr> <td> Adobe Personnel</td> <td> Read, understand, and follow the standards and
procedures in this Standard. Communicate the requirements of this document to
related parties and business partners.</td> </tr>
<tr> <th> Group</th> <th> Responsibilities</th> </tr>
<tr> <td> Adobe PKI team</td> <td> Authorized service that provides certificates to
be used by Adobe services.</td> </tr></table>
# 8. Governing Policy
This Standard must adhere to the following governing Policy:
• Information Security Policy: The Information Security Policy outlines the
strategic objectives, requirements, and goals to secure data, systems, and products
under Adobe's control. The policy establishes the tenets of the Information
Security Management System (ISMS) of Adobe and addresses the expectations that it
has from all Adobe workers.
# 9. References
• Adobe PKI team
The Policies or Standards mentioned herein can be found on the Technology Policies
and Standards Inside Adobe page:
• Key Management Standard: The Key Management Standard defines Adobe’s required
processes for protecting logical access keys from disclosure and misuse. The
purpose of this Standard is to communicate requirements in securing logical access
keys and to restrict certain functions such as key generation, key distribution,
and key storage to authorized personnel only. The standard elaborates over all
necessary aspects of key management.
• Data Classification and Handling Standard: The Data Classification and Handling
Standard establishes that all data collected, processed, transmitted, stored, or
destroyed by or on behalf of Adobe must be classified and then protected in
accordance with its designated classification.
# 10. Document Properties
<table><tr> <th> Coordinator</th> <th> Policy Module Admin; Ensures that Approval
Occurs</th> <th> Harrison Martorana</th> </tr>
<tr> <td> Driver</td> <td> Coordinates Document Drafting, Reviews and Updates</td>
<td> Peleus Uhley</td> </tr>
<tr> <th> Coordinator</th> <th> Policy Module Admin; Ensures that Approval
Occurs</th> <th> Harrison Martorana</th> </tr>
<tr> <td> Approver</td> <td> Approves Document and Exceptions; Ultimately
Responsible for Execution</td> <td> Mike Mellor</td> </tr>
<tr> <th> Coordinator</th> <th> Policy Module Admin; Ensures that Approval
Occurs</th> <th> Harrison Martorana</th> </tr>
<tr> <td> Contributor</td> <td> Provides Recommendations; Subject Matter Expert;
Critical Reviewer</td> <td> Click here for Contributor list</td> </tr>
<tr> <th> Coordinator</th> <th> Policy Module Admin; Ensures that Approval
Occurs</th> <th> Harrison Martorana</th> </tr>
<tr> <td> Informed</td> <td> Receives Document Status Updates; Stakeholders</td>
<td> Click here for Informed list</td> </tr></table>
# 11. Document History
<table><tr> <th> Version</th> <th> Approval Date</th> <th> Changes</th> <th>
Approved By</th> </tr>
<tr> <td> 1.0</td> <td> 11/20/2015</td> <td> Not applicable</td> <td> Brad
Arkin</td> </tr>
<tr> <th> Version</th> <th> Approval Date</th> <th> Changes</th> <th> Approved
By</th> </tr>
<tr> <td> 2.0</td> <td> September 2016</td> <td> • Added requirements to use data
integrity mechanisms in order preserve the integrity of data • Added section 3.5
stating that regulatory encryption requirements supersede this Standard • Added
section 3.2.1 stating that Restricted data over Adobe internal networks does not
require encryption. • Added section 3.2.5 requiring outside entities to be securely
authenticated prior to transmitting Restricted data • Added section 3.2.6 requiring
the transmission of Restricted data to be kept to a minimum • Removed allowance of
sending emails with Restricted data as long as the email was properly encrypted.
Added requirement that no emails can contain Restricted data. • Added restriction
for the non-use of SSL. • Added third scoping paragraph limiting the requirements
of this Standard to Restricted data only.</td> <td> David Lenoe, Product Security
Director</td> </tr>
<tr> <th> Version</th> <th> Approval Date</th> <th> Changes</th> <th> Approved
By</th> </tr>
<tr> <td> 3.0</td> <td> October 2017</td> <td> • Updated the scope to apply to
encryption in general with callouts to additional requirements for Restricted data.
• Added links to the AWS and Azure standards. • Added the approved symmetric block
ciphers and key lengths requirement. • Added the approved asymmetric algorithms,
key lengths, and padding requirement. • Added the approved cryptographic hash
functions requirement. • Added the approved random number generator requirement. •
Added the approved digital certificates requirement. • Removed TLS 1.0 from the
allowed protocols.</td> <td> Mark Oliver, CSO Chief of Staff/Dir of Operations</td>
</tr>
<tr> <th> Version</th> <th> Approval Date</th> <th> Changes</th> <th> Approved
By</th> </tr>
<tr> <td></td> <td></td> <td> • Added a requirement to prefer PFS cipher suites. •
Added an ordered list of cipher suites that products should use as both clients and
servers. • Prohibited use of TLS session resumption via Session IDs. • Added a
requirement to use reasonable methods to validate certificates when presented. •
Refined the requirement for encrypting persistent data by adding a clear definition
and removing the confusing statements on what is ephemeral data. • Removed the
contradictory statements on TLS protocols for Cardholder and ePHI data. • Removed
the Data Integrity section as it was repetitive with previous requirements. •
Replaced multiple statements that contradict or restate requirements from the DC&H
standard with “please see the DC&H standard” links. • Corrected several minor
syntax issues based on comments.</td> <td></td> </tr>
<tr> <th> Version</th> <th> Approval Date</th> <th> Changes</th> <th> Approved
By</th> </tr>
<tr> <td> 3.1</td> <td> N/A for minor version changes. See Information Security
Management Standard</td> <td> Added FIPS column to 3.2.1.3</td> <td> N/A for minor
version changes. See Information Security Management Standard</td> </tr>
<tr> <th> Version</th> <th> Approval Date</th> <th> Changes</th> <th> Approved
By</th> </tr>
<tr> <td> 4.0</td> <td> December 2018</td> <td> Major Changes • Complete overhaul
to content – individual requirements and section titles. The changes focus on
minimum cryptography use requirements and less on the protection of data in transit
and at rest using encryption, which is use case of cryptography. Data protection
aspects are still covered but other uses of cryptography are covered more
comprehensively. • Changed the title to “Cryptography Standard” from “Data
Encryption Standard”. No Minor Changes</td> <td> David Lenoe, Product Security
Director Mohit Kalra, Director Secure Software Engineering</td> </tr>
<tr> <th> Version</th> <th> Approval Date</th> <th> Changes</th> <th> Approved
By</th> </tr>
<tr> <td> 4.1</td> <td> April 2019</td> <td> Major Changes • Added section
“Requirements Specific to Cardholder Data Environments” No Minor Changes</td> <td>
David Lenoe, Product Security Director Mohit Kalra, Director Secure Software
Engineering</td> </tr>
<tr> <th> Version</th> <th> Approval Date</th> <th> Changes</th> <th> Approved
By</th> </tr>
<tr> <td> 5.0</td> <td> January 2020</td> <td> Major Changes • Removed 3.7.1 which
said PKI team is responsible for maintaining an inventory of keys in use and
distributing them • Added 3.7.2 referring to the Key Management Standard for
distribution and management of keys Minor Changes • Added section 3.6
“Certificates” and moved points from section 3.5 “TLS” to this section</td> <td>
David Lenoe, Product Security Director Mohit Kalra, Director Secure Software
Engineering</td> </tr>
<tr> <th> Version</th> <th> Approval Date</th> <th> Changes</th> <th> Approved
By</th> </tr>
<tr> <td> 6.0</td> <td> March 2021</td> <td> No changes in this version</td> <td>
David Lenoe, Product Security Director Mohit Kalra, Director Secure Software
Engineering</td> </tr>
<tr> <th> Version</th> <th> Approval Date</th> <th> Changes</th> <th> Approved
By</th> </tr>
<tr> <td> 7.0</td> <td> February 2022</td> <td> Major Changes • Added 3.3.5 to
account for generating randomness for all applications or services not explicitly
covered in 3.3.1 – 3.3.4 • Added 3.6.4 to provide guideline on how to validate a
certificate Minor Changes • Updated driver to Anuraag Baishya • Added Shannon Lietz
as approver</td> <td> Shannon Lietz, Vice President, Vulnerability Labs
Security</td> </tr>
<tr> <th> Version</th> <th> Approval Date</th> <th> Changes</th> <th> Approved
By</th> </tr>
<tr> <td> 8.0</td> <td> March 2023</td> <td> Major Changes • Section 3 – Renumbered
the section and made a general claim that secure sources of randomness must be used
Minor Changes • Minor formatting changes • Section 3.3.1 – ‘Win32/Win64’ replaced
by ‘Windows’ • Section 3.5.1 – updated to require at least TLS 1.2, deprecating all
prior versions • Section 3.5.2 – removed the point and renumbered the section since
it is similar to 3.6.2 • Section 3.6 - rewrote the section to simplify the
statements and requirements • Section 3.8.1 - ‘The use of all versions of SSL and
TLS 1.0 is prohibited in Cardholder Data Environments.’ replaced by ‘Currently, no
additional requirements are needed.’ • Approver – Added Mike Mellor • Driver –
Replaced Anuraag Baishya with Peleus Uhley</td> <td> Mike Mellor, Vice President,
Cyber Operations</td> </tr>
<tr> <th> Version</th> <th> Approval Date</th> <th> Changes</th> <th> Approved
By</th> </tr>
<tr> <td> 9.0</td> <td> May 2024</td> <td> Major Changes • No major changes Minor
Changes • Section 3.1.3 - Reworded section to be more accurate • Section 3.5.1 –
Added ‘Services that use TLS 1.2 must not use static RSA keys in the key exchange’
• Section 3.6.4 – Added ‘They should also use OCSP or CRL checking to verify that
the certificate has not been revoked.’ • Section 8-9 – Added summary descriptions
to referenced policies/standards</td> <td> Mike Mellor, Vice President, Cyber
Operations</td> </tr></table>