draft-ietf-lamps-cms-mix-with-psk-02.txt   draft-ietf-lamps-cms-mix-with-psk-03.txt 
INTERNET-DRAFT R. Housley INTERNET-DRAFT R. Housley
Intended Status: Proposed Standard Vigil Security Internet Engineering Task Force (IETF) Vigil Security
Expires: 14 June 2019 14 December 2018 Intended Status: Proposed Standard
Expires: 8 September 2019 8 March 2019
Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)
<draft-ietf-lamps-cms-mix-with-psk-02.txt> <draft-ietf-lamps-cms-mix-with-psk-03.txt>
Abstract Abstract
The invention of a large-scale quantum computer would pose a serious The invention of a large-scale quantum computer would pose a serious
challenge for the cryptographic algorithms that are widely deployed challenge for the cryptographic algorithms that are widely deployed
today. The Cryptographic Message Syntax (CMS) supports key transport today. The Cryptographic Message Syntax (CMS) supports key transport
and key agreement algorithms that could be broken by the invention of and key agreement algorithms that could be broken by the invention of
such a quantum computer. By storing communications that are such a quantum computer. By storing communications that are
protected with the CMS today, someone could decrypt them in the protected with the CMS today, someone could decrypt them in the
future when a large-scale quantum computer becomes available. Once future when a large-scale quantum computer becomes available. Once
skipping to change at page 2, line 18 skipping to change at page 2, line 18
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . . 4 1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 6 3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 6
4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 7 4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 7
5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9
6. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 14 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A: Key Transport with PSK Example . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 A.1. Originator Processing Example . . . . . . . . . . . . . . 17
A.2. ContentInfo and AuthEnvelopedData . . . . . . . . . . . . 20
A.3. Recipient Processing Example . . . . . . . . . . . . . . . 22
Appendix B: Key Agreement with PSK Example . . . . . . . . . . . . 23
B.1. Originator Processing Example . . . . . . . . . . . . . . 23
B.2. ContentInfo and AuthEnvelopedData . . . . . . . . . . . . 26
B.3. Recipient Processing Example . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The invention of a large-scale quantum computer would pose a serious The invention of a large-scale quantum computer would pose a serious
challenge for the cryptographic algorithms that are widely deployed challenge for the cryptographic algorithms that are widely deployed
today. It is an open question whether or not it is feasible to build today. It is an open question whether or not it is feasible to build
a large-scale quantum computer, and if so, when that might happen. a large-scale quantum computer, and if so, when that might happen.
However, if such a quantum computer is invented, many of the However, if such a quantum computer is invented, many of the
cryptographic algorithms and the security protocols that use them cryptographic algorithms and the security protocols that use them
would become vulnerable. would become vulnerable.
skipping to change at page 5, line 29 skipping to change at page 5, line 33
4. The KEK is used to encrypt the CEK. 4. The KEK is used to encrypt the CEK.
When using a key agreement algorithm: When using a key agreement algorithm:
1. The content-encryption key or the content-authenticated- 1. The content-encryption key or the content-authenticated-
encryption key, called CEK, is generated at random. encryption key, called CEK, is generated at random.
2. For each recipient, a pairwise key-encryption key, called KEK1, 2. For each recipient, a pairwise key-encryption key, called KEK1,
is established using the recipient's public key and the is established using the recipient's public key and the
sender's private key. sender's private key. Note that KEK1 will be used as a key-
derivation key.
3. For each recipient, the key derivation function (KDF) is used 3. For each recipient, the key derivation function (KDF) is used
to mix the pre-shared key (PSK) and the pairwise KEK1, and the to mix the pre-shared key (PSK) and the pairwise KEK1, and the
result is called KEK2. result is called KEK2.
4. For each recipient, the pairwise KEK2 is used to encrypt the 4. For each recipient, the pairwise KEK2 is used to encrypt the
CEK. CEK.
As specified in Section 6.2.5 of [RFC5652], recipient information for As specified in Section 6.2.5 of [RFC5652], recipient information for
additional key management techniques are represented in the additional key management techniques are represented in the
skipping to change at page 9, line 21 skipping to change at page 9, line 26
A KDF has several input values. This section describes the A KDF has several input values. This section describes the
conventions for using the KDF to compute the key-encryption key for conventions for using the KDF to compute the key-encryption key for
KeyTransPSKRecipientInfo and KeyAgreePSKRecipientInfo. For KeyTransPSKRecipientInfo and KeyAgreePSKRecipientInfo. For
simplicity, the terminology used in the HKDF [RFC5869] specification simplicity, the terminology used in the HKDF [RFC5869] specification
is used here. is used here.
The KDF inputs are: The KDF inputs are:
IKM is the input keying material; it is the symmetric secret input IKM is the input keying material; it is the symmetric secret input
to the KDF. For KeyTransPSKRecipientInfo, it is the PSK to the KDF. For KeyTransPSKRecipientInfo, it is the key-
concatenated with the key-derivation key. For derivation key. For KeyAgreePSKRecipientInfo, it is the pairwise
KeyAgreePSKRecipientInfo, it is the PSK concatenated with the key-encryption key produced by the key agreement algorithm.
pairwise key-encryption key produced by the key agreement
algorithm.
salt is an optional non-secret random value. The salt is not salt is an optional non-secret random value. The salt is not
used. used.
L is the length of output keying material in octets; the value L is the length of output keying material in octets; the value
depends on the key-encryption algorithm that will be used. The depends on the key-encryption algorithm that will be used. The
algorithm is identified by the KeyEncryptionAlgorithmIdentifier. algorithm is identified by the KeyEncryptionAlgorithmIdentifier.
In addition, the OBJECT IDENTIFIER portion of the In addition, the OBJECT IDENTIFIER portion of the
KeyEncryptionAlgorithmIdentifier is included in the next input KeyEncryptionAlgorithmIdentifier is included in the next input
value, called info. value, called info.
info is optional context and application specific information. info is optional context and application specific information.
The DER-encoding of CMSORIforPSKOtherInfo is used as the info The DER-encoding of CMSORIforPSKOtherInfo is used as the info
value. Note that EXPLICIT tagging is used in the ASN.1 module value, and the PSK is included in this structure. Note that
that deines this structure. For KeyTransPSKRecipientInfo, the EXPLICIT tagging is used in the ASN.1 module that deines this
ENUMERATED value of 5 is used. For KeyAgreePSKRecipientInfo, the structure. For KeyTransPSKRecipientInfo, the ENUMERATED value of
ENUMERATED value of 10 is used. CMSORIforPSKOtherInfo is defined 5 is used. For KeyAgreePSKRecipientInfo, the ENUMERATED value of
by the following ASN.1 structure: 10 is used. CMSORIforPSKOtherInfo is defined by the following
ASN.1 structure:
CMSORIforPSKOtherInfo ::= SEQUENCE { CMSORIforPSKOtherInfo ::= SEQUENCE {
psk OCTET STRING,
keyMgmtAlgType ENUMERATED { keyMgmtAlgType ENUMERATED {
keyTrans (5), keyTrans (5),
keyAgree (10) }, keyAgree (10) },
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
pskLength INTEGER (1..MAX), pskLength INTEGER (1..MAX),
kdkLength INTEGER (1..MAX) } kdkLength INTEGER (1..MAX) }
The fields of type CMSORIforPSKOtherInfo have the following meanings: The fields of type CMSORIforPSKOtherInfo have the following meanings:
psk is an OCTET STRING; it contains the PSK.
keyMgmtAlgType is either set to 5 or 10. For keyMgmtAlgType is either set to 5 or 10. For
KeyTransPSKRecipientInfo, the ENUMERATED value of 5 is used. For KeyTransPSKRecipientInfo, the ENUMERATED value of 5 is used. For
KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used. KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used.
keyEncryptionAlgorithm is the KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm is the KeyEncryptionAlgorithmIdentifier,
which identifies the algorithm and provides algorithm parameters, which identifies the algorithm and provides algorithm parameters,
if any. if any.
pskLength is a positive integer; it contains the length of the PSK pskLength is a positive integer; it contains the length of the PSK
in octets. in octets.
skipping to change at page 10, line 36 skipping to change at page 11, line 5
OKM is the output keying material, which is exactly L octets. The OKM is the output keying material, which is exactly L octets. The
OKM is the key-encryption key that is used to encrypt the content- OKM is the key-encryption key that is used to encrypt the content-
encryption key or the content-authenticated-encryption key. encryption key or the content-authenticated-encryption key.
6. ASN.1 Module 6. ASN.1 Module
This section contains the ASN.1 module for the two key management This section contains the ASN.1 module for the two key management
techniques defined in this document. This module imports types from techniques defined in this document. This module imports types from
other ASN.1 modules that are defined in [RFC5911] and [RFC5912]. other ASN.1 modules that are defined in [RFC5911] and [RFC5912].
CMSORIforPSK-2017 CMSORIforPSK-2019
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-ori-psk-2017(TBD0) } smime(16) modules(0) id-mod-cms-ori-psk-2019(TBD0) }
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
IMPORTS IMPORTS
AlgorithmIdentifier{}, KEY-DERIVATION AlgorithmIdentifier{}, KEY-DERIVATION
FROM AlgorithmInformation-2009 -- [RFC5912] FROM AlgorithmInformation-2009 -- [RFC5912]
skipping to change at page 12, line 17 skipping to change at page 12, line 35
KeyAgreePSKRecipientInfo ::= SEQUENCE { KeyAgreePSKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 version CMSVersion, -- always set to 0
pskid PreSharedKeyIdentifier, pskid PreSharedKeyIdentifier,
originator [0] EXPLICIT OriginatorIdentifierOrKey, originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
kdfAlgorithm KeyDerivationAlgorithmIdentifier, kdfAlgorithm KeyDerivationAlgorithmIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys } recipientEncryptedKeys RecipientEncryptedKeys }
-- --
-- Structure to provide 'info' input to the KDF -- Structure to provide 'info' input to the KDF,
-- including the Pre-Shared Key
-- --
CMSORIforPSKOtherInfo ::= SEQUENCE { CMSORIforPSKOtherInfo ::= SEQUENCE {
psk OCTET STRING,
keyMgmtAlgType ENUMERATED { keyMgmtAlgType ENUMERATED {
keyTrans (5), keyTrans (5),
keyAgree (10) }, keyAgree (10) },
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
pskLength INTEGER (1..MAX), pskLength INTEGER (1..MAX),
kdkLength INTEGER (1..MAX) } kdkLength INTEGER (1..MAX) }
END END
7. Security Considerations 7. Security Considerations
skipping to change at page 17, line 5 skipping to change at page 17, line 21
June 2010. June 2010.
[RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the [RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)" RFC 5912, Public Key Infrastructure Using X.509 (PKIX)" RFC 5912,
June 2010. June 2010.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, November 2016. RFC 8017, November 2016.
Appendix A: Key Transport with PSK Example
This example shows the establishment of an AES-256 content-encryption
key using:
- a pre-shared key of 256 bits;
- key transport using RSA PKCS#1 v1.5 with a 3072-bit key;
- key derivation using HKDF with SHA-384; and
- key wrap using AES-256-KEYWRAP.
In real-world use, the originator would encrypt the key-derivation
key in their own RSA public key as well as the recipient's public
key. This is omited in an attempt to simplify the example.
A.1. Originator Processing Example
The pre-shared key known to Alice and Bob:
c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15
The identifier assigned to the pre-shared key is:
ptf-kmc:13614122112
Alice obtains Bob's public key:
-----BEGIN PUBLIC KEY-----
MIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEA3ocW14cxncPJ47fnEjBZ
AyfC2lqapL3ET4jvV6C7gGeVrRQxWPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JH
Keeza+itfuhsz3yifgeEpeK8T+SusHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqq
vS3jg/VO+OPnZbofoHOOevt8Q/roahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx
2AHHZJevo3nmRnlgJXo6mE00E/6qkhjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0v
SH7qUl8/vN13y4UOFkn8hM4kmZ6bJqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39a
uLNnH3EXdXaV1tk75H3qC7zJaeGWMJyQfOE3YfEGRKn8fxubji716D8UecAxAzFy
FL6m1JiOyV5acAiOpxN14qRYZdHnXOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fS
whSZG7VNf+vgNWTLNYSYLI04KiMdulnvU6ds+QPz+KKtAgMBAAE=
-----END PUBLIC KEY-----
Bob's RSA public key has the following key identifier:
9eeb67c9b95a74d44d2f16396680e801b5cba49c
Alice randomly generates a content-encryption key:
c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83
Alice randomly generates a key-derivation key:
df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb
Alice encrypts the key-derivation key in Bob's public key:
4e6200431ed95e0e28f7288dba56d4b90e75959e068884664c43368f3d978f3d
8179e5837e3c27bf8dc1f6e2827b9ede969be77417516de07d90e37c560add01
48deb0c9178088ccb72c068d8a9076b6a5e7ecc9093e30fdeaecc9e138d80626
74fcf685f3082b910839551cd8741beedeee6e87c08ff84f03ba87118730cdf7
667002316f1a29a6cc596c7ddf95a51e398927d1916bf27929945de080fc7c80
6af6281aed6492acffa4ef1b4f53e67fca9a417db2350a2277d586ee3cabefd3
b4a44f04d3c6803d54fe9a7159210dabedda9a94f310d303331da51c0218d92a
2efb003792259195a9fd4cc403af613fdf1a6265ea70bf702fd1c6f734264c9a
59196e8e8fd657fa028e272ef741eb7711fd5b3f4ea7da9c33df66bf487da710
1c9bbfddaf1c073900a3ea99da513d8aa32605db07dc1c47504cab30c9304a85
d87377f603ec3df4056ddcf3d756fb7ed98254421a4ae151f17ad4e28c5ea077
63358dfb1ef5f73435f337b21a38c1a3fa697a530dd97e462f6b5fb2052a2d53
Alice produces a 256-bit key-encryption key with HKDF using SHA-384;
the secret value is the key-derivation key; the 'info' is the DER-
encoded CMSORIforPSKOtherInfo structure with the following values:
0 56: SEQUENCE {
2 32: OCTET STRING
: C2 44 CD D1 1A 0D 1F 39 D9 B6 12 82 77 02 44 FB
: 0F 6B EF B9 1A B7 F9 6C B0 52 13 36 5C F9 5B 15
36 1: ENUMERATED 5
39 11: SEQUENCE {
41 9: OBJECT IDENTIFIER aes256-wrap
: { 2 16 840 1 101 3 4 1 45 }
: }
52 1: INTEGER 32
55 1: INTEGER 32
: }
The DER encoding of CMSORIforPSKOtherInfo produces 58 octets:
30380420c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb0521336
5cf95b150a0105300b060960864801650304012d020120020120
The HKDF output is 256 bits:
a14d87451dfd11d83cd54ffe2bd38c49a2adfed3ac49f1d3e62bbdc64ae43b32
Alice uses AES-KEY-WRAP to encrypt the 256-bit content-encryption
key with the key-encryption key:
ae4ea1d99e78fcdcea12d9f10d991ac71502939ee0c30ebdcc97dd1fc5ba3566
c83d0dd5d1b4faa5
Alice encrypts the content using AES-256-GCM with the content-
encryption key. The 12-octet nonce used is:
cafebabefacedbaddecaf888
The content plaintext is:
48656c6c6f2c20776f726c6421
The resutling ciphertext is:
9af2d16f21547fcefed9b3ef2d
The resutling 12-octet authentication tag is:
a0e5925cc184e0172463c44c
A.2. ContentInfo and AuthEnvelopedData
Alice encodes the AuthEnvelopedData and the ContentInfo, and
sends the result to Bob. The resulting structure is:
0 650: SEQUENCE {
4 11: OBJECT IDENTIFIER authEnvelopedData
: { 1 2 840 113549 1 9 16 1 23 }
17 633: [0] {
21 629: SEQUENCE {
25 1: INTEGER 0
28 551: SET {
32 547: [4] {
36 11: OBJECT IDENTIFIER ** Placeholder **
: { 1 2 840 113549 1 9 16 TBD 1 }
49 530: SEQUENCE {
53 1: INTEGER 0
56 19: OCTET STRING 'ptf-kmc:13614122112'
77 13: SEQUENCE {
79 11: OBJECT IDENTIFIER ** Placeholder **
: { 1 2 840 113549 1 9 16 3 TBD }
: }
92 11: SEQUENCE {
94 9: OBJECT IDENTIFIER aes256-wrap
: { 2 16 840 1 101 3 4 1 45 }
: }
105 432: SEQUENCE {
109 428: SEQUENCE {
113 1: INTEGER 2
116 20: [0]
: 9E EB 67 C9 B9 5A 74 D4 4D 2F 16 39 66 80 E8 01
: B5 CB A4 9C
138 13: SEQUENCE {
140 9: OBJECT IDENTIFIER rsaEncryption
: { 1 2 840 113549 1 1 1 }
151 0: NULL
: }
153 384: OCTET STRING
: 18 09 D6 23 17 DF 2D 09 55 57 3B FE 75 95 EB 6A
: 3D 57 84 6C 69 C1 49 0B F1 11 1A BB 40 0C D8 B5
: 26 5F D3 62 4B E2 D8 E4 CA EC 6A 12 36 CA 38 E3
: A0 7D AA E0 5F A1 E3 BC 59 F3 AD A8 8D 95 A1 6B
: 06 85 20 93 C7 C5 C0 05 62 ED DF 02 1D FE 68 7C
: 18 A1 3A AB AA 59 92 30 6A 1B 92 73 D5 01 C6 5B
: FD 1E BB A9 B9 D2 7F 48 49 7F 3C 4F 3C 13 E3 2B
: 2A 19 F1 7A CD BC 56 28 EF 7F CA 4F 69 6B 7E 92
: 66 22 0D 13 B7 23 AD 41 9E 5E 98 2A 80 B7 6C 77
: FF 9B 76 B1 04 BA 30 6D 4B 4D F9 25 57 E0 7F 0E
: 95 9A 43 6D 14 D5 72 3F AA 8F 66 35 40 D0 E3 71
: 4B 7F 20 9D ED 67 EA 33 79 CD AB 84 16 72 07 D2
: AC 8D 3A DA 12 43 B7 2F 3A CF 91 3E F1 D9 58 20
: 6D F2 9C 09 E1 EC D2 0B 82 BE 5D 69 77 6F FE F7
: EB F6 31 C0 D9 B7 15 BF D0 24 F3 05 1F FF 48 76
: 1D 73 17 19 2C 38 C6 D5 86 BD 67 82 2D B2 61 AA
: 08 C7 E4 37 34 D1 2D E0 51 32 15 4A AC 6B 2B 28
: 5B CD FA 7C 65 89 2F A2 63 DB AB 64 88 43 CC 66
: 27 84 29 AC 15 5F 3B 9E 5B DF 99 AE 4F 1B B2 BC
: 19 6C 17 A1 99 A5 CF F7 80 32 11 88 F1 9D B3 6F
: 4B 16 5F 3F 03 F7 D2 04 3D DE 5F 30 CD 8B BB 3A
: 38 DA 9D EC 16 6C 36 4F 8B 7E 99 AA 99 FB 42 D6
: 1A FF 3C 85 D7 A2 30 74 2C D3 AA F7 18 2A 25 3C
: B5 02 C4 17 62 21 97 F1 E9 81 83 D0 4E BF 5B 5D
: }
: }
541 40: OCTET STRING
: AE 4E A1 D9 9E 78 FC DC EA 12 D9 F1 0D 99 1A C7
: 15 02 93 9E E0 C3 0E BD CC 97 DD 1F C5 BA 35 66
: C8 3D 0D D5 D1 B4 FA A5
: }
: }
: }
583 55: SEQUENCE {
585 9: OBJECT IDENTIFIER data { 1 2 840 113549 1 7 1 }
596 27: SEQUENCE {
598 9: OBJECT IDENTIFIER aes256-GCM
: { 2 16 840 1 101 3 4 1 46 }
609 14: SEQUENCE {
611 12: OCTET STRING CA FE BA BE FA CE DB AD DE CA F8 88
: }
: }
625 13: [0] 9A F2 D1 6F 21 54 7F CE FE D9 B3 EF 2D
: }
640 12: OCTET STRING A0 E5 92 5C C1 84 E0 17 24 63 C4 4C
: }
: }
: }
A.3. Recipient Processing Example
Bob's private key:
-----BEGIN RSA PRIVATE KEY-----
MIIG5AIBAAKCAYEA3ocW14cxncPJ47fnEjBZAyfC2lqapL3ET4jvV6C7gGeVrRQx
WPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JHKeeza+itfuhsz3yifgeEpeK8T+Su
sHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqqvS3jg/VO+OPnZbofoHOOevt8Q/ro
ahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx2AHHZJevo3nmRnlgJXo6mE00E/6q
khjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0vSH7qUl8/vN13y4UOFkn8hM4kmZ6b
JqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39auLNnH3EXdXaV1tk75H3qC7zJaeGW
MJyQfOE3YfEGRKn8fxubji716D8UecAxAzFyFL6m1JiOyV5acAiOpxN14qRYZdHn
XOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fSwhSZG7VNf+vgNWTLNYSYLI04KiMd
ulnvU6ds+QPz+KKtAgMBAAECggGATFfkSkUjjJCjLvDk4aScpSx6+Rakf2hrdS3x
jwqhyUfAXgTTeUQQBs1HVtHCgxQd+qlXYn3/qu8TeZVwG4NPztyi/Z5yB1wOGJEV
3k8N/ytul6pJFFn6p48VM01bUdTrkMJbXERe6g/rr6dBQeeItCaOK7N5SIJH3Oqh
9xYuB5tH4rquCdYLmt17Tx8CaVqU9qPY3vOdQEOwIjjMV8uQUR8rHSO9KkSj8AGs
Lq9kcuPpvgJc2oqMRcNePS2WVh8xPFktRLLRazgLP8STHAtjT6SlJ2UzkUqfDHGK
q/BoXxBDu6L1VDwdnIS5HXtL54ElcXWsoOyKF8/ilmhRUIUWRZFmlS1ok8IC5IgX
UdL9rJVZFTRLyAwmcCEvRM1asbBrhyEyshSOuN5nHJi2WVJ+wSHijeKl1qeLlpMk
HrdIYBq4Nz7/zXmiQphpAy+yQeanhP8O4O6C8e7RwKdpxe44su4Z8fEgA5yQx0u7
8yR1EhGKydX5bhBLR5Cm1VM7rT2BAoHBAP/+e5gZLNf/ECtEBZjeiJ0VshszOoUq
haUQPA+9Bx9pytsoKm5oQhB7QDaxAvrn8/FUW2aAkaXsaj9F+/q30AYSQtExai9J
fdKKook3oimN8/yNRsKmhfjGOj8hd4+GjX0qoMSBCEVdT+bAjjry8wgQrqReuZnu
oXU85dmb3jvv0uIczIKvTIeyjXE5afjQIJLmZFXsBm09BG87Ia5EFUKly96BOMJh
/QWEzuYYXDqOFfzQtkAefXNFW21Kz4Hw2QKBwQDeiGh4lxCGTjECvG7fauMGlu+q
DSdYyMHif6t6mx57eS16EjvOrlXKItYhIyzW8Kw0rf/CSB2j8ig1GkMLTOgrGIJ1
0322o50FOr5oOmZPueeR4pOyAP0fgQ8DD1L3JBpY68/8MhYbsizVrR+Ar4jM0f96
W2bF5Xj3h+fQTDMkx6VrCCQ6miRmBUzH+ZPs5n/lYOzAYrqiKOanaiHy4mjRvlsy
mjZ6z5CG8sISqcLQ/k3Qli5pOY/v0rdBjgwAW/UCgcEAqGVYGjKdXCzuDvf9EpV4
mpTWB6yIV2ckaPOn/tZi5BgsmEPwvZYZt0vMbu28Px7sSpkqUuBKbzJ4pcy8uC3I
SuYiTAhMiHS4rxIBX3BYXSuDD2RD4vG1+XM0h6jVRHXHh0nOXdVfgnmigPGz3jVJ
B8oph/jD8O2YCk4YCTDOXPEi8Rjusxzro+whvRR+kG0gsGGcKSVNCPj1fNISEte4
gJId7O1mUAAzeDjn/VaS/PXQovEMolssPPKn9NocbKbpAoHBAJnFHJunl22W/lrr
ppmPnIzjI30YVcYOA5vlqLKyGaAsnfYqP1WUNgfVhq2jRsrHx9cnHQI9Hu442PvI
x+c5H30YFJ4ipE3eRRRmAUi4ghY5WgD+1hw8fqyUW7E7l5LbSbGEUVXtrkU5G64T
UR91LEyMF8OPATdiV/KD4PWYkgaqRm3tVEuCVACDTQkqNsOOi3YPQcm270w6gxfQ
SOEy/kdhCFexJFA8uZvmh6Cp2crczxyBilR/yCxqKOONqlFdOQKBwFbJk5eHPjJz
AYueKMQESPGYCrwIqxgZGCxaqeVArHvKsEDx5whI6JWoFYVkFA8F0MyhukoEb/2x
2qB5T88Dg3EbqjTiLg3qxrWJ2OxtUo8pBP2I2wbl2NOwzcbrlYhzEZ8bJyxZu5i1
sYILC8PJ4Qzw6jS4Qpm4y1WHz8e/ElW6VyfmljZYA7f9WMntdfeQVqCVzNTvKn6f
hg6GSpJTzp4LV3ougi9nQuWXZF2wInsXkLYpsiMbL6Fz34RwohJtYA==
-----END RSA PRIVATE KEY-----
Bob decrypts the key-derivation key with his RSA private key:
df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb
Bob produces a 256-bit key-encryption key with HKDF using SHA-384;
the secret value is the key-derivation key; the 'info' is the DER-
encoded CMSORIforPSKOtherInfo structure with the same values as
shown in A.1. The HKDF output is 256 bits:
a14d87451dfd11d83cd54ffe2bd38c49a2adfed3ac49f1d3e62bbdc64ae43b32
Bob uses AES-KEY-WRAP to decrypt the content-encryption key
with the key-encryption key; the content-encryption key is:
c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83
Bob decrypts the content using AES-256-GCM with the content-
encryption key, and checks the received authentication tag. The
12-octet nonce used is:
cafebabefacedbaddecaf888
The 12-octet authentication tag is:
a0e5925cc184e0172463c44c
The received ciphertext content is:
9af2d16f21547fcefed9b3ef2d
The resutling plaintext content is:
48656c6c6f2c20776f726c6421
Appendix B: Key Agreement with PSK Example
This example shows the establishment of an AES-256 content-encryption
key using:
- a pre-shared key of 256 bits;
- key agreement using ECDH on curve P-384 and X9.63 KDF
with SHA-384;
- key derivation using HKDF with SHA-384; and
- key wrap using AES-256-KEYWRAP.
In real-world use, the originator would treat themselves as an additional
recipient by performing key agreement with their own static public key
the ephemeral private key generated for this message. This is omited in
an attempt to simplify the example.
B.1. Originator Processing Example
The pre-shared key known to Alice and Bob:
4aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c078660214e2d83e4
The identifier assigned to the pre-shared key is:
ptf-kmc:216840110121
Alice randomly generates a content-encryption key:
937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033
Alice obtains Bob's static ECDH public key:
-----BEGIN PUBLIC KEY-----
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEScGPBO9nmUwGrgbGEoFY9HR/bCo0WyeY
/dePQVrwZmwN2yMJmO2d1kWCvLTz8U7atinxyIRe9CV54yau1KWU/wbkhPDnzuSM
YkcpxMGo32z3JetEloW5aFOja13vv/W5
-----END PUBLIC KEY-----
It has a key identifier of:
e8218b98b8b7d86b5e9ebdc8aeb8c4ecdc05c529
Alice generates an ephemeral ECDH key pair on the same curve:
-----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDCMiWLG44ik+L8cYVvJrQdLcFA+PwlgRF+Wt1Ab25qUh8OB7OePWjxp
/b8P6IOuI6GgBwYFK4EEACKhZANiAAQ5G0EmJk/2ks8sXY1kzbuG3Uu3ttWwQRXA
LFDJICjvYfr+yTpOQVkchm88FAh9MEkw4NKctokKNgpsqXyrT3DtOg76oIYENpPb
GE5lJdjPx9sBsZQdABwlsU0Zb7P/7i8=
-----END EC PRIVATE KEY-----
Alice computes a shared secret, called Z, using the Bob's static
ECDH public key and her ephemeral ECDH private key; Z is:
3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556
19cf8807e6d800c2de40240fe0e26adc
Alice computes the pairwise key-encryption key, called KEK1, from Z
using the X9.63 KDF with the ECC-CMS-SharedInfo structure with the
following values:
0 21: SEQUENCE {
2 11: SEQUENCE {
4 9: OBJECT IDENTIFIER aes256-wrap
: { 2 16 840 1 101 3 4 1 45 }
: }
15 6: [2] {
17 4: OCTET STRING 00 00 00 20
: }
: }
The DER encoding of ECC-CMS-SharedInfo produces 23 octets:
3015300b060960864801650304012da206040400000020
The X9.63 KDF output is the 256-bit KEK1:
27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da
Alice produces the 256-bit KEK2 with HKDF using SHA-384; the secret
value is KEK1; the 'info' is the DER-encoded CMSORIforPSKOtherInfo
structure with the following values:
0 56: SEQUENCE {
2 32: OCTET STRING
: 4A A5 3C BF 50 08 50 DD 58 3A 5D 98 21 60 5C 6F
: A2 28 FB 59 17 F8 7C 1C 07 86 60 21 4E 2D 83 E4
36 1: ENUMERATED 10
39 11: SEQUENCE {
41 9: OBJECT IDENTIFIER aes256-wrap
: { 2 16 840 1 101 3 4 1 45 }
: }
52 1: INTEGER 32
55 1: INTEGER 32
: }
The DER encoding of CMSORIforPSKOtherInfo produces 58 octets:
303804204aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c07866021
4e2d83e40a010a300b060960864801650304012d020120020120
The HKDF output is the 256-bit KEK2:
7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb
Alice uses AES-KEY-WRAP to encrypt the content-encryption key
with the KEK2; the wrapped key is:
229fe0b45e40003e7d8244ec1b7e7ffb2c8dca16c36f5737222553a71263a92b
de08866a602d63f4
Alice encrypts the content using AES-256-GCM with the content-
encryption key. The 12-octet nonce used is:
dbaddecaf888cafebabeface
The resulting ciphertext is:
fc6d6f823e3ed2d209d0c6ffcf
The resulting 12-octet authentication tag is:
550260c42e5b29719426c1ff
B.2. ContentInfo and AuthEnvelopedData
Alice encodes the AuthEnvelopedData and the ContentInfo, and
sends the result to Bob. The resulting structure is:
0 327: SEQUENCE {
4 11: OBJECT IDENTIFIER authEnvelopedData
: { 1 2 840 113549 1 9 16 1 23 }
17 310: [0] {
21 306: SEQUENCE {
25 1: INTEGER 0
28 229: SET {
31 226: [4] {
34 11: OBJECT IDENTIFIER ** Placeholder **
: { 1 2 840 113549 1 9 16 TBD 2 }
47 210: SEQUENCE {
50 1: INTEGER 0
53 20: OCTET STRING 'ptf-kmc:216840110121'
75 85: [0] {
77 83: [1] {
79 19: SEQUENCE {
81 6: OBJECT IDENTIFIER
: dhSinglePass-stdDH-sha256kdf-scheme
: { 1 3 132 1 11 1 }
89 9: OBJECT IDENTIFIER aes256-wrap
: { 2 16 840 1 101 3 4 1 45 }
: }
100 60: BIT STRING, encapsulates {
103 57: OCTET STRING
: 1B 41 26 26 4F F6 92 CF 2C 5D 8D 64 CD BB 86 DD
: 4B B7 B6 D5 B0 41 15 C0 2C 50 C9 20 28 EF 61 FA
: FE C9 3A 4E 41 59 1C 86 6F 3C 14 08 7D 30 49 30
: E0 D2 9C B6 89 0A 36 0A 6C
: }
: }
: }
162 13: SEQUENCE {
164 11: OBJECT IDENTIFIER ** Placeholder **
: { 1 2 840 113549 1 9 16 3 TBD }
: }
177 11: SEQUENCE {
179 9: OBJECT IDENTIFIER aes256-wrap
: { 2 16 840 1 101 3 4 1 45 }
: }
190 68: SEQUENCE {
192 66: SEQUENCE {
194 22: [0] {
196 20: OCTET STRING
: E8 21 8B 98 B8 B7 D8 6B 5E 9E BD C8 AE B8 C4 EC
: DC 05 C5 29
: }
218 40: OCTET STRING
: 22 9F E0 B4 5E 40 00 3E 7D 82 44 EC 1B 7E 7F FB
: 2C 8D CA 16 C3 6F 57 37 22 25 53 A7 12 63 A9 2B
: DE 08 86 6A 60 2D 63 F4
: }
: }
: }
: }
: }
260 55: SEQUENCE {
262 9: OBJECT IDENTIFIER data { 1 2 840 113549 1 7 1 }
273 27: SEQUENCE {
275 9: OBJECT IDENTIFIER aes256-GCM
: { 2 16 840 1 101 3 4 1 46 }
286 14: SEQUENCE {
288 12: OCTET STRING DB AD DE CA F8 88 CA FE BA BE FA CE
: }
: }
302 13: [0] FC 6D 6F 82 3E 3E D2 D2 09 D0 C6 FF CF
: }
317 12: OCTET STRING 55 02 60 C4 2E 5B 29 71 94 26 C1 FF
: }
: }
: }
B.3. Recipient Processing Example
Bob obtains Alice's ephemeral ECDH public key from the message:
-----BEGIN PUBLIC KEY-----
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEORtBJiZP9pLPLF2NZM27ht1Lt7bVsEEV
wCxQySAo72H6/sk6TkFZHIZvPBQIfTBJMODSnLaJCjYKbKl8q09w7ToO+qCGBDaT
2xhOZSXYz8fbAbGUHQAcJbFNGW+z/+4v
-----END PUBLIC KEY-----
Bob's static ECDH private key:
-----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDAnJ4hB+tTUN9X03/W0RsrYy+qcptlRSYkhaDIsQYPXfTU0ugjJEmRk
NTPj4y1IRjegBwYFK4EEACKhZANiAARJwY8E72eZTAauBsYSgVj0dH9sKjRbJ5j9
149BWvBmbA3bIwmY7Z3WRYK8tPPxTtq2KfHIhF70JXnjJq7UpZT/BuSE8OfO5Ixi
RynEwajfbPcl60SWhbloU6NrXe+/9bk=
-----END EC PRIVATE KEY-----
Bob computes a shared secret, called Z, using the Alice's ephemeral
ECDH public key and his static ECDH private key; Z is:
3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556
19cf8807e6d800c2de40240fe0e26adc
Bob computes the pairwise key-encryption key, called KEK1, from Z
using the X9.63 KDF with the ECC-CMS-SharedInfo structure with the
values shown in B.1. The X9.63 KDF output is the 256-bit KEK1:
27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da
Bob produces the 256-bit KEK2 with HKDF using SHA-384; the secret
value is KEK1; the 'info' is the DER-encoded CMSORIforPSKOtherInfo
structure with the values shown in B.1. The HKDF output is the
256-bit KEK2:
7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb
Bob uses AES-KEY-WRAP to decrypt the content-encryption key
with the KEK2; the content-encryption key is:
937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033
Bob decrypts the content using AES-256-GCM with the content-
encryption key, and checks the received authentication tag. The
12-octet nonce used is:
dbaddecaf888cafebabeface
The 12-octet authentication tag is:
550260c42e5b29719426c1ff
The received ciphertext content is:
fc6d6f823e3ed2d209d0c6ffcf
The resutling plaintext content is:
48656c6c6f2c20776f726c6421
Acknowledgements Acknowledgements
Many thanks to Burt Kaliski, Panos Kampanakis, Jim Schaad, Sean Many thanks to Burt Kaliski, Panos Kampanakis, Jim Schaad, Sean
Turner, and Daniel Van Geest for their review and insightful Turner, and Daniel Van Geest for their review and insightful
comments. They have greatly improved the design, clarity, and comments. They have greatly improved the design, clarity, and
implementation guidance. implementation guidance.
Author's Address Author's Address
Russell Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
516 Dranesville Road 516 Dranesville Road
Herndon, VA 20170 Herndon, VA 20170
USA USA
EMail: housley@vigilsec.com EMail: housley@vigilsec.com
 End of changes. 17 change blocks. 
24 lines changed or deleted 526 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/