RFC 4490
Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)
RFC 4490: Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS) 🎀
okay bestie, let's get into this one 💖 It's RFC 4490, published in May 2006 by the Network Working Group, and it's on the Standards Track 🦋 The editors are S. Leontiev, Ed. and G. Chudov, Ed., both from CRYPTO-PRO. The doc doesn't list anything it obsoletes or updates, so it's standing on its own ✨
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the conventions for using the cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 with the Cryptographic Message Syntax (CMS). The CMS is used for digital signature, digest, authentication, and encryption of arbitrary message contents. 🔐
Table of Contents 🌸
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Message Digest Algorithms .......................................3
2.1. Message Digest Algorithm GOST R 34.11-94 ...................3
3. Signature Algorithms ............................................4
3.1. Signature Algorithm GOST R 34.10-94 ........................4
3.2. Signature Algorithm GOST R 34.10-2001 ......................5
4. Key Management Algorithms .......................................5
4.1. Key Agreement Algorithms ...................................6
4.1.1. Key Agreement Algorithms Based on GOST R
34.10-94/2001 Public ................................6
4.2. Key Transport Algorithms ...................................8
4.2.1. Key Transport Algorithm Based on GOST R
34.10-94/2001 Public ................................8
5. Content Encryption Algorithms ...................................9
5.1. Content Encryption Algorithm GOST 28147-89 ................10
6. MAC Algorithms .................................................10
6.1. HMAC with GOST R 34.11-94 .................................10
7. Use with S/MIME ................................................11
7.1. Parameter micalg ..........................................11
7.2. Attribute SMIMECapabilities ...............................11
8. Security Considerations ........................................12
9. Examples .......................................................12
9.1. Signed Message ............................................12
9.2. Enveloped Message Using Key Agreement .....................14
9.3. Enveloped Message Using Key Transport .....................17
10. ASN.1 Modules .................................................19
10.1. GostR3410-EncryptionSyntax ...............................19
10.2. GostR3410-94-SignatureSyntax .............................21
10.3. GostR3410-2001-SignatureSyntax ...........................22
11. Acknowledgements ..............................................23
12. References ....................................................24
12.1. Normative References .....................................24
12.2. Informative References ...................................251. Introduction ✨
The Cryptographic Message Syntax [CMS] is used for digital signature, digest, authentication, and encryption of arbitrary message contents. This companion spec describes how to use the cryptographic algorithms GOST 28147-89 [GOST28147], GOST R 34.10-94 [GOST3431095, GOSTR341094], GOST R 34.10-2001 [GOST3431004, GOSTR341001], and GOST R 34.11-94 [GOST3431195, GOSTR341194] in CMS, as proposed by the CRYPTO-PRO Company for the "Russian Cryptographic Software Compatibility Agreement" community. It does not describe these algorithms themselves, since they're defined in the corresponding national standards 📚
The CMS values are generated using ASN.1 [X.208-88], using BER encoding [X.209-88]. This document specifies the algorithm identifiers for each algorithm, including ASN.1 for object identifiers and any associated parameters.
The fields in the CMS employed by each algorithm are identified.
1.1. Terminology 🧠
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
2. Message Digest Algorithms 💌
This section specifies the conventions for using the digest algorithm GOST R 34.11-94 employed by CMS.
Digest values are located in the DigestedData digest field and the Message Digest authenticated attribute. On top of that, digest values are input to signature algorithms, so they're everywhere 💅
2.1. Message Digest Algorithm GOST R 34.11-94 🔑
The hash function GOST R 34.11-94 was developed by "GUBS of Federal Agency Government Communication and Information" and "All-Russian Scientific and Research Institute of Standardization". The algorithm GOST R 34.11-94 produces a 256-bit hash value of the arbitrary finite bit-length input. This document does not contain the full GOST R 34.11-94 specification, which you can find in [GOSTR341194] in Russian. [Schneier95], ch. 18.11, p. 454, has a brief technical description in English.
The hash algorithm GOST R 34.11-94 has the following identifier:
id-GostR3411-94 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
gostr3411(9) }The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain NULL. Implementations MAY accept the GOST R 34.11-94 AlgorithmIdentifiers with absent parameters as well as NULL parameters.
This function is always used with default parameters id-GostR3411-94-CryptoProParamSet (see Section 8.2 of [CPALGS]).
When the Message Digest authenticated attribute is present, the DigestedData digest contains a 32-byte digest in little-endian representation:
GostR3411-94-Digest ::= OCTET STRING (SIZE (32))3. Signature Algorithms ✍️
This section specifies the CMS procedures for the GOST R 34.10-94 and GOST R 34.10-2001 signature algorithms.
Signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of SignedData. Signature algorithm identifiers are also located in the SignerInfo signatureAlgorithm field of countersignature attributes.
Signature values are located in the SignerInfo signature field of SignedData. Signature values are also located in the SignerInfo signature field of countersignature attributes.
3.1. Signature Algorithm GOST R 34.10-94 💫
GOST R 34.10-94 was developed by "GUBS of Federal Agency Government Communication and Information" and "All-Russian Scientific and Research Institute of Standardization". This signature algorithm MUST be used conjointly with the GOST R 34.11-94 message digest algorithm. This document does not contain the full GOST R 34.10-94 specification, which is fully described in [GOSTR341094] in Russian. A brief description in English can be found in [Schneier95], ch. 20.3, p. 495.
The GOST R 34.10-94 signature algorithm has the following public key algorithm identifier:
id-GostR3410-94-signature OBJECT IDENTIFIER ::= id-GostR3410-94id-GostR3410-94 is defined in Section 2.3.1 of [CPPK].
The signature algorithm GOST R 34.10-94 generates a digital signature in the form of two 256-bit numbers, r' and s. Its octet string representation consists of 64 octets, where the first 32 octets contain the big-endian representation of s and the second 32 octets contain the big-endian representation of r'.
GostR3410-94-Signature ::= OCTET STRING (SIZE (64))3.2. Signature Algorithm GOST R 34.10-2001 🌈
GOST R 34.10-2001 was developed by "GUBS of Federal Agency Government Communication and Information" and "All-Russian Scientific and Research Institute of Standardization". This signature algorithm MUST be used conjointly with GOST R 34.11-94. This document does not contain the full GOST R 34.10-2001 specification, which is fully described in [GOSTR341001].
The signature algorithm GOST R 34.10-2001 has the following public key algorithm identifier:
id-GostR3410-2001-signature OBJECT IDENTIFIER ::= id-GostR3410-2001id-GostR3410-2001 is defined in Section 2.3.2 of [CPPK].
The signature algorithm GOST R 34.10-2001 generates a digital signature in the form of two 256-bit numbers, r and s. Its octet string representation consists of 64 octets, where the first 32 octets contain the big-endian representation of s and the second 32 octets contain the big-endian representation of r.
GostR3410-2001-Signature ::= OCTET STRING (SIZE (64))4. Key Management Algorithms 🗝️
This chapter describes the key agreement and key transport algorithms. They're based on the VKO GOST R 34.10-94 and VKO GOST R 34.10-2001 key derivation algorithms, and on the CryptoPro and GOST 28147-89 key wrap algorithms, all described in [CPALGS]. They MUST be used only with the content encryption algorithm GOST 28147-89, defined in Section 5 of this document. 🫶
4.1. Key Agreement Algorithms 🤝
This section specifies the conventions employed by CMS implementations that support key agreement using both the VKO GOST R 34.10-94 and VKO GOST R 34.10-2001 algorithms, described in [CPALGS].
Key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field. Wrapped message-authentication keys are located in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field.
That's part 1 of 5 🎀 Next up is Section 4.1.1, bestie 🦋
4.1.1. Key Agreement Algorithms Based on GOST R 34.10-94/2001 Public Keys 🔐
Okay so the EnvelopedData RecipientInfos KeyAgreeRecipientInfo field has its own set of rules, bestie 🦋 Here they are:
- The version MUST be 3.
- The originator MUST be the
originatorKeyalternative. - The
originatorKeyalgorithm field MUST contain the object identifierid-GostR3410-94orid-GostR3410-2001, plus the matching parameters (defined in Sections 2.3.1, 2.3.2 of [CPPK]) 💜 - The
originatorKeypublicKeyfield MUST contain the sender's public key. keyEncryptionAlgorithmMUST be theid-GostR3410-94-CryptoPro-ESDHor theid-GostR3410-2001-CryptoPro-ESDHalgorithm identifier, depending on the recipient's public key algorithm. The parameter field for these isKeyWrapAlgorithm, and this parameter MUST be present ✨KeyWrapAlgorithmbasically spells out the algorithm and parameters used to encrypt the content-encryption key with the pairwise key-encryption key. That pairwise key comes from the VKO GOST R 34.10-94 or VKO GOST R 34.10-2001 key agreement algorithms.
The algorithm identifiers and parameter syntax look like this:
id-GostR3410-94-CryptoPro-ESDH OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
gostR3410-94-CryptoPro-ESDH(97) }
id-GostR3410-2001-CryptoPro-ESDH OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
gostR3410-2001-CryptoPro-ESDH(96) }
KeyWrapAlgorithm ::= AlgorithmIdentifier- When
keyEncryptionAlgorithmisid-GostR3410-94-CryptoPro-ESDH, theKeyWrapAlgorithmalgorithm MUST be theid-Gost28147-89-CryptoPro-KeyWrapalgorithm identifier:
id-Gost28147-89-CryptoPro-KeyWrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
keyWrap(13) cryptoPro(1) }The CryptoPro Key Wrap algorithm is described in Sections 6.3 and 6.4 of [CPALGS].
- When
keyEncryptionAlgorithmisid-GostR3410-2001-CryptoPro-ESDH, theKeyWrapAlgorithmalgorithm MUST be either theid-Gost28147-89-CryptoPro-KeyWrapor theid-Gost28147-89-None-KeyWrapalgorithm identifier:
id-Gost28147-89-None-KeyWrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
keyWrap(13) none(0) }The GOST 28147-89 Key Wrap algorithm is described in Sections 6.1 and 6.2 of [CPALGS].
KeyWrapAlgorithmalgorithm parameters MUST be present. The syntax for those parameters is:
Gost28147-89-KeyWrapParameters ::=
SEQUENCE {
encryptionParamSet Gost28147-89-ParamSet,
ukm OCTET STRING (SIZE (8)) OPTIONAL
}
Gost28147-89-ParamSet ::= OBJECT IDENTIFIERGost28147-89-KeyWrapParametersukmMUST be absent.KeyAgreeRecipientInfoukmMUST be present and contain eight octets.encryptedKeyMUST encapsulateGost28147-89-EncryptedKey, wheremaskKeyMUST be absent:
Gost28147-89-EncryptedKey ::= SEQUENCE {
encryptedKey Gost28147-89-Key,
maskKey [0] IMPLICIT Gost28147-89-Key
OPTIONAL,
macKey Gost28147-89-MAC
}Here's the key-making flow 🌈 First, using the secret key that goes with the originatorKey publicKey and the recipient's public key, you run VKO GOST R 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) to produce the KEK. Then the key wrap algorithm named by KeyWrapAlgorithm gets applied to produce CEK_ENC, CEK_MAC, and UKM. Gost28147-89-KeyWrapParameters encryptionParamSet is used for all the encryption operations.
Finally, the encrypted key (CEK_ENC) goes into the Gost28147-89-EncryptedKey encryptedKey field, its MAC (CEK_MAC) goes into the macKey field, and UKM goes into the KeyAgreeRecipientInfo ukm field. Iconic 👑
4.2. Key Transport Algorithms 🚚
This section lays out the conventions CMS implementations follow when they do key transport with both the VKO GOST R 34.10-94 and VKO GOST R 34.10-2001 algorithms, described in [CPALGS] 💅
Key transport algorithm identifiers live in the EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field. The key transport encrypted content-encryption keys live in the EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey field.
4.2.1. Key Transport Algorithm Based on GOST R 34.10-94/2001 Public Keys 🦢
The EnvelopedData RecipientInfos KeyTransRecipientInfo field works like this:
- The version MUST be 0 or 3.
keyEncryptionAlgorithmand its parameters MUST be identical to the recipient public key algorithm and parameters.encryptedKeyencapsulatesGostR3410-KeyTransport, which holds the encrypted content-encryption key, its MAC, the GOST 28147-89 algorithm parameters used for key encryption, the sender's ephemeral public key, and UKM (UserKeyingMaterial; see [CMS], Section 10.2.6) 🫶transportParametersMUST be present.ephemeralPublicKeyMUST be present, and its parameters, if present, MUST be equal to the recipient public key parameters.
GostR3410-KeyTransport ::= SEQUENCE {
sessionEncryptedKey Gost28147-89-EncryptedKey,
transportParameters
[0] IMPLICIT GostR3410-TransportParameters OPTIONAL
}
GostR3410-TransportParameters ::= SEQUENCE {
encryptionParamSet OBJECT IDENTIFIER,
ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo OPTIONAL,
ukm OCTET STRING
}Using the secret key that goes with GostR3410-TransportParameters ephemeralPublicKey and the recipient's public key, you run VKO GOST R 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) to produce the KEK. Then the CryptoPro key wrap algorithm gets applied to produce CEK_ENC, CEK_MAC, and UKM. GostR3410-TransportParameters encryptionParamSet is used for all the encryption operations.
The encrypted key (CEK_ENC) goes into the Gost28147-89-EncryptedKey encryptedKey field, its MAC (CEK_MAC) goes into the Gost28147-89-EncryptedKey macKey field, and UKM goes into the GostR3410-TransportParameters ukm field ✨
5. Content Encryption Algorithms 🎀
This section covers the conventions CMS implementations use when they support content encryption with GOST 28147-89 🌸
Content encryption algorithm identifiers live in the EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. These algorithms encipher the content found in the EnvelopedData EncryptedContentInfo encryptedContent field and the EncryptedData EncryptedContentInfo encryptedContent field.
5.1. Content Encryption Algorithm GOST 28147-89 🧚
This section explains how to use the GOST 28147-89 algorithm for data encipherment. GOST 28147-89 is fully described in [GOST28147] (in Russian) 🇷🇺
This document specifies the following object identifier (OID) for this algorithm:
id-Gost28147-89 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
gost28147-89(21) }Algorithm parameters MUST be present and have the following structure:
Gost28147-89-Parameters ::=
SEQUENCE {
iv Gost28147-89-IV,
encryptionParamSet OBJECT IDENTIFIER
}
Gost28147-89-IV ::= OCTET STRING (SIZE (8))encryptionParamSet points to the set of matching Gost28147-89-ParamSetParameters (see Section 8.1 of [CPALGS]).
6. MAC Algorithms 🔒
This section covers the conventions CMS implementations use when they support the message authentication code (MAC) based on GOST R 34.11-94 🔑
MAC algorithm identifiers live in the AuthenticatedData macAlgorithm field, and MAC values live in the AuthenticatedData mac field.
6.1. HMAC with GOST R 34.11-94 🌈
The HMAC_GOSTR3411 (K,text) function is built on the GOST R 34.11-94 hash function, as defined in Section 3 of [CPALGS] 💜
This document specifies the following OID for this algorithm:
id-HMACGostR3411-94 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
hmacgostr3411(10) }This algorithm has the same parameters as the GOST R 34.11-94 digest algorithm, and it uses the same OIDs for identification (see [CPPK]).
7. Use with S/MIME 💌
This section defines how to use the algorithms from this document with S/MIME [RFC3851] 🦋
7.1. Parameter micalg 🍓
When you use the algorithms defined in this document, the micalg parameter is RECOMMENDED to be set to "gostr3411-94". Otherwise, it MUST be set to "unknown".
Wait, I'm rewriting that as it should read: the micalg parameter SHOULD be set to "gostr3411-94" 💅 Otherwise, it MUST be set to "unknown".
7.2. Attribute SMIMECapabilities 🎀
The SMIMECapability value that signals support for the GOST R 34.11-94 digest algorithm is a SEQUENCE whose capabilityID field holds the object identifier id-GostR3411-94, with no parameters. Its DER encoding is:
30 08 06 06 2A 85 03 02 02 09The SMIMECapability value that signals support for the GOST 28147-89 encryption algorithm is a SEQUENCE whose capabilityID field holds the object identifier id-Gost28147-89, with no parameters. Its DER encoding is:
30 08 06 06 2A 85 03 02 02 15If the sender wants to show support for a specific parameter set, SMIMECapability parameters MUST contain the Gost28147-89-Parameters structure. Recipients MUST ignore the Gost28147-89-Parameters iv field and assume the sender supports the parameters in the Gost28147-89-Parameters encryptionParamSet field. 🙈
The DER encoding for the SMIMECapability that shows support for GOST 28147-89 with id-Gost28147-89-CryptoPro-A-ParamSet (see [CPALGS]) is:
30 1D 06 06 2A 85 03 02 02 15 30 13 04 08 00 00
00 00 00 00 00 00 06 07 2A 85 03 02 02 1F 018. Security Considerations 💀
Okay bestie, this part is SERIOUS. Read it twice 😭
Conforming applications MUST use unique values for ukm and iv. Recipients MAY verify that the ukm and iv values the sender specified are unique 🔥
It is RECOMMENDED that software applications verify that signature values, subject public keys, and algorithm parameters conform to [GOSTR341001] and [GOSTR341094] standards before using them ✨
Cryptographic algorithm parameters affect algorithm strength. Using parameters not listed in [CPALGS] is NOT RECOMMENDED (see the Security Considerations section of [CPALGS]) 💀
Using the same key for signature and key derivation is NOT RECOMMENDED. When signed CMS documents are used as an analogue to a manual signature, under the Russian Federal Electronic Digital Signature Law [RFEDSL], the signer certificate MUST contain the keyUsage extension, that extension MUST be critical, and keyUsage MUST NOT include keyEncipherment or keyAgreement (see [PROFILE], Section 4.2.1.3) 👑 An application SHOULD be submitted for examination by an authorized agency at the appropriate levels of target_of_evaluation (TOE), according to [RFEDSL], [RFLLIC], and [CRYPTOLIC] 🫶
9. Examples 🧚
Examples here are stored in the same format as the examples in [RFC4134], and you can extract them with 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 any Base64 decoder can process 🦋
9.1. Signed Message ✨
okay bestie, this one is a signed message 🖊️ and it's signed with the sample certificate from Section 4.2 of [CPPK] 💅. the public key (x,y) from that same section can be used to verify the signature 🔍
0 296: SEQUENCE {
4 9: OBJECT IDENTIFIER signedData
15 281: [0] {
19 277: SEQUENCE {
23 1: INTEGER 1
26 12: SET {
28 10: SEQUENCE {
30 6: OBJECT IDENTIFIER id-GostR3411-94
38 0: NULL
: }
: }
40 27: SEQUENCE {
42 9: OBJECT IDENTIFIER data
53 14: [0] {
55 12: OCTET STRING 73 61 6D 70 6C 65 20 74 65 78 74 0A
: }
: }
69 228: SET {
72 225: SEQUENCE {
75 1: INTEGER 1
78 129: SEQUENCE {
81 109: SEQUENCE {
83 31: SET {
85 29: SEQUENCE {
87 3: OBJECT IDENTIFIER commonName
92 22: UTF8String 'GostR3410-2001 example'
: }
: }
116 18: SET {
118 16: SEQUENCE {
120 3: OBJECT IDENTIFIER organizationName
125 9: UTF8String 'CryptoPro'
: }
: }
136 11: SET {
138 9: SEQUENCE {
140 3: OBJECT IDENTIFIER countryName
145 2: PrintableString 'RU'
: }
: }
149 41: SET {
151 39: SEQUENCE {
153 9: OBJECT IDENTIFIER emailAddress
164 26: IA5String 'GostR3410-2001@example.com'
: }
: }
: }
192 16: INTEGER
: 2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21
: }
210 10: SEQUENCE {
212 6: OBJECT IDENTIFIER id-GostR3411-94
220 0: NULL
: }
222 10: SEQUENCE {
224 6: OBJECT IDENTIFIER id-GostR3410-2001
232 0: NULL
: }
234 64: OCTET STRING
: C0 C3 42 D9 3F 8F FE 25 11 11 88 77 BF 89 C3 DB
: 83 42 04 D6 20 F9 68 2A 99 F6 FE 30 3B E4 F4 C8
: F8 D5 B4 DA FB E1 C6 91 67 34 1F BC A6 7A 0D 12
: 7B FD 10 25 C6 51 DB 8D B2 F4 8C 71 7E ED 72 A9
: }
: }
: }
: }
: }here's the signed message as base64, the bin file is ready to go 🎀
|>GostR3410-2001-signed.bin
|MIIBKAYJKoZIhvcNAQcCoIIBGTCCARUCAQExDDAKBgYqhQMCAgkFADAbBgkqhkiG
|9w0BBwGgDgQMc2FtcGxlIHRleHQKMYHkMIHhAgEBMIGBMG0xHzAdBgNVBAMMFkdv
|c3RSMzQxMC0yMDAxIGV4YW1wbGUxEjAQBgNVBAoMCUNyeXB0b1BybzELMAkGA1UE
|BhMCUlUxKTAnBgkqhkiG9w0BCQEWGkdvc3RSMzQxMC0yMDAxQGV4YW1wbGUuY29t
|AhAr9cYewhG9F8fc1GJmtC4hMAoGBiqFAwICCQUAMAoGBiqFAwICEwUABEDAw0LZ
|P4/+JRERiHe/icPbg0IE1iD5aCqZ9v4wO+T0yPjVtNr74caRZzQfvKZ6DRJ7/RAl
|xlHbjbL0jHF+7XKp
|<GostR3410-2001-signed.bin9.2. Enveloped Message Using Key Agreement 🌸
this message is encrypted 🔐 using the sample certificate from Section 4.2 of [CPPK] as the recipient certificate. the private key 'd' from that same section can be used to decrypt it 🗝️
0 420: SEQUENCE {
4 9: OBJECT IDENTIFIER envelopedData
15 405: [0] {
19 401: SEQUENCE {
23 1: INTEGER 2
26 336: SET {
30 332: [1] {
34 1: INTEGER 3
37 101: [0] {
39 99: [1] {
41 28: SEQUENCE {
43 6: OBJECT IDENTIFIER id-GostR3410-2001
51 18: SEQUENCE {
53 7: OBJECT IDENTIFIER
: id-GostR3410-2001-CryptoPro-XchA-ParamSet
62 7: OBJECT IDENTIFIER
: id-GostR3411-94-CryptoProParamSet
: }
: }
71 67: BIT STRING, encapsulates {
74 64: OCTET STRING
: B3 55 39 F4 67 81 97 2B A5 C4 D9 84 1F 27 FB 81
: ED 08 32 E6 9A D4 F2 00 78 B8 FF 83 64 EA D2 1D
: B0 78 3C 7D FE 03 C1 F4 06 E4 3B CC 16 B9 C5 F6
: F6 19 37 1C 17 B8 A0 AA C7 D1 A1 94 B3 A5 36 20
: }
: }
: }
140 10: [1] {
142 8: OCTET STRING 2F F0 F6 D1 86 4B 32 8A
: }
152 30: SEQUENCE {
154 6: OBJECT IDENTIFIER id-GostR3410-2001-CryptoPro-ESDH
162 20: SEQUENCE {
164 7: OBJECT IDENTIFIER id-Gost28147-89-None-KeyWrap
173 9: SEQUENCE {
175 7: OBJECT IDENTIFIER
: id-Gost28147-89-CryptoPro-A-ParamSet
: }
: }
: }
184 179: SEQUENCE {
187 176: SEQUENCE {
190 129: SEQUENCE {
193 109: SEQUENCE {
195 31: SET {
197 29: SEQUENCE {
199 3: OBJECT IDENTIFIER commonName
204 22: UTF8String 'GostR3410-2001 example'
: }
: }
228 18: SET {
230 16: SEQUENCE {
232 3: OBJECT IDENTIFIER organizationName
237 9: UTF8String 'CryptoPro'
: }
: }
248 11: SET {
250 9: SEQUENCE {
252 3: OBJECT IDENTIFIER countryName
257 2: PrintableString 'RU'
: }
: }
261 41: SET {
263 39: SEQUENCE {
265 9: OBJECT IDENTIFIER emailAddress
276 26: IA5String 'GostR3410-2001@example.com'
: }
: }
: }
304 16: INTEGER
: 2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21
: }
322 42: OCTET STRING, encapsulates {
324 40: SEQUENCE {
326 32: OCTET STRING
: 16 A3 1C E7 CE 4E E9 0D F1 EC 74 69 04 68 1E C7
: 9F 3A ED B8 3B 1F 1D 4A 7E F9 A5 D9 CB 19 D5 E8
360 4: OCTET STRING
: 93 FD 86 7E
: }
: }
: }
: }
: }
: }
366 56: SEQUENCE {
368 9: OBJECT IDENTIFIER data
379 29: SEQUENCE {
381 6: OBJECT IDENTIFIER id-Gost28147-89
389 19: SEQUENCE {
391 8: OCTET STRING B7 35 E1 7A 07 35 A2 1D
401 7: OBJECT IDENTIFIER id-Gost28147-89-CryptoPro-A-ParamSet
: }
: }
410 12: [0] 39 B1 8A F4 BF A9 E2 65 25 B6 55 C9
: }
: }
: }
: }|>GostR3410-2001-keyagree.bin
|MIIBpAYJKoZIhvcNAQcDoIIBlTCCAZECAQIxggFQoYIBTAIBA6BloWMwHAYGKoUD
|AgITMBIGByqFAwICJAAGByqFAwICHgEDQwAEQLNVOfRngZcrpcTZhB8n+4HtCDLm
|mtTyAHi4/4Nk6tIdsHg8ff4DwfQG5DvMFrnF9vYZNxwXuKCqx9GhlLOlNiChCgQI
|L/D20YZLMoowHgYGKoUDAgJgMBQGByqFAwICDQAwCQYHKoUDAgIfATCBszCBsDCB
|gTBtMR8wHQYDVQQDDBZHb3N0UjM0MTAtMjAwMSBleGFtcGxlMRIwEAYDVQQKDAlD
|cnlwdG9Qcm8xCzAJBgNVBAYTAlJVMSkwJwYJKoZIhvcNAQkBFhpHb3N0UjM0MTAt
|MjAwMUBleGFtcGxlLmNvbQIQK/XGHsIRvRfH3NRiZrQuIQQqMCgEIBajHOfOTukN
|8ex0aQRoHsefOu24Ox8dSn75pdnLGdXoBAST/YZ+MDgGCSqGSIb3DQEHATAdBgYq
|hQMCAhUwEwQItzXhegc1oh0GByqFAwICHwGADDmxivS/qeJlJbZVyQ==
|<GostR3410-2001-keyagree.bin9.3. Enveloped Message Using Key Transport 💜
same vibe as the last one 💕 this message is encrypted using the sample certificate from Section 4.2 of [CPPK] as a recipient certificate. the private key 'd' from that same section can be used to decrypt it 🔓
0 423: SEQUENCE {
4 9: OBJECT IDENTIFIER envelopedData
15 408: [0] {
19 404: SEQUENCE {
23 1: INTEGER 0
26 339: SET {
30 335: SEQUENCE {
34 1: INTEGER 0
37 129: SEQUENCE {
40 109: SEQUENCE {
42 31: SET {
44 29: SEQUENCE {
46 3: OBJECT IDENTIFIER commonName
51 22: UTF8String 'GostR3410-2001 example'
: }
: }
75 18: SET {
77 16: SEQUENCE {
79 3: OBJECT IDENTIFIER organizationName
84 9: UTF8String 'CryptoPro'
: }
: }
95 11: SET {
97 9: SEQUENCE {
99 3: OBJECT IDENTIFIER countryName
104 2: PrintableString 'RU'
: }
: }
108 41: SET {
110 39: SEQUENCE {
112 9: OBJECT IDENTIFIER emailAddress
123 26: IA5String 'GostR3410-2001@example.com'
: }
: }
: }
151 16: INTEGER
: 2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21
: }
169 28: SEQUENCE {
171 6: OBJECT IDENTIFIER id-GostR3410-2001
179 18: SEQUENCE {
181 7: OBJECT IDENTIFIER
: id-GostR3410-2001-CryptoPro-XchA-ParamSet
190 7: OBJECT IDENTIFIER
: id-GostR3411-94-CryptoProParamSet
: }
: }
199 167: OCTET STRING, encapsulates {
202 164: SEQUENCE {
205 40: SEQUENCE {
207 32: OCTET STRING
: 6A 2F A8 21 06 95 68 9F 9F E4 47 AA 9E CB 61 15
: 2B 7E 41 60 BC 5D 8D FB F5 3D 28 1B 18 9A F9 75
241 4: OCTET STRING
: 36 6D 98 B7
: }
247 120: [0] {
249 7: OBJECT IDENTIFIER
: id-Gost28147-89-CryptoPro-A-ParamSet
258 99: [0] {
260 28: SEQUENCE {
262 6: OBJECT IDENTIFIER id-GostR3410-2001
270 18: SEQUENCE {
272 7: OBJECT IDENTIFIER
: id-GostR3410-2001-CryptoPro-XchA-ParamSet
281 7: OBJECT IDENTIFIER
: id-GostR3411-94-CryptoProParamSet
: }
: }
290 67: BIT STRING encapsulates {
293 64: OCTET STRING
: 4D 2B 2F 33 90 E6 DC A3 DD 55 2A CD DF E0 EF FB
: 31 F7 73 7E 4E FF BF 78 89 8A 2B C3 CD 31 94 04
: 4B 0E 60 48 96 1F DB C7 5D 12 6F DA B2 40 8A 77
: B5 BD EA F2 EC 34 CB 23 9F 9B 8B DD 9E 12 C0 F6
: }
: }
359 8: OCTET STRING
: 97 95 E3 2C 2B AD 2B 0C
: }
: }
: }
: }
: }
369 56: SEQUENCE {
371 9: OBJECT IDENTIFIER data
382 29: SEQUENCE {
384 6: OBJECT IDENTIFIER id-Gost28147-89
392 19: SEQUENCE {
394 8: OCTET STRING BC 10 8B 1F 0B FF 34 29
404 7: OBJECT IDENTIFIER id-Gost28147-89-CryptoPro-A-ParamSet
: }
: }
413 12: [0] AA 8E 72 1D EE 4F B3 2E E3 0F A1 37
: }
: }
: }
: }|>GostR3410-2001-keytrans.bin
|MIIBpwYJKoZIhvcNAQcDoIIBmDCCAZQCAQAxggFTMIIBTwIBADCBgTBtMR8wHQYD
|VQQDDBZHb3N0UjM0MTAtMjAwMSBleGFtcGxlMRIwEAYDVQQKDAlDcnlwdG9Qcm8x
|CzAJBgNVBAYTAlJVMSkwJwYJKoZIhvcNAQkBFhpHb3N0UjM0MTAtMjAwMUBleGFt
|cGxlLmNvbQIQK/XGHsIRvRfH3NRiZrQuITAcBgYqhQMCAhMwEgYHKoUDAgIkAAYH
|KoUDAgIeAQSBpzCBpDAoBCBqL6ghBpVon5/kR6qey2EVK35BYLxdjfv1PSgbGJr5
|dQQENm2Yt6B4BgcqhQMCAh8BoGMwHAYGKoUDAgITMBIGByqFAwICJAAGByqFAwIC
|HgEDQwAEQE0rLzOQ5tyj3VUqzd/g7/sx93N+Tv+/eImKK8PNMZQESw5gSJYf28dd
|Em/askCKd7W96vLsNMsjn5uL3Z4SwPYECJeV4ywrrSsMMDgGCSqGSIb3DQEHATAd
|BgYqhQMCAhUwEwQIvBCLHwv/NCkGByqFAwICHwGADKqOch3uT7Mu4w+hNw==
|<GostR3410-2001-keytrans.bin10. ASN.1 Modules 🧚
okay so the extra ASN.1 modules this doc refers to are over in [CPALGS] 📚 go check there if you need them 🤓
10.1. GostR3410-EncryptionSyntax
GostR3410-EncryptionSyntax
{ iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
other(1) modules(1) gostR3410-EncryptionSyntax(5) 2 }
DEFINITIONS ::=
BEGIN
-- EXPORTS All --
-- The types and values defined in this module are exported for
-- use in the other ASN.1 modules contained within the Russian
-- Cryptography "GOST" & "GOST R" Specifications, and for the use
-- of other applications which will use them to access Russian-- Cryptography services. Other applications may use them for
-- their own purposes, but this will not constrain extensions and
-- modifications needed to maintain or improve the Russian
-- Cryptography service.
IMPORTS
id-CryptoPro-algorithms,
gost28147-89-EncryptionSyntax,
gostR3410-94-PKISyntax,
gostR3410-2001-PKISyntax,
ALGORITHM-IDENTIFIER,
cryptographic-Gost-Useful-Definitions
FROM Cryptographic-Gost-Useful-Definitions -- in [CPALGS]
{ iso(1) member-body(2) ru(643) rans(2)
cryptopro(2) other(1) modules(1)
cryptographic-Gost-Useful-Definitions(0) 1 }
id-GostR3410-94
FROM GostR3410-94-PKISyntax -- in [CPALGS]
gostR3410-94-PKISyntax
id-GostR3410-2001
FROM GostR3410-2001-PKISyntax -- in [CPALGS]
gostR3410-2001-PKISyntax
Gost28147-89-ParamSet,
Gost28147-89-EncryptedKey
FROM Gost28147-89-EncryptionSyntax -- in [CPALGS]
gost28147-89-EncryptionSyntax
SubjectPublicKeyInfo
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)}
;
-- CMS/PKCS#7 key agreement algorithms & parameters
Gost28147-89-KeyWrapParameters ::=
SEQUENCE {
encryptionParamSet Gost28147-89-ParamSet,
ukm OCTET STRING (SIZE (8)) OPTIONAL
}
id-Gost28147-89-CryptoPro-KeyWrap OBJECT IDENTIFIER ::=
{ id-CryptoPro-algorithms keyWrap(13) cryptoPro(1) }
id-Gost28147-89-None-KeyWrap OBJECT IDENTIFIER ::=
{ id-CryptoPro-algorithms keyWrap(13) none(0) }
Gost28147-89-KeyWrapAlgorithms ALGORITHM-IDENTIFIER ::= {
{ Gost28147-89-KeyWrapParameters IDENTIFIED BY
id-Gost28147-89-CryptoPro-KeyWrap } |
{ Gost28147-89-KeyWrapParameters IDENTIFIED BY
id-Gost28147-89-None-KeyWrap }
}
id-GostR3410-2001-CryptoPro-ESDH OBJECT IDENTIFIER ::=
{ id-CryptoPro-algorithms
gostR3410-2001-CryptoPro-ESDH(96) }
id-GostR3410-94-CryptoPro-ESDH OBJECT IDENTIFIER ::=
{ id-CryptoPro-algorithms
gostR3410-94-CryptoPro-ESDH(97) }
-- CMS/PKCS#7 key transport algorithms & parameters
-- OID for CMS/PKCS#7 Key transport is id-GostR3410-94 from
-- GostR3410-94-PKISyntax or id-GostR3410-2001 from
-- GostR3410-2001-PKISyntax
-- Algorithms for CMS/PKCS#7 Key transport are
-- GostR3410-94-PublicKeyAlgorithms from
-- GostR3410-94-PKISyntax or
-- GostR3410-2001-PublicKeyAlgorithms from
-- GostR3410-2001-PKISyntax
-- SMIMECapability for CMS/PKCS#7 Key transport are
-- id-GostR3410-94 from GostR3410-94-PKISyntax or
-- id-GostR3410-2001 from GostR3410-2001-PKISyntax
id-GostR3410-94-KeyTransportSMIMECapability
OBJECT IDENTIFIER ::= id-GostR3410-94
id-GostR3410-2001-KeyTransportSMIMECapability
OBJECT IDENTIFIER ::= id-GostR3410-2001
GostR3410-KeyTransport ::=
SEQUENCE {
sessionEncryptedKey Gost28147-89-EncryptedKey,
transportParameters [0]
IMPLICIT GostR3410-TransportParameters OPTIONAL
}
GostR3410-TransportParameters ::=
SEQUENCE {
encryptionParamSet Gost28147-89-ParamSet,
ephemeralPublicKey [0]
IMPLICIT SubjectPublicKeyInfo OPTIONAL,
ukm OCTET STRING ( SIZE(8) )
}
END -- GostR3410-EncryptionSyntax10.2. GostR3410-94-SignatureSyntax
okay so this is the module for GOST R 34.10-94 signatures, and it's giving very organised 🗂️✨ It starts with its own OID-style name, then the DEFINITIONS and EXPORTS bit, which is basically the module saying "other ASN.1 modules and apps can use this stuff, and that won't stop the Russian Cryptography service from getting extensions and improvements" 🫶
GostR3410-94-SignatureSyntax
{ iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
other(1) modules(1) gostR3410-94-SignatureSyntax(3) 1 }
DEFINITIONS ::=
BEGIN
-- EXPORTS All --
-- The types and values defined in this module are exported for
-- use in the other ASN.1 modules contained within the Russian
-- Cryptography "GOST" & "GOST R" Specifications, and for the use
-- of other applications which will use them to access Russian
-- Cryptography services. Other applications may use them for
-- their own purposes, but this will not constrain extensions and
-- modifications needed to maintain or improve the Russian
-- Cryptography service.
IMPORTS
gostR3410-94-PKISyntax, ALGORITHM-IDENTIFIER,
cryptographic-Gost-Useful-Definitions
FROM Cryptographic-Gost-Useful-Definitions -- in [CPALGS]
{ iso(1) member-body(2) ru(643) rans(2)
cryptopro(2) other(1) modules(1)
cryptographic-Gost-Useful-Definitions(0) 1 }
id-GostR3410-94,
GostR3410-94-PublicKeyParameters
FROM GostR3410-94-PKISyntax -- in [CPALGS]
gostR3410-94-PKISyntax
;
-- GOST R 34.10-94 signature data type
GostR3410-94-Signature ::=
OCTET STRING (SIZE (64))
-- GOST R 34.10-94 signature algorithm & parameters
GostR3410-94-CMSSignatureAlgorithms ALGORITHM-IDENTIFIER ::= {
{ GostR3410-94-PublicKeyParameters IDENTIFIED BY
id-GostR3410-94 }
}
END -- GostR3410-94-SignatureSyntax10.3. GostR3410-2001-SignatureSyntax
and now the GOST R 34.10-2001 version, which is basically the same vibe but a newer model 💅 The signature is still 64 octets, and it's tied to id-GostR3410-2001 🦋
GostR3410-2001-SignatureSyntax
{ iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
other(1) modules(1) gostR3410-2001-SignatureSyntax(10) 1 }
DEFINITIONS ::=
BEGIN
-- EXPORTS All --
-- The types and values defined in this module are exported for
-- use in the other ASN.1 modules contained within the Russian
-- Cryptography "GOST" & "GOST R" Specifications, and for the use
-- of other applications which will use them to access Russian
-- Cryptography services. Other applications may use them for
-- their own purposes, but this will not constrain extensions and
-- modifications needed to maintain or improve the Russian
-- Cryptography service.
IMPORTS
gostR3410-2001-PKISyntax, ALGORITHM-IDENTIFIER,
cryptographic-Gost-Useful-Definitions
FROM Cryptographic-Gost-Useful-Definitions -- in [CPALGS]
{ iso(1) member-body(2) ru(643) rans(2)
cryptopro(2) other(1) modules(1)
cryptographic-Gost-Useful-Definitions(0) 1 }
id-GostR3410-2001,
GostR3410-2001-PublicKeyParameters -- in [CPALGS]
FROM GostR3410-2001-PKISyntax
gostR3410-2001-PKISyntax
;
-- GOST R 34.10-2001 signature data type
GostR3410-2001-Signature ::=
OCTET STRING (SIZE (64))
-- GOST R 34.10-2001 signature algorithms and parameters
GostR3410-2001-CMSSignatureAlgorithms
ALGORITHM-IDENTIFIER ::= {
{ GostR3410-2001-PublicKeyParameters IDENTIFIED BY
id-GostR3410-2001 }
}
END -- GostR3410-2001-SignatureSyntax11. Acknowledgements ✨
this doc was made under the "Russian Cryptographic Software Compatibility Agreement" 🤝 It was signed by FGUE STC "Atlas", CRYPTO-PRO, Factor-TS, MD PREI, Infotecs GmbH, SPRCIS (SPbRCZI), Cryptocom, and R-Alpha. The whole point is mutual compatibility of the products and solutions, which is so responsible of them 👑
The authors wanted to thank:
- Microsoft Corporation Russia, for providing information about company products and solutions, and for technical consulting in PKI. 💜
- RSA Security Russia and Demos Co Ltd, for active collaboration and critical help in creating this document. 🫶
- Russ Housley (Vigil Security, LLC, housley@vigilsec.com) and Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru), for encouraging the authors to create this document. 🌸
- Prikhodko Dmitriy (VSTU, PrikhodkoDV@volgablob.ru), for invaluable assistance in proofreading this document and verifying the form and the contents of the ASN.1 structures mentioned or used in this document. 🧚
12. References 📚
12.1. Normative References
- [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
- [CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, "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", RFC 4357, January 2006.
- [CPPK] Leontiev, S., Ed. and D. Shefanovskij, Ed., "Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 4491, May 2006.
- [GOST28147] "Cryptographic Protection for Data Processing System", GOST 28147-89, Gosudarstvennyi Standard of USSR, Government Committee of the USSR for Standards, 1989. (In Russian)
- [GOST3431195] "Information technology. Cryptographic Data Security. Cashing function.", GOST 34.311-95, Council for Standardization, Metrology and Certification of the Commonwealth of Independence States (EASC), Minsk, 1995. (In Russian)
- [GOST3431095] "Information technology. Cryptographic Data Security. Produce and check procedures of Electronic Digital Signature based on Asymmetric Cryptographic Algorithm.", GOST 34.310-95, Council for Standardization, Metrology and Certification of the Commonwealth of Independence States (EASC), Minsk, 1995. (In Russian)
- [GOST3431004] "Information technology. Cryptographic Data Security. Formation and verification processes of (electronic) digital signature based on Asymmetric Cryptographic Algorithm.", GOST 34.310-2004, Council for Standardization, Metrology and Certification of the Commonwealth of Independence States (EASC), Minsk, 2004. (In Russian)
- [GOSTR341094] "Information technology. Cryptographic Data Security. Produce and check procedures of Electronic Digital Signatures based on Asymmetric Cryptographic Algorithm.", GOST R 34.10-94, Gosudarstvennyi Standard of Russian Federation, Government Committee of the Russia for Standards, 1994. (In Russian)
- [GOSTR341001] "Information technology. Cryptographic data security. Signature and verification processes of [electronic] digital signature.", GOST R 34.10-2001, Gosudarstvennyi Standard of Russian Federation, Government Committee of the Russia for Standards, 2001. (In Russian)
- [GOSTR341194] "Information technology. Cryptographic Data Security. Hashing function.", GOST R 34.10-94, Gosudarstvennyi Standard of Russian Federation, Government Committee of the Russia for Standards, 1994. (In Russian)
- [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
- [X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
- [X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
12.2. Informative References ✨
Okay so these are the extra-reading sources, bestie 📚 They're not required to build the thing, but they help you understand the whole vibe.
- [CRYPTOLIC] "Russian Federal Government Regulation on Licensing of Selected Activity Categories in Cryptography Area", 23 Sep 2002 N 691. 🇷🇺
- [RFC4134] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, July 2005. 💌
- [RFEDSL] "Russian Federal Electronic 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. 📜
- [Schneier95] B. Schneier, Applied Cryptography, Second Edition, John Wiley & Sons, Inc., 1995. 🔐
Authors' Addresses 🧚
Here are the amazing humans who wrote this, with their addresses and emails so you can slide into their DMs (professionally, obviously) 💅
Serguei Leontiev, Ed.
CRYPTO-PRO
38, Obraztsova,
Moscow, 127018, Russian Federation
EMail: lse@cryptopro.ru
Grigorij Chudov, Ed.
CRYPTO-PRO
38, Obraztsova,
Moscow, 127018, Russian Federation
EMail: chudov@cryptopro.ru
Vladimir Popov
CRYPTO-PRO
38, Obraztsova,
Moscow, 127018, Russian Federation
EMail: vpopov@cryptopro.ru
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
Igor Ovcharenko
MD PREI
Office 600, 14, B.Novodmitrovskaya,
Moscow, Russian Federation
EMail: igori@mo.msk.ru
Serguei Murugov
R-Alpha
4/1, Raspletina,
Moscow, 123060, Russian Federation
EMail: msm@top-cross.ru
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.netFull 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. So the writers still own their stuff, ngl 🫶
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 🔥
Okay, legal bit but make it cute. The IETF takes no position on whether any Intellectual Property Rights (or other rights) that someone might claim over the tech in this document are valid, how far they reach, or whether any license for them is actually available. It also doesn't claim to have done any independent digging to find such rights. 🕵️♀️ For the procedures around rights in RFC documents, check out BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses that might be offered, or the results of any attempt to get a general license or permission for implementers or users of this spec, can be found in the IETF online IPR repository at http://www.ietf.org/ipr. 📂
The IETF invites anyone to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 📬
Acknowledgement 🎀
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Thank you, IASA, you're literally keeping the lights on ✨
And that's a wrap on RFC 4490! 🌈🦋💖
📦 where this page comes from
- ietf: rfc4490 2006-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms