< draft-chudov-cryptopro-cptls-03.txt		draft-chudov-cryptopro-cptls-04.txt >
	- G. Chudov, Ed.		- G. Chudov, Ed.
	Internet-Draft S. Leontiev, Ed.		Internet-Draft S. Leontiev, Ed.
	Intended status: Standards Track CRYPTO-PRO		Intended status: Informational CRYPTO-PRO
	Expires: March 12, 2007 September 8, 2006		Expires: June 11, 2009 December 8, 2008
	GOST 28147-89 Cipher Suites for Transport Layer Security (TLS)		GOST 28147-89 Cipher Suites for Transport Layer Security (TLS)
	draft-chudov-cryptopro-cptls-03.txt		draft-chudov-cryptopro-cptls-04
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	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		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "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.
	This Internet-Draft will expire on March 12, 2007.		This Internet-Draft will expire on June 11, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (c) 2008 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(http://trustee.ietf.org/license-info) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with respect
			to this document.
	Abstract		Abstract
	This document is intended to register new cipher suites for the		This document is intended to register new cipher suites for the
	Transport Layer Security (TLS) protocol, according to the procedure		Transport Layer Security (TLS) protocol, according to the procedure
	specified in TLS Protocol standards. These cipher suites are based		specified in TLS Protocol standards. These cipher suites are based
	on Russian national cryptographic standards - GOST R 34.10-94 and		on Russian national cryptographic standards - GOST R 34.10-94 and
	GOST R 34.10-2001 public keys, GOST 28147-89 encryption algorithm and		GOST R 34.10-2001 public keys, GOST 28147-89 encryption algorithm and
	GOST R 34.11-94 digest algorithm.		GOST R 34.11-94 digest algorithm.
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 30 ¶
	3.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 5		3.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 5
	3.5. Certificate Request . . . . . . . . . . . . . . . . . . . 6		3.5. Certificate Request . . . . . . . . . . . . . . . . . . . 6
	3.6. Client Key Exchange Message . . . . . . . . . . . . . . . 6		3.6. Client Key Exchange Message . . . . . . . . . . . . . . . 6
	3.7. Certificate Verify . . . . . . . . . . . . . . . . . . . . 8		3.7. Certificate Verify . . . . . . . . . . . . . . . . . . . . 8
	3.8. Finished . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.8. Finished . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Normative references . . . . . . . . . . . . . . . . . . . 10		7.1. Normative references . . . . . . . . . . . . . . . . . . . 10
	7.2. Informative references . . . . . . . . . . . . . . . . . . 11		7.2. Informative references . . . . . . . . . . . . . . . . . . 12
	Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 12		Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 12
	A.1. Gost-CryptoPro-TLS . . . . . . . . . . . . . . . . . . . . 12		A.1. Gost-CryptoPro-TLS . . . . . . . . . . . . . . . . . . . . 12
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 13		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	Intellectual Property and Copyright Statements . . . . . . . . . . 16
	1. Introduction		1. Introduction
	This document proposes the addition of new cipher suites to the		This document proposes the addition of new cipher suites to the
	Transport Layer Security (TLS) protocol to support GOST R 34.11-94		Transport Layer Security (TLS) protocol to support GOST R 34.11-94
	digest, GOST 28147-89 encryption and VKO GOST R 34.10-94/2001 key		digest, GOST 28147-89 encryption and VKO GOST R 34.10-94/2001 key
	exchange algorithms. The cipher suites defined here were proposed by		exchange algorithms. The cipher suites defined here were proposed by
	CRYPTO-PRO Company for the "Russian Cryptographic Software		CRYPTO-PRO Company for the "Russian Cryptographic Software
	Compatibility Agreement" community.		Compatibility Agreement" community.
	skipping to change at page 4, line 20 ¶		skipping to change at page 4, line 20 ¶
	| TLS_GOSTR341094_WITH_NULL_GOSTR3411 | VKO GOST R 34.10-94 |		| TLS_GOSTR341094_WITH_NULL_GOSTR3411 | VKO GOST R 34.10-94 |
	| TLS_GOSTR341001_WITH_NULL_GOSTR3411 | VKO GOST R 34.10-2001 |		| TLS_GOSTR341001_WITH_NULL_GOSTR3411 | VKO GOST R 34.10-2001 |
	+-------------------------------------+------------------------+		+-------------------------------------+------------------------+
	Key derivation algorithms based on GOST R 34.10-94 and GOST R 34.10-		Key derivation algorithms based on GOST R 34.10-94 and GOST R 34.10-
	2001 public keys (VKO GOST R 34.10-94, VKO GOST R 34.10-2001) are		2001 public keys (VKO GOST R 34.10-94, VKO GOST R 34.10-2001) are
	described in [CPALGS].		described in [CPALGS].
	2.2. PRF, Signature and Hash		2.2. PRF, Signature and Hash
	For a PRF, described in section 5 of [TLS1.2], the cipher suites		The cipher suites described here use HMAC and TLS PRF, as described
	described here use PRF_GOSTR3411 (refer to Section 3.1). The same		in section 5 of [TLS1.2], based on GOST R 34.11-94 hash function
	PRF MUST be used for all dependent protocols, such as [EAP-TLS].		(HMAC_GOSTR3411 and PRF_GOSTR3411), with parameter set identified by
			id-GostR3411-94-CryptoProParamSet (refer to [CPALGS]). The same PRF
			MUST be used for all dependent protocols, such as [EAP-TLS].
	GOST R 34.10-94/2001 signature is used for CertificateVerify message.		GOST R 34.10-94/2001 signature is used for CertificateVerify message.
	GOST R 34.11 digest algorithm ([GOSTR341194]) is used for		GOST R 34.11 digest algorithm ([GOSTR341194]) is used for
	CertificateVerify.signature.gostR3411_hash and Finished.verify_data		CertificateVerify.signature.gostR3411_hash and Finished.verify_data
	(see sections 7.4.10 and 7.4.11 of [TLS1.2])		(see sections 7.4.10 and 7.4.11 of [TLS1.2])
	2.3. Cipher and MAC		2.3. Cipher and MAC
	The following cipher algorithm and MAC functions are used (for		The following cipher algorithm and MAC functions are used (for
	skipping to change at page 4, line 45 ¶		skipping to change at page 4, line 47 ¶
	+-------------------------------------+-----------+----------------+		+-------------------------------------+-----------+----------------+
	| CipherSuite | Cipher | MAC |		| CipherSuite | Cipher | MAC |
	+-------------------------------------+-----------+----------------+		+-------------------------------------+-----------+----------------+
	| TLS_GOSTR341094_WITH_28147_CNT_IMIT | GOST28147 | IMIT_GOST28147 |		| TLS_GOSTR341094_WITH_28147_CNT_IMIT | GOST28147 | IMIT_GOST28147 |
	| TLS_GOSTR341001_WITH_28147_CNT_IMIT | GOST28147 | IMIT_GOST28147 |		| TLS_GOSTR341001_WITH_28147_CNT_IMIT | GOST28147 | IMIT_GOST28147 |
	| TLS_GOSTR341094_WITH_NULL_GOSTR3411 | - | HMAC_GOSTR3411 |		| TLS_GOSTR341094_WITH_NULL_GOSTR3411 | - | HMAC_GOSTR3411 |
	| TLS_GOSTR341001_WITH_NULL_GOSTR3411 | - | HMAC_GOSTR3411 |		| TLS_GOSTR341001_WITH_NULL_GOSTR3411 | - | HMAC_GOSTR3411 |
	+-------------------------------------+-----------+----------------+		+-------------------------------------+-----------+----------------+
	For all four cipher suites, the use of MAC is slighttly different		For all four cipher suites, the use of MAC is slighttly different
	from the one, described in section 6.2.3.1 of [TLS1.2]. In [TLS1.2],		from the one, described in section 6.2.3.1 of [TLS1.2] for standard
	MAC is calculated from the following data:		stream ciphers, where MAC is calculated from the following data:
	MACed_data[seq_num] = seq_num +		MACed_data[seq_num] = seq_num +
	TLSCompressed.type +		TLSCompressed.type +
	TLSCompressed.version +		TLSCompressed.version +
	TLSCompressed.length +		TLSCompressed.length +
	TLSCompressed.fragment;		TLSCompressed.fragment;
	These cipher suites use the same input for first record, but for each		Cipher suites defined in this document use the same input for first
	next record the input from all previous records is concatenated:		record, but for each consequent record the input from all previous
			records is concatenated:
	MACed_data[0] + ... + MACed_data[n]		MACed_data[0] + ... + MACed_data[n]
	3. Data Structures and Computations		3. Data Structures and Computations
	3.1. Algorithms		3.1. Algorithms
	GOST 28147-89 [GOST28147] uses 256-bit key size and 8-byte IV.		GOST 28147-89 [GOST28147] uses 256-bit key size and 8-byte IV.
	Cipher suites, defined here, use GOST 28147-89 as a stream cipher in		Cipher suites, defined here, use GOST 28147-89 as a stream cipher in
	counter mode with S-box from id-Gost28147-89-CryptoPro-A-ParamSet		counter mode with S-box parameter from id-Gost28147-89-CryptoPro-A-
	(see [CPALGS]) and CryptoPro key meshing algorithm.		ParamSet (see [CPALGS]) and CryptoPro key meshing algorithm.
	IMIT_GOST28147 is GOST 28147-89 [GOST28147] in "IMITOVSTAVKA" mode (4		IMIT_GOST28147 is GOST 28147-89 [GOST28147] in "IMITOVSTAVKA" mode (4
	bytes)		bytes)
	HMAC_GOSTR3411(secret, data) is based on GOST R 34.11-94 digest and
	described in [CPALGS].
	PRF_GOSTR3411(secret, label, seed) is based on HMAC_GOSTR3411 and
	described in [CPALGS].
	3.2. Keys Calculation		3.2. Keys Calculation
	Key calculation is done according to section 6.3 of [TLS1.2], with		Key calculation is done according to section 6.3 of [TLS1.2], using
	PRF_GOSTR3411 function used instead of PRF. The parameters are as		PRF_GOSTR3411. The parameters are as follows:
	follows:
	SecurityParameters.hash_size = 32		SecurityParameters.enc_key_length = 32
	SecurityParameters.key_material_length = 32		SecurityParameters.mac_key_length = 32
	SecurityParameters.IV_size = 8		SecurityParameters.fixed_iv_length = 8
	Length of necessary key material is 144 bytes.		Length of necessary key material is 144 bytes.
	3.3. Server Certificate		3.3. Server Certificate
	For these cipher suites this message is required and it MUST contain		For these cipher suites this message is required and it MUST contain
	a certificate, with a public key algorithm matching		a certificate, with a public key algorithm matching
	ServerHello.cipher_suite.		ServerHello.cipher_suite.
	3.4. Server Key Exchange		3.4. Server Key Exchange
	This message MUST NOT be used in these cipher suites, because all the		This message MUST NOT be used in these cipher suites, because all the
	parameters necessary are present in server certificate (see [CPPK]).		parameters necessary are present in server certificate (see [CPPK]).
	3.5. Certificate Request		3.5. Certificate Request
	This message is used as described in section 7.4.5 of [TLS1.2], and		This message is used as described in section 7.4.4 of [TLS1.2], and
	extended as follows:		extended as follows:
	enum {		enum {
	gostr341094(21), gostr34102001(22),(255)		gostr341094(21), gostr34102001(22),(255)
	} ClientCertificateType;		} ClientCertificateType;
	gostr341094 and gostr34102001 certificate types identify that the		gostr341094 and gostr34102001 certificate types identify that the
	server accepts GOST R 34.10-94 and GOST R 34.10-2001 public key		server accepts GOST R 34.10-94 and GOST R 34.10-2001 public key
	certificates.		certificates.
	[IANA please remove] Note: The above numeric definitions for		enum{
	ClientCertificateType have not yet been registered.		gostr3411(XX)
			} HashAlgorithm;
	enum{		enum{
	gostr3411(XX), (255)		gostr341094(XX), gostr34102001(XX)
	} HashType;		} SignatureAlgorithm;
	gostr3411 hash type identifes that the server accepts GOST R 34.11-94		gostr3411 hash type identifes that the server accepts GOST R 34.11-94
	hash function. It is RECOMMENDED to populate		hash function. It is RECOMMENDED to populate
	CertificateRequest.certificate_hash only with gostr3411 value, when		CertificateRequest.certificate_hash only with gostr3411 value, when
	one of the cipher suites described in this document is chosen.		one of the cipher suites described in this document is chosen.
			The server SHOULD populate supported_signature_algorithm field with
			SignatureAndHashAlgorithm pairs, where HashAlgorithm equals gostr3411
			and SignatureAlgorithm matches corresponding ClientCertificateType.
	3.6. Client Key Exchange Message		3.6. Client Key Exchange Message
	This message is used as described in section 7.4.9 of [TLS1.2], it is		This message is used as described in section 7.4.7 of [TLS1.2], it is
	required for these suites, and contains DER-encoded		required for these suites, and contains DER-encoded
	TLSGostKeyTransportBlob structure [X.660].		TLSGostKeyTransportBlob structure [X.660].
	enum { vko_gost } KeyExchangeAlgorithm;		enum { vko_gost } KeyExchangeAlgorithm;
	struct {		struct {
	select (KeyExchangeAlgorithm) {		select (KeyExchangeAlgorithm) {
	case vko_gost: TLSGostKeyTransportBlob;		case vko_gost: TLSGostKeyTransportBlob;
	} exchange_keys;		} exchange_keys;
	} ClientKeyExchange;		} ClientKeyExchange;
	skipping to change at page 8, line 25 ¶		skipping to change at page 8, line 25 ¶
	Server applies VKO GOST R 34.10-94 or VKO GOST R 34.10-2001,		Server applies VKO GOST R 34.10-94 or VKO GOST R 34.10-2001,
	(depending on the client public key type), and CryptoPro Key Unwrap		(depending on the client public key type), and CryptoPro Key Unwrap
	algorithm in the simillar manner to decrypt the premaster_secret.		algorithm in the simillar manner to decrypt the premaster_secret.
	Server MUST verify keyBlob.sessionEncryptedKey.macKey after		Server MUST verify keyBlob.sessionEncryptedKey.macKey after
	decrypting the premaster_secret.		decrypting the premaster_secret.
	3.7. Certificate Verify		3.7. Certificate Verify
	This message is used as described in section 7.4.10 of [TLS1.2]. If		This message is used as described in section 7.4.8 of [TLS1.2]. If
	the client have sent both a client certificate and an ephemeral		the client have sent both a client certificate and an ephemeral
	public key, it MUST send a certificate verify message, as a proof of		public key, it MUST send a certificate verify message, as a proof of
	possession of the private key for provided certificate.		possession of the private key for provided certificate.
	The TLS structures are extended as follows:		The TLS structures are extended as follows:
	enum { gostr341094, gostr34102001 }		enum { gostr341094, gostr34102001 }
	SignatureAlgorithm;		SignatureAlgorithm;
	select (SignatureAlgorithm) {		select (SignatureAlgorithm) {
	skipping to change at page 9, line 7 ¶		skipping to change at page 9, line 7 ¶
	digitally-signed struct {		digitally-signed struct {
	opaque gostr341194_hash[32];		opaque gostr341194_hash[32];
	};		};
	} Signature;		} Signature;
	CertificateVerify.signature.gostR3411_hash =		CertificateVerify.signature.gostR3411_hash =
	GOSTR3411(handshake_messages)		GOSTR3411(handshake_messages)
	3.8. Finished		3.8. Finished
	This message is used as described in section 7.4.11 of [TLS1.2].		This message is used as described in section 7.4.9 of [TLS1.2].
	Finished.verify_data = PRF_GOSTR3411(master_secret, finished_label,		Finished.verify_data = PRF_GOSTR3411(master_secret, finished_label,
	GOSTR3411(handshake_messages)) [0..11]		GOSTR3411(handshake_messages)) [0..11]
	4. Compatibility		4. Compatibility
	Some applications use the cipher suites specified herein with		For historical reasons, some applications use the cipher suites
	[TLS1.0], using features of [TLS1.2], including cipher-suite		specified herein with [TLS1.0], using some features of [TLS1.2],
	dependent PRF, Finished and Certificate Verify computations.		including cipher-suite dependent PRF, Finished and Certificate Verify
			computations.
	5. Security Considerations		5. Security Considerations
	It is RECOMMENDED that software applications verify signature values,		It is RECOMMENDED that software applications verify signature values,
	subject public keys and algorithm parameters to conform to		subject public keys and algorithm parameters to conform to
	[GOSTR341001], [GOSTR341094] standards prior to their use.		[GOSTR341001], [GOSTR341094] standards prior to their use.
	Use of the same key for signature and key derivation is NOT		Use of the same key for signature and key derivation is NOT
	RECOMMENDED.		RECOMMENDED.
	skipping to change at page 9, line 42 ¶		skipping to change at page 9, line 43 ¶
	analyzed by special certification laboratory of Scientific and		analyzed by special certification laboratory of Scientific and
	Technical Centre "ATLAS" in appropriate levels of		Technical Centre "ATLAS" in appropriate levels of
	target_of_evaluation (TOE).		target_of_evaluation (TOE).
	It is RECOMMENDED to subject the implementations of these cipher		It is RECOMMENDED to subject the implementations of these cipher
	suites to examination by an authorized agency with approved methods		suites to examination by an authorized agency with approved methods
	of cryptographic analysis.		of cryptographic analysis.
	6. IANA Considerations		6. IANA Considerations
	IANA has assigned the following values for GOST 28147-89 mode ciphers		This document defines the following new cipher suites, whose values
	definitions:		presented here are used by several implementations of the same cipher
			suites for TLS 1.0, and were described in previous drafts. They are
			currently listed in the registry as reserved. IANA is requested to
			update the TLS Cipher Suite registry defined in [RFC5246] with these
			values.
			CipherSuite TLS_GOSTR341094_WITH_28147_CNT_IMIT = {0x00,0x80}
			CipherSuite TLS_GOSTR341001_WITH_28147_CNT_IMIT = {0x00,0x81}
			CipherSuite TLS_GOSTR341094_WITH_NULL_GOSTR3411 = {0x00,0x82}
			CipherSuite TLS_GOSTR341001_WITH_NULL_GOSTR3411 = {0x00,0x83}
			This document defines the following new client certificate types,
			whose values presented here are used by several implementations of
			the same suites for TLS 1.0, and were described in previous drafts.
			They are currently listed in the registry as reserved. IANA is
			requested to update the TLS ClientCertificateType Identifiers
			Registry defined in [RFC5246] with these values.
	enum {		enum {
	gostr341094(21), gostr34102001(22)		gostr341094(21), gostr34102001(22)
	} ClientCertificateType;		} ClientCertificateType;
			This document defines the following new signature algorithm types,
			whose values are to be assigned from the TLS SignatureAlgorithm
			Registry defined in [RFC5246].
	enum{		enum{
	gostr3411(XX)		gostr341094(XX), gostr34102001(XX)
	} HashType;		} SignatureAlgorithm;
	CipherSuite TLS_GOSTR341094_WITH_28147_CNT_IMIT = {0x00,0x80}		This document defines the following new hash algorithm types, whose
	CipherSuite TLS_GOSTR341001_WITH_28147_CNT_IMIT = {0x00,0x81}		values are to be assigned from the TLS HashAlgorithm Registry defined
	CipherSuite TLS_GOSTR341094_WITH_NULL_GOSTR3411 = {0x00,0x82}		in [RFC5246].
	CipherSuite TLS_GOSTR341001_WITH_NULL_GOSTR3411 = {0x00,0x83}
	[IANA please remove] Note: The above numeric definitions for		enum {
	CipherSuites and ClientCertificateType have not yet been registered.		gostr3411(XX)
			} HashAlgorithm;
	7. References		7. References
	7.1. Normative references		7.1. Normative references
	[CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, "Additional		[CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, "Additional
	Cryptographic Algorithms for Use with GOST 28147-89, GOST		Cryptographic Algorithms for Use with GOST 28147-89, GOST
	R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94		R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
	Algorithms", RFC 4357, January 2006.		Algorithms", RFC 4357, January 2006.
	skipping to change at page 15, line 9 ¶		skipping to change at page 16, line 9 ¶
	Anatolij Erkin		Anatolij Erkin
	SPRCIS (SPbRCZI)		SPRCIS (SPbRCZI)
	1, Obrucheva,		1, Obrucheva,
	St.Petersburg, 195220, Russian Federation		St.Petersburg, 195220, Russian Federation
	EMail: erkin@nevsky.net		EMail: erkin@nevsky.net
	Authors' Addresses		Authors' Addresses
	Grigorij S. Chudov (editor)		Grigorij S. Chudov (editor)
	CRYPTO-PRO, Ltd.		CRYPTO-PRO, Ltd.
	38, Obraztsova		16/5, Suschevskij val
	Moscow 127018		Moscow 127018
	Russia		Russia
	Phone: +7 (495) 933 11 68		Phone: +7 (495) 780 48 20
	Fax: +7 (495) 933 11 68		Fax: +7 (495) 660 2330
	Email: chudov@CryptoPro.ru		Email: chudov@CryptoPro.ru
	URI: http://www.CryptoPro.ru		URI: http://www.CryptoPro.ru
	Serguei E. Leontiev (editor)		Serguei E. Leontiev (editor)
	CRYPTO-PRO, Ltd.		CRYPTO-PRO, Ltd.
	38, Obraztsova		16/5, Suschevskij val
	Moscow 127018		Moscow 127018
	Russia		Russia
	Phone: +7 (495) 933 11 68		Phone: +7 (495) 933 11 68
	Fax: +7 (495) 933 11 68		Fax: +7 (495) 933 11 68
	Email: lse@CryptoPro.ru		Email: lse@CryptoPro.ru
	URI: http://www.CryptoPro.ru		URI: http://www.CryptoPro.ru
	Full Copyright Statement
	Copyright (C) The Internet Society (2006).
	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 procedures with respect to rights in RFC 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.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 32 change blocks.
	58 lines changed or deleted		86 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/