doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc4010.txt b/doc/rfc/rfc4010.txt
new file mode 100644
index 0000000..625dc9f
--- /dev/null
+++ b/doc/rfc/rfc4010.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                            J. Park
+Request for Comments: 4010                                        S. Lee
+Category: Standards Track                                         J. Kim
+                                                                  J. Lee
+                                                                    KISA
+                                                           February 2005
+
+
+                  Use of the SEED Encryption Algorithm
+                 in Cryptographic Message Syntax (CMS)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document specifies the conventions for using the SEED encryption
+   algorithm for encryption with the Cryptographic Message Syntax (CMS).
+
+   SEED is added to the set of optional symmetric encryption algorithms
+   in CMS by providing two classes of unique object identifiers (OIDs).
+   One OID class defines the content encryption algorithms and the other
+   defines the key encryption algorithms.
+
+1.  Introduction
+
+   This document specifies the conventions for using the SEED encryption
+   algorithm [SEED][TTASSEED] for encryption with the Cryptographic
+   Message Syntax (CMS)[CMS].  The relevant object identifiers (OIDs)
+   and processing steps are provided so that SEED may be used in the CMS
+   specification (RFC 3852, RFC 3370) for content and key encryption.
+
+
+
+
+
+
+
+
+
+
+
+Park, et al.                Standards Track                     [Page 1]
+
+RFC 4010          The SEED Encryption Algorithm in CMS     February 2005
+
+
+1.1.  SEED
+
+   SEED is a symmetric encryption algorithm developed by KISA (Korea
+   Information Security Agency) and a group of experts since 1998.  The
+   input/output block size and key length of SEED is 128-bits.  SEED has
+   the 16-round Feistel structure.  A 128-bit input is divided into two
+   64-bit blocks and the right 64-bit block is an input to the round
+   function, with a 64-bit subkey generated from the key scheduling.
+
+   SEED is easily implemented in various software and hardware because
+   it takes less memory to implement than other algorithms and generates
+   keys without degrading the security of the algorithm.  In particular,
+   it can be effectively adopted in a computing environment with a
+   restricted resources, such as mobile devices and smart cards.
+
+   SEED is robust against known attacks including DC (Differential
+   cryptanalysis), LC (Linear cryptanalysis), and related key attacks.
+   SEED has gone through wide public scrutinizing procedures.  It has
+   been evaluated and is considered cryptographically secure by credible
+   organizations such as ISO/IEC JTC 1/SC 27 and Japan CRYPTREC
+   (Cryptography Research and Evaluation Committees)
+   [ISOSEED][CRYPTREC].
+
+   SEED is a national industrial association standard [TTASSEED] and is
+   widely used in South Korea for electronic commerce and financial
+   services operated on wired and wireless communications.
+
+1.2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
+   "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
+   as shown) are to be interpreted as described in [RFC2119].
+
+2.  Object Identifiers for Content and Key Encryption
+
+   This section provides the OIDs and processing information necessary
+   for SEED to be used for content and key encryption in CMS.  SEED is
+   added to the set of optional symmetric encryption algorithms in CMS
+   by providing two classes of unique object identifiers (OIDs).  One
+   OID class defines the content encryption algorithms and the other
+   defines the key encryption algorithms.  Thus, a CMS agent can apply
+   SEED either for content or key encryption by selecting the
+   corresponding object identifier, supplying the required parameter,
+   and starting the program code.
+
+
+
+
+
+
+
+Park, et al.                Standards Track                     [Page 2]
+
+RFC 4010          The SEED Encryption Algorithm in CMS     February 2005
+
+
+2.1.  OIDs for Content Encryption
+
+   SEED is added to the set of symmetric content encryption algorithms
+   defined in [CMSALG].  The SEED content-encryption algorithm in Cipher
+   Block Chaining (CBC) mode has the following object identifier:
+
+      id-seedCBC OBJECT IDENTIFIER ::=
+        { iso(1) member-body(2) korea(410) kisa(200004)
+          algorithm(1) seedCBC(4) }
+
+   The AlgorithmIdentifier parameters field MUST be present, and the
+   parameters field MUST contain the value of Initialization Vector
+   (IV):
+
+      SeedCBCParameter ::= SeedIV  --  Initialization Vector
+
+      SeedIV ::= OCTET STRING (SIZE(16))
+
+   The plain text is padded according to Section 6.3 of [CMS].
+
+2.2.  OIDs for Key Encryption
+
+   The key-wrap/unwrap procedures used to encrypt/decrypt a SEED
+   content-encryption key (CEK) with a SEED key-encryption key (KEK) are
+   specified in Section 3.  Generation and distribution of key-
+   encryption keys are beyond the scope of this document.
+
+   The SEED key-encryption algorithm has the following object
+   identifier:
+
+      id-npki-app-cmsSeed-wrap OBJECT IDENTIFIER ::=
+        { iso(1) member-body(2) korea(410) kisa(200004) npki-app(7)
+          smime(1) alg(1) cmsSEED-wrap(1) }
+
+   The parameter associated with this object identifier MUST be absent,
+   because the key wrapping procedure itself defines how and when to use
+   an IV.
+
+3.  Key Wrap Algorithm
+
+   SEED key wrapping and unwrapping is done in conformance with the AES
+   key wrap algorithm [RFC3394].
+
+3.1.  Notation and Definitions
+
+   The following notation is used in the description of the key wrapping
+   algorithms:
+
+
+
+
+Park, et al.                Standards Track                     [Page 3]
+
+RFC 4010          The SEED Encryption Algorithm in CMS     February 2005
+
+
+         SEED(K, W)    Encrypt W using the SEED codebook with key K
+         SEED-1(K, W)  Decrypt W using the SEED codebook with key K
+         MSB(j, W)     Return the most significant j bits of W
+         LSB(j, W)     Return the least significant j bits of W
+         B1 ^ B2       The bitwise exclusive or (XOR) of B1 and B2
+         B1 | B2       Concatenate B1 and B2
+         K             The key-encryption key K
+         n             The number of 64-bit key data blocks
+         s             The number of steps in the wrapping process,
+                       s = 6n
+         P[i]          The ith plaintext key data block
+         C[i]          The ith ciphertext data block
+         A             The 64-bit integrity check register
+         R[i]          An array of 64-bit registers where
+                       i = 0, 1, 2, ..., n
+         A[t], R[i][t] The contents of registers A and R[i] after
+                       encryption step t.
+         IV            The 64-bit initial value used during the
+                       wrapping process.
+
+   In the key wrap algorithm, the concatenation function will be used to
+   concatenate 64-bit quantities to form the 128-bit input to the SEED
+   codebook.  The extraction functions will be used to split the 128-bit
+   output from the SEED codebook into two 64-bit quantities.
+
+3.2.  SEED Key Wrap
+
+   Key wrapping with SEED is identical to Section 2.2.1 of [RFC3394]
+   with "AES" replaced by "SEED".
+
+   The inputs to the key wrapping process are the KEK and the plaintext
+   to be wrapped.  The plaintext consists of n 64-bit blocks containing
+   the key data being wrapped.  The key wrapping process is described
+   below.
+
+     Inputs:  Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}, and
+              Key, K (the KEK).
+     Outputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}.
+
+   1) Initialize variables.
+
+     Set A[0] to an initial value (see Section 3.4)
+     For i = 1 to n
+       R[0][i] = P[i]
+
+
+
+
+
+
+
+Park, et al.                Standards Track                     [Page 4]
+
+RFC 4010          The SEED Encryption Algorithm in CMS     February 2005
+
+
+   2) Calculate intermediate values.
+
+     For t = 1 to s, where s = 6n
+       A[t] = MSB(64, SEED(K, A[t-1] | R[t-1][1])) ^ t
+       For i = 1 to n-1
+         R[t][i] = R[t-1][i+1]
+       R[t][n] = LSB(64, SEED(K, A[t-1] | R[t-1][1]))
+
+   3) Output the results.
+
+     Set C[0] = A[s]
+     For i = 1 to n
+       C[i] = R[s][i]
+
+   An alternative description of the key wrap algorithm involves
+   indexing rather than shifting.  This approach allows one to calculate
+   the wrapped key in place, avoiding the rotation in the previous
+   description.  This produces identical results and is more easily
+   implemented in software.
+
+     Inputs:  Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}, and
+              Key, K (the KEK).
+     Outputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}.
+
+   1) Initialize variables.
+
+     Set A = IV, an initial value (see Section 3.4)
+     For i = 1 to n
+       R[i] = P[i]
+
+   2) Calculate intermediate values.
+
+     For j = 0 to 5
+       For i=1 to n
+         B = SEED(K, A | R[i])
+         A = MSB(64, B) ^ t where t = (n*j)+i
+         R[i] = LSB(64, B)
+
+   3) Output the results.
+
+      Set C[0] = A
+      For i = 1 to n
+        C[i] = R[i]
+
+
+
+
+
+
+
+
+Park, et al.                Standards Track                     [Page 5]
+
+RFC 4010          The SEED Encryption Algorithm in CMS     February 2005
+
+
+3.3.  SEED Key Unwrap
+
+   Key unwrapping with SEED is identical to Section 2.2.2 of [RFC3394],
+   with "AES" replaced by "SEED".
+
+   The inputs to the unwrap process are the KEK and (n+1) 64-bit blocks
+   of ciphertext consisting of previously wrapped key.  It returns n
+   blocks of plaintext consisting of the n 64-bit blocks of the
+   decrypted key data.
+
+     Inputs:  Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]},
+              and Key, K (the KEK).
+     Outputs: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}.
+
+   1) Initialize variables.
+
+     Set A[s] = C[0] where s = 6n
+     For i = 1 to n
+       R[s][i] = C[i]
+
+   2) Calculate the intermediate values.
+
+     For t = s to 1
+       A[t-1] = MSB(64, SEED-1(K, ((A[t] ^ t) | R[t][n]))
+       R[t-1][1] = LSB(64, SEED-1(K, ((A[t]^t) | R[t][n]))
+       For i = 2 to n
+         R[t-1][i] = R[t][i-1]
+
+   3) Output the results.
+
+     If A[0] is an appropriate initial value (see Section 3.4),
+     Then
+       For i = 1 to n
+         P[i] = R[0][i]
+     Else
+       Return an error
+
+   The unwrap algorithm can also be specified as an index based
+   operation, allowing the calculations to be carried out in place.
+   Again, this produces the same results as the register shifting
+   approach.
+
+     Inputs:  Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]},
+              and Key, K (the KEK).
+     Outputs: Plaintext, n 64-bit values {P[0], P[1], ..., P[n]}.
+
+
+
+
+
+
+Park, et al.                Standards Track                     [Page 6]
+
+RFC 4010          The SEED Encryption Algorithm in CMS     February 2005
+
+
+   1) Initialize variables.
+
+     Set A = C[0]
+     For i = 1 to n
+       R[i] = C[i]
+
+   2) Compute intermediate values.
+
+     For j = 5 to 0
+       For i = n to 1
+         B = SEED-1(K, (A ^ t) | R[i]) where t = n*j+i
+         A = MSB(64, B)
+         R[i] = LSB(64, B)
+
+   3) Output results.
+
+     If A is an appropriate initial value (see Section 3.4),
+     Then
+       For i = 1 to n
+         P[i] = R[i]
+     Else
+       Return an error
+
+3.4.  Key Data Integrity -- the Initial Value
+
+   The initial value (IV) refers to the value assigned to A[0] in the
+   first step of the wrapping process.  This value is used to obtain an
+   integrity check on the key data.  In the final step of the unwrapping
+   process, the recovered value of A[0] is compared to the expected
+   value of A[0].  If there is a match, the key is accepted as valid,
+   and the unwrapping algorithm returns it.  If there is not a match,
+   then the key is rejected, and the unwrapping algorithm returns an
+   error.
+
+   The exact properties achieved by this integrity check depend on the
+   definition of the initial value.  Different applications may call for
+   somewhat different properties; for example, whether there is a need
+   to determine the integrity of key data throughout its lifecycle or
+   just when it is unwrapped.  This specification defines a default
+   initial value that supports the integrity of the key data during the
+   period it is wrapped (in Section 3.4.1).  Provision is also made to
+   support alternative initial values (in Section 3.4.2).
+
+
+
+
+
+
+
+
+
+Park, et al.                Standards Track                     [Page 7]
+
+RFC 4010          The SEED Encryption Algorithm in CMS     February 2005
+
+
+3.4.1.  Default Initial Value
+
+   The default initial value (IV) is defined to be the hexadecimal
+   constant:
+
+     A[0] = IV = A6A6A6A6A6A6A6A6
+
+   The use of a constant as the IV supports a strong integrity check on
+   the key data during the period that it is wrapped.  If unwrapping
+   produces A[0] = A6A6A6A6A6A6A6A6, then the chance that the key data
+   is corrupt is 2^-64.  If unwrapping produces A[0] = any other value,
+   then the unwrap must return an error and not return any key data.
+
+3.4.2.  Alternative Initial Values
+
+   When the key wrap is used as part of a larger key management protocol
+   or system, the desired scope for data integrity may be more than just
+   the key data, and the desired duration may be more than just the
+   period that it is wrapped.  Also, if the key data is not just a SEED
+   key, it may not always be a multiple of 64 bits.  Alternative
+   definitions of the initial value can be used to address such
+   problems.  According to RFC 3394 [RFC3394], NIST will define
+   alternative initial values in future key management publications as
+   they are needed.  To accommodate a set of alternatives that may
+   evolve over time, non-application-specific key wrap implementations
+   will require some flexibility in the way the initial value is set and
+   tested.
+
+4.  SMIMECapabilities Attribute
+
+   An S/MIME client SHOULD announce the set of cryptographic functions
+   it supports by using the S/MIME capabilities attribute.  This
+   attribute provides a partial list of OIDs of cryptographic functions
+   and MUST be signed by the client.  The functions' OIDs SHOULD be
+   logically separated in functional categories and MUST be ordered with
+   respect to their preference.
+
+   RFC 3851 [RFC3851], Section 2.5.2 defines the SMIMECapabilities
+   signed attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs)
+   to be used to specify a partial list of algorithms that the software
+   announcing the SMIMECapabilities can support.
+
+   If an S/MIME client is required to support symmetric encryption with
+   SEED, the capabilities attribute MUST contain the SEED OID specified
+   above in the category of symmetric algorithms.  The parameter
+   associated with this OID MUST be SeedSMimeCapability.
+
+     SeedSMimeCapabilty ::= NULL
+
+
+
+Park, et al.                Standards Track                     [Page 8]
+
+RFC 4010          The SEED Encryption Algorithm in CMS     February 2005
+
+
+   The SMIMECapability SEQUENCE representing SEED MUST be DER-encoded as
+   the following hexadecimal strings:
+
+     30 0C 06 08 2A 83 1A 8C 9A 44 01 04 05 00
+
+   When a sending agent creates an encrypted message, it has to decide
+   which type of encryption algorithm to use.  In general, the decision
+   process involves information obtained from the capabilities lists
+   included in messages received from the recipient, as well as other
+   information, such as private agreements, user preferences and legal
+   restrictions.  If local policy requires the use of SEED for symmetric
+   encryption, then both the sending and receiving S/MIME clients must
+   support it, and SEED must be configured as the preferred symmetric
+   algorithm.
+
+5.  Security Considerations
+
+   This document specifies the use of SEED for encrypting the content of
+   a CMS message and for encrypting the symmetric key used to encrypt
+   the content of a CMS message, with the other mechanisms being the
+   same as the existing ones.  Therefore, the security considerations
+   described in the CMS specifications [CMS][CMSALG] and the AES key
+   wrap algorithm [RFC3394] can be applied to this document.  No
+   security problem has been found on SEED [CRYPTREC].
+
+6.  References
+
+6.1.  Normative References
+
+   [TTASSEED]  Telecommunications Technology Association (TTA), South
+               Korea, "128-bit Symmetric Block Cipher (SEED)", TTAS.KO-
+               12.0004, September, 1998 (In Korean)
+               http://www.tta.or.kr/English/new/main/index.htm
+
+   [CMS]       Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+               3852, July 2004.
+
+   [CMSALG]    Housley, R., "Cryptographic Message Syntax (CMS)
+               Algorithms", RFC 3370, August 2002.
+
+   [RFC3851]   Ramsdell, B., "Secure/Multipurpose Internet Mail
+               Extensions (S/MIME) Version 3.1 Message Specification",
+               RFC 3851, July 2004.
+
+   [RFC3394]   Schaad, J. and R. Housley, "Advanced Encryption Standard
+               (AES) Key Wrap Algorithm", RFC 3394, September 2002.
+
+
+
+
+
+Park, et al.                Standards Track                     [Page 9]
+
+RFC 4010          The SEED Encryption Algorithm in CMS     February 2005
+
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+6.2.  Informative References
+
+   [SEED]      Park, J., Lee, S., Kim, J., and J. Lee, "The SEED
+               Encryption Algorithm", RFC 4009, February 2005.
+
+   [ISOSEED]   ISO/IEC, ISO/IEC JTC1/SC 27 N 256r1, "National Body
+               contributions on NP 18033 Encryption algorithms in
+               response to document SC 27 N 2563", October, 2000
+
+   [CRYPTREC]  Information-technology Promotion Agency (IPA), Japan,
+               CRYPTREC. "SEED Evaluation Report", February, 2002
+               http://www.kisa.or.kr
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park, et al.                Standards Track                    [Page 10]
+
+RFC 4010          The SEED Encryption Algorithm in CMS     February 2005
+
+
+Appendix A.  ASN.1 Module
+
+     SeedEncryptionAlgorithmInCMS
+         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+           pkcs9(9) smime(16) modules(0) id-mod-cms-seed(24) }
+
+
+     DEFINITIONS IMPLICIT TAGS ::=
+
+     BEGIN
+
+       id-seedCBC OBJECT IDENTIFIER ::=
+        { iso(1) member-body(2) korea(410) kisa(200004)
+          algorithm(1) seedCBC(4) }
+
+       --  Initialization Vector (IV)
+
+       SeedCBCParameter ::= SeedIV
+       SeedIV ::= OCTET STRING (SIZE(16))
+
+       -- SEED Key Wrap Algorithm identifiers - Parameter is absent.
+
+       id-npki-app-cmsSeed-wrap OBJECT IDENTIFIER ::=
+         { iso(1) member-body(2) korea(410) kisa(200004) npki-app(7)
+           smime(1) alg(1) cmsSEED-wrap(1) }
+
+       -- SEED S/MIME Capability parameter
+
+       SeedSMimeCapability ::= NULL
+
+     END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park, et al.                Standards Track                    [Page 11]
+
+RFC 4010          The SEED Encryption Algorithm in CMS     February 2005
+
+
+Authors' Addresses
+
+   Jongwook Park
+   Korea Information Security Agency
+   78, Garak-Dong, Songpa-Gu, Seoul, 138-803
+   REPUBLIC OF KOREA
+
+   Phone: +82-2-405-5432
+   FAX  : +82-2-405-5499
+   EMail: khopri@kisa.or.kr
+
+
+   Sungjae Lee
+   Korea Information Security Agency
+
+   Phone: +82-2-405-5243
+   FAX  : +82-2-405-5499
+   EMail: sjlee@kisa.or.kr
+
+
+   Jeeyeon Kim
+   Korea Information Security Agency
+
+   Phone: +82-2-405-5238
+   FAX  : +82-2-405-5499
+   EMail: jykim@kisa.or.kr
+
+
+   Jaeil Lee
+   Korea Information Security Agency
+   Phone: +82-2-405-5300
+   FAX  : +82-2-405-5499
+   EMail: jilee@kisa.or.kr
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park, et al.                Standards Track                    [Page 12]
+
+RFC 4010          The SEED Encryption Algorithm in CMS     February 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+Park, et al.                Standards Track                    [Page 13]
+