RFC4357 Additional Cryptographic Algorithms for Use with GOST 28147-89,GOST R 34
4357 Additional Cryptographic Algorithms for Use with GOST 28147-89,GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms.V. Popov, I. Kurepkin, S. Leontiev. January 2006. (Format: TXT=114564 bytes) (Status: INFORMATIONAL)
日本語訳
RFC一覧
参照
Network Working Group V. Popov
Request for Comments: 4357 I. Kurepkin
Category: Informational S. Leontiev
CRYPTO-PRO
January 2006
Additional Cryptographic Algorithms for Use with GOST 28147-89,
GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the cryptographic algorithms and parameters
supplementary to the original GOST specifications, GOST 28147-89,
GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94, for use in
Internet applications.
Table of Contents
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. Cipher Modes and Parameters .....................................3
2.1. GOST 28147-89 CBC Mode .....................................4
2.2. GOST 28147-89 Padding Modes ................................4
2.3. Key Meshing Algorithms .....................................4
2.3.1. Null Key Meshing ....................................5
2.3.2. CryptoPro Key Meshing ...............................5
3. HMAC_GOSTR3411 ..................................................6
4. PRF_GOSTR3411 ...................................................6
5. Key Derivation Algorithms .......................................6
5.1. VKO GOST R 34.10-94 ........................................6
5.2. VKO GOST R 34.10-2001 ......................................7
6. Key Wrap Algorithms .............................................7
6.1. GOST 28147-89 Key Wrap .....................................7
6.2. GOST 28147-89 Key Unwrap ...................................8
6.3. CryptoPro Key Wrap .........................................8
6.4. CryptoPro Key Unwrap .......................................9
6.5. CryptoPro KEK Diversification Algorithm ....................9
Popov, et al. Informational [Page 1]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
7. Secret Key Diversification .....................................10
8. Algorithm Parameters ...........................................10
8.1. Encryption Algorithm Parameters ...........................10
8.2. Digest Algorithm Parameters ...............................11
8.3. GOST R 34.10-94 Public Key Algorithm Parameters ...........12
8.4. GOST R 34.10-2001 Public Key Algorithm Parameters .........13
9. Security Considerations ........................................14
10. Appendix ASN.1 Modules ........................................15
10.1. Cryptographic-Gost-Useful-Definitions ....................15
10.2. Gost28147-89-EncryptionSyntax ............................17
10.3. Gost28147-89-ParamSetSyntax ..............................19
10.4. GostR3411-94-DigestSyntax ................................21
10.5. GostR3411-94-ParamSetSyntax ..............................22
10.6. GostR3410-94-PKISyntax ...................................23
10.7. GostR3410-94-ParamSetSyntax ..............................25
10.8. GostR3410-2001-PKISyntax .................................27
10.9. GostR3410-2001-ParamSetSyntax ............................29
11. Appendix Parameters ...........................................30
11.1. Encryption Algorithm Parameters ..........................30
11.2. Digest Algorithm Parameters ..............................33
11.3. GOST R 34.10-94 Public Key Algorithm Parameters ..........34
11.4. GOST R 34.10-2001 Public Key Algorithm Parameters ........42
12. Acknowledgements ..............................................46
13. References ....................................................47
13.1. Normative References .....................................47
13.2. Informative References ...................................47
1. Introduction
Russian cryptographic standards that define the algorithms GOST
28147-89 [GOST28147], GOST R 34.10-94 [GOSTR341094], GOST R
34.10-2001 [GOSTR341001], and GOST R34.11-94 [GOSTR341194] provide
basic information about how the algorithms work, but supplemental
specifications are needed to effectively use the algorithms (a brief
English technical description of these algorithms can be found in
[Schneier95]).
This document is a proposal put forward by the CRYPTO-PRO Company to
provide supplemental information and specifications needed by the
"Russian Cryptographic Software Compatibility Agreement" community.
1.1. Terminology
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described
in [RFC2119].
Popov, et al. Informational [Page 2]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
The following functions and operators are also used in this document:
'|' stands for concatenation.
'~' stands for bitwise NOT operator.
'^' stands for the power operator.
encryptECB (K, D) is D, encrypted with key K using GOST 28147-89 in
"prostaya zamena" (ECB) mode.
decryptECB (K, D) is D, decrypted with key K using GOST 28147-89 in
ECB mode.
encryptCFB (IV, K, D) is D, encrypted with key K using GOST 28147-89
in "gammirovanie s obratnoj svyaziyu" (64-bit CFB) mode, and IV is
used as the initialization vector.
encryptCNT (IV, K, D) is D, encrypted with key K using GOST 28147-89
in "gammirovanie" (counter) mode, and IV is used as the
initialization vector.
gostR3411 (D) is the 256-bit result of the GOST R 34.11-94 hash
function, used with zero initialization vector, and S-Box parameter,
defined by id-GostR3411-94-CryptoProParamSet (see Section 11.2).
gost28147IMIT (IV, K, D) is the 32-bit result of the GOST 28147-89 in
"imitovstavka" (MAC) mode, used with D as plaintext, K as key and IV
as initialization vector. Note that the standard specifies its use
in this mode only with an initialization vector of zero.
When keys and initialization vectors are converted to/from byte
arrays, little-endian byte order is assumed.
2. Cipher Modes and Parameters
This document defines four cipher properties that allow an
implementer to vary cipher operations. The four parameters are the
cipher mode, the key meshing algorithm, the padding mode, and the
S-box.
[GOST28147] defines only three cipher modes for GOST 28147-89: ECB,
CFB, and counter mode. This document defines an additional cipher
mode, CBC.
Popov, et al. Informational [Page 3]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
When GOST 28147-89 is used to process large amounts of data, a
symmetric key should be protected by a key meshing algorithm. Key
meshing transforms a symmetric key after some amount of data has been
processed. This document defines the CryptoPro key meshing
algorithm.
The cipher mode, key meshing algorithm, padding mode, and S-box are
specified by algorithm parameters.
2.1. GOST 28147-89 CBC Mode
This section provides the supplemental information for GOST 28147-89
(a block-to-block primitive) needed to operate in CBC mode.
Before each plaintext block is encrypted, it is combined with the
cipher text of the previous block via a bitwise XOR operation. This
ensures that even if the plaintext contains many identical blocks,
each block will encrypt to a different cipher text block. The
initialization vector is combined with the first plaintext block by a
bitwise XOR operation before the block is encrypted.
2.2. GOST 28147-89 Padding Modes
This section provides the supplemental information for GOST 28147-89,
needed to operate on plaintext where the length is not divisible by
GOST 28147-89 block size (8 bytes).
Let x (0 < x <= 8) be the number of bytes in the last, possibly
incomplete, block of data.
There are three padding modes:
* Zero padding: 8-x remaining bytes are filled with zero
* PKCS#5 padding: 8-x remaining bytes are filled with the value of
8-x. If there's no incomplete block, one extra block filled with
value 8 is added.
* Random padding: 8-x remaining bytes of the last block are set to
random.
2.3. Key Meshing Algorithms
Key meshing algorithms transform the key after processing a certain
amount of data. In applications that must be strictly robust to
attacks based on timing and EMI analysis, one symmetric key should
not be used for quantities of plaintext larger than 1024 octets.
Popov, et al. Informational [Page 4]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
A key meshing algorithm affects internal cipher state; it is not a
protocol level feature. Its role is similar to that of a cipher
mode. The choice of key meshing algorithm is usually dictated by the
encryption algorithm parameters, but some protocols explicitly
specify applicable key meshing algorithms.
All encryption parameter sets defined in this document specify the
use of the CryptoPro key meshing algorithm, except for id-Gost28147-
89-TestParamSet, which specifies use of null key meshing algorithm.
2.3.1. Null Key Meshing
The null key meshing algorithm never changes a key.
The identifier for this algorithm is:
id-Gost28147-89-None-KeyMeshing OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
keyMeshing(14) none(0) }
There are no meaningful parameters to this algorithm. If present,
AlgorithmIdentifier.parameters MUST contain NULL.
2.3.2. CryptoPro Key Meshing
The CryptoPro key meshing algorithm transforms the key and
initialization vector every 1024 octets (8192 bits, or 256 64-bit
blocks) of plaintext data.
This algorithm has the same drawback as OFB cipher mode: it is
impossible to re-establish crypto synch while decrypting a ciphertext
if parts of encrypted data are corrupted, lost, or processed out of
order. Furthermore, it is impossible to re-synch even if an IV for
each data packet is provided explicitly. Use of this algorithm in
protocols such as IPsec ESP requires special care.
The identifier for this algorithm is:
id-Gost28147-89-CryptoPro-KeyMeshing OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
keyMeshing(14) cryptoPro(1) }
There are no meaningful parameters to this algorithm. If present,
AlgorithmIdentifier.parameters MUST contain NULL.
GOST 28147-89, in encrypt, decrypt, or MAC mode, starts with key K[0]
= K, IV0[0] = IV, i = 0. Let IVn[0] be the value of the
initialization vector after processing the first 1024 octets of data.
Popov, et al. Informational [Page 5]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
Processing of the next 1024 octets will start with K[1] and IV0[1],
which are calculated using the following formula:
K[i+1] = decryptECB (K[i], C);
IV0[i+1] = encryptECB (K[i+1],IVn[i])
Where C = {0x69, 0x00, 0x72, 0x22, 0x64, 0xC9, 0x04, 0x23,
0x8D, 0x3A, 0xDB, 0x96, 0x46, 0xE9, 0x2A, 0xC4,
0x18, 0xFE, 0xAC, 0x94, 0x00, 0xED, 0x07, 0x12,
0xC0, 0x86, 0xDC, 0xC2, 0xEF, 0x4C, 0xA9, 0x2B};
After processing each 1024 octets of data:
* the resulting initialization vector is stored as IVn[i];
* K[i+1] and IV0[i+1] are calculated;
* i is incremented;
* Encryption or decryption of next 1024 bytes starts, using
the new key and IV;
The process is repeated until all the data has been processed.
3. HMAC_GOSTR3411
HMAC_GOSTR3411 (K,text) function is based on the hash function GOST R
34.11-94, as defined in [HMAC], with the following parameter values:
B = 32, L = 32.
4. PRF_GOSTR3411
PRF_GOSTR3411 is a pseudorandom function, based on HMAC_GOSTR3411.
It is calculated as P_hash, defined in Section 5 of [TLS].
PRF_GOSTR3411(secret,label,seed) = P_GOSTR3411 (secret,label|seed).
5. Key Derivation Algorithms
Standards [GOSTR341094] and [GOSTR341001] do not define any key
derivation algorithms.
Section 5.1 specifies algorithm VKO GOST R 34.10-94, which generates
GOST KEK using two GOST R 34.10-94 keypairs.
Section 5.2 specifies algorithm VKO GOST R 34.10-2001, which
generates GOST KEK using two GOST R 34.10-2001 keypairs and UKM.
Keypairs MUST have identical parameters.
5.1. VKO GOST R 34.10-94
This algorithm creates a key encryption key (KEK) using the sender's
private key and the recipient's public key (or vice versa).
Popov, et al. Informational [Page 6]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
Exchange key KEK is a 256-bit hash of the 1024-bit shared secret that
is generated using Diffie-Hellman key agreement.
1) Let K(x,y) = a^(x*y) (mod p), where
x - sender's private key, a^x - sender's public key
y - recipient's private key, a^y - recipient's public key
a, p - parameters
2) Calculate a 256-bit hash of K(x,y):
KEK(x,y) = gostR3411 (K(x,y))
Keypairs (x,a^x) and (y,a^y) MUST comply with [GOSTR341094].
This algorithm MUST NOT be used when a^x = a (mod p) or a^y = a (mod
p).
5.2. VKO GOST R 34.10-2001
This algorithm creates a key encryption key (KEK) using 64 bit UKM,
the sender's private key, and the recipient's public key (or the
reverse of the latter pair).
1) Let K(x,y,UKM) = ((UKM*x)(mod q)) . (y.P) (512 bit), where
x - sender's private key (256 bit)
x.P - sender's public key (512 bit)
y - recipient's private key (256 bit)
y.P - recipient's public key (512 bit)
UKM - non-zero integer, produced as in step 2 p. 6.1 [GOSTR341001]
P - base point on the elliptic curve (two 256-bit coordinates)
UKM*x - x multiplied by UKM as integers
x.P - a multiple point
2) Calculate a 256-bit hash of K(x,y,UKM):
KEK(x,y,UKM) = gostR3411 (K(x,y,UKM))
Keypairs (x,x.P) and (y,y.P) MUST comply with [GOSTR341001].
This algorithm MUST NOT be used when x.P = P, y.P = P
6. Key Wrap Algorithms
This document defines two key wrap algorithms: GOST 28147-89 Key Wrap
and CryptoPro Key Wrap. These are used to encrypt a Content
Encryption Key (CEK) with a Key Encryption Key (KEK).
6.1. GOST 28147-89 Key Wrap
This algorithm encrypts GOST 28147-89 CEK with a GOST 28147-89 KEK.
Popov, et al. Informational [Page 7]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
Note: This algorithm MUST NOT be used with a KEK produced by VKO GOST
R 34.10-94, because such a KEK is constant for every sender-recipient
pair. Encrypting many different content encryption keys on the same
constant KEK may reveal that KEK.
The GOST 28147-89 key wrap algorithm is:
1) For a unique symmetric KEK, generate 8 octets at random and call
the result UKM. For a KEK, produced by VKO GOST R 34.10-2001,
use the UKM that was used for key derivation.
2) Compute a 4-byte checksum value, gost28147IMIT (UKM, KEK, CEK).
Call the result CEK_MAC.
3) Encrypt the CEK in ECB mode using the KEK. Call the ciphertext
CEK_ENC.
4) The wrapped content-encryption key is (UKM | CEK_ENC | CEK_MAC).
6.2. GOST 28147-89 Key Unwrap
This algorithm decrypts GOST 28147-89 CEK with a GOST 28147-89 KEK.
The GOST 28147-89 key unwrap algorithm is:
1) If the wrapped content-encryption key is not 44 octets, then
error.
2) Decompose the wrapped content-encryption key into UKM, CEK_ENC,
and CEK_MAC. UKM is the most significant (first) 8 octets.
CEK_ENC is next 32 octets, and CEK_MAC is the least significant
(last) 4 octets.
3) Decrypt CEK_ENC in ECB mode using the KEK. Call the output CEK.
4) Compute a 4-byte checksum value, gost28147IMIT (UKM, KEK, CEK),
compare the result with CEK_MAC. If they are not equal, then
error.
6.3. CryptoPro Key Wrap
This algorithm encrypts GOST 28147-89 CEK with a GOST 28147-89 KEK.
It can be used with any KEK (e.g., produced by VKO GOST R 34.10-94 or
VKO GOST R 34.10-2001) because a unique UKM is used to diversify the
KEK.
The CryptoPro key wrap algorithm is:
1) For a unique symmetric KEK or a KEK produced by VKO GOST R
34.10-94, generate 8 octets at random. Call the result UKM. For
a KEK, produced by VKO GOST R 34.10-2001, use the UKM that was
used for key derivation.
2) Diversify KEK, using the CryptoPro KEK Diversification Algorithm,
described in Section 6.5. Call the result KEK(UKM).
Popov, et al. Informational [Page 8]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
3) Compute a 4-byte checksum value, gost28147IMIT (UKM, KEK(UKM),
CEK). Call the result CEK_MAC.
4) Encrypt CEK in ECB mode using KEK(UKM). Call the ciphertext
CEK_ENC.
5) The wrapped content-encryption key is (UKM | CEK_ENC | CEK_MAC).
6.4. CryptoPro Key Unwrap
This algorithm encrypts GOST 28147-89 CEK with a GOST 28147-89 KEK.
The CryptoPro key unwrap algorithm is:
1) If the wrapped content-encryption key is not 44 octets, then it
is an error.
2) Decompose the wrapped content-encryption key into UKM, CEK_ENC,
and CEK_MAC. UKM is the most significant (first) 8 octets.
CEK_ENC is next 32 octets, and CEK_MAC is the least significant
(last) 4 octets.
3) Diversify KEK using the CryptoPro KEK Diversification Algorithm,
described in section 6.5. Call the result KEK(UKM).
4) Decrypt CEK_ENC in ECB mode using KEK(UKM). Call the output CEK.
5) Compute a 4-byte checksum value, gost28147IMIT (UKM, KEK(UKM),
CEK), compare the result with CEK_MAC. If they are not equal,
then it is an error.
6.5. CryptoPro KEK Diversification Algorithm
Given a random 64-bit UKM and a GOST 28147-89 key K, this algorithm
creates a new GOST 28147-89 key K(UKM).
1) Let K[0] = K;
2) UKM is split into components a[i,j]:
UKM = a[0]|..|a[7] (a[i] - byte, a[i,0]..a[i,7] - it's bits)
3) Let i be 0.
4) K[1]..K[8] are calculated by repeating the following algorithm
eight times:
A) K[i] is split into components k[i,j]:
K[i] = k[i,0]|k[i,1]|..|k[i,7] (k[i,j] - 32-bit integer)
B) Vector S[i] is calculated:
S[i] = ((a[i,0]*k[i,0] + ... + a[i,7]*k[i,7]) mod 2^32) |
(((~a[i,0])*k[i,0] + ... + (~a[i,7])*k[i,7]) mod 2^32);
C) K[i+1] = encryptCFB (S[i], K[i], K[i])
D) i = i + 1
5) Let K(UKM) be K[8].
Popov, et al. Informational [Page 9]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
7. Secret Key Diversification
This algorithm creates a GOST 28147-89 key Kd, given GOST R 34.10-94
or GOST R 34.10-2001 secret key K and diversification data D of size
4..40 bytes.
1) 40-byte blob B is created from D by cloning it enough times to
fill all 40 bytes. For example, if D is 40-bytes long, B = D; If
D is 6-bytes long, B = D|D|D|D|D|D|D[0..3].
2) B is split into 8-byte UKM and 32-byte SRCKEY (B = UKM|SRCKEY).
3) The algorithm from Section 6.5 is used to create K(UKM) from key
K and UKM, with two differences:
* Instead of S[i], vector (0,0,0,UKM[i],ff,ff,ff,ff XOR UKM[i])
is used.
* During each encryption step, only 8 out of 32 GOST 28147-89
rounds are done.
4) Kd is calculated:
Kd = encryptCFB (UKM, K(UKM), SRCKEY).
8. Algorithm Parameters
Standards [GOST28147], [GOST341194], [GOSTR341094], and [GOSTR341001]
do not define specific values for algorithm parameters.
This document introduces the use of ASN.1 object identifiers (OIDs)
to specify algorithm parameters.
Identifiers for all of the proposed parameter sets can be found in
Appendix ASN.1 modules. Corresponding parameter values for proposed
parameter sets can be found in Section 11.
8.1. Encryption Algorithm Parameters
GOST 28147-89 can be used in several modes; additional CBC mode is
defined in Section 2.1. It also has an S-Box parameter. (See the
Algorithm Parameters part in [GOST28147] in Russian; for a
description in English, see [Schneier95], ch. 14.1, p. 331.)
This table contains the list of proposed parameter sets for GOST
28147-89:
Gost28147-89-ParamSetAlgorithms ALGORITHM-IDENTIFIER ::= {
{ Gost28147-89-ParamSetParameters IDENTIFIED BY
id-Gost28147-89-TestParamSet } |
{ Gost28147-89-ParamSetParameters IDENTIFIED BY
id-Gost28147-89-CryptoPro-A-ParamSet } |
{ Gost28147-89-ParamSetParameters IDENTIFIED BY
id-Gost28147-89-CryptoPro-B-ParamSet } |
Popov, et al. Informational [Page 10]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
{ Gost28147-89-ParamSetParameters IDENTIFIED BY
id-Gost28147-89-CryptoPro-C-ParamSet } |
{ Gost28147-89-ParamSetParameters IDENTIFIED BY
id-Gost28147-89-CryptoPro-D-ParamSet }
}
Identifier values are in the Appendix ASN.1 modules, and
corresponding parameters are in Section 11.1.
Parameters for GOST 28147-89 are presented in the following form:
Gost28147-89-ParamSetParameters ::= SEQUENCE {
eUZ Gost28147-89-UZ,
mode INTEGER {
gost28147-89-CNT(0),
gost28147-89-CFB(1),
cryptoPro-CBC(2)
},
shiftBits INTEGER { gost28147-89-block(64) },
keyMeshing AlgorithmIdentifier
}
Gost28147-89-UZ ::= OCTET STRING (SIZE (64))
Gost28147-89-KeyMeshingAlgorithms ALGORITHM-IDENTIFIER ::= {
{ NULL IDENTIFIED BY id-Gost28147-89-CryptoPro-KeyMeshing } |
{ NULL IDENTIFIED BY id-Gost28147-89-None-KeyMeshing }
}
where
eUZ - S-box value;
mode - cipher mode;
shiftBits - cipher parameter;
keyMeshing - key meshing algorithm identifier.
8.2. Digest Algorithm Parameters
This table contains the list of proposed parameter sets for
[GOST341194]:
GostR3411-94-ParamSetAlgorithms ALGORITHM-IDENTIFIER ::= {
{ GostR3411-94-ParamSetParameters IDENTIFIED BY
id-GostR3411-94-TestParamSet
} |
{ GostR3411-94-ParamSetParameters IDENTIFIED BY
id-GostR3411-94-CryptoProParamSet
}
}
Popov, et al. Informational [Page 11]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
Identifier values are in the Appendix ASN.1 modules, and
corresponding parameters are in Section 11.2.
Parameters for [GOST341194] are presented in the following form:
GostR3411-94-ParamSetParameters ::=
SEQUENCE {
hUZ Gost28147-89-UZ, -- S-Box for digest
h0 GostR3411-94-Digest -- start digest value
}
GostR3411-94-Digest ::= OCTET STRING (SIZE (32))
8.3. GOST R 34.10-94 Public Key Algorithm Parameters
This table contains the list of proposed parameter sets for GOST R
34.10-94:
GostR3410-94-ParamSetAlgorithm ALGORITHM-IDENTIFIER ::= {
{ GostR3410-94-ParamSetParameters IDENTIFIED BY
id-GostR3410-94-TestParamSet } |
{ GostR3410-94-ParamSetParameters IDENTIFIED BY
id-GostR3410-94-CryptoPro-A-ParamSet } |
{ GostR3410-94-ParamSetParameters IDENTIFIED BY
id-GostR3410-94-CryptoPro-B-ParamSet } |
{ GostR3410-94-ParamSetParameters IDENTIFIED BY
id-GostR3410-94-CryptoPro-C-ParamSet } |
{ GostR3410-94-ParamSetParameters IDENTIFIED BY
id-GostR3410-94-CryptoPro-D-ParamSet } |
{ GostR3410-94-ParamSetParameters IDENTIFIED BY
id-GostR3410-94-CryptoPro-XchA-ParamSet } |
{ GostR3410-94-ParamSetParameters IDENTIFIED BY
id-GostR3410-94-CryptoPro-XchB-ParamSet } |
{ GostR3410-94-ParamSetParameters IDENTIFIED BY
id-GostR3410-94-CryptoPro-XchC-ParamSet }
}
Identifier values are in the Appendix ASN.1 modules, and
corresponding parameters are in Section 11.3.
Parameters for GOST R 34.10-94 are presented in the following form:
GostR3410-94-ParamSetParameters ::=
SEQUENCE {
t INTEGER,
p INTEGER,
q INTEGER,
a INTEGER,
validationAlgorithm AlgorithmIdentifier {{
Popov, et al. Informational [Page 12]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
GostR3410-94-ValidationAlgorithms
}} OPTIONAL
}
GostR3410-94-ValidationParameters ::=
SEQUENCE {
x0 INTEGER,
c INTEGER,
d INTEGER OPTIONAL
}
Where
t - bit length of p (512 or 1024 bits);
p - modulus, prime number, 2^(t-1)RFC4134], can be extracted using the same program.
If you want to extract without the program, copy all the lines
between the "|>" and "|<" markers, remove any page breaks, and remove
the "|" in the first column of each line. The result is a valid
Base64 blob that can be processed by any Base64 decoder.
11.1. Encryption Algorithm Parameters
For each AlgorithmIdentifier in this sequence, the parameters field
contains Gost28147-89-ParamSetParameters.
0 30 480: SEQUENCE {
4 30 94: SEQUENCE {
6 06 7: OBJECT IDENTIFIER
: id-Gost28147-89-TestParamSet
15 30 83: SEQUENCE {
17 04 64: OCTET STRING
: 4C DE 38 9C 29 89 EF B6 FF EB 56 C5 5E C2 9B 02
: 98 75 61 3B 11 3F 89 60 03 97 0C 79 8A A1 D5 5D
: E2 10 AD 43 37 5D B3 8E B4 2C 77 E7 CD 46 CA FA
: D6 6A 20 1F 70 F4 1E A4 AB 03 F2 21 65 B8 44 D8
Popov, et al. Informational [Page 30]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
83 02 1: INTEGER 0
86 02 1: INTEGER 64
89 30 9: SEQUENCE {
91 06 7: OBJECT IDENTIFIER
: id-Gost28147-89-None-KeyMeshing
: }
: }
: }
100 30 94: SEQUENCE {
102 06 7: OBJECT IDENTIFIER
: id-Gost28147-89-CryptoPro-A-ParamSet
111 30 83: SEQUENCE {
113 04 64: OCTET STRING
-- K1 K2 K3 K4 K5 K6 K7 K8
-- 9 3 E E B 3 1 B
-- 6 7 4 7 5 A D A
-- 3 E 6 A 1 D 2 F
-- 2 9 2 C 9 C 9 5
-- 8 8 B D 8 1 7 0
-- B A 3 1 D 2 A C
-- 1 F D 3 F 0 6 E
-- 7 0 8 9 0 B 0 8
-- A 5 C 0 E 7 8 6
-- 4 2 F 2 4 5 C 2
-- E 6 5 B 2 9 4 3
-- F C A 4 3 4 5 9
-- C B 0 F C 8 F 1
-- 0 4 7 8 7 F 3 7
-- D D 1 5 A E B D
-- 5 1 9 6 6 6 E 4
: 93 EE B3 1B 67 47 5A DA 3E 6A 1D 2F 29 2C 9C 95
: 88 BD 81 70 BA 31 D2 AC 1F D3 F0 6E 70 89 0B 08
: A5 C0 E7 86 42 F2 45 C2 E6 5B 29 43 FC A4 34 59
: CB 0F C8 F1 04 78 7F 37 DD 15 AE BD 51 96 66 E4
179 02 1: INTEGER 1
182 02 1: INTEGER 64
185 30 9: SEQUENCE {
187 06 7: OBJECT IDENTIFIER
: id-Gost28147-89-CryptoPro-KeyMeshing
: }
: }
: }
196 30 94: SEQUENCE {
198 06 7: OBJECT IDENTIFIER
: id-Gost28147-89-CryptoPro-B-ParamSet
207 30 83: SEQUENCE {
Popov, et al. Informational [Page 31]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
209 04 64: OCTET STRING
: 80 E7 28 50 41 C5 73 24 B2 00 C2 AB 1A AD F6 BE
: 34 9B 94 98 5D 26 5D 13 05 D1 AE C7 9C B2 BB 31
: 29 73 1C 7A E7 5A 41 42 A3 8C 07 D9 CF FF DF 06
: DB 34 6A 6F 68 6E 80 FD 76 19 E9 85 FE 48 35 EC
275 02 1: INTEGER 1
278 02 1: INTEGER 64
281 30 9: SEQUENCE {
283 06 7: OBJECT IDENTIFIER
: id-Gost28147-89-CryptoPro-KeyMeshing
: }
: }
: }
292 30 94: SEQUENCE {
294 06 7: OBJECT IDENTIFIER
: id-Gost28147-89-CryptoPro-C-ParamSet
303 30 83: SEQUENCE {
305 04 64: OCTET STRING
: 10 83 8C A7 B1 26 D9 94 C7 50 BB 60 2D 01 01 85
: 9B 45 48 DA D4 9D 5E E2 05 FA 12 2F F2 A8 24 0E
: 48 3B 97 FC 5E 72 33 36 8F C9 C6 51 EC D7 E5 BB
: A9 6E 6A 4D 7A EF F0 19 66 1C AF C3 33 B4 7D 78
371 02 1: INTEGER 1
374 02 1: INTEGER 64
377 30 9: SEQUENCE {
379 06 7: OBJECT IDENTIFIER
: id-Gost28147-89-CryptoPro-KeyMeshing
: }
: }
: }
388 30 94: SEQUENCE {
390 06 7: OBJECT IDENTIFIER
: id-Gost28147-89-CryptoPro-D-ParamSet
399 30 83: SEQUENCE {
401 04 64: OCTET STRING
: FB 11 08 31 C6 C5 C0 0A 23 BE 8F 66 A4 0C 93 F8
: 6C FA D2 1F 4F E7 25 EB 5E 60 AE 90 02 5D BB 24
: 77 A6 71 DC 9D D2 3A 83 E8 4B 64 C5 D0 84 57 49
: 15 99 4C B7 BA 33 E9 AD 89 7F FD 52 31 28 16 7E
467 02 1: INTEGER 1
470 02 1: INTEGER 64
473 30 9: SEQUENCE {
475 06 7: OBJECT IDENTIFIER
: id-Gost28147-89-CryptoPro-KeyMeshing
: }
: }
: }
: }
Popov, et al. Informational [Page 32]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
|>Gost28147-89-ParamSetParameters.bin
|MIIB4DBeBgcqhQMCAh8AMFMEQEzeOJwpie+2/+tWxV7CmwKYdWE7ET+JYAOXDHmK
|odVd4hCtQzdds460LHfnzUbK+tZqIB9w9B6kqwPyIWW4RNgCAQACAUAwCQYHKoUD
|AgIOADBeBgcqhQMCAh8BMFMEQJPusxtnR1raPmodLyksnJWIvYFwujHSrB/T8G5w
|iQsIpcDnhkLyRcLmWylD/KQ0WcsPyPEEeH833RWuvVGWZuQCAQECAUAwCQYHKoUD
|AgIOATBeBgcqhQMCAh8CMFMEQIDnKFBBxXMksgDCqxqt9r40m5SYXSZdEwXRrsec
|srsxKXMceudaQUKjjAfZz//fBts0am9oboD9dhnphf5INewCAQECAUAwCQYHKoUD
|AgIOATBeBgcqhQMCAh8DMFMEQBCDjKexJtmUx1C7YC0BAYWbRUja1J1e4gX6Ei/y
|qCQOSDuX/F5yMzaPycZR7Nflu6luak167/AZZhyvwzO0fXgCAQECAUAwCQYHKoUD
|AgIOATBeBgcqhQMCAh8EMFMEQPsRCDHGxcAKI76PZqQMk/hs+tIfT+cl615grpAC
|Xbskd6Zx3J3SOoPoS2TF0IRXSRWZTLe6M+mtiX/9UjEoFn4CAQECAUAwCQYHKoUD
|AgIOAQ==
|GostR3411-94-ParamSetParameters.bin
|MIHiMG8GByqFAwICHgAwZARATldk0auNy7+UGnpNLNEQENagVzWNOPL3D0nRWuov
|jZRi7kMJs/SmohjGmOPBfOV+cGsJZvcCPItVlb8oObMuzAQgAAAAAAAAAAAAAAAA
|AAAAAAAAAAAAAAAAAAAAAAAAAAAwbwYHKoUDAgIeATBkBECldHfRT/pm41THQkpg
|7LQZgpCddR1PyQs7Ei9UeQigr9E+GjjHsYHG5lYFhwMl6/6cbfhtLqveILqJPJL4
|01O8BCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
|GostR3410-94-ParamSetParameters.bin
|MIILQjCB0QYHKoUDAgIgADCBxQICAgACQQDugXKuiZZgj7aTWbieuCpphUUQ4pd6
|TWO8lzIs5dwzhuoKErND6RkPIxd1OYRYOXhrsMNF0WWXbvIZXsmxw3njAiEAmJFe
|fsgmXt/Nox6I8kgJ3bBkvccoXdUNconwrG9J3S0CQQCelgMVAMh3SoaVgtSv3iEn
|r60lOLS2JwpvfIg3tQ1Q8gZ1WYSknlCTBNZIviq1qrGOvizUasPYSVsUKqbOI+Ic
|MBYGByqFAwICFAEwCwICXskCAnNBAgECMIIBVgYHKoUDAgIgAjCCAUkCAgQAAoGB
|ALTiXvsBjjyLh1BeKmdVPF7cVsKRS35PidI/A/Azd+cKKQNIndYOeEGNPYUe21MX
|xIceQLBCKMO3kCljxLfYXVK5qojyr9vrKNqIadbfhGodmJJOklVhvWkwC53dBdJH
|tZItlny7AmcYgcV9EOXvctPm2tQiPcgqoffQKUZRpIDfAiEAlyQypDcXizC9lhlb
|dzeJqy//FVlLF23RdbYyVu5a8s8CgYEAj9NnMSN2VLvkH18fhFPnHKQU/8IsJdkV
|MJ5dLmKiomxxEfP8eVaNr6AoBC/hpSoEiYBcDemhpGnIRMfKu+5iXDB4iIwdhe6o
|g/GtW8Tmd26OGgdQkS32T3mVZJnx4YJHWwtg4mMq3NjPlOnFT9HzsQnYHwC/KrjL
|hirffUC5NpowGAYHKoUDAgIUBDANAgRSCHT1AgUA7jmtszCCAasGByqFAwICIAMw
|ggGeAgIEAAKBgQDGlx/FdSSzDJAYxeYh3hVJlzaFT1am+K7mWnpARjKxvPA0n/yv
|ywoQMXeXH8FhKtzbjIzJOMcCJcj9Eq/wGx0GTgrW/earkVkWbLny/BcdkvDMe2pr
|LNf6NCrL4skxWkLVdrHsznepYxV/PQvZao6wsPNQKtI4EBsFEWM08eW3qwIhALCd
|Y0wQiZzX1MOnZXQD4FgQsHxhpoi6ssN/R14wiwYHAoGAPSa0Z9lKP/ydcb+NuJNA
|hBNyZPPC6esW3KIUuLx8hySFM2dEk0/S71lD+e0LdFuQqj7I1wzckWgkeLZkouH4
|+1bO8pcv7n7bCEr3RkGbhU+tAsw+Nkb/LhoY3UvrPET38nRViAKWSWdFRsyRh8IH
|+48s7OjiKT9oOVxHBK8EurUwbgYHKoUDAgIUBDBjAgRbl3zbAgRulpLdAlUAvDy7
|235vhIKG4ZrZonqOKX5bccU92XTN9g+Tc1bfacvJejAMzHFoXFUwRhR/EVaMT93z
|Y9nYhkODRaYsO3WWPWVGrfq/MbMSkNEsrmXsuDCe9meCMIIBXwYHKoUDAgIgBDCC
|AVICAgQAAoGBAJ2I5tf+MxO9LnRcfN0que5K88iJnoR950ozeD6mi8MFiLofc4xq
|r4qzUFMfGFTDg3zDyGD/1+LhBsP2Oz2KTANM5zlCpsPVhbWZz2le16PEqTsrlHtx
|V7saHAQ6tB7IVmxhRek4phGQbeDTLlYklFadfpmaDdpch5vdkf4STfHpAiEA+t0Z
Popov, et al. Informational [Page 41]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
|er0ZobRlPuz37KTWoisff4k7ZB+QFkH7tVU1T68CgYB0R+1xVjEFmQcLEmCZR6XI
|yKhiXPHPJStAezMfk9Y53dG6OSZW3sqZLdA1NUMpoelabjLW9HiC2WC48QrK/3lt
|E82WEfhT2rbSYjSD5GeIcISTk3oaKUQlmK7C4HQgIlY0QP6cGHQOzmdlrAX68CSm
|SwJufkCIQIGeli5+X0Aa4zAiBgcqhQMCAhQEMBcCBEOEh0QCBQC1CoJtAgh/V16B
|lLxb3zCCAXMGByqFAwICIAUwggFmAgIEAAKBgQCA8QLTKw/RZ9BpwnowetrSxGYJ
|GQTbqlXVuMxwJvL3oZGbiQy2UsQOBU4ekwZzW0PXsnnt35ECABzZ4agx/ooWPu2J
|qwfPKr6CQqyd7d2/mNYs3dHqT18V06QqZne90pOyQmDA8nwPHRWUhhTVZ7ZvqQK6
|oRpprjvOrbuD45nJtQIhAPD1RMQYqsI09oPwM1EbZcIWUaYHi9otabufcyhnUCFJ
|AoGAa8wLT62ziJweBq3SPMCbirbs3t9z8EYyWV7kJQAF1q9fWt5Eyx4m5iY8ZyNH
|z6JvnpOTaB5rdZczeEzeXb2aFKOTad/Zn6hcwNECQcQBA0PzSpE5OnBs8SZ3y/of
|V41rbPvooSQs/MlLO2U6R24UXjhiwYzD/tglfP73TNsgW/EwNgYHKoUDAgIUBDAr
|AgQT2oudAgUAoOneSwIcQauXhX9CYUNV0y2wsQafEJpNooNnbHxTpoGFtDCCAYwG
|ByqFAwICIQEwggF/AgIEAAKBgQDKOz8u7p/UYxfUlZWp51GObGPY9OtNItENKK8L
|iDnwefgonmA7A1MHhLm7Wh52hZ5IUMZwx7ccDfhMo+DWwXf+n3ip2EMyMKiDzYKi
|srXHozBpgCeFcM23m/AQdKacliM0iCSwxTeR1TxqeMq2nhz7KDaGEaOX9Q9UHhbb
|NI2+XwIhAMrk2F+AwUdwSwykjoX7AKkFeqSsxEZo4X8ZltcVJpDZAoGBAL4n1lLy
|8eM52nNCEbhbBq5N4jaqj77rPxrcxSzUOFN3foNKalGBOGeKitvTpVxwp+qxunoH
|GVSGd6r05gn/tH9rnX5FsNBtg9etxTMQq9hXg+cxf37HMmi2qcCNJguF2EhWlso5
|wXsX8ETR4FBIkDar04HF5r+CujUqGv8TZgGvME4GByqFAwICFAQwQwIFANBenxQC
|BEYwTF8CNDWrh1OZzaM8FGymKWYOWl5cB3FMoybbAy3WdRmVzbkKYSuSKJMtgwJw
|TsJKXe93OcWBPYMwggF3BgcqhQMCAiECMIIBagICBAACgYEAkobb2pHsz8MGCqVZ
|gxjipjn1upCkymVhV7JnP7GRzQWJ7gX0zvG9E1CECCcUWMMIUc56TvU0dCv7EfR0
|PI94exEZO6MEwOa8olcBv4ivHLm4/UcR2J+I4ys32VMWVBvx5du0mJs98TZZuIwP
|l6PBCHufLVMX1Vfc1K/G0KdU4nkCIQDJZumzuLfN2C/w+Dr4cDbDj0IjjsUKh2zT
|kOQ9Z7YBPwKBgH6cMJZnb1HjsvmITPCsIVZ3lJb0EOBJztflPYt7WzZrGmAI5Rlm
|BaVeicMZDav4C58RY8l5/NGDKNrl6QSIEbNwEHu3cV+CCRu53g4z7i/tYlVHT4dp
|/OXq+u7xy1oy4NXGwvD8CzRHBylH9bTDh2Zpk6Mz/AZWjlNK1W0jONcpMDoGByqF
|AwICFAQwLwIEegB4BAIFANMaT/cCIH7BI9FhR3dig4wr6p298zB0r21B0QigZqHn
|oHqzBI3iMIIBfAYHKoUDAgIhAzCCAW8CAgQAAoGBALGUA2rOFBOdNtZCla5sUPxL
|fWXYs0BxE2bKk/ODZTkI7mN75CgFHYZhJnCte0AsCbgg+nfZ2inIERqEltpsJhpT
|7SUuTYppogN25q3bO9zTMXSaSRoYS4/abYTDHPBfkRm17TUkbqRWLYWSi6ETao0O
|Wn5cdkuokCApoTNsYxodAiEAlhIEd98POJZijm9KiNg8kyBMIQ/yYrzLfa5FA1US
|UlkCgYA/GBcFK6p1mP4+T0/FxfYW4SLP+evYnvgdx86L9WzGS0NYbIDxxPVt1XGP
|3XYwC+M2eEJZyiWq3lpIP2TAKiDPShD5wYnEM97+MdJj5sl2RmCnMezK7LdMgnkw
|NzHoz2kgW8c+WnC9+T5btoHatO65xzPKqy9nPEdeDsqSHSl4LjA/BgcqhQMCAhQE
|MDQCBBYquRACBQCT+CjTAiUAyoLM54pzi8RvED1Tub+Al0XshF5PbaRiYGxR9g7P
|MC4xIEuB
|GostR3410-2001-ParamSetParameters.bin
|MIID5jCBnAYHKoUDAgIjADCBkAIBBwIgX7/0mKqTjOc5uOAi+6/vQFY/bmo0cvwq
|UUwM6driO34CIQCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMQIhAIAA
|AAAAAAAAAAAAAAAAAAFQ/ooYkpdhVMWc/Bk6zPWzAgECAiAI4qig5lFH1L1jFgMO
Popov, et al. Informational [Page 45]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
|FtGchcl/CpyiZxIrlqu86n6PyDCBnwYHKoUDAgIjATCBkwIhAP//////////////
|//////////////////////////2UAgIApgIhAP//////////////////////////
|//////////////2XAiEA/////////////////////2xhEHCZWtEARYQbCbdhuJMC
|AQECIQCNkeRx4Jic2iffUFpFPyt2NSlPLd8j47EirMmcnp8eFDCBvAYHKoUDAgIj
|AjCBsAIhAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyWAiA+GvQZomml
|+Gan08JcPfgK6Xklk3P/KxgvSdTOfhu8iwIhAIAAAAAAAAAAAAAAAAAAAAAAAAAA
|AAAAAAAAAAAAAAyZAiEAgAAAAAAAAAAAAAAAAAAAAV9wDP/xpiTl5JcWG8yKGY8C
|AQECID+oEkNZ+WaAuD0cPrLAcOXFRcmFjQPs+3RL+NcXcX78MIGfBgcqhQMCAiMD
|MIGTAiEAm59gX1qFgQerHshea0HIqs+EboZ4kFHTeZj3uQItdZgCAwCAWgIhAJuf
|YF9ahYEHqx7IXmtByKrPhG6GeJBR03mY97kCLXWbAiEAm59gX1qFgQerHshea0HI
|qlgso1Ee3ft08C86ZZiYC7kCAQACIEHs5VdDcRqMPL83g80IwO5NTcRA1GQajzZu
|VQ39s7tnMIGfBgcqhQMCAiQAMIGTAiEA////////////////////////////////
|/////////ZQCAgCmAiEA/////////////////////////////////////////ZcC
|IQD/////////////////////bGEQcJla0QBFhBsJt2G4kwIBAQIhAI2R5HHgmJza
|J99QWkU/K3Y1KU8t3yPjsSKsyZyenx4UMIGfBgcqhQMCAiQBMIGTAiEAm59gX1qF
|gQerHshea0HIqs+EboZ4kFHTeZj3uQItdZgCAwCAWgIhAJufYF9ahYEHqx7IXmtB
|yKrPhG6GeJBR03mY97kCLXWbAiEAm59gX1qFgQerHshea0HIqlgso1Ee3ft08C86
|ZZiYC7kCAQACIEHs5VdDcRqMPL83g80IwO5NTcRA1GQajzZuVQ39s7tn
|RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
13.2. Informative References
[Schneier95] B. Schneier, Applied cryptography, second edition, John
Wiley & Sons, Inc., 1995.
[RFDSL] "Russian Federal Digital Signature Law", 10 Jan 2002 N
1-FZ
[RFLLIC] "Russian Federal Law on Licensing of Selected Activity
Categories", 08 Aug 2001 N 128-FZ
Popov, et al. Informational [Page 47]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
[CRYPTOLIC] "Russian Federal Government Regulation on Licensing of
Selected Activity Categories in Cryptography Area", 23
Sep 2002 N 691
[X.660] ITU-T Recommendation X.660 Information Technology -
ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER), 1997.
[RFC4134] Hoffman, P., "Examples of S/MIME Messages", RFC 4134,
July 2005.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
Authors' Addresses
Vladimir Popov
CRYPTO-PRO
38, Obraztsova,
Moscow, 127018, Russian Federation
EMail: vpopov@cryptopro.ru
Igor Kurepkin
CRYPTO-PRO
38, Obraztsova,
Moscow, 127018, Russian Federation
EMail: kure@cryptopro.ru
Serguei Leontiev
CRYPTO-PRO
38, Obraztsova,
Moscow, 127018, Russian Federation
EMail: lse@cryptopro.ru
Grigorij Chudov
CRYPTO-PRO
38, Obraztsova,
Moscow, 127018, Russian Federation
EMail: chudov@cryptopro.ru
Popov, et al. Informational [Page 48]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
Alexandr Afanasiev
Factor-TS
office 711, 14, Presnenskij val,
Moscow, 123557, Russian Federation
EMail: afa1@factor-ts.ru
Nikolaj Nikishin
Infotecs GmbH
p/b 35, 80-5, Leningradskij prospekt,
Moscow, 125315, Russian Federation
EMail: nikishin@infotecs.ru
Boleslav Izotov
FGUE STC "Atlas"
38, Obraztsova,
Moscow, 127018, Russian Federation
EMail: izotov@nii.voskhod.ru
Elena Minaeva
MD PREI
build 3, 6A, Vtoroj Troitskij per.,
Moscow, Russian Federation
EMail: evminaeva@mail.ru
Serguei Murugov
R-Alpha
4/1, Raspletina,
Moscow, 123060, Russian Federation
EMail: msm@top-cross.ru
Igor Ovcharenko
MD PREI
Office 600, 14, B.Novodmitrovskaya,
Moscow, Russian Federation
EMail: igori@mo.msk.ru
Popov, et al. Informational [Page 49]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
Igor Ustinov
Cryptocom
office 239, 51, Leninskij prospekt,
Moscow, 119991, Russian Federation
EMail: igus@cryptocom.ru
Anatolij Erkin
SPRCIS (SPbRCZI)
1, Obrucheva,
St.Petersburg, 195220, Russian Federation
EMail: erkin@nevsky.net
Popov, et al. Informational [Page 50]
RFC 4357 Crypto-Pro Cryptographic Algorithms January 2006
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Popov, et al. Informational [Page 51]
一覧
スポンサーリンク
