draft-ietf-curdle-cms-chacha20-poly1305-06.txt   rfc8103.txt 
Internet-Draft R. Housley Internet Engineering Task Force (IETF) R. Housley
Intended status: Standards Track Vigil Security Request for Comments: 8103 Vigil Security
Expires: 19 July 2017 19 January 2017 Category: Standards Track February 2017
ISSN: 2070-1721
Using ChaCha20-Poly1305 Authenticated Encryption
in the Cryptographic Message Syntax (CMS)
<draft-ietf-curdle-cms-chacha20-poly1305-06.txt> Using ChaCha20-Poly1305 Authenticated Encryption
in the Cryptographic Message Syntax (CMS)
Abstract Abstract
This document describes the conventions for using ChaCha20-Poly1305 This document describes the conventions for using ChaCha20-Poly1305
Authenticated Encryption in the Cryptographic Message Syntax (CMS). Authenticated Encryption in the Cryptographic Message Syntax (CMS).
ChaCha20-Poly1305 is an authenticated encryption algorithm ChaCha20-Poly1305 is an authenticated encryption algorithm
constructed of the ChaCha stream cipher and Poly1305 authenticator. constructed of the ChaCha stream cipher and Poly1305 authenticator.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 19 July 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8103.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
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
1. Introduction ....................................................2
1.1. The ChaCha20 and Poly1305 AEAD Construction ................3
1.2. ASN.1 ......................................................3
1.3. Terminology ................................................3
2. Key Management ..................................................4
3. Using the AEAD_CHACHA20_POLY1305 Algorithm with
AuthEnvelopedData ...............................................4
4. S/MIME Capabilities Attribute ...................................5
5. IANA Considerations .............................................6
6. Security Considerations .........................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................8
Appendix A. ASN.1 Module ...........................................9
Acknowledgements ...................................................9
Author's Address ...................................................9
1. Introduction 1. Introduction
This document specifies the conventions for using ChaCha20-Poly1305 This document specifies the conventions for using ChaCha20-Poly1305
Authenticated Encryption with the Cryptographic Message Syntax (CMS) Authenticated Encryption with the Cryptographic Message Syntax (CMS)
[CMS] authenticated-enveloped-data content type [AUTHENV]. [CMS] authenticated-enveloped-data content type [AUTHENV].
ChaCha [CHACHA] is a stream cipher developed by D. J. Bernstein in ChaCha [CHACHA] is a stream cipher developed by D. J. Bernstein in
2008. It is a refinement of Salsa20, which is one of the ciphers in 2008. It is a refinement of Salsa20, which is one of the ciphers in
the eSTREAM portfolio [ESTREAM]. the eSTREAM portfolio [ESTREAM].
ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit key ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit key
and a 96-bit nonce. [FORIETF] provides a detailed algorithm and a 96-bit nonce. [FORIETF] provides a detailed algorithm
description, examples, and test vectors of ChaCha20. description, examples, and test vectors of ChaCha20.
Poly1305 [POLY1305] is a Wegman-Carter, one-time authenticator Poly1305 [POLY1305] is a Wegman-Carter, one-time authenticator
designed by D. J. Bernstein. Poly1305 produces a 16-byte designed by D. J. Bernstein. Poly1305 produces a 16-byte
authentication tag; it requires a 256-bit, single-use key. [FORIETF] authentication tag; it requires a 256-bit, single-use key. [FORIETF]
also provides a detailed algorithm description, examples, and test also provides a detailed algorithm description, examples, and test
vectors of Poly1305. vectors of Poly1305.
ChaCha20 and Poly1305 have been designed for high performance ChaCha20 and Poly1305 have been designed for high-performance
software implementations. They can typically be implemented with few software implementations. They can typically be implemented with few
resources and inexpensive operations, making them suitable on a wide resources and inexpensive operations, making them suitable on a wide
range of systems. They have also been designed to minimize leakage range of systems. They have also been designed to minimize leakage
of information through side channels. of information through side channels.
1.1. The ChaCha20 and Poly1305 AEAD Construction 1.1. The ChaCha20 and Poly1305 AEAD Construction
ChaCha20 and Poly1305 have been combined to create an Authenticated ChaCha20 and Poly1305 have been combined to create an Authenticated
Encryption with Associated Data (AEAD) algorithm [AEAD]. This AEAD Encryption with Associated Data (AEAD) algorithm [AEAD]. This AEAD
algorithm is often referred to as AEAD_CHACHA20_POLY1305, and it is algorithm is often referred to as AEAD_CHACHA20_POLY1305, and it is
described [FORIETF]. described in [FORIETF].
AEAD_CHACHA20_POLY1305 accepts four inputs: a 256-bit key, a 96-bit AEAD_CHACHA20_POLY1305 accepts four inputs: a 256-bit key, a 96-bit
nonce, an arbitrary length plaintext, and an arbitrary length nonce, an arbitrary-length plaintext, and an arbitrary-length
additional authenticated data (AAD). As the name implies, a nonce additional authenticated data (AAD). As the name implies, a nonce
value cannot be used securely more than once with the same key. value cannot be used securely more than once with the same key.
AEAD_CHACHA20_POLY1305 produces two outputs: ciphertext of the same AEAD_CHACHA20_POLY1305 produces two outputs: ciphertext of the same
length as the plaintext and a 128-bit authentication tag. length as the plaintext and a 128-bit authentication tag.
AEAD_CHACHA20_POLY1305 authenticated decryption processing is similar AEAD_CHACHA20_POLY1305 authenticated decryption processing is similar
to the encryption processing. Of course, the roles of ciphertext and to the encryption processing. Of course, the roles of ciphertext and
plaintext are reversed, so the ChaCha20 encryption function is plaintext are reversed, so the ChaCha20 encryption function is
applied to the ciphertext, producing the plaintext. The Poly1305 applied to the ciphertext, producing the plaintext. The Poly1305
skipping to change at page 3, line 25 skipping to change at page 4, line 12
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [STDWORDS]. document are to be interpreted as described in RFC 2119 [STDWORDS].
2. Key Management 2. Key Management
The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key
destroys the security guarantees. It can be extremely difficult to destroys the security guarantees. It can be extremely difficult to
use a statically configured AEAD_CHACHA20_POLY1305 key and never use a statically configured AEAD_CHACHA20_POLY1305 key and never
repeat a nonce value; however, the CMS authenticated-enveloped-data repeat a nonce value; however, the CMS authenticated-enveloped-data
content type supports four key management techniques that allow a content type supports four key management techniques that allow a
fresh AEAD_CHACHA20_POLY1305 key to be used as the content- fresh AEAD_CHACHA20_POLY1305 key to be used as the
authenticated-encryption key for a single protected content: content-authenticated-encryption key for a single protected content:
Key Transport: the fresh content-authenticated-encryption key Key Transport: the fresh content-authenticated-encryption key is
is encrypted in the recipient's public key; encrypted in the recipient's public key;
Key Agreement: the recipient's public key and the sender's Key Agreement: the recipient's public key and the sender's private
private key are used to generate a pairwise symmetric key- key are used to generate a pairwise symmetric key-encryption
encryption key, then the fresh content-authenticated-encryption key, then the fresh content-authenticated-encryption key is
key is encrypted in the pairwise symmetric key; encrypted in the pairwise symmetric key;
Symmetric Key-Encryption Keys: the fresh content-authenticated- Symmetric Key-Encryption Keys: the fresh content-authenticated-
encryption key is encrypted in a previously distributed encryption key is encrypted in a previously distributed
symmetric key-encryption key; and symmetric key-encryption key; and
Passwords: the fresh content-authenticated-encryption key is Passwords: the fresh content-authenticated-encryption key is
encrypted in a key-encryption key that is derived from a encrypted in a key-encryption key that is derived from a
password or other shared secret value. password or other shared secret value.
In addition to these four general key management techniques, CMS In addition to these four general key management techniques, CMS
supports other key management techniques. See Section 6.2.5 of supports other key management techniques. See Section 6.2.5 of
[CMS]. Since the properties of these key management techniques are [CMS]. Since the properties of these key management techniques are
unknown, no statement about their support of fresh content- unknown, no statement about their support of fresh
authenticated-encryption keys can be made. Designers and content-authenticated-encryption keys can be made. Designers and
implementers must perform their own analysis if one of these other implementers must perform their own analysis if one of these other
key management techniques is supported. key management techniques is supported.
3. Using the AEAD_CHACHA20_POLY1305 Algorithm with AuthEnvelopedData 3. Using the AEAD_CHACHA20_POLY1305 Algorithm with AuthEnvelopedData
This section specifies the conventions employed by CMS This section specifies the conventions employed by CMS
implementations that support the authenticated-enveloped-data content implementations that support the authenticated-enveloped-data content
type and the AEAD_CHACHA20_POLY1305 algorithm. type and the AEAD_CHACHA20_POLY1305 algorithm.
The AEAD_CHACHA20_POLY1305 algorithm identifier is located in the The AEAD_CHACHA20_POLY1305 algorithm identifier is located in the
AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm
field. field.
The AEAD_CHACHA20_POLY1305 algorithm is used to authenticate the The AEAD_CHACHA20_POLY1305 algorithm is used to (1) authenticate the
attributes located in the AuthEnvelopedData authAttrs field, if any attributes located in the AuthEnvelopedData authAttrs field, if any
are present, encipher the content located in the AuthEnvelopedData are present, (2) encipher the content located in the
EncryptedContentInfo encryptedContent field, and to provide the AuthEnvelopedData EncryptedContentInfo encryptedContent field, and
message authentication code (MAC) located in the AuthEnvelopedData (3) provide the message authentication code (MAC) located in the
mac field. The authenticated attributes are DER encoded to produce AuthEnvelopedData mac field. The authenticated attributes are
the AAD input value to the AEAD_CHACHA20_POLY1305 algorithm. The DER encoded to produce the AAD input value to the
ciphertext and the MAC are the two outputs of the AEAD_CHACHA20_POLY1305 algorithm. The ciphertext and the MAC are the
AEAD_CHACHA20_POLY1305 algorithm. Note that the MAC, which is called two outputs of the AEAD_CHACHA20_POLY1305 algorithm. Note that the
the authentication tag in [FORIETF], provides integrity protection MAC, which is called the authentication tag in [FORIETF], provides
for both the AuthEnvelopedData authAttrs and the AuthEnvelopedData integrity protection for both the AuthEnvelopedData authAttrs and the
EncryptedContentInfo encryptedContent. AuthEnvelopedData EncryptedContentInfo encryptedContent.
Neither the plaintext content nor the optional AAD inputs need to be Neither the plaintext content nor the optional AAD inputs need to be
padded prior to invoking the AEAD_CHACHA20_POLY1305 algorithm. padded prior to invoking the AEAD_CHACHA20_POLY1305 algorithm.
There is one algorithm identifier for the AEAD_CHACHA20_POLY1305 There is one algorithm identifier for the AEAD_CHACHA20_POLY1305
algorithm: algorithm:
id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::= id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) smime(16) alg(3) TBD1 } pkcs9(9) smime(16) alg(3) 18 }
The AlgorithmIdentifier parameters field MUST be present, and the The AlgorithmIdentifier parameters field MUST be present, and the
parameters field MUST contain a AEADChaCha20Poly1305Nonce: parameters field MUST contain an AEADChaCha20Poly1305Nonce:
AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12)) AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))
The AEADChaCha20Poly1305Nonce contains a 12-octet nonce. With the The AEADChaCha20Poly1305Nonce contains a 12-octet nonce. With the
CMS, the content-authenticated-encryption key is normally used for a CMS, the content-authenticated-encryption key is normally used for a
single content. Within the scope of any content-authenticated- single content. Within the scope of any content-authenticated-
encryption key, the nonce value MUST be unique. That is, the set of encryption key, the nonce value MUST be unique. That is, the set of
nonce values used with any given key MUST NOT contain any duplicate nonce values used with any given key MUST NOT contain any duplicate
values. values.
skipping to change at page 5, line 15 skipping to change at page 6, line 5
the software announcing the SMIMECapabilities can support. When the software announcing the SMIMECapabilities can support. When
constructing a CMS signed-data content type, compliant software MAY constructing a CMS signed-data content type, compliant software MAY
include the SMIMECapabilities signed attribute to announce support include the SMIMECapabilities signed attribute to announce support
for the AEAD_CHACHA20_POLY1305 algorithm. for the AEAD_CHACHA20_POLY1305 algorithm.
The SMIMECapability SEQUENCE representing the AEAD_CHACHA20_POLY1305 The SMIMECapability SEQUENCE representing the AEAD_CHACHA20_POLY1305
algorithm MUST include the id-alg-AEADChaCha20Poly1305 object algorithm MUST include the id-alg-AEADChaCha20Poly1305 object
identifier in the capabilityID field and MUST omit the parameters identifier in the capabilityID field and MUST omit the parameters
field. field.
The DER encoding of a SMIMECapability SEQUENCE is the same as the DER The DER encoding of an SMIMECapability SEQUENCE is the same as the
encoding of an AlgorithmIdentifier. The DER encoding for the DER encoding of an AlgorithmIdentifier. The DER encoding for the
AEAD_CHACHA20_POLY1305 algorithm in the SMIMECapability SEQUENCE (in AEAD_CHACHA20_POLY1305 algorithm in the SMIMECapability SEQUENCE (in
hexadecimal) is: hexadecimal) is:
30 0c 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 12
{{{ Correct above after IANA assigns the object identifier. }}}
5. IANA Considerations 5. IANA Considerations
IANA is requested to add the following entry in the SMI Security for IANA has added the following entry in the "SMI Security for S/MIME
S/MIME Algorithms (1.2.840.113549.1.9.16.3) registry: Algorithms (1.2.840.113549.1.9.16.3)" registry:
TBD1 id-alg-AEADChaCha20Poly1305 [This Document] 18 id-alg-AEADChaCha20Poly1305 RFC 8103
IANA is requested to add the following entry in the SMI Security for IANA has added the following entry in the "SMI Security for S/MIME
S/MIME Module Identifier (1.2.840.113549.1.9.16.0) registry: Module Identifier (1.2.840.113549.1.9.16.0)" registry:
TBD2 id-mod-CMS-AEADChaCha20Poly1305 [This Document] 66 id-mod-CMS-AEADChaCha20Poly1305 RFC 8103
6. Security Considerations 6. Security Considerations
The CMS AuthEnvelopedData provides all of the tools needed to avoid The CMS AuthEnvelopedData provides all of the tools needed to avoid
reuse of the same nonce value under the same key. See the discussion reuse of the same nonce value under the same key. See the discussion
in Section 2 of this document. RFC 7539 [FORIETF] describes the in Section 2 of this document. RFC 7539 [FORIETF] describes the
consequences of using a nonce value more than once: consequences of using a nonce value more than once:
Consequences of repeating a nonce: If a nonce is repeated, then Consequences of repeating a nonce: If a nonce is repeated, then
both the one-time Poly1305 key and the keystream are identical both the one-time Poly1305 key and the keystream are identical
between the between the messages. This reveals the XOR of the plaintexts,
messages. This reveals the XOR of the plaintexts, because the because the XOR of the plaintexts is equal to the XOR of the
XOR of the plaintexts is equal to the XOR of the ciphertexts. ciphertexts.
When using AEAD_CHACHA20_POLY1305, the resulting ciphertext is always When using AEAD_CHACHA20_POLY1305, the resulting ciphertext is always
the same size as the original plaintext. Some other mechanism needs the same size as the original plaintext. Some other mechanism needs
to be used in conjunction with AEAD_CHACHA20_POLY1305 if disclosure to be used in conjunction with AEAD_CHACHA20_POLY1305 if disclosure
of the size of the plaintext is a concern. of the size of the plaintext is a concern.
The amount of encrypted data possible in a single invocation of The amount of encrypted data possible in a single invocation of
AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of
the size of the block counter field in the ChaCha20 block function. the size of the block counter field in the ChaCha20 block function.
This gives a total of 247,877,906,880 octets, which likely to be This gives a total of 247,877,906,880 octets, which is likely to be
sufficient to handle the size of any CMS content type. Note that sufficient to handle the size of any CMS content type. Note that the
ciphertext length field in the authentication buffer will accomodate ciphertext length field in the authentication buffer will accommodate
2^64 octets, which is much larger than necessary. 2^64 octets, which is much larger than necessary.
The AEAD_CHACHA20_POLY1305 construction is a novel composition of The AEAD_CHACHA20_POLY1305 construction is a novel composition of
ChaCha20 and Poly1305. A security analysis of this composition is ChaCha20 and Poly1305. A security analysis of this composition is
given in [PROCTER]. given in [PROCTER].
Implementations must randomly generate content-authenticated- Implementations must randomly generate content-authenticated-
encryption keys. The use of inadequate pseudo-random number encryption keys. The use of inadequate pseudorandom number
generators (PRNGs) to generate cryptographic keys can result in generators (PRNGs) to generate cryptographic keys can result in
little or no security. An attacker may find it much easier to little or no security. An attacker may find it much easier to
reproduce the PRNG environment that produced the keys, searching the reproduce the PRNG environment that produced the keys, searching the
resulting small set of possibilities, rather than brute force resulting small set of possibilities rather than "brute force"
searching the whole key space. The generation of quality random searching the whole key space. The generation of quality random
numbers is difficult. RFC 4086 [RANDOM] offers important guidance in numbers is difficult. RFC 4086 [RANDOM] offers important guidance in
this area. this area.
7. Acknowledgements 7. References
Thanks to Jim Schaad, Daniel Migault, Stephen Farrell, Yoav Nir, and
Niclas Comstedt for their review and insightful comments.
8. Normative References 7.1. Normative References
[AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) [AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", RFC 5083, Authenticated-Enveloped-Data Content Type", RFC 5083,
November 2007. DOI 10.17487/RFC5083, November 2007,
<http://www.rfc-editor.org/info/rfc5083>.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
5652, September 2009. RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>.
[FORIETF] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [FORIETF] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 7539, May 2015. Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
<http://www.rfc-editor.org/info/rfc7539>.
[MSG] Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet [MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, DOI 10.17487/RFC5751,
January 2010, <http://www.rfc-editor.org/info/rfc5751>.
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[X680] ITU-T, "Information technology -- Abstract Syntax Notation [X680] ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, 2015. Recommendation X.680, ISO/IEC 8824-1, August 2015,
<https://www.itu.int/rec/T-REC-X.680/en>.
[X690] ITU-T, "Information technology -- ASN.1 encoding rules: [X690] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, 2015. (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1,
August 2015, <https://www.itu.int/rec/T-REC-X.690/en>.
9. Informative References 7.2. Informative References
[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008. Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>.
[CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20", January [CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20",
2008, January 2008,
<http://cr.yp.to/chacha/chacha-20080128.pdf>. <http://cr.yp.to/chacha/chacha-20080128.pdf>.
[ESTREAM] Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C., [ESTREAM] Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C.,
Gilbert, H., Johansson, T., Parker, M., Preneel, B., Gilbert, H., Johansson, T., Parker, M., Preneel, B.,
Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio
(rev. 1)", September 2008, (rev. 1)", September 2008,
<http://www.ecrypt.eu.org/stream/finallist.html>. <http://www.ecrypt.eu.org/stream/finallist.html>.
[POLY1305] Bernstein, D., "The Poly1305-AES message-authentication [POLY1305] Bernstein, D., "The Poly1305-AES message-authentication
code.", March 2005, code", March 2005,
<http://cr.yp.to/mac/poly1305-20050329.pdf>. <http://cr.yp.to/mac/poly1305-20050329.pdf>.
[PROCTER] Procter, G., "A Security Analysis of the Composition of [PROCTER] Procter, G., "A Security Analysis of the Composition of
ChaCha20 and Poly1305", August 2014, ChaCha20 and Poly1305", August 2014,
<http://eprint.iacr.org/2014/613.pdf>. <http://eprint.iacr.org/2014/613.pdf>.
[RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker,
Recommendations for Security", BCP 106, RFC 4086, June "Randomness Requirements for Security", BCP 106, RFC 4086,
2005. DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>.
Appendix: ASN.1 Module Appendix A. ASN.1 Module
CMS-AEADChaCha20Poly1305 CMS-AEADChaCha20Poly1305
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) TBD2 } pkcs-9(9) smime(16) modules(0) 66 }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS IMPORTS
CONTENT-ENCRYPTION CONTENT-ENCRYPTION
FROM AlgorithmInformation-2009 FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }; id-mod-algorithmInformation-02(58) };
skipping to change at page 8, line 32 skipping to change at page 9, line 32
AEADContentEncryptionAlgs CONTENT-ENCRYPTION ::= AEADContentEncryptionAlgs CONTENT-ENCRYPTION ::=
{ cea-AEADChaCha20Poly1305, ... } { cea-AEADChaCha20Poly1305, ... }
cea-AEADChaCha20Poly1305 CONTENT-ENCRYPTION ::= { cea-AEADChaCha20Poly1305 CONTENT-ENCRYPTION ::= {
IDENTIFIER id-alg-AEADChaCha20Poly1305 IDENTIFIER id-alg-AEADChaCha20Poly1305
PARAMS TYPE AEADChaCha20Poly1305Nonce ARE required PARAMS TYPE AEADChaCha20Poly1305Nonce ARE required
SMIME-CAPS { IDENTIFIED BY id-alg-AEADChaCha20Poly1305 } } SMIME-CAPS { IDENTIFIED BY id-alg-AEADChaCha20Poly1305 } }
id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::= id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) smime(16) alg(3) TBD1 } pkcs9(9) smime(16) alg(3) 18 }
AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12)) AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))
END END
Acknowledgements
Thanks to Jim Schaad, Daniel Migault, Stephen Farrell, Yoav Nir, and
Niclas Comstedt for their review and insightful comments.
Author's Address Author's Address
Russell Housley Russell Housley
Vigil Security, LLC Vigil Security, LLC
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA United States of America
EMail: housley@vigilsec.com Email: housley@vigilsec.com
 End of changes. 54 change blocks. 
97 lines changed or deleted 122 lines changed or added

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