idnits 2.17.1 draft-ietf-openpgp-camellia-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 143. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 154. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 161. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 167. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4880, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC4880, updated by this document, for RFC5378 checks: 1999-12-21) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 5, 2008) is 5614 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3713 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Shaw 3 Internet-Draft December 5, 2008 4 Updates: 4880 (if approved) 5 Intended status: Standards Track 6 Expires: June 8, 2009 8 The Camellia Cipher in OpenPGP 9 draft-ietf-openpgp-camellia-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 8, 2009. 36 Abstract 38 This document presents the necessary information to use the Camellia 39 symmetric block cipher in the OpenPGP protocol. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 45 3. Camellia . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 47 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 48 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 49 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 Intellectual Property and Copyright Statements . . . . . . . . . . 5 52 1. Introduction 54 The OpenPGP protocol [RFC4880] can support many different symmetric 55 ciphers. This document presents the necessary information to use the 56 Camellia [RFC3713] cipher in the OpenPGP protocol. 58 2. Requirements notation 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [RFC2119]. 64 3. Camellia 66 Camellia is specified in [RFC3713]. It is a 128-bit block cipher (as 67 are AES and Twofish in OpenPGP), that supports 128-bit, 192-bit, and 68 256-bit keys. This document defines the use of Camellia in OpenPGP. 70 +---------------------+----------------------------------------+ 71 | Camellia Key Length | OpenPGP Symmetric-Key Algorithm Number | 72 +---------------------+----------------------------------------+ 73 | 128 | XXXX | 74 | 192 | YYYY | 75 | 256 | ZZZZ | 76 +---------------------+----------------------------------------+ 78 [[To be allocated by IANA. Please fill this in: presumably XXXX == 79 11, YYYY == 12, and ZZZZ == 13]] 81 OpenPGP applications MAY implement Camellia. If implemented, 82 Camellia may be used in any place in OpenPGP where a symmetric cipher 83 is usable, and is subject to the same usage requirements (such as its 84 presence in the Preferred Symmetric Algorithms signature subpacket) 85 as the other symmetric ciphers in OpenPGP. 87 While the OpenPGP algorithm preferences system prevents 88 interoperability problems with public key encrypted messages, if 89 Camellia (or any other optional cipher) is used for encrypting 90 private keys, there could be interoperability problems when migrating 91 a private key from one system to another. A similar issue can arise 92 when using an optional cipher for symmetrically encrypted messages, 93 as this OpenPGP message type does not perform cipher negotiation. 94 Those using optional ciphers in this manner should take care they are 95 using a cipher that their intended recipient can decrypt. 97 4. Security Considerations 99 At publication time, there are no known weak keys for Camellia, and 100 the Camellia algorithm is believed to be strong. However, as with 101 any technology involving cryptography, implementers should check the 102 current literature, as well as the Camellia home page at 103 , to determine if Camellia has 104 been found to be vulnerable to attack. 106 5. IANA Considerations 108 This document requires IANA to assign three algorithm numbers from 109 the registry of OpenPGP Symmetric-Key Algorithms that was created by 110 [RFC4880]. 112 6. Normative References 114 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 115 Requirement Levels", BCP 14, RFC 2119, March 1997. 117 [RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of 118 the Camellia Encryption Algorithm", RFC 3713, April 2004. 120 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 121 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 123 Author's Address 125 David Shaw 127 Email: dshaw@jabberwocky.com 129 Full Copyright Statement 131 Copyright (C) The IETF Trust (2008). 133 This document is subject to the rights, licenses and restrictions 134 contained in BCP 78, and except as set forth therein, the authors 135 retain all their rights. 137 This document and the information contained herein are provided on an 138 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 139 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 140 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 141 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 142 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 143 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 145 Intellectual Property 147 The IETF takes no position regarding the validity or scope of any 148 Intellectual Property Rights or other rights that might be claimed to 149 pertain to the implementation or use of the technology described in 150 this document or the extent to which any license under such rights 151 might or might not be available; nor does it represent that it has 152 made any independent effort to identify any such rights. Information 153 on the procedures with respect to rights in RFC documents can be 154 found in BCP 78 and BCP 79. 156 Copies of IPR disclosures made to the IETF Secretariat and any 157 assurances of licenses to be made available, or the result of an 158 attempt made to obtain a general license or permission for the use of 159 such proprietary rights by implementers or users of this 160 specification can be obtained from the IETF on-line IPR repository at 161 http://www.ietf.org/ipr. 163 The IETF invites any interested party to bring to its attention any 164 copyrights, patents or patent applications, or other proprietary 165 rights that may cover technology that may be required to implement 166 this standard. Please address the information to the IETF at 167 ietf-ipr@ietf.org.