< draft-ietf-smime-cms-seed-01.txt		draft-ietf-smime-cms-seed-02.txt >
	S/MIME Working Group Jongwook Park (KISA)		S/MIME Working Group Jongwook Park (KISA)
	Internet Draft Sungjae Lee (KISA)		Internet Draft Sungjae Lee (KISA)
	Document: draft-ietf-smime-cms-seed-01.txt Jeeyeon Kim (KISA)		Document: draft-ietf-smime-cms-seed-02.txt Jeeyeon Kim (KISA)
	Expires: October 2004 Jaeil Lee (KISA)		Expires: Feburary 2005 Jaeil Lee (KISA)
	Target category : Standard Track April 2004		Target category : Standard Track August 2004
	Use of the SEED Encryption Algorithm in CMS		Use of the SEED Encryption Algorithm
			in Cryptographic Message Syntax (CMS)
	<draft-ietf-smime-cms-seed-01.txt>		<draft-ietf-smime-cms-seed-02.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026.		patent or other IPR claims of which I am aware have been disclosed,
			and any of which I become aware will be disclosed, in accordance with
			RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its Areas, and its Working Groups. Note that other
	groups may also distribute working documents as Internet- Drafts.		groups may also distribute working documents as Internet Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet Drafts are draft documents valid for a maximum of six
	and may be updated, replaced, or obsoleted by other documents at any		months. Internet Drafts may be updated, replaced, or obsoleted by
	time. It is inappropriate to use Internet-Drafts as reference		other documents at any time. It is not appropriate to use Internet
	material or to cite them other than as "work in progress."		Drafts as reference material or to cite them other than as a "working
			draft" or "work in progress".
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http//www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http//www.ietf.org/shadow.html.
	Comments or suggestions for improvement may be made on the "ietf-		Copyright Notice
	smime" mailing list, or directly to the author.
			Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This document specifies the conventions for using the SEED encryption		This document specifies the conventions for using the SEED encryption
	algorithm for encryption with the Cryptographic Message Syntax (CMS).		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		1. Introduction
	This document specifies the conventions for using the SEED encryption		This document specifies the conventions for using the SEED encryption
	algorithm [SEED][TTASSEED] for encryption with the Cryptographic		algorithm [SEED][TTASSEED] for encryption with the Cryptographic
	Message Syntax (CMS)[CMS]. The relevant object identifiers (OIDs) and		Message Syntax (CMS)[CMS]. The relevant object identifiers (OIDs) and
	processing steps are provided so that SEED may be used in the CMS		processing steps are provided so that SEED may be used in the CMS
	specification (RFC 3369, RFC 3370) for content and key encryption.		specification (RFC 3369, RFC 3370) for content and key encryption.
	1.1 SEED		1.1 SEED
	SEED is a symmetric encryption algorithm that had been developed by		SEED is a symmetric encryption algorithm that had been developed by
	KISA (Korea Information Security Agency) and a group of experts since		KISA (Korea Information Security Agency) and a group of experts since
	1998. The input/output block size of SEED is 128-bit and the key		1998. The input/output block size of SEED is 128-bit and the key
	length is also 128-bit. SEED has the 16-round Feistel structure. A		length is also 128-bit. SEED has the 16-round Feistel structure. A
	128-bit input is divided into two 64-bit blocks and the right 64-bit		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		block is an input to the round function with a 64-bit subkey
	generated from the key scheduling.		generated from the key scheduling.
	SEED is easily implemented in various software and hardware because		SEED is easily implemented in various software and hardware because
	it is designed to increase the efficiency of memory storage and the		it takes less memory to implement that than other algorithms and
	simplicity in generating keys without degrading the security of the		generates keys without degrading the security of the algorithm. In
	algorithm. In particular, it can be effectively adopted to a		particular, it can be effectively adopted to a computing environment
	computing environment with a restricted resources such as a mobile		with a restricted resources such as a mobile devices, smart cards and
	devices, smart cards and so on.		so on.
	SEED is robust against known attacks including DC (Differential		SEED is robust against known attacks including DC (Differential
	cryptanalysis), LC (Linear cryptanalysis) and related key attacks,		cryptanalysis), LC (Linear cryptanalysis) and related key attacks,
	etc. SEED has gone through wide public scrutinizing procedures.		etc. SEED has gone through wide public scrutinizing procedures.
	Especially, it has been evaluated and also considered		Especially, it has been evaluated and also considered
	cryptographically secure by trustworhty organizations such as ISO/IEC		cryptographically secure by credible organizations such as ISO/IEC
	JTC 1/SC 27 and Japan CRYTEC (Cryptography Reasearch and Evaluation		JTC 1/SC 27 and Japan CRYTEC (Cryptography Reasearch and Evaluation
	Comittees) [ISOSEED][CRYPTEC].		Comittees) [ISOSEED][CRYPTEC].
	SEED is a national industrial association standard [TTASSEED] and is		SEED is a national industrial association standard [TTASSEED] and is
	widely used in South Korea for electronic commerce and financial		widely used in South Korea for electronic commerce and financial
	services operated on wired & wireless PKI.		services operated on wired & wireless communications.
	1.2 Terminology		1.2 Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
	"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,		"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
	as shown) are to be interpreted as described in [RFC2119].		as shown) are to be interpreted as described in [RFC2119].
	2. Object Identifiers for Content and Key Encryption		2. Object Identifiers for Content and Key Encryption
	This section provides the OIDs and processing information necessary		This section provides the OIDs and processing information necessary
	for SEED to be used for content and key encryption in CMS. SEED is		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		added to the set of optional symmetric encryption algorithms in CMS
	by providing two classes of unique object identifiers (OIDs). One		by providing two classes of unique object identifiers (OIDs). One OID
	OID class defines the content encryption algorithms and the other		class defines the content encryption algorithms and the other defines
	defines the key encryption algorithms. Thus a CMS agent can apply		the key encryption algorithms. Thus a CMS agent can apply SEED either
	SEED either for content or key encryption by selecting the		for content or key encryption by selecting the corresponding object
	corresponding object identifier, supplying the required parameter,		identifier, supplying the required parameter, and starting the
	and starting the program code.		program code.
	2.1 OIDs for Content Encryption		2.1 OIDs for Content Encryption
	SEED is added to the set of symmetric content encryption algorithms		SEED is added to the set of symmetric content encryption algorithms
	defined in [CMSALG]. The SEED content-encryption algorithm in Cipher		defined in [CMSALG]. The SEED content-encryption algorithm in Cipher
	Block Chaining (CBC) mode has the following object identifier:		Block Chaining (CBC) mode has the following object identifier:
	id-seedCBC OBJECT IDENTIFIER ::=		id-seedCBC OBJECT IDENTIFIER ::=
	{ iso(1) member-body(2) korea(410) kisa(200004)		{ iso(1) member-body(2) korea(410) kisa(200004)
	algorithm(1) seedCBC(4) }		algorithm(1) seedCBC(4) }
	The AlgorithmIdentifier parameters field MUST be present, and the		The AlgorithmIdentifier parameters field MUST be present, and the
	parameters field MUST contain the value of IV:		parameters field MUST contain the value of Initialization Vector
			(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].		The plain text is padded according to Section 6.3 of [CMS].
	2.2 OIDs for Key Encryption		2.2 OIDs for Key Encryption
	The key-wrap/unwrap procedures used to encrypt/decrypt a SEED		The key-wrap/unwrap procedures used to encrypt/decrypt a SEED
	content-encryption key (CEK) with a SEED key-encryption key		content-encryption key (CEK) with a SEED key-encryption key (KEK) are
	(KEK) are specified in Section 3. Generation and distribution of		specified in Section 3. Generation and distribution of key-encryption
	key-encryption keys are beyond the scope of this document.		keys are beyond the scope of this document.
	The SEED key-encryption algorithm has the following object		The SEED key-encryption algorithm has the following object
	identifier:		identifier:
	id-npki-app-cmsSeed-wrap OBJECT IDENTIFIER ::=		id-npki-app-cmsSeed-wrap OBJECT IDENTIFIER ::=
	{ iso(1) member-body(2) korea(410) kisa(200004) npki-app(7)		{ iso(1) member-body(2) korea(410) kisa(200004) npki-app(7)
	smime(1) alg(1) cmsSEED-wrap(1) }		smime(1) alg(1) cmsSEED-wrap(1) }
	The parameter associated with this object identifier MUST be absent,		The parameter associated with this object identifier MUST be absent,
	because the key wrapping procedure itself defines how and when to		because the key wrapping procedure itself defines how and when to use
	use an IV.		an IV.
	3. Key Wrap Algorithm		3. Key Wrap Algorithm
	SEED key wrapping and unwrapping is done in conformance with the		SEED key wrapping and unwrapping is done in conformance with the AES
	AES key wrap algorithm [AES-WRAP][RFC3394].		key wrap algorithm [RFC3394].
	3.1 Notation and Defintions		3.1 Notation and Defintions
	The following notation is used in the description of the key		The following notation is used in the description of the key wrapping
	wrapping algorithms:		algorithms:
	SEED(K, W) Encrypt W using the SEED codebook with key K		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		SEED-1(K, W) Decrypt W using the SEED codebook with key K
	MSB(j, W) Return the most significant j bits of W		MSB(j, W) Return the most significant j bits of W
	LSB(j, W) Return the least 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 The bitwise exclusive or (XOR) of B1 and B2
	B1 | B2 Concatenate B1 and B2		B1 | B2 Concatenate B1 and B2
	K The key-encryption key K		K The key-encryption key K
	n The number of 64-bit key data blocks		n The number of 64-bit key data blocks
	s The number of steps in the wrapping process,		s The number of steps in the wrapping process,
	s = 6n		s = 6n
	P[i] The ith plaintext key data block		P[i] The ith plaintext key data block
	C[i] The ith ciphertext data block		C[i] The ith ciphertext data block
	A The 64-bit integrity check register		A The 64-bit integrity check register
	R[i] An array of 64-bit registers where		R[i] An array of 64-bit registers where
	i = 0, 1, 2, ..., n		i = 0, 1, 2, ..., n
	A[t], R[t][i] The contents of registers A and R[i] after		A[t], R[t][i] The contents of registers A and R[i] after
	encryption step t.		encryption step t.
	IV The 64-bit initial value used during the		IV The 64-bit initial value used during the
	wrapping process.		wrapping process.
	In the key wrap algorithm, the concatenation function will be used to		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		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		codebook. The extraction functions will be used to split the 128-bit
	output from the SEED codebook into two 64-bit quantities.		output from the SEED codebook into two 64-bit quantities.
	3.2 SEED Key Wrap		3.2 SEED Key Wrap
	Key wrapping with SEED is identical to Section 2.2.1 of [RFC3394]		Key wrapping with SEED is identical to Section 2.2.1 of [RFC3394]
	with "AES" replaced by "SEED".		with "AES" replaced by "SEED".
	The inputs to the key wrapping process are the KEK and the plaintext		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		to be wrapped. The plaintext consists of n 64-bit blocks, containing
	the key data being wrapped. The key wrapping process is described		the key data being wrapped. The key wrapping process is described
	below.		below.
	Inputs: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}, and		Inputs: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}, and
	Key, K (the KEK).		Key, K (the KEK).
	Outputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}.		Outputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}.
	1) Initialize variables.		1) Initialize variables.
	Set A[0] to an initial value (see Section 3.4)		Set A[0] to an initial value (see Section 3.4)
	For i = 1 to n		For i = 1 to n
	R[0][i] = P[i]		R[0][i] = P[i]
	2) Calculate intermediate values.		2) Calculate intermediate values.
	For t = 1 to s, where s = 6n		For t = 1 to s, where s = 6n
	A[t] = MSB(64, SEED(K, A[t-1] | R[t-1][1])) ^ t		A[t] = MSB(64, SEED(K, A[t-1] | R[t-1][1])) ^ t
	For i = 1 to n-1		For i = 1 to n-1
	R[t][i] = R[t-1][i+1]		R[t][i] = R[t-1][i+1]
	R[t][n] = LSB(64, SEED(K, A[t-1] | R[t-1][1]))		R[t][n] = LSB(64, SEED(K, A[t-1] | R[t-1][1]))
	3) Output the results.		3) Output the results.
	Set C[0] = A[s]		Set C[0] = A[s]
	For i = 1 to n		For i = 1 to n
	C[i] = R[s][i]		C[i] = R[s][i]
	An alternative description of the key wrap algorithm involves		An alternative description of the key wrap algorithm involves
	indexing rather than shifting. This approach allows one to		indexing rather than shifting. This approach allows one to calculate
	calculate the wrapped key in place, avoiding the rotation in the		the wrapped key in place, avoiding the rotation in the previous
	previous description. This produces identical results and is more		description. This produces identical results and is more easily
	easily implemented in software.		implemented in software.
	Inputs: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}, and		Inputs: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}, and
	Key, K (the KEK).		Key, K (the KEK).
	Outputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}.		Outputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}.
	1) Initialize variables.		1) Initialize variables.
	Set A = IV, an initial value (see Section 3.4)		Set A = IV, an initial value (see Section 3.4)
	For i = 1 to n		For i = 1 to n
	R[i] = P[i]		R[i] = P[i]
	2) Calculate intermediate values.		2) Calculate intermediate values.
	For j = 0 to 5		For j = 0 to 5
	For i=1 to n		For i=1 to n
	B = SEED(K, A | R[i])		B = SEED(K, A | R[i])
	A = MSB(64, B) ^ t where t = (n*j)+i		A = MSB(64, B) ^ t where t = (n*j)+i
	R[i] = LSB(64, B)		R[i] = LSB(64, B)
	3) Output the results.		3) Output the results.
	Set C[0] = A		Set C[0] = A
	For i = 1 to n		For i = 1 to n
	C[i] = R[i]		C[i] = R[i]
	3.3 SEED Key Unwrap		3.3 SEED Key Unwrap
	Key unwrapping with SEED is identical to Section 2.2.2 of		Key unwrapping with SEED is identical to Section 2.2.2 of [RFC3394],
	[RFC3394], with "AES" replaced by "SEED".		with "AES" replaced by "SEED".
	The inputs to the unwrap process are the KEK and (n+1) 64-bit blocks		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		of ciphertext consisting of previously wrapped key. It returns n
	blocks of plaintext consisting of the n 64-bit blocks of the		blocks of plaintext consisting of the n 64-bit blocks of the
	decrypted key data.		decrypted key data.
	Inputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}, and		Inputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]},
	Key, K (the KEK).		and Key, K (the KEK).
	Outputs: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}.		Outputs: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}.
	1) Initialize variables.		1) Initialize variables.
	Set A[s] = C[0] where s = 6n		Set A[s] = C[0] where s = 6n
	For i = 1 to n		For i = 1 to n
	R[s][i] = C[i]		R[s][i] = C[i]
	2) Calculate the intermediate values.		2) Calculate the intermediate values.
	For t = s to 1		For t = s to 1
	A[t-1] = MSB(64, SEED-1(K, ((A[t] ^ t) | R[t][n]))		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]))		R[t-1][1] = LSB(64, SEED-1(K, ((A[t]^t) | R[t][n]))
	For i = 2 to n		For i = 2 to n
	R[t-1][i] = R[t][i-1]		R[t-1][i] = R[t][i-1]
	3) Output the results.		3) Output the results.
	If A[0] is an appropriate initial value (see Section 3.4),		If A[0] is an appropriate initial value (see Section 3.4),
	Then		Then
	For i = 1 to n		For i = 1 to n
	P[i] = R[0][i]		P[i] = R[0][i]
	Else		Else
	Return an error		Return an error
	The unwrap algorithm can also be specified as an index based		The unwrap algorithm can also be specified as an index based
	operation, allowing the calculations to be carried out in place.		operation, allowing the calculations to be carried out in place.
	Again, this produces the same results as the register shifting		Again, this produces the same results as the register shifting
	approach.		approach.
	Inputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}, and		Inputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]},
	Key, K (the KEK).		and Key, K (the KEK).
	Outputs: Plaintext, n 64-bit values {P[0], P[1], ..., P[n]}.
			Outputs: Plaintext, n 64-bit values {P[0], P[1], ..., P[n]}.
	1) Initialize variables.		1) Initialize variables.
	Set A = C[0]		Set A = C[0]
	For i = 1 to n		For i = 1 to n
	R[i] = C[i]		R[i] = C[i]
	2) Compute intermediate values.		2) Compute intermediate values.
	For j = 5 to 0		For j = 5 to 0
	For i = n to 1		For i = n to 1
	B = SEED-1(K, (A ^ t) | R[i]) where t = n*j+i		B = SEED-1(K, (A ^ t) | R[i]) where t = n*j+i
	A = MSB(64, B)		A = MSB(64, B)
	R[i] = LSB(64, B)		R[i] = LSB(64, B)
	3) Output results.		3) Output results.
	If A is an appropriate initial value (see Section 3.4),		If A is an appropriate initial value (see Section 3.4),
	Then		Then
	For i = 1 to n		For i = 1 to n
	P[i] = R[i]		P[i] = R[i]
	Else		Else
	Return an error		Return an error
	3.4 Key Data Integrity -- the Initial Value		3.4 Key Data Integrity -- the Initial Value
	The initial value (IV) refers to the value assigned to A[0] in the		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		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		integrity check on the key data. In the final step of the unwrapping
	unwrapping process, the recovered value of A[0] is compared to the		process, the recovered value of A[0] is compared to the expected
	expected value of A[0]. If there is a match, the key is accepted as		value of A[0]. If there is a match, the key is accepted as valid, and
	valid, and the unwrapping algorithm returns it. If there is not a		the unwrapping algorithm returns it. If there is not a match, then
	match, then the key is rejected, and the unwrapping algorithm		the key is rejected, and the unwrapping algorithm returns an error.
	returns an error.
	The exact properties achieved by this integrity check depend on the		The exact properties achieved by this integrity check depend on the
	definition of the initial value. Different applications may call		definition of the initial value. Different applications may call for
	for somewhat different properties; for example, whether there is		somewhat different properties; for example, whether there is need to
	need to determine the integrity of key data throughout its lifecycle		determine the integrity of key data throughout its lifecycle or just
	or just when it is unwrapped. This specification defines a default		when it is unwrapped. This specification defines a default initial
	initial value that supports integrity of the key data during the		value that supports integrity of the key data during the period it is
	period it is wrapped (in Section 3.4.1). Provision is also made to		wrapped (in Section 3.4.1). Provision is also made to support
	support alternative initial values (in Section 3.4.2).		alternative initial values (in Section 3.4.2).
	3.4.1 Default Initial Value		3.4.1 Default Initial Value
	The default initial value (IV) is defined to be the hexadecimal		The default initial value (IV) is defined to be the hexadecimal
	constant:		constant:
	A[0] = IV = A6A6A6A6A6A6A6A6		A[0] = IV = A6A6A6A6A6A6A6A6
	The use of a constant as the IV supports a strong integrity check on		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		the key data during the period that it is wrapped. If unwrapping
	produces A[0] = A6A6A6A6A6A6A6A6, then the chance that the key data		produces A[0] = A6A6A6A6A6A6A6A6, then the chance that the key data
	is corrupt is 2^-64. If unwrapping produces A[0] any other value,		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.		then the unwrap must return an error and not return any key data.
	3.4.2 Alternative Initial Values		3.4.2 Alternative Initial Values
	When the key wrap is used as part of a larger key management		When the key wrap is used as part of a larger key management protocol
	protocol or system, the desired scope for data integrity may be more		or system, the desired scope for data integrity may be more than just
	than just the key data or the desired duration for more than just		the key data or the desired duration for more than just the period
	the period that it is wrapped. Also, if the key data is not just an		that it is wrapped. Also, if the key data is not just an SEED key, it
	SEED key, it may not always be a multiple of 64 bits.		may not always be a multiple of 64 bits. Alternative definitions of
	Alternative definitions of the initial value can be used to address		the initial value can be used to address such problems. According to
	such problems. According to [RFC3394], NIST will define alternative		[RFC3394], NIST will define alternative initial values in future key
	initial values in future key management publications as needed. In		management publications as needed. In order to accommodate a set of
	order to accommodate a set of alternatives that may evolve over		alternatives that may evolve over time, key wrap implementations that
	time, key wrap implementations that are not application-specific		are not application-specific will require some flexibility in the way
	will require some flexibility in the way that the initial value is		that the initial value is set and tested.
	set and tested.
	4. SMIMECapabilities Attribute		4. SMIMECapabilities Attribute
	An S/MIME client SHOULD announce the set of cryptographic functions		An S/MIME client SHOULD announce the set of cryptographic functions
	it supports by using the S/MIME capabilities attribute. This		it supports by using the S/MIME capabilities attribute. This
	attribute provides a partial list of OIDs of cryptographic functions		attribute provides a partial list of OIDs of cryptographic functions
	and MUST be signed by the client. The functions' OIDs SHOULD be		and MUST be signed by the client. The functions' OIDs SHOULD be
	logically separated in functional categories and MUST be ordered		logically separated in functional categories and MUST be ordered with
	with respect to their preference.		respect to their preference.
	RFC 2633 [RFC2633], Section 2.5.2 defines the SMIMECapabilities		RFC 2633 [RFC2633], Section 2.5.2 defines the SMIMECapabilities
	signed attribute (defined as a SEQUENCE of SMIMECapability		signed attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs)
	SEQUENCEs) to be used to specify a partial list of algorithms that		to be used to specify a partial list of algorithms that the software
	the software announcing the SMIMECapabilities can support.		announcing the SMIMECapabilities can support.
	If an S/MIME client is required to support symmetric encryption with		If an S/MIME client is required to support symmetric encryption with
	SEED, the capabilities attribute MUST contain the SEED OID		SEED, the capabilities attribute MUST contain the SEED OID specified
	specified above in the category of symmetric algorithms. The		above in the category of symmetric algorithms. The parameter
	parameter associated with this OID MUST be SeedSMimeCapability.		associated with this OID MUST be SeedSMimeCapability.
	SeedSMimeCapabilty ::= NULL		SeedSMimeCapabilty ::= NULL
	The SMIMECapability SEQUENCE representing SEED MUST be		The SMIMECapability SEQUENCE representing SEED MUST be DER-encoded as
	DER-encoded as the following hexadecimal strings:		the following hexadecimal strings:
	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 05 00
	When a sending agent creates an encrypted message, it has to decide		When a sending agent creates an encrypted message, it has to decide
	which type of encryption algorithm to use. In general the decision		which type of encryption algorithm to use. In general the decision
	process involves information obtained from the capabilities lists		process involves information obtained from the capabilities lists
	included in messages received from the recipient, as well as other		included in messages received from the recipient, as well as other
	information such as private agreements, user preferences, legal		information such as private agreements, user preferences, legal
	restrictions, and so on. If users require SEED for symmetric		restrictions, and so on. If local policy requires the use of SEED for
	encryption, it MUST be supported by the S/MIME clients on both the		symmetric encryption, then the both the sending and receiving S/MIME
	sending and receiving side, and it MUST be set in the user		clients must support it, and SEED must be configured as the preferred
	preferences.		symmetric algorithm.
	5. Security Considerations		5. Security Considerations
	This document specifies the use of SEED for encrypting the		This document specifies the use of SEED for encrypting the content of
	content of a CMS message and for encrypting the symmetric key used		a CMS message and for encrypting the symmetric key used to encrypt
	to encrypt the content of a CMS message, and the other mechanisms		the content of a CMS message, and the other mechanisms are the same
	are the same as the existing ones. Therefore, the security		as the existing ones. Therefore, the security considerations
	considerations described in the CMS specifications [CMS][CMSALG] and		described in the CMS specifications [CMS][CMSALG] and the AES key
	the AES key wrap algorithm [AES-WRAP][RFC3394] can be applied to		wrap algorithm [RFC3394] can be applied to this document. No security
	this document. No security problem has been found on SEED		problem has been found on SEED [CRYPTREC].
	[CRYPTREC].
	6. Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any
	intellectual property 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; neither does it represent
	that it has made any effort to identify any such rights.
	Information on the IETF's procedures with respect to rights in
	standards-track and standards-related documentation can be found
	in BCP-11. Copies of claims of rights made available for
	publication 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 implementors
	or users of this specification can be obtained from the IETF
	Secretariat.
	The IETF invites any interested party to bring to its attention
	any copyrights, patents or patent applications, or other
	proprietary rights which may cover technology that may be required
	to practice this standard. Please address the information to the
	IETF Executive Director.
	7. Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.
	This document and translations of it may be copied and furnished
	to others, and derivative works that comment on or otherwise
	explain it or assist in its implmentation may be prepared, copied,
	published and distributed, in whole or in part, without
	restriction of any kind, provided that the above copyright notice
	and this paragraph are included on all such copies and derivative
	works. However, this document itself may not be modified in any
	way, such as by removing the copyright notice or references to the
	Internet Society or other Internet organizations, except as needed
	for the purpose of developing Internet standards in which case the
	procedures for copyrights defined in the Internet Standards
	process must be followed, or as required to translate it into
	languages other than English.
	The limited permissions granted above are perpetual and will not
	be revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on		6. References
	an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIMS 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."
	8. References		6.1 Normative Reference
	8.1 Normative Reference		[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] R. Housley, "Cryptographic Message Syntax", RFC 3369,		[CMS] R. Housley, "Cryptographic Message Syntax", RFC 3369,
	August 2002.		August 2002.
	[CMSALG] R. Housley, "Cryptographic Message Syntax (CMS)		[CMSALG] R. Housley, "Cryptographic Message Syntax (CMS)
	Algorithms", RFC 3370, August 2002.		Algorithms", RFC 3370, August 2002.
	[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2633] Ramsdell, B., Editor. S/MIME Version 3 Message		[RFC2633] Ramsdell, B., Editor. S/MIME Version 3 Message
	Specification. RFC 2633. June 1999.		Specification. RFC 2633. June 1999.
	[RFC3394] J. Schaad and R. Housley, "Advanced Encryption Standard		[RFC3394] J. Schaad and R. Housley, "Advanced Encryption Standard
	(AES) Key Wrap Algorithm", RFC 3394, September 2002.		(AES) Key Wrap Algorithm", RFC 3394, September 2002.
	[AES-WRAP] National Institute of Standards and Technology. AES Key		[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
	Wrap Specification. 17 November 2001.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	http://csrc.nist.gov/encryption/kms/key-wrap.pdf
	8.2 Informative Reference		6.2 Informative Reference
	[SEED] Jongwook Park, Sungjae Lee, Jeeyeon Kim, Jaeil Lee,		[SEED] Jongwook Park, Sungjae Lee, Jeeyeon Kim, Jaeil Lee,
	"The SEED Encryption Algorithm", draft-park-seed-00.txt		"The SEED Encryption Algorithm", draft-park-seed-01.txt
	[SEED-WEB] KISA, "SEED Algorithm Specification",
	http://www.kisa.or.kr/seed/seed_eng.html"
	[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
	[ISOSEED] ISO/IEC, ISO/IEC JTC1/SC 27 N 256r1, "National Body		[ISOSEED] ISO/IEC, ISO/IEC JTC1/SC 27 N 256r1, "National Body
	contributions on NP 18033 Encryption algorithms in		contributions on NP 18033 Encryption algorithms in
	response to document SC 27 N 2563", October, 2000		response to document SC 27 N 2563", October, 2000
	[CRYPTREC] Information-technology Promotion Agency (IPA), Japan,		[CRYPTREC] Information-technology Promotion Agency (IPA), Japan,
	CRYPTREC. "SEED Evaluation Report", February, 2002		CRYPTREC. "SEED Evaluation Report", February, 2002
	http://www.kisa.or.kr		http://www.kisa.or.kr
	9. Authors' Address		7. Authors' Address
	Jongwook Park		Jongwook Park
	Korea Information Security Agency		Korea Information Security Agency
			78, Garak-Dong, Songpa-Gu, Seoul, 138-803
			REPUBLIC OF KOREA
	Phone: +82-2-405-5432		Phone: +82-2-405-5432
	FAX : +82-2-405-5499		FAX : +82-2-405-5499
	Email: khopri@kisa.or.kr		Email: khopri@kisa.or.kr
	Sungjae Lee		Sungjae Lee
	Korea Information Security Agency		Korea Information Security Agency
	Phone: +82-2-405-5243		Phone: +82-2-405-5243
	FAX : +82-2-405-5499		FAX : +82-2-405-5499
	Email: sjlee@kisa.or.kr		Email: sjlee@kisa.or.kr
	skipping to change at page 12, line 8 ¶		skipping to change at page 10, line 46 ¶
	Phone: +82-2-405-5238		Phone: +82-2-405-5238
	FAX : +82-2-405-5499		FAX : +82-2-405-5499
	Email: jykim@kisa.or.kr		Email: jykim@kisa.or.kr
	Jaeil Lee		Jaeil Lee
	Korea Information Security Agency		Korea Information Security Agency
	Phone: +82-2-405-5300		Phone: +82-2-405-5300
	FAX : +82-2-405-5499		FAX : +82-2-405-5499
	Email: jilee@kisa.or.kr		Email: jilee@kisa.or.kr
	Appendix A ASN.1 Module		8. Intellectual Property Statement
	SeedEncryptionAlgorithmInCMS		The IETF takes no position regarding the validity or scope of any
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)		Intellectual Property Rights or other rights that might be claimed to
	pkcs9(9) smime(16) modules(0) id-mod-cms-seed(25) }		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 procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
	DEFINITIONS IMPLICIT TAGS ::=		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.
	BEGIN		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.
	id-seedCBC OBJECT IDENTIFIER ::=		9. Full Copyright Statement
	{ iso(1) member-body(2) korea(410) kisa(200004)
	algorithm(1) seedCBC(4) }
			Copyright (C) The Internet Society (2004). 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.
	SeedCBCParameter ::= SeedIV		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.
	SeedIV ::= OCTET STRING (SIZE(16))		Appendix. 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) }
	id-npki-app-cmsSeed-wrap OBJECT IDENTIFIER ::=		DEFINITIONS IMPLICIT TAGS ::=
	{ iso(1) member-body(2) korea(410) kisa(200004) npki-app(7)
	smime(1) alg(1) cmsSEED-wrap(1) }
			BEGIN
	SeedSMimeCapability ::= NULL		id-seedCBC OBJECT IDENTIFIER ::=
			{ iso(1) member-body(2) korea(410) kisa(200004)
			algorithm(1) seedCBC(4) }
	END		-- 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 Capabilty parameter
			SeedSMimeCapability ::= NULL
			END
End of changes. 83 change blocks.
	261 lines changed or deleted		239 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/