Use of Post-Quantum KEM in the Cryptographic Message Syntax (CMS)
draft-perret-prat-lamps-cms-pq-kem-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Ludovic Perret , PRAT Julien , Mike Ounsworth | ||
| Last updated | 2021-11-22 | ||
| Replaced by | draft-ietf-lamps-kyber | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-perret-prat-lamps-cms-pq-kem-00
LAMPS L. Perret
Internet-Draft J. Prat
Intended status: Standards Track CryptoNext Security
Expires: 26 May 2022 M. Ounsworth
Entrust Limited
22 November 2021
Use of Post-Quantum KEM in the Cryptographic Message Syntax (CMS)
draft-perret-prat-lamps-cms-pq-kem-00
Abstract
This document describes the conventions for using a Key Encapsulation
Mechanism algorithm (KEM) within the Cryptographic Message Syntax
(CMS). The CMS specifies the enveloped-data content type, which
consists of an encrypted content and encrypted content-encryption
keys for one or more recipients. The mechanism proposed here can
rely on either post-quantum KEMs, hybrid KEMs or classical KEMs.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 May 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Perret, et al. Expires 26 May 2022 [Page 1]
Internet-Draft PQ KEM in CMS November 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Design Rationales . . . . . . . . . . . . . . . . . . . . . . 3
4. KEM Key Transport Mechanism (KEM-TRANS) . . . . . . . . . . . 4
4.1. Underlying Components . . . . . . . . . . . . . . . . . . 4
4.1.1. KEM . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. KDF . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.3. WRAP . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Recipient's Key Generation and Distribution . . . . . . . 6
4.3. Sender's Operations . . . . . . . . . . . . . . . . . . . 6
4.4. Recipient's Operations . . . . . . . . . . . . . . . . . 7
5. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. RecipientInfo Conventions . . . . . . . . . . . . . . . . 7
5.2. Certificate Conventions . . . . . . . . . . . . . . . . . 8
5.2.1. Key Usage Extension . . . . . . . . . . . . . . . . . 8
5.2.2. Subject Public Key Info . . . . . . . . . . . . . . . 9
5.3. SMIME Capabilities Attribute Conventions . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. Annex A : ASN.1 Syntax . . . . . . . . . . . . . . . . . . . 10
9.1. Annex A1 : KEM-TRANS Key Transport Mechanism . . . . . . 10
9.2. Annex A2 : Underlying Components . . . . . . . . . . . . 11
9.2.1. Key Encapsulation Mechanisms . . . . . . . . . . . . 11
9.2.2. Key Derivation Functions . . . . . . . . . . . . . . 11
9.2.3. Key Wrapping Schemes . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Perret, et al. Expires 26 May 2022 [Page 2]
Internet-Draft PQ KEM in CMS November 2021
1. Introduction
In recent years, there has been a substantial amount of research on
quantum computers -- machines that exploit quantum mechanical
phenomena to solve mathematical problems that are difficult or
intractable for conventional computers. If large-scale quantum
computers are ever built, they will be able to break many of the
public-key cryptosystems currently in use. This would seriously
compromise the confidentiality and integrity of digital
communications on the Internet and elsewhere. Under such a threat
model, the current key encapsulation mechanisms would be vulnerable.
Post-quantum key encapsulation mechanisms (PQ-KEM) are being
developed in order to provide secure key establishment against an
adversary with access to a quantum computer.
As the National Institute of Standards and Technology (NIST) is still
in the process of selecting the new post-quantum cryptographic
algorithms that are secure against both quantum and classical
computers, the purpose of this document is to propose a generic
"algorithm-agnostic" solution to protect in confidentiality the CMS
envelopped-data content against the quantum threat : the KEM-TRANS
mechanism. This mechanism could thus be used with any key
encapsulation mechanism, including post-quantum KEMs or hybrid KEMs.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terms are used in this document:
BER: Basic Encoding Rules (BER) as defined in [X.690].
DER: Distinguished Encoding Rules as defined in [X.690].
3. Design Rationales
In the Envelopped-Data Content section of [RFC5652], two levels of
encryptions are defined for CMS:
* the Content-encryption process which protects the data thanks to a
symmetric algorithm used with a content encryption key (CEK);
Perret, et al. Expires 26 May 2022 [Page 3]
Internet-Draft PQ KEM in CMS November 2021
* the Key-encryption process which protects this CEK thanks to a key
transport mechanism.
One of the typical use case of the CMS Envelopped-Data Content is to
randomly generate a CEK, encrypt the data with a symmetric algorithm
using this CEK and individually send the CEK to several recipients.
In this scenario the CEK must be protected individually to the
different recipients.
To achieve this scenario with KEM primitives, it is necessary to
define a new key transport mechanism that will fulfil the following
requirements:
* the Key Transport Mechanism SHALL be secure againt quantum
computers.
* the Key Transport Mechanism SHALL take the Content-Encryption Key
(CEK) as input.
According to NIST, a KEM encapsulation algorithm generates a random
secret and a ciphertext from which the recipient can extract the
shared secret, meaning that a KEM can not be used straightforward as
a key transport mechanism in the CMS "multi-recipients" context. The
KEM-TRANS mechanism defined in this document aims to turn a KEM into
a key transport scheme allowing the sender to distribute a randomly
generated key to several recipients. The KEM-TRANS Key transport
mechanism described in the following section fulfils the requirements
listed above and is an adaptation of the RSA-KEM algorithm previously
specified in [RFC5652].
4. KEM Key Transport Mechanism (KEM-TRANS)
The KEM Key Transport Mechanism (KEM-TRANS) is a one-pass (store-and-
forward) mechanism for transporting keying data to a recipient.
With this type of mechanism, a sender encrypts the keying data using
the recipient's public key to obtain encrypted keying data. The
recipient can then decrypt the encrypted keying data using his
private key to recover the plaintext keying data.
4.1. Underlying Components
The KEM-TRANS mechanism has the following underlying components:
* KEM, a Key Encapsulation Mechanism;
* KDF, a Key Derivation Function, which derives keying data of a
specified length from a shared secret value;
Perret, et al. Expires 26 May 2022 [Page 4]
Internet-Draft PQ KEM in CMS November 2021
* WRAP, a symmetric key-wrapping scheme, which encrypts keying Data
using a key-encrypting key (KEK).
4.1.1. KEM
A KEM is cryptographic algorithm consisting of three functions :
* a key generation function *KEM.keygen* taking as input a security
level and returning a key pair (private key and the associated
public key) for this security level.
* an encapsulation function *KEM.encaps* taking a public key as
input and returning a random session key and a ciphertext that is
an encapsulation of the session key.
* a decaspulation function *KEM.decaps* taking as input a private
key and a ciphertext and returning a session key.
4.1.2. KDF
A key derivation function (KDF) is a cryptographic function that
derives one or more secret keys from a secret value using a
pseudorandom function. KDFs can be used to stretch keys into longer
keys or to obtain keys of a required format.
4.1.3. WRAP
A wrapping algorithm is a symmetric algorithm protecting data in
confidentiality and integrity. It is especially designed to
transport key material. the WRAP algorithm consists of two functions
:
* a wrapping function *Wrap* taking a wrapping key and a plaintext
key as input and returning a wrapped key.
* a decaspulation function *Unwrap* taking as input a wrapping key
and a wraped key and returning the plaintext key.
In the following, _kekLen_ denotes the length in bytes of the
wrapping key for the underlying symmetric key-wrapping scheme.
In this scheme, the length of the keying data to be transported MUST
be among the lengths supported by the underlying symmetric key-
wrapping scheme.
Usage and formatting of the keying data is outside the scope of this
algorithm. With some key derivation functions, it is possible to
include other information besides the shared secret value in the
Perret, et al. Expires 26 May 2022 [Page 5]
Internet-Draft PQ KEM in CMS November 2021
input to the function. Also, with some symmetric key-wrapping
schemes, it is possible to associate a label with the keying data.
Such uses are outside the scope of this document, as they are not
directly supported by CMS.
4.2. Recipient's Key Generation and Distribution
The KEM-TRANS mechanism described in the next sections assumes that
the recipient has previously generated a key pair (_recipPrivKey_ and
_recipPubKey_) and has distributed this public key to the sender.
The protocols and mechanisms by which the key pair is securely
generated and the public key is securely distributed are out of the
scope of this document.
4.3. Sender's Operations
Let _recipPubKey_ be the recipient's public key, and let _K_ be the
keying data to be transported.
The sender performs the following operations:
1. Generate a shared secret _SS_ and the associated ciphertext _CT_
thanks to the KEM encaspulation function and the recipient's
public key _recipPubKey_:
(SS, CT) = KEM.encaps(recipPubKey)
2. Derive a key-encrypting key _KEK_ of length _kekLen_ bytes from
the shared secret _SS_ using the underlying key derivation
function:
KEK = KDF(SS, kekLen)
3. Wrap the keying data _K_ with the key-encrypting key _KEK_ using
the underlying key-wrapping scheme to obtain wrapped keying data
_WK_ of length _wrappedKekLen_:
WK = Wrap(KEK, K)
4. Concatenate the wrapped keying data _WK_ of length
_wrappedKekLen_ and the ciphertext _CT_ to obtain the encrypted
keying data _EK_:
EK = (WK || CT)
5. Output the encrypted keying data _EK_.
Perret, et al. Expires 26 May 2022 [Page 6]
Internet-Draft PQ KEM in CMS November 2021
4.4. Recipient's Operations
Let _recipPrivKey_ be the recipient's private key and let _EK_ be the
encrypted keying data.
The recipient performs the following operations:
1. Separate the encrypted keying data _EK_ into wrapped keying data
_WK_ of length _wrappedKekLen_ and a ciphertext _CT_ :
(WK || CT) = EK
2. Decapsulate the ciphertext _CT_ thanks to the KEM decaspulation
function and the recipient's private key to retrieve the shared
secret _SS_:
SS = KEM.decaps(recipPrivKey, CT)
If the decapsulation operation outputs an error, output
"decryption error", and stop.
3. Derive a key-encrypting key _KEK_ of length _kekLen_ bytes from
the shared secret _SS_ using the underlying key derivation
function:
KEK = KDF(SS, kekLen)
4. Unwrap the wrapped keying data _WK_ with the key-encrypting key
_KEK_ using the underlying key-wrapping scheme to recover the
keying data _K_:
K = Unwrap(KEK, WK)
If the unwrapping operation outputs an error, output "decryption
error", and stop.
5. Output the keying data _K_.
5. Use in CMS
The KEM Key Transport Mechanism MAY be employed for one or more
recipients in the CMS enveloped-data content type (Section 6 of
[RFC5652]), where the keying data processed by the mechanism is the
CMS content-encryption key (_CEK_).
5.1. RecipientInfo Conventions
Perret, et al. Expires 26 May 2022 [Page 7]
Internet-Draft PQ KEM in CMS November 2021
EDITOR'S NOTE' - TO BE DISCUSSED
3 possibilities to communicate info:
-Use KeyTransRecipientInfo (as it is done in RSA-KEM and in here)
-Define in this RFC a KemRecipientInfo as instance of OtherRecipientInfo
-Define in this RFC a new top-level KemRecipientInfo
When the KEM Key Transport Mechanism is employed for a recipient, the
RecipientInfo alternative for that recipient MUST be
KeyTransRecipientInfo.
The mechanism satisfies the KeyTransportRecipientInfo interface
defined in RFC 5652 by taking in a Content Encryption Key (CEK) and a
recipient public key, and encrypting the CEK for that recipient.
The algorithm-specific fields of the KeyTransRecipientInfo value MUST
have the following values:
* keyEncryptionAlgorithm.algorithm MUST be id-kem-trans (see
Appendix A);
* keyEncryptionAlgorithm.parameters MUST be a value of type
GenericHybridParameters (see Appendix A), identifying:
- the key encapsulation mechanism (id-kem);
- the key derivation function (id-kdf);
- the symmetric wrapping mechanism (id-wrap).
* encryptedKey MUST be the encrypted keying data output by the KEM-
TRANS Mechanism, where the keying data is the content-encryption
key (CEK).
5.2. Certificate Conventions
The conventions specified in this section augment [RFC5280].
5.2.1. Key Usage Extension
The intended application for the key MAY be indicated in the key
usage certificate extension (see [RFC5280], Section 4.2.1.3). If the
keyUsage extension is present in a certificate that conveys a public
key with the id-kem object identifier as discussed above, then the
key usage extension MUST contain only the value _keyEncipherment_
_digitalSignature_, _nonRepudiation_, _dataEncipherment_,
_keyAgreement_, _keyCertSign_, _cRLSign_, _encipherOnly_ and
_decipherOnly_ SHOULD NOT be present.
Perret, et al. Expires 26 May 2022 [Page 8]
Internet-Draft PQ KEM in CMS November 2021
A key intended to be employed only with the KEM-TRANS Mechanism
SHOULD NOT also be employed for data encryption. Good cryptographic
practice employs a given key pair in only one scheme. This practice
avoids the risk that vulnerability in one scheme may compromise the
security of the other, and may be essential to maintain provable
security.
5.2.2. Subject Public Key Info
EDITOR'S NOTE' - TODO
Update this section according to the future PQC-PKIX RFCs
If the recipient wishes only to employ the KEM-TRANS Mechanism with a
given public key, the recipient MUST identify the public key in the
certificate using the _id-kem_ object identifier.
EDITOR'S NOTE' - TODO
Clarify that id-kem refers to the KEM algo
while KEM-TRANS refers to the KEM Transport mechanism
5.3. SMIME Capabilities Attribute Conventions
[RFC8551], Section 2.5.2 defines the SMIMECapabilities signed
attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be
used to specify a partial list of algorithms that the software
announcing the SMIMECapabilities can support. When constructing a
signedData object, compliant software MAY include the
SMIMECapabilities signed attribute announcing that it supports the
KEM Key Transport Mechanism.
The SMIMECapability SEQUENCE representing the KEM Key Transport
Mechanism MUST include the id-kem-trans object identifier in the
capabilityID field and MUST include a GenericHybridParameters value
in the parameters field identifying the components with which the
mechanism is to be employed.
The DER encoding of a SMIMECapability SEQUENCE is the same as the DER
encoding of an AlgorithmIdentifier. Example DER encodings for
typical sets of components are given in Appendix A.
6. Security Considerations
EDITOR'S NOTE' - TODO
section to be completed
Perret, et al. Expires 26 May 2022 [Page 9]
Internet-Draft PQ KEM in CMS November 2021
7. IANA Considerations
Within the CMS, algorithms are identified by object identifiers
(OIDs). With one exception, all of the OIDs used in this document
were assigned in other IETF documents, in ISO/IEC standards
documents, by the National Institute of Standards and Technology
(NIST). The two exceptions are the ASN.1 module's identifier and id-
kem-transport that are both assigned in this document.
8. Acknowledgements
This document incorporates contributions and comments from a large
group of experts. The Editors would especially like to acknowledge
the expertise and tireless dedication of the following people, who
attended many long meetings and generated millions of bytes of
electronic mail and VOIP traffic over the past year in pursuit of
this document:
EDITOR'S NOTE' - TODO
section to be completed
We are grateful to all, including any contributors who may have been
inadvertently omitted from this list.
This document borrows text from similar documents, including those
referenced below. Thanks go to the authors of those documents.
"Copying always makes things easier and less error prone" -
[RFC8411].
9. Annex A : ASN.1 Syntax
The ASN.1 syntax for identifying the KEM Key Transport Mechanism is
an extension of the syntax for the "generic hybrid cipher" in ANS
X9.44 [X9.44].
The syntax for the scheme is given in Appendix A.1.
The syntax for selected underlying components including those
mentioned above is given in Appendix A.2.
9.1. Annex A1 : KEM-TRANS Key Transport Mechanism
The object identifier for the KEM Key Transport Mechanism is id-kem-
trans, which is defined in this document as:
id-kem-trans OID ::= { TBD }
Perret, et al. Expires 26 May 2022 [Page 10]
Internet-Draft PQ KEM in CMS November 2021
When id-kem-trans is used in an AlgorithmIdentifier, the parameters
MUST employ the GenericHybridParameters syntax. The syntax for
GenericHybridParameters is as follows:
GenericHybridParameters ::= {
kem KeyEncapsulationMechanism,
kdf KeyDerivationFunction,
wrap KeyWrappingMechanism
}
The fields of type GenericHybridParameters have the following
meanings:
* kem identifies the underlying key encapsulation mechanism (KEM).
This can be any NIST KEM.
* kdf identifies the underlying key derivation function (KDF). This
can be any KDF from [SP-800-56C-r2]. kdf can be equal to _null_ if
the key encaspulation mechanism outputs a shared secret _SS_ of
size _kekLen_.
* wrap identifies the underlying key wrapping mechanism (WRAP).
This can be any wrapping mechanism from [RFC5649].
9.2. Annex A2 : Underlying Components
9.2.1. Key Encapsulation Mechanisms
The KEM-TRANS Mechanism can support any NIST KEM, including post-
quantum KEMs.
The object identifier for KEM is (TBD)
EDITOR'S NOTE' - TODO :
PQ-KEMs OID have to be defined
9.2.2. Key Derivation Functions
The KEM-TRANS Mechanism can support any KDF from [SP-800-56C-r2].
The KDF can be bypassed if the key encaspulation mechanism outputs a
shared secret _SS_ of size _kekLen_. kdf is then equal to _null_.
EDITOR'S NOTE' - TO BE DISCUSSED :
Is there a RFC defining KDF with SHA3?
Should we limit the compatible KDFs to [SP-800-56C-r2]?
Perret, et al. Expires 26 May 2022 [Page 11]
Internet-Draft PQ KEM in CMS November 2021
9.2.3. Key Wrapping Schemes
The KEM-TRANS Mechanism can support any wrapping mechanism from
[RFC5649].
EDITOR'S NOTE' - TO BE DISCUSSED :
Should we limit the compatible wrapping modes to [RFC5649]?
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[SP-800-56C-r2]
NIST, "Recommendation for Key-Derivation Methods in Key-
Establishment Schemes", 2020.
[X.690] ASC, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", 2007.
Perret, et al. Expires 26 May 2022 [Page 12]
Internet-Draft PQ KEM in CMS November 2021
[X9.44] ASC, "American National Standard X9.44: Public Key
Cryptography for the Financial Services Industry -- Key
Establishment Using Integer Factorization Cryptography",
2007.
10.2. Informative References
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649,
DOI 10.17487/RFC5649, September 2009,
<https://www.rfc-editor.org/info/rfc5649>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC5990] Randall, J., Kaliski, B., Brainard, J., and S. Turner,
"Use of the RSA-KEM Key Transport Algorithm in the
Cryptographic Message Syntax (CMS)", RFC 5990,
DOI 10.17487/RFC5990, September 2010,
<https://www.rfc-editor.org/info/rfc5990>.
[RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the
Cryptographic Algorithm Object Identifier Range",
RFC 8411, DOI 10.17487/RFC8411, August 2018,
<https://www.rfc-editor.org/info/rfc8411>.
[SP-800-108]
NIST, "Recommendation for Key Derivation Using
Pseudorandom Functions", 2009.
Authors' Addresses
Ludovic Perret
CryptoNext Security
Email: ludovic.perret@cryptonext-security.com
Julien Prat
CryptoNext Security
Perret, et al. Expires 26 May 2022 [Page 13]
Internet-Draft PQ KEM in CMS November 2021
Email: julien.prat@cryptonext-security.com
Mike Ounsworth
Entrust Limited
Email: mike.ounsworth@entrust.com
Perret, et al. Expires 26 May 2022 [Page 14]