| Network Working Group | P. Hallam-Baker |
| Internet-Draft | Comodo Group Inc. |
| Intended status: Informational | May 24, 2018 |
| Expires: November 25, 2018 |
Data At Rest Encryption Part 1: DARE Message
draft-hallambaker-dare-message-00
This document describes the Data At Rest Encryption (DARE) message syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content.
This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-dare-message.html .
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 November 25, 2018.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document describes the Data At Rest Encryption (DARE) message syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content.
The DARE Message syntax is based on a subset of the JSON Web Signature [RFC7515] and JSON Web Encryption [RFC7516] standards and shares many fields and semantics. The processing model and data structures have been simplified to remove as many redundant features and alternative means of specifying the same content.
An important innovation in the DARE message format is the separation of key exchange and data encryption operations so that a Master Key (MK) established in a single exchange to be applied to multiple octet sequences. This means that a public key operation may be used to encrypt multiple parts of the same message or to multiple messages.
To maintain the security of the cryptographic algorithm, each octet sequence is encrypted under a different encryption key (and IV if required) derived from the Master Key by means of a salt. Depending on application needs, the salt may be explicit or implicit. An explicit salt is an opaque sequence of octets prepended to the data item. An implicit salt is an octet sequence constructed by application specific means such as the sequence number of a message or the byte position of a field in a file.
Traditional cryptographic containers describe the application of a single key exchange to a single octet sequence. Examples include PCKS#7/CMS [RFC2315] , OpenPGP [RFC4880] and JSON Web Encryption [RFC7516] .
To encrypt a message using RSA, the creator first generates a random encryption key and initialization vector (IV). The encryption key is encrypted under the public key of each recipient to create a per-recipient decryption entry. The encryption key, plaintext and IV are used to generate the ciphertext (figure 1).
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-dare-message.html.]]
Monolithic Key Exchange and Encrypt
This approach is adequate for the task of encrypting a single octet stream. It is less than satisfactory when encrypting multiple octet streams or very long streams for which a rekeying operation is desirable.
The DARE key exchange begins with the same key exchange used to produce the CEK in JWE but instead of using the CEK to encipher data directly, it is used as one of the inputs to a Key Derivation Function (KDF) that is used to derive parameters for each block of data to be encrypted. To avoid the need to introduce additional terminology, the term 'CEK' is still used to describe the output of the key agreement algorithm (including key unwrapping if required) but it is more appropriately described as a Master Key (figure 2).
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-dare-message.html.]]
Exchange of Master Key
A Master Key may be used to encrypt any number of data items. Each data item is encrypted under a different encryption key and IV (if required). This data is derived from the Master Key using the HKDF function [RFC5869] using a different salt for each data item and separate info tags for each cryptographic function (figure 3).
[[This figure is not viewable in this format. The figure is available at http://mathmesh.com/Documents/draft-hallambaker-dare-message.html.]]
Data item encryption under Master Key and per-item salt.
This approach to encryption offers considerably greater flexibility allowing the same format for data item encryption to be applied at the transport, message or field level.
The DARE message format is based on the following existing standards and specifications.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] .
The terms "Authentication Tag", "Content Encryption Key", "Key Management Mode", "Key Encryption", "Direct Key Agreement", "Key Agreement with Key Wrapping" and "Direct Encryption" are defined in the JWE specification [RFC7516] .
The terms "Authentication", "Ciphertext", "Digital Signature", "Encryption", "Initialization Vector (IV)", "Message Authentication Code (MAC)", "Plaintext" and "Salt" are defined by the Internet Security Glossary, Version 2 [RFC4949] .
A consolidated DARE message contains the ciphertext and authentication data for a data object together with the key exchange information necessary for the intended recipient(s) to process it.
Consolidated messages provide the same functionality as traditional PKJCS#7/CMS and OpenPGP message formats and may be used as a one-for-one replacement.
A set of DARE messages are related if they share the same key exchange information.
Related messages allow a single key exchange to be amortized over a collection of data items. This is particularly useful when a large collection of short data items is required such as in a server log or a chat-room transcript.
A detached DARE message contains only the ciphertext and authentication data for a data object and does not provide any key exchange information.
The use of detached messages in a protocol allows key exchange information and message data to be passed to a recipient separately, possibly over different channels or even with entirely different partners.
For example, a service returning the last hundred entries from a log file encrypted as a series of DARE related messages need only provide the key exchange data once.
An annotated DARE message contains a message header with encrypted metadata in addition to an encrypted body. The use of annotated messages allows a receiver to process message data and metadata separately.
For example, a mail application typically provides users with a display showing a short summary of the messages received (sender, date, subject, etc.). Encrypting the metadata to be shown to the user in the summary display separately from the message body allows this data to be presented to the user without the need to download any part of the message bodies
The ability to re-use the output of a key exchange is of particular importance when using proxy re-encryption or distributed key generation as completing each key agreement incurs an interaction with the key server.
The DARE message format supports encryption and decryption in 'streaming mode' in which blocks of output data are emitted as the input is presented.
This allows synchronous communications (e.g. video, voice) to be supported and permits files of arbitrary size to be encrypted with finite state. It is not necessary to buffer the entire plaintext or ciphertext before generating a message.
Overwriting a DARE salt value prevents decryption of the corresponding data unless the salt can be recovered. Use of a suitably large random salt allows erasure of the salt to be considered equivalent to erasure of the message data. For example, if a salt of 128 random bits and an encryption algorithm of at least 128 bits are used, the work factor for decryption will be O(2^128) even if the decryption key is compromised.
The DARE key exchange and data item encoding may be applied to encrypt multiple fields in a single file under a Common Encryption Key. Field level encryption is particularly useful in database and spreadsheet applications.
A consolidated DARE message is a sequence of four parts as follows.
A DARE message MAY be presented in JSON encoding or a compact encoding based on JSON-B.
The DARE message is encoded as JSON sequence with up to four entries. The position of the item in the sequence specifies its function. Thus the Header entry MAY be empty but MUST not be absent.
For example, the following sequence is a JSON encoded message with an empty header and trailer and a salt and body of zero length:
[ {}, "", "", {} ]
Figure 1
JSON-B Encoding provides a more compact representation and in particular, allows ciphertext to be presented in binary form as opposed to Base-64 encoding. Note that JSON-B encoding is a superset of JSON, a JSON-B decoder will be able to decode either format without additional tagging to specify which format is being used.
The square braces used to specify a JSON sequence MUST be present when a DARE Message is embedded in a JSON-B encoded object but MAY be omitted in situations where no ambiguity arises from doing so. For example, when presenting a DARE Message as a standalone file or in a DARE Container.
Applications MAY define their own encoding mechanisms to suit their needs.
The DARE processing model is based on the model in JWE [RFC7516] with the following extensions:
Two generation modes are supported:
Use of buffered mode avoids the need for data chunking and allows messages to provide all the information required for processing in the message header.
Use of streamed mode avoids the need to buffer the data body while assembly of the header is completed. This allows messages of arbitrary size to be processed with fixed resources.
The Message header contains the key exchange information which MAY be shared by multiple related messages,
If the message is to be authenticated by means of a digital signature, the Header MUST contain either a Signatures field or a Signers field but not both.
The Signatures field contains the actual signature value which cannot usually be calculated until processing of the message body is complete. The Signers field contains all the information from a signature except for the signature itself. This allows a verifier to perform decryption and signer verification processing in parallel and to reject a message that is not signed by an accepted signer before completing processing of the message body.
The DARE key exchange is based on the JWE key exchange except that encryption modes are intentionally limited and the output of the key exchange is the DARE Master Key rather than the Content Encryption Key.
A DARE Key Exchange MAY contain any number of Recipient entries, each providing a means of decrypting the Master Key using a different private key.
If the Key Exchange mechanism supports message recovery, Direct Key Agreement is used, in all other cases, Key Wrapping is used.
This approach allows messages with one intended recipient to be handled in the exact same fashion as messages with multiple recipients. While this does require an additional key wrapping operation, that could be avoided if a message has exactly one intended recipient, this is offset by the reduction in code complexity.
If the key exchange algorithm does not support message recovery (e.g. Diffie Hellman and Elliptic Curve Diffie-Hellman), the HKDF Extract-and-Expand Key Derivation Function is used to derive a master key using the following info tag:
The master key length is the maximum of the key size of the encryption algorithm specified by the key exchange header, the key size of the MAC algorithm specified by the key exchange header (if used) and 256.
The JWE/JWS specifications define a kid field for use as a key identifier but not how the identifier itself is constructed. All DARE key identifiers are either UDF key fingerprints [draft-hallambaker-udf] or Group Key Identifiers.
A UDF fingerprint is formed as the digest of an IANA content type and the digested data. A UDF key fingerprint is formed with the content type application/pkix-keyinfo and the digested data is the ASN.1 DER encoded PKIX certificate keyInfo sequence for the corresponding public key.
A Group Key Identifier has the form <fingerprint>@<domain>. Where <fingerprint> is a UDF key fingerprint and <domain> is the DNS address of a service that provides the encryption service to support decryption by group members.
A DARE Enhanced Data Segment is an atomic unit that contains a salt and the result(s) of applying the salt and Master Key to a plaintext under the enhancement mode specified in the key exchange. The following enhancement modes are supported:
In each case the encryption and/or authentication algorithms and all associated parameters (key size, output length) are specified in the associated key exchange header.
A DARE message MAY contain multiple Enhanced Data Sequences. The message body, cloaked headers, annotations and signature values are all presented as Enhanced Data Sequences.
The message body is distinct from all other Enhanced Data Sequences in that each message MUST have exactly one message body and only the message body can be signed. Additionally, when the compact encoding is used, it is the only Enhanced Data Sequence that can be of variable length.
A salt is a sequence of zero or more octets that is unique within the scope of a Master Key.
Generators SHOULD NOT generate salt values that exceed 1024 octets.
The salt value is opaque to the DARE encoding but MAY be used to encode application specific semantics including:
For data erasure to be effective, the salt must be constructed so that the difficulty of recovering the key is sufficiently high that it is infeasible. For most purposes, a salt with 128 bits of appropriately random data will be sufficient.
Encryption and/or authentication keys are derived from the Master Key using a Extract-and-Expand Key Derivation Function as follows:
The application specific information inputs are:
The content of an Enhanced Data Sequence is the plaintext or ciphertext with the appended authentication tag as directed by the enhancement mode.
Support for enhancement of unbuffered streaming data presents implementations with two cases of interest:
If the length of the body is known in advance of enhancement the generator can calculate the final length of the Enhanced Data Segment before encryption begins. This allows encryption of (e.g.) data files as a single data-last production when the compact encoding is being used.
If the final length of the body is not known in advance of enhancement the generator must either buffer the output data in memory before generation or use an encoding that permits indefinite length octet sequences to be represented. In the compact encoding, this means a (possibly zero length) sequence of data-chunk productions terminated by a single data-last production
The trailer only contains information when the message is authenticated by means of a signature.
A list of message signature values.
If the message header contains a Signer field, the trailer MUST contain a Signatures field giving the corresponding signature values.
Decryption and verification is the opposite of the generation process
Recipients MAY verify that the message signatures are adequate to meet the requirements of the security policy at any point in message recovery.
The recipient determines which signer or signature entries are appropriate to their needs and if so, which digest algorithms are to be applied to the message plaintext.
The first step in recovering the master key is to determine which (if any) of the recipient entries can be used for decryption by examining the kid fields.
Having identified the key exchange to use, the Master key.
Having recovered the Master Key, the recipient can decrypt whichever Enhanced Data Sequences it requires.
If validation of one or more signature entries is required, the recipient recovers the signature value from the corresponding Enhanced Data Sequences and performs signature verification according to the specified algorithm.
Processing of a detached message is the same as for a consolidated message except for the fact that at least some of the header information is passed out of band with respect to the message. There are thus two sets of headers:
Message headers take precedence over context headers. Thus if the encryption algorithm field 'enc' is specified in both places, the value specified in the message header takes precedence.
A cloaked message is a DARE message that contains a Cloaked field in the header.
Implementations MAY support generation and parsing of cloaked messages. Implementations SHOULD NOT generate and MAY reject nested cloaked headers unless specifically directed by an application specification.
The use of cloaked headers allows a second layer of key agreement to be specified within the first. The message body is always encrypted under the Master Key corresponding to the innermost key exchange.
Enhanced Data Sequences that are contained in a cloaked header are encrypted under the master key contained in that header.
The key wrapping and derivation algorithms.
Since the means of public key exchange is determined by the key identifier of the recipient key, it is only necessary to specify the algorithms used for key wrapping and derivation.
The default (and so far only) algorithm is kwd-aes-sha2-256-256.
Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm [RFC3394] is used to wrap the Master Exchange Key. AES 256 is used.
HMAC-based Extract-and-Expand Key Derivation Function [RFC5869] is used for key derivation. SHA-2-256 is used for the hash function.
A DARE Message consists of a Header, an Enhanced Data Sequence (EDS) and an optional trailer. This section describes the JSON data fields used to construct headers, trailers and complete messages.
Wherever possible, fields from JWE, JWS and JWK have been used. In these cases, the fields have the exact same semantics. Note however that the classes in which these fields are presented have different structure and nesting.
A DARE Message contains a single DAREMessageSequence in either the JSON or Compact serialization as directed by the protocol in which it is applied.
A DARE Message containing Header, EDS and Trailer in JSON object encoding. Since a DAREMessage is almost invariably presented in JSON sequence or compact encoding, use of the DAREMessage subclass is preferred.
Although a DARE Message is functionally an object, it is serialized as an ordered sequence. This ensures that the message header field will always precede the body in a serialization, this allowing processing of the header information to be performed before the entire body has been received.
A DARE Message sequence MUST contain a (possibly empty) DAREHeader and MAY contain a DARETrailer.
A DARE Message Trailer
A DARE Message Header. Since any field that is present in a trailer MAY be placed in a header instead, the message header inherits from the trailer.
DARE Message uses the same fields as JWE and JWS but with different structure. In particular, DARE messages MAY have multiple recipients and multiple signers.
The signature value
The signature value
Recipient information
In the following examples, Alice's public key parameters are:
{
"PrivateKeyDH": {
"kid": "MB6GU-TKTNH-QOH3W-UXMLL-336UD-R52NE-A",
"Domain": "YE6bnq1MlX5ojaJto6PLP_PEwA",
"Public": "rJIvzTjRmFa6SBtwnPe_ZkBGFxxa_W0yS5K0cnVI2x6rtT2eSkpp
ovzCtTagsAlnAwI426HgQcinyF4AxJMNgOqqG9KvoGnbmMclnMdvRYY7nGFEcoT4R
6BmvcpJtivh3M6odHslh60niJMQGuYdhF9-8nFPi9uC4WJljplq9FCReHKG_0RkBp
dsa2CGQNQLG3yXCvFxj99cvkZknmUY_VSq8X3tMVaO-3MbN-fIPTr5aCuJE5jPcrK
38taOwekH5XGyc-Mls4-rUd5zK0nr2uCiO2RIVKJQfjQ1h62rTVRf3bdP477Wk1ZN
iiWuHijuF8uJVlT2RDLMRJ6NM3excA",
"Private": "8PreevvNyy8MEutpHO_bqh2_N_9zH9R5mE5N76dLXIX0VZsob0f
z9zA_lQ-nP4aRAFUPwJpqli0FNFS5a3BWW2AnRV_hCxsVFAl2UX6v4eCxvNPyx2sU
is9r1bgptfj_wu2FtEIKZTFh1AZ7ncgypK0N6OdwKolhmHUDVrWBU1PFG34jVgvY9
-MFwX8Ee3Uq6foMyGQo6wGRqMlvUWcfiFrETH-Xdi-DqKPfabeaKB3zGCA-YRH3L8
SlzQZ-qzE0G7tJvA8yMlZJ84m-GT8R_uxvgMoPWr1Je5oR16ZyIKru2enfH2jwOzV
tTIdFwQ3RVgA-TzrsIO-pCLyQ-ztYOQ"}}
Figure 2
The body of the test message is the UTF8 representation of the following string:
"This is a test long enough to require multiple blocks"
Figure 3
The EDS sequences, are the UTF8 representation of the following strings:
"Subject: Message metadata should be encrypted" "2018-02-01"
Figure 4
A plaintext message without associated EDS sequences is an empty header followed by the message body:
{
"DAREMessage": [{},
"VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZ
SBtdWx0aXBsZSBibG9ja3M"]}
Figure 5
If a plaintext message contains EDS sequences, these are also in plaintext:
{
"DAREMessage": [{
"edss": ["U3ViamVjdDogTWVzc2FnZSBtZXRhZGF0YSBzaG91bGQgYmUgZW5jcn
lwdGVk",
"MjAxOC0wMi0wMQ"]},
"VGhpcyBpcyBhIHRlc3QgbG9uZyBlbm91Z2ggdG8gcmVxdWlyZSBtdW
x0aXBsZSBibG9ja3M"]}
Figure 6
The creator generates a master session key:
1E 20 22 8F B7 5E 47 59 06 DA D9 39 A1 00 7E C5 63 15 A0 42 18 40 1D AD 17 EB 5B 87 E3 F3 0F B0
Figure 7
The creator generates an ephemeral key:
{
"PrivateKeyDH": {
"kid": "MB7ZZ-3W33A-F2VNY-ADWAT-6X65X-HHHPG-A",
"Domain": "YE6bnq1MlX5ojaJto6PLP_PEwA",
"Public": "bhlMqhBTwLSjpph1ieEbehhDLmJzlNa6T_KgryqJk6CpgosOGMnj
nvkVx4SflKwMDZgdmlHMmKxuAF5AFcvC5iVaLKcN8GFKiUMFnl-u5HCSkZ4pO7VtD
WIEw22eQ6kpnE6lPRoLGEnizs8NEC31QwDsbt7BlT3yvNyys7Cq1Zi7zEytcikxRP
JT-7ayFb0c2SkkeSgcaAnOnADIjtOSUNP6oyJfdAGCric3L9q2sYQH0A3zofCDkMH
PTz9B2juBTIkF2ZP-E4FL3qskm8rFhWXYDaBOoz0L8Ri0H4yL5lIR_NYeU7NmEsmN
soPnMzFub5-vDk05hKzSYsZSapxsNw",
"Private": "H9NDxDPDczPI4VfaADhpktKGNnbbFEXU32LrN6HWUOqC-jjgEjq
JQPSSsh5OqOGI-qH3MRIWQptnZBoZZw8AZrst2hMSUgavR5pjdOUfI3qFDJ7X2BoJ
9tWIxdeRqRY68yZKQ2GRIsYWuJX-G4rMBne3OJMpYvSgOdMVAULfhIqQxQ4Bg36nh
5aiAFhHbAhFT_U8G9uJVp-MziOpFJMDJuuVpafl9BMwEroAbXbnqcCPZxm52MwrUa
15bUsRPiad4Rs3nUy3vwdBC0O5jJQDw_F7ood6-uhpTx7t_R5vntf5Tjq7hEU1QLq
EZskmJ6uK4Lya6-WoAPpsmTKgXI_HXg"}}
Figure 8
The key agreement value is calculated:
22811486391394414590492811341153777463986902783003089366556548209526762765730219683813707386799406750290691991753923128379146807967938078807539268764153770385646898665685008214627230328234942573389292959755404564616024770330032105390813078723890794285774439949542234967770376637613771818877350239294601632726372687979478370265482477606010822581622774899854594915608577020941832506650132488015593629195309445336842126287753184731712091345210543038195952101405956063248137905625118965725721384090610579010991196609345058434675430657696472302230895509628359510168125995303027050657800721605305012305489054529556556071287
Figure 9
The key agreement value is used as the input to a HKDF key derivation function with the info parameter "master".
E6 2B 66 B3 03 F1 23 62 50 1D 88 5E A3 1C DB 86 16 80 A1 1A 62 E9 9F 2B D1 5B 35 66 84 FB 08 ED
Figure 10
To create the first EDS, a salt value is assigned. In this case a single octet with the value '01'. The salt value is then used to create the encryption key and IV as follows:
Salt: Example.DareEDSSalt.ToStringBase16FormatHex() Encryption Key: Example.DareMessageKeyEncrypt.ToStringBase16FormatHex() IV: Example.DareMessageKeyIV.ToStringBase16FormatHex()
Figure 11
The output sequence is the salt followed by the ciphertext:
88 01 01 88 40 15 3A AA 2A 62 BA 09 F2 C5 7D EF 40 F1 DF 4F 8E 62 9B 75 0B C1 CB 6D AE 87 BE 8C C3 BE 92 F9 42 64 8D 37 DB 1D 69 7C D9 60 21 05 94 C5 1C 8B F0 AC 17 5F 55 D6 D1 1F A5 EA 1C D7 42 39 E7 8C 61
Figure 12
The completed message is:
{
"DAREMessage": [{
"recipients": [{
"kid": "MB6GU-TKTNH-QOH3W-UXMLL-336UD-R52NE-A",
"epk": {
"PublicKeyDH": {
"kid": "MB7ZZ-3W33A-F2VNY-ADWAT-6X65X-HHHPG-A",
"Domain": "YE6bnq1MlX5ojaJto6PLP_PEwA",
"Public": "bhlMqhBTwLSjpph1ieEbehhDLmJzlNa6T_KgryqJk6CpgosOGMnj
nvkVx4SflKwMDZgdmlHMmKxuAF5AFcvC5iVaLKcN8GFKiUMFnl-u5HCSkZ4pO7VtD
WIEw22eQ6kpnE6lPRoLGEnizs8NEC31QwDsbt7BlT3yvNyys7Cq1Zi7zEytcikxRP
JT-7ayFb0c2SkkeSgcaAnOnADIjtOSUNP6oyJfdAGCric3L9q2sYQH0A3zofCDkMH
PTz9B2juBTIkF2ZP-E4FL3qskm8rFhWXYDaBOoz0L8Ri0H4yL5lIR_NYeU7NmEsmN
soPnMzFub5-vDk05hKzSYsZSapxsNw"}},
"wmk": "BbAZbgVlhI35WYKXJ-JgYDr0XyaFwa30KNJaoWmQhItN2Fb2WYfesA"}]},
"iAEBiEAVOqoqYroJ8sV970Dx30-OYpt1C8HLba6HvozDvpL5QmSNN9s
daXzZYCEFlMUci_CsF19V1tEfpeoc10I554xh"]}
Figure 13
This is not yet implemented.
| [draft-hallambaker-jsonbcd] | Hallam-Baker, P., "Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D", Internet-Draft draft-hallambaker-jsonbcd-11, April 2018. |
| [draft-hallambaker-udf] | Hallam-Baker, P., "Uniform Data Fingerprint (UDF)", Internet-Draft draft-hallambaker-udf-10, April 2018. |
| [IANAJOSE] | , "[Reference Not Found!]" |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC2315] | Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998. |
| [RFC3394] | Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002. |
| [RFC4880] | Callas, J., Donnerhacke, L., Finney, H., Shaw, D. and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007. |
| [RFC4949] | Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007. |
| [RFC5869] | Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010. |
| [RFC7159] | Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014. |
| [RFC7515] | Jones, M., Bradley, J. and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015. |
| [RFC7516] | Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015. |
| [RFC7517] | Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015. |
| [RFC7518] | Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015. |