Network Working Group J. Park
Request for Comments: 4010 S. Lee
Category: Standards Track J. Kim
J. Lee
KISA
February 2005
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)
在加密消息语法（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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).
本文件规定了使用种子加密算法对加密消息语法（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.
通过提供两类唯一对象标识符（OID），将种子添加到CMS中的可选对称加密算法集中。一个OID类定义内容加密算法，另一个定义密钥加密算法。
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.
本文件规定了使用种子加密算法[SEED][TTASSEED]进行加密的约定，该算法采用加密消息语法（CMS）[CMS]。提供相关对象标识符（OID）和处理步骤，以便在CMS规范（RFC 3852、RFC 3370）中使用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是KISA（韩国信息安全局）和一组专家自1998年以来开发的对称加密算法。种子的输入/输出块大小和密钥长度为128位。种子具有16个圆形的Feistel结构。128位输入分为两个64位块，右64位块是round函数的输入，其中64位子键由键调度生成。
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易于在各种软件和硬件中实现，因为它比其他算法占用更少的内存，并且在不降低算法安全性的情况下生成密钥。特别是，它可以有效地应用于资源受限的计算环境，如移动设备和智能卡。
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对已知的攻击具有鲁棒性，包括DC（差分密码分析）、LC（线性密码分析）和相关的密钥攻击。SEED已经通过了广泛的公众审查程序。ISO/IEC JTC 1/SC 27和日本CRYPTREC（密码学研究和评估委员会）[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.
SEED是国家工业协会标准[TTASSEED]，在韩国广泛用于有线和无线通信的电子商务和金融服务。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应该”、“不应该”、“建议”、“可以”和“可选”（大写，如图所示）应按照[RFC2119]中所述进行解释。
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.
本节提供了在CMS中用于内容和密钥加密的种子所需的OID和处理信息。通过提供两类唯一对象标识符（OID），将种子添加到CMS中的可选对称加密算法集中。一个OID类定义内容加密算法，另一个定义密钥加密算法。因此，CMS代理可以通过选择相应的对象标识符、提供所需参数并启动程序代码，为内容或密钥加密应用种子。
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:
种子添加到[CMSALG]中定义的对称内容加密算法集。密码块链接（CBC）模式下的种子内容加密算法具有以下对象标识符：
id-seedCBC OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) korea(410) kisa(200004)
algorithm(1) seedCBC(4) }
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):
AlgorithmIdentifier parameters字段必须存在，parameters字段必须包含初始化向量（IV）的值：
SeedCBCParameter ::= SeedIV -- Initialization Vector
SeedCBCParameter ::= SeedIV -- Initialization Vector
SeedIV ::= OCTET STRING (SIZE(16))
SeedIV ::= OCTET STRING (SIZE(16))
The plain text is padded according to Section 6.3 of [CMS].
纯文本根据[CMS]第6.3节进行填充。
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.
第3节规定了用于使用种子密钥加密密钥（KEK）加密/解密种子内容加密密钥（CEK）的密钥包装/展开过程。密钥加密密钥的生成和分发超出了本文档的范围。
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) }
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.
必须缺少与此对象标识符关联的参数，因为密钥包装过程本身定义了如何以及何时使用IV。
SEED key wrapping and unwrapping is done in conformance with the AES key wrap algorithm [RFC3394].
种子密钥包装和展开按照AES密钥包装算法[RFC3394]进行。
The following notation is used in the description of the key wrapping algorithms:
以下符号用于密钥包装算法的描述：
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.
SEED（K，W）使用密钥为K的种子码本加密W SEED-1（K，W）使用密钥为K的种子码本解密W MSB（j，W）返回W的最高有效j位LSB（j，W）返回W B1^B2的最低有效j位按位异或（XOR）B1和B2的B1 | B2连接B1和b2k密钥加密密钥kn 64位密钥数据块的数量s包装过程中的步骤数，s=6np[i]第i个明文密钥数据块C[i]第i个密文数据块A 64位完整性检查寄存器R[i]一个64位寄存器数组，其中i=0，1，2，…，na[t]，R[i][t]在加密步骤t之后，寄存器A和R[i]的内容。IV包装过程中使用的64位初始值。
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.
在密钥包裹算法中，串联函数将用于串联64位量，以形成种子码本的128位输入。提取函数将用于将种子码本的128位输出分成两个64位量。
Key wrapping with SEED is identical to Section 2.2.1 of [RFC3394] with "AES" replaced by "SEED".
带种子的键包装与[RFC3394]第2.2.1节相同，将“AES”替换为“种子”。
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.
密钥包装过程的输入是KEK和要包装的明文。明文由n个64位块组成，其中包含要包装的密钥数据。密钥包装过程如下所述。
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]}.
输入：明文，n个64位值{P[1]，P[2]，…，P[n]}，键，K（KEK）。输出：密文，（n+1）64位值{C[0]，C[1]，…，C[n]}。
1) Initialize variables.
1) 初始化变量。
Set A[0] to an initial value (see Section 3.4) For i = 1 to n R[0][i] = P[i]
对于i=1到nR[0][i]=P[i]，将A[0]设置为初始值（见第3.4节）
2) Calculate intermediate values.
2) 计算中间值。
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]))
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.
3) 输出结果。
Set C[0] = A[s] For i = 1 to n C[i] = R[s][i]
将i=1的C[0]=A[s]设置为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]}.
输入：明文，n个64位值{P[1]，P[2]，…，P[n]}，键，K（KEK）。输出：密文，（n+1）64位值{C[0]，C[1]，…，C[n]}。
1) Initialize variables.
1) 初始化变量。
Set A = IV, an initial value (see Section 3.4) For i = 1 to n R[i] = P[i]
设置A=IV，i=1到nR[i]=P[i]的初始值（见第3.4节）
2) Calculate intermediate values.
2) 计算中间值。
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)
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.
3) 输出结果。
Set C[0] = A For i = 1 to n C[i] = R[i]
将i=1的C[0]=A设置为nc[i]=R[i]
Key unwrapping with SEED is identical to Section 2.2.2 of [RFC3394], with "AES" replaced by "SEED".
带种子的密钥展开与[RFC3394]第2.2.2节相同，“AES”替换为“种子”。
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.
解包裹过程的输入是KEK和（n+1）64位密文块，由先前包装的密钥组成。它返回由n个64位解密密钥数据块组成的n个明文块。
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]}.
输入：密文，（n+1）64位值{C[0]，C[1]，…，C[n]}，以及密钥K（KEK）。输出：明文，n个64位值{P[1]，P[2]，…，P[n]}。
1) Initialize variables.
1) 初始化变量。
Set A[s] = C[0] where s = 6n For i = 1 to n R[s][i] = C[i]
设置A[s]=C[0]，其中i=1的s=6n到n R[s][i]=C[i]
2) Calculate the intermediate values.
2) 计算中间值。
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]
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.
3) 输出结果。
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
如果[0]是一个合适的初始值（见第3.4节），则对于i=1到n P[i]=R[0][i]，否则返回一个错误
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]}.
输入：密文，（n+1）64位值{C[0]，C[1]，…，C[n]}，以及密钥K（KEK）。输出：明文，n个64位值{P[0]，P[1]，…，P[n]}。
1) Initialize variables.
1) 初始化变量。
Set A = C[0] For i = 1 to n R[i] = C[i]
将i=1的A=C[0]设置为nr[i]=C[i]
2) Compute intermediate values.
2) 计算中间值。
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)
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.
3) 输出结果。
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
如果A是适当的初始值（见第3.4节），则对于i=1到n P[i]=R[i]，否则返回一个错误
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.
初始值（IV）是指在包装过程的第一步中分配给[0]的值。此值用于获取密钥数据的完整性检查。在展开过程的最后一步中，将[0]的恢复值与[0]的预期值进行比较。如果存在匹配项，则密钥被视为有效密钥，展开算法将返回该密钥。如果不存在匹配项，则拒绝密钥，并且展开算法返回错误。
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).
此完整性检查实现的确切属性取决于初始值的定义。不同的应用可能需要一些不同的属性；例如，是否需要确定关键数据在其整个生命周期中的完整性，还是仅在其展开时确定其完整性。本规范定义了一个默认初始值，该值支持密钥数据在包装期间的完整性（见第3.4.1节）。还提供了支持备选初始值的规定（见第3.4.2节）。
The default initial value (IV) is defined to be the hexadecimal constant:
默认初始值（IV）定义为十六进制常数：
A[0] = IV = A6A6A6A6A6A6A6A6
A[0]=IV=A6
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.
将常量用作IV支持在关键数据包装期间对其进行强完整性检查。如果展开生成[0]=A6，则密钥数据损坏的可能性为2^-64。如果展开生成[0]=任何其他值，则展开必须返回错误，而不返回任何关键数据。
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.
当密钥包装被用作更大密钥管理协议或系统的一部分时，所需的数据完整性范围可能不仅仅是密钥数据，并且所需的持续时间可能不仅仅是其包装的周期。此外，如果密钥数据不仅仅是种子密钥，它可能并不总是64位的倍数。初始值的替代定义可用于解决此类问题。根据RFC 3394[RFC3394]，NIST将根据需要在未来的关键管理出版物中定义替代初始值。为了适应一组可能随时间发展的备选方案，非特定于应用程序的密钥封装实现需要在初始值的设置和测试方式上具有一定的灵活性。
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.
S/MIME客户端应通过使用S/MIME capabilities属性来宣布其支持的加密函数集。此属性提供加密函数OID的部分列表，必须由客户端签名。函数的OID应按功能类别进行逻辑分隔，并且必须根据其偏好进行排序。
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.
RFC 3851[RFC3851]，第2.5.2节定义了SMIMECapability签名属性（定义为SMIMECapability序列），用于指定宣布SMIMECapability的软件可以支持的算法的部分列表。
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.
如果S/MIME客户端需要支持使用SEED的对称加密，则“能力”属性必须包含上述对称算法类别中指定的SEED OID。与此OID关联的参数必须是SeedSMimeCapability。
SeedSMimeCapabilty ::= NULL
SeedSMimeCapabilty ::= NULL
The SMIMECapability SEQUENCE representing SEED MUST be DER-encoded as the following hexadecimal strings:
表示种子的SMIMECapability序列必须按以下十六进制字符串进行DER编码：
30 0C 06 08 2A 83 1A 8C 9A 44 01 04 05 00
30 0C 06 08 2A 83 1A 8C 9A 44 01 04 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.
当发送代理创建加密消息时，它必须决定使用哪种类型的加密算法。一般来说，决策过程涉及从收件人收到的邮件中包含的功能列表中获得的信息，以及其他信息，如私人协议、用户偏好和法律限制。如果本地策略要求使用SEED进行对称加密，则发送和接收S/MIME客户端都必须支持它，并且SEED必须配置为首选对称算法。
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].
本文件规定了使用SEED加密CMS消息内容和加密用于加密CMS消息内容的对称密钥，其他机制与现有机制相同。因此，CMS规范[CMS][CMSALG]和AES密钥封装算法[RFC3394]中描述的安全注意事项可应用于本文件。在种子[CRYPTREC]上未发现任何安全问题。
[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
[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.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年7月。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMSALG]Housley，R.，“加密消息语法（CMS）算法”，RFC3370，2002年8月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851]Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3394]Schaad，J.和R.Housley，“高级加密标准（AES）密钥包裹算法”，RFC 3394，2002年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SEED] Park, J., Lee, S., Kim, J., and J. Lee, "The SEED Encryption Algorithm", RFC 4009, February 2005.
[SEED]Park，J.，Lee，S.，Kim，J.，和J.Lee，“种子加密算法”，RFC 4009，2005年2月。
[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
[ISOSEED]ISO/IEC，ISO/IEC JTC1/SC 27 N 256r1，“国家机构对文件SC 27 N 2563的NP 18033加密算法的贡献”，2000年10月
[CRYPTREC] Information-technology Promotion Agency (IPA), Japan, CRYPTREC. "SEED Evaluation Report", February, 2002 http://www.kisa.or.kr
[CRYPTREC]信息技术促进机构（IPA），日本，CRYPTREC。“种子评估报告”，2002年2月http://www.kisa.or.kr
SeedEncryptionAlgorithmInCMS
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) smime(16) modules(0) id-mod-cms-seed(24) }
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 ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
id-seedCBC OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) korea(410) kisa(200004)
algorithm(1) seedCBC(4) }
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))
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) }
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
--种子S/MIME功能参数
SeedSMimeCapability ::= NULL
SeedSMimeCapability ::= NULL
END
终止
Authors' Addresses
作者地址
Jongwook Park Korea Information Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA
Jongwook Park韩国信息安全局78号，韩国首尔松帕谷Garak Dong，138-803
Phone: +82-2-405-5432
FAX : +82-2-405-5499
EMail: khopri@kisa.or.kr
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
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
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
Jaeil Lee韩国信息安全局电话：+82-2-405-5300传真：+82-2-405-5499电子邮件：jilee@kisa.or.kr
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。