idnits 2.17.1 draft-ietf-pkix-gost-cppk-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 829. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 853. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 859. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 17, 2006) is 6673 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'GOSTR3411' is mentioned on line 134, but not defined == Unused Reference: 'GOST28147' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'GOSTR341194' is defined on line 705, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GOST28147' -- Possible downref: Non-RFC (?) normative reference: ref. 'GOSTR341094' -- Possible downref: Non-RFC (?) normative reference: ref. 'GOSTR341001' -- Possible downref: Non-RFC (?) normative reference: ref. 'GOSTR341194' ** Downref: Normative reference to an Informational RFC: RFC 4357 (ref. 'CPALGS') ** Obsolete normative reference: RFC 3280 (ref. 'PROFILE') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group Serguei Leontiev, CRYPTO-PRO 3 Internet Draft Dennis Shefanovski, DEMOS Co Ltd 4 Expires July 17, 2006 January 17, 2006 5 Intended Category: Standards Track 7 Using the GOST R 34.10-94, GOST R 34.10-2001 and 8 GOST R 34.11-94 algorithms with the 9 Internet X.509 Public Key Infrastructure 10 Certificate and CRL Profile. 12 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 17, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document supplements RFC 3279. It describes encoding formats, 46 identifiers and parameter formats for the algorithms GOST R 34.10-94, 47 GOST R 34.10-2001 and GOST R 34.11-94 for use in Internet X.509 48 Public Key Infrastructure (PKI). 50 Table of Contents 52 1. Introduction............................................... 2 53 2. Algorithm Support.......................................... 3 54 2.1. One-way Hash Function................................. 3 55 2.1.1. One-way Hash Function GOST R 34.11-94............ 3 56 2.2. Signature Algorithms.................................. 3 57 2.2.1. Signature Algorithm GOST R 34.10-94.............. 4 58 2.2.2. Signature Algorithm GOST R 34.10-2001............ 4 59 2.3. Subject Public Key Algorithms......................... 5 60 2.3.1. GOST R 34.10-94 Keys............................. 5 61 2.3.2. GOST R 34.10-2001 Keys........................... 7 62 3. Security Considerations.................................... 8 63 4. Appendix Examples.......................................... 9 64 4.1. GOST R 34.10-94 Certificate........................... 9 65 4.2. GOST R 34.10-2001 Certificate......................... 11 66 5. IANA Considerations........................................ 14 67 6. Acknowledgments............................................ 14 68 7. References................................................. 15 69 7.1. Normative References.................................. 15 70 7.2. Informative References................................ 16 71 Contact Information........................................... 16 72 Full Copyright Statement...................................... 18 74 1. Introduction 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 This document supplements RFC 3279 [PKALGS]. It describes the 81 conventions for using the GOST R 34.10-94 and GOST R 34.10-2001 82 signature algorithms, VKO GOST R 34.10-94 and VKO GOST R 34.10-2001 83 key derivation algorithms, and GOST R 34.11-94 one-way hash function 84 in the Internet X.509 Public Key Infrastructure (PKI) [PROFILE]. 86 This document provides supplemental information and specifications 87 needed by the "Russian Cryptographic Software Compatibility 88 Agreement" community. 90 The algorithm identifiers and associated parameters for subject 91 public keys that employ the GOST R 34.10-94 [GOSTR341094] / VKO GOST 92 R 34.10-94 [CPALGS] or the GOST R 34.10-2001 [GOSTR341001] / VKO GOST 93 R 34.10-2001 [CPALGS] algorithms, and the encoding format for the 94 signatures produced by these algorithms are specified. Also, the 95 algorithm identifiers for using the GOST R 34.11-94 one-way hash 96 function with the GOST R 34.10-94 and GOST R 34.10-2001 signature 97 algorithms are specified. 99 This specification defines the contents of the signatureAlgorithm, 100 signatureValue, signature, and subjectPublicKeyInfo fields within 101 X.509 Certificates and CRLs. For each algorithm, the appropriate 102 alternatives for the keyUsage certificate extension are provided. 104 ASN.1 modules, including all the definitions used in this document 105 can be found in [CPALGS]. 107 2. Algorithm Support 109 This section is an overview of cryptographic algorithms, that may be 110 used within the Internet X.509 certificates and CRL profile 111 [PROFILE]. It describes one-way hash functions and digital signature 112 algorithms, that may be used to sign certificates and CRLs, and 113 identifies OIDs and ASN.1 encoding for public keys contained in a 114 certificate. 116 CAs and/or applications conforming to this standard MUST support at 117 least one of the specified public key and signature algorithms. 119 2.1. One-way Hash Function 121 This section describes the use of a one-way, collision free hash 122 function GOST R 34.11-94 - the only one that can be used in digital 123 signature algorithms GOST R 34.10-94/2001. The data that is hashed 124 for certificates and CRL signing is fully described in RFC 3280 125 [PROFILE]. 127 2.1.1 One-way Hash Function GOST R 34.11-94 129 GOST R 34.11-94 has been developed by "GUBS of Federal Agency 130 Government Communication and Information" and "All-Russian Scientific 131 and Research Institute of Standardization". The algorithm GOST R 132 34.11-94 produces a 256-bit hash value of an arbitrary finite bit 133 length input. This document does not contain the full GOST R 34.11-94 134 specification, which can be found in [GOSTR3411] (in Russian). 135 [Schneier95] ch. 18.11, p. 454. contains a brief technical 136 description in English. 138 This function MUST always be used with parameter set identified by 139 id-GostR3411-94-CryptoProParamSet (see section 8.2 of [CPALGS]). 141 2.2. Signature Algorithms 143 Conforming CAs may use GOST R 34.10-94 or GOST R 34.10-2001 signature 144 algorithms to sign certificates and CRLs. 146 These signature algorithms MUST always be used with a one-way hash 147 function GOST R 34.11-94 as indicated in [GOSTR341094] and 148 [GOSTR341001]. 150 This section defines algorithm identifiers and parameters to be used 151 in the signatureAlgorithm field in a Certificate or CertificateList. 153 2.2.1. Signature Algorithm GOST R 34.10-94 155 GOST R 34.10-94 has been developed by "GUBS of Federal Agency 156 Government Communication and Information" and "All-Russian Scientific 157 and Research Institute of Standardization". This document does not 158 contain the full GOST R 34.10-94 specification, which can be found in 159 [GOSTR341094] (in Russian). [Schneier95] ch. 20.3, p. 495 contains a 160 brief technical description in English. 162 The ASN.1 object identifier used to identify this signature algorithm 163 is: 165 id-GostR3411-94-with-GostR3410-94 OBJECT IDENTIFIER ::= 166 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 167 gostR3411-94-with-gostR3410-94(4) } 169 When the id-GostR3411-94-with-GostR3410-94 algorithm identifier 170 appears as the algorithm field in an AlgorithmIdentifier, the 171 encoding SHALL omit the parameters field. That is, the 172 AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OBJECT 173 IDENTIFIER id-GostR3411-94-with-GostR3410-94. 175 Signature algorithm GOST R 34.10-94 generates a digital signature in 176 the form of two 256-bit numbers r' and s. Its octet string 177 representation consists of 64 octets, where first 32 octets contain 178 the big endian representation of s and second 32 octets contain the 179 big endian representation of r'. 181 This definition of a signature value is directly usable in CMS [CMS], 182 where such values are represented as octet strings. However, 183 signature values in certificates and CRLs [PROFILE] are represented 184 as bit strings, and thus the octet string representation must be 185 converted. 187 To convert an octet string signature value to a bit string, the most 188 significant bit of the first octet of the signature value SHALL 189 become the first bit of the bit string, and so on through the least 190 significant bit of the last octet of the signature value, which SHALL 191 become the last bit of the bit string. 193 2.2.2. Signature Algorithm GOST R 34.10-2001 194 GOST R 34.10-2001 was developed by "GUBS of Federal Agency Government 195 Communication and Information" and "All-Russian Scientific and 196 Research Institute of Standardization". This document does not 197 contain the full GOST R 34.10-2001 specification, which can be found 198 in [GOSTR341001] (in Russian). 200 The ASN.1 object identifier used to identify this signature algorithm 201 is: 203 id-GostR3411-94-with-GostR3410-2001 OBJECT IDENTIFIER ::= 204 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 205 gostR3411-94-with-gostR3410-2001(3) } 207 When the id-GostR3411-94-with-GostR3410-2001 algorithm identifier 208 appears as the algorithm field in an AlgorithmIdentifier, the 209 encoding SHALL omit the parameters field. That is, the 210 AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OBJECT 211 IDENTIFIER id-GostR3411-94-with-GostR3410-2001. 213 Signature algorithm GOST R 34.10-2001 generates a digital signature 214 in the form of two 256-bit numbers r' and s. Its octet string 215 representation consists of 64 octets, where first 32 octets contain 216 the big endian representation of s and second 32 octets contain the 217 big endian representation of r'. 219 The process decribed above (Section 2.2.10) MUST be used to convert 220 this octet string representation to a bit string for use in 221 certificates and CRLs. 223 2.3. Subject Public Key Algorithms 225 This section defines OIDs and public key parameters for public keys 226 that employ the GOST R 34.10-94 [GOSTR341094] / VKO GOST R 34.10-94 227 [CPALGS] or the GOST R 34.10-2001 [GOSTR341001] / VKO GOST R 228 34.10-2001 [CPALGS] algorithms. 230 Use of the same key for both signature and key derivation is NOT 231 RECOMMENDED. The intended application for the key MAY be indicated in 232 the keyUsage certificate extension (see [PROFILE], Section 4.2.1.3). 234 2.3.1. GOST R 34.10-94 Keys 236 GOST R 34.10-94 public keys can be used for signature algorithm GOST 237 R 34.10-94 [GOSTR341094] and for key derivation algorithm VKO GOST R 238 34.10-94 [CPALGS]. 240 GOST R 34.10-94 public keys are identified by the following OID: 242 id-GostR3410-94 OBJECT IDENTIFIER ::= 243 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 244 gostR3410-94(20) } 246 The SubjectPublicKeyInfo.algorithm.algorithm field (see RFC 3280 247 [PROFILE]) for GOST R 34.10-94 keys MUST be set to id-GostR3410-94. 249 When the id-GostR3410-94 algorithm identifier appears as the 250 algorithm field in an AlgorithmIdentifier, the encoding MAY omit the 251 parameters field or set it to NULL. Otherwise this field MUST have 252 the following structure: 254 GostR3410-94-PublicKeyParameters ::= 255 SEQUENCE { 256 publicKeyParamSet 257 OBJECT IDENTIFIER, 258 digestParamSet 259 OBJECT IDENTIFIER, 260 encryptionParamSet 261 OBJECT IDENTIFIER DEFAULT 262 id-Gost28147-89-CryptoPro-A-ParamSet 263 } 265 where: 266 * publicKeyParamSet - public key parameters identifier for GOST R 267 34.10-94 (see section 8.3 of [CPALGS]) 268 * digestParamSet - parameters identifier for GOST R 34.11-94 (see 269 section 8.2 of [CPALGS]) 270 * encryptionParamSet - parameters identifier for GOST 28147-89 (see 271 section 8.1 of [CPALGS]) 273 Absence of parameters SHALL be processed as described in RFC 3280 274 [PROFILE], section 6.1, that is, parameters are inherited from the 275 issuer certificate. When the working_public_key_parameters variable 276 is set to null, any signature SHALL be rejected. 278 The GOST R 34.10-94 public key MUST be ASN.1 DER encoded as an OCTET 279 STRING; this encoding shall be used as the contents (i.e., the value) 280 of the subjectPublicKey component (a BIT STRING) of the 281 SubjectPublicKeyInfo data element. 283 GostR3410-94-PublicKey ::= OCTET STRING -- public key, Y 285 GostR3410-94-PublicKey MUST contain 128 octets of the little-endian 286 representation of the public key Y = a^x (mod p), where a and p are 287 public key parameters, and x is a private key. 289 If the keyUsage extension is present in an end-entity certificate 290 that contains a GOST R 34.10-94 public key, the following values MAY 291 be present: 293 digitalSignature; 294 nonRepudiation; 295 keyEncipherment; and 296 keyAgreement. 298 If the keyAgreement or keyEnchiperment extension is present in a 299 certificate GOST R 34.10-94 public key, the following values MAY be 300 present as well: 302 encipherOnly; and 303 decipherOnly. 305 The keyUsage extension MUST NOT assert both encipherOnly and 306 decipherOnly. 308 If the keyUsage extension is present in an CA or CRL signer 309 certificate which contains a GOST R 34.10-94 public key, the 310 following values MAY be present: 312 digitalSignature; 313 nonRepudiation; 314 keyCertSign; and 315 cRLSign. 317 2.3.2. GOST R 34.10-2001 Keys 319 GOST R 34.10-2001 public keys can be used for signature algorithm 320 GOST R 34.10-2001 [GOSTR341001] and for key derivation algorithm VKO 321 GOST R 34.10-2001 [CPALGS]. 323 GOST R 34.10-2001 public keys are identified by the following OID: 325 id-GostR3410-2001 OBJECT IDENTIFIER ::= 326 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 327 gostR3410-2001(19) } 329 The SubjectPublicKeyInfo.algorithm.algorithm field (see RFC 3280 330 [PROFILE]) for GOST R 34.10-2001 keys MUST be set to id- 331 GostR3410-2001. 333 When the id-GostR3410-2001 algorithm identifier appears as the 334 algorithm field in an AlgorithmIdentifier, the encoding MAY omit the 335 parameters field or set it to NULL. Otherwise this field MUST have 336 the following structure: 338 GostR3410-2001-PublicKeyParameters ::= 339 SEQUENCE { 340 publicKeyParamSet 341 OBJECT IDENTIFIER, 342 digestParamSet 343 OBJECT IDENTIFIER, 344 encryptionParamSet 345 OBJECT IDENTIFIER DEFAULT 346 id-Gost28147-89-CryptoPro-A-ParamSet 347 } 349 where: 350 * publicKeyParamSet - public key parameters identifier for GOST R 351 34.10-2001 (see section 8.4 of [CPALGS]) 352 * digestParamSet - parameters identifier for GOST R 34.11-94 (see 353 section 8.2 of [CPALGS]) 354 * encryptionParamSet - parameters identifier for GOST 28147-89 (see 355 section 8.1 of [CPALGS]) 357 Absence of parameters SHALL be processed as described in RFC 3280 358 [PROFILE], section 6.1, that is, parameters are inherited from the 359 issuer certificate. When the working_public_key_parameters variable 360 is set to null, any signature SHALL be rejected. 362 The GOST R 34.10-2001 public key MUST be ASN.1 DER encoded as an 363 OCTET STRING; this encoding shall be used as the contents (i.e., the 364 value) of the subjectPublicKey component (a BIT STRING) of the 365 SubjectPublicKeyInfo data element. 367 GostR3410-2001-PublicKey ::= OCTET STRING -- public key vector, Q 369 According to [GOSTR341001], a public key is a point on the elliptic 370 curve Q = (x,y). 372 GostR3410-2001-PublicKey MUST contain 64 octets, where first 32 373 octets contain little endian representation of x and second 32 octets 374 contain little endian representation of y. This corresponds to the 375 binary representation of (256||256) from [GOSTR341001], ch. 376 5.3. 378 The same keyUsage constraints apply for use of GOST R 34.10-2001 keys 379 as described in Section 2.3.1 for GOST R 34.10-94 keys. 381 3. Security Considerations 383 It is RECOMMENDED, that applications verify signature values and 384 subject public keys to conform to [GOSTR341001] [GOSTR341094] 385 standards prior to their use. 387 When a certificate is used to support digital signatures as an 388 analogue to manual ("wet") signatures, in the context of Russian 389 Federal Digital Signature Law [RFDSL], the certificate MUST contain 390 keyUsage extension, it MUST be critical, and keyUsage MUST NOT 391 include keyEncipherment and keyAgreement. 393 It is RECOMMENDED, that CAs and applications make sure that the 394 private key is not used for more than it's allowed validity period 395 (typically 15 months for both GOST R 34.10-94 and GOST R 34.10-2001 396 algorithms). 398 For security discussion concerning use of algorithm parameters, see 399 section Security Considerations from [CPALGS]. 401 4. Appendix Examples 403 4.1. GOST R 34.10-94 Certificate 405 -----BEGIN CERTIFICATE----- 406 MIICCzCCAboCECMO42BGlSTOxwvklBgufuswCAYGKoUDAgIEMGkxHTAbBgNVBAMM 407 FEdvc3RSMzQxMC05NCBleGFtcGxlMRIwEAYDVQQKDAlDcnlwdG9Qcm8xCzAJBgNV 408 BAYTAlJVMScwJQYJKoZIhvcNAQkBFhhHb3N0UjM0MTAtOTRAZXhhbXBsZS5jb20w 409 HhcNMDUwODE2MTIzMjUwWhcNMTUwODE2MTIzMjUwWjBpMR0wGwYDVQQDDBRHb3N0 410 UjM0MTAtOTQgZXhhbXBsZTESMBAGA1UECgwJQ3J5cHRvUHJvMQswCQYDVQQGEwJS 411 VTEnMCUGCSqGSIb3DQEJARYYR29zdFIzNDEwLTk0QGV4YW1wbGUuY29tMIGlMBwG 412 BiqFAwICFDASBgcqhQMCAiACBgcqhQMCAh4BA4GEAASBgLuEZuF5nls02CyAfxOo 413 GWZxV/6MVCUhR28wCyd3RpjG+0dVvrey85NsObVCNyaE4g0QiiQOHwxCTSs7ESuo 414 v2Y5MlyUi8Go/htjEvYJJYfMdRv05YmKCYJo01x3pg+2kBATjeM+fJyR1qwNCCw+ 415 eMG1wra3Gqgqi0WBkzIydvp7MAgGBiqFAwICBANBABHHCH4S3ALxAiMpR3aPRyqB 416 g1DjB8zy5DEjiULIc+HeIveF81W9lOxGkZxnrFjXBSqnjLeFKgF1hffXOAP7zUM= 417 -----END CERTIFICATE----- 419 0 30 523: SEQUENCE { 420 4 30 442: SEQUENCE { 421 8 02 16: INTEGER 422 : 23 0E E3 60 46 95 24 CE C7 0B E4 94 18 2E 7E EB 423 26 30 8: SEQUENCE { 424 28 06 6: OBJECT IDENTIFIER 425 : id-GostR3411-94-with-GostR3410-94 (1 2 643 2 2 4) 426 : } 427 36 30 105: SEQUENCE { 428 38 31 29: SET { 429 40 30 27: SEQUENCE { 430 42 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 431 47 0C 20: UTF8String 'GostR3410-94 example' 432 : } 433 : } 434 69 31 18: SET { 435 71 30 16: SEQUENCE { 436 73 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 437 78 0C 9: UTF8String 'CryptoPro' 438 : } 439 : } 440 89 31 11: SET { 441 91 30 9: SEQUENCE { 442 93 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 443 98 13 2: PrintableString 'RU' 444 : } 445 : } 446 102 31 39: SET { 447 104 30 37: SEQUENCE { 448 106 06 9: OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1) 449 117 16 24: IA5String 'GostR3410-94@example.com' 450 : } 451 : } 452 : } 453 143 30 30: SEQUENCE { 454 145 17 13: UTCTime '050816123250Z' 455 160 17 13: UTCTime '150816123250Z' 456 : } 457 175 30 105: SEQUENCE { 458 177 31 29: SET { 459 179 30 27: SEQUENCE { 460 181 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 461 186 0C 20: UTF8String 'GostR3410-94 example' 462 : } 463 : } 464 208 31 18: SET { 465 210 30 16: SEQUENCE { 466 212 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 467 217 0C 9: UTF8String 'CryptoPro' 468 : } 469 : } 470 228 31 11: SET { 471 230 30 9: SEQUENCE { 472 232 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 473 237 13 2: PrintableString 'RU' 474 : } 475 : } 476 241 31 39: SET { 477 243 30 37: SEQUENCE { 478 245 06 9: OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1) 479 256 16 24: IA5String 'GostR3410-94@example.com' 480 : } 481 : } 482 : } 484 282 30 165: SEQUENCE { 485 285 30 28: SEQUENCE { 486 287 06 6: OBJECT IDENTIFIER id-GostR3410-94 (1 2 643 2 2 20) 487 295 30 18: SEQUENCE { 488 297 06 7: OBJECT IDENTIFIER 489 : id-GostR3410-94-CryptoPro-A-ParamSet 490 : (1 2 643 2 2 32 2) 491 306 06 7: OBJECT IDENTIFIER 492 : id-GostR3411-94-CryptoProParamSet 493 : (1 2 643 2 2 30 1) 494 : } 495 : } 496 315 03 132: BIT STRING 0 unused bits, encapsulates { 497 319 04 128: OCTET STRING 498 : BB 84 66 E1 79 9E 5B 34 D8 2C 80 7F 13 A8 19 66 499 : 71 57 FE 8C 54 25 21 47 6F 30 0B 27 77 46 98 C6 500 : FB 47 55 BE B7 B2 F3 93 6C 39 B5 42 37 26 84 E2 501 : 0D 10 8A 24 0E 1F 0C 42 4D 2B 3B 11 2B A8 BF 66 502 : 39 32 5C 94 8B C1 A8 FE 1B 63 12 F6 09 25 87 CC 503 : 75 1B F4 E5 89 8A 09 82 68 D3 5C 77 A6 0F B6 90 504 : 10 13 8D E3 3E 7C 9C 91 D6 AC 0D 08 2C 3E 78 C1 505 : B5 C2 B6 B7 1A A8 2A 8B 45 81 93 32 32 76 FA 7B 506 : } 507 : } 508 : } 509 450 30 8: SEQUENCE { 510 452 06 6: OBJECT IDENTIFIER 511 : id-GostR3411-94-with-GostR3410-94 (1 2 643 2 2 4) 512 : } 513 460 03 65: BIT STRING 0 unused bits 514 : 11 C7 08 7E 12 DC 02 F1 02 23 29 47 76 8F 47 2A 515 : 81 83 50 E3 07 CC F2 E4 31 23 89 42 C8 73 E1 DE 516 : 22 F7 85 F3 55 BD 94 EC 46 91 9C 67 AC 58 D7 05 517 : 2A A7 8C B7 85 2A 01 75 85 F7 D7 38 03 FB CD 43 518 : } 520 In the signature of the above certificate, r' equals to 521 0x22F785F355BD94EC46919C67AC58D7052AA78CB7852A017585F7D73803FBCD43 522 and s equals to 523 0x11C7087E12DC02F102232947768F472A818350E307CCF2E431238942C873E1DE 525 4.2. GOST R 34.10-2001 Certificate 527 -----BEGIN CERTIFICATE----- 528 MIIB0DCCAX8CECv1xh7CEb0Xx9zUYma0LiEwCAYGKoUDAgIDMG0xHzAdBgNVBAMM 529 Fkdvc3RSMzQxMC0yMDAxIGV4YW1wbGUxEjAQBgNVBAoMCUNyeXB0b1BybzELMAkG 530 A1UEBhMCUlUxKTAnBgkqhkiG9w0BCQEWGkdvc3RSMzQxMC0yMDAxQGV4YW1wbGUu 531 Y29tMB4XDTA1MDgxNjE0MTgyMFoXDTE1MDgxNjE0MTgyMFowbTEfMB0GA1UEAwwW 532 R29zdFIzNDEwLTIwMDEgZXhhbXBsZTESMBAGA1UECgwJQ3J5cHRvUHJvMQswCQYD 533 VQQGEwJSVTEpMCcGCSqGSIb3DQEJARYaR29zdFIzNDEwLTIwMDFAZXhhbXBsZS5j 534 b20wYzAcBgYqhQMCAhMwEgYHKoUDAgIkAAYHKoUDAgIeAQNDAARAhJVodWACGkB1 535 CM0TjDGJLP3lBQN6Q1z0bSsP508yfleP68wWuZWIA9CafIWuD+SN6qa7flbHy7Df 536 D2a8yuoaYDAIBgYqhQMCAgMDQQA8L8kJRLcnqeyn1en7U23Sw6pkfEQu3u0xFkVP 537 vFQ/3cHeF26NG+xxtZPz3TaTVXdoiYkXYiD02rEx1bUcM97i 538 -----END CERTIFICATE----- 540 0 30 464: SEQUENCE { 541 4 30 383: SEQUENCE { 542 8 02 16: INTEGER 543 : 2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21 544 26 30 8: SEQUENCE { 545 28 06 6: OBJECT IDENTIFIER 546 : id-GostR3411-94-with-GostR3410-2001 (1 2 643 2 2 3) 547 : } 548 36 30 109: SEQUENCE { 549 38 31 31: SET { 550 40 30 29: SEQUENCE { 551 42 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 552 47 0C 22: UTF8String 'GostR3410-2001 example' 553 : } 554 : } 555 71 31 18: SET { 556 73 30 16: SEQUENCE { 557 75 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 558 80 0C 9: UTF8String 'CryptoPro' 559 : } 560 : } 561 91 31 11: SET { 562 93 30 9: SEQUENCE { 563 95 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 564 100 13 2: PrintableString 'RU' 565 : } 566 : } 567 104 31 41: SET { 568 106 30 39: SEQUENCE { 569 108 06 9: OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1) 570 119 16 26: IA5String 'GostR3410-2001@example.com' 571 : } 572 : } 573 : } 574 147 30 30: SEQUENCE { 575 149 17 13: UTCTime '050816141820Z' 576 164 17 13: UTCTime '150816141820Z' 577 : } 578 179 30 109: SEQUENCE { 579 181 31 31: SET { 580 183 30 29: SEQUENCE { 581 185 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 582 190 0C 22: UTF8String 'GostR3410-2001 example' 583 : } 584 : } 585 214 31 18: SET { 586 216 30 16: SEQUENCE { 587 218 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 588 223 0C 9: UTF8String 'CryptoPro' 589 : } 590 : } 591 234 31 11: SET { 592 236 30 9: SEQUENCE { 593 238 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 594 243 13 2: PrintableString 'RU' 595 : } 596 : } 597 247 31 41: SET { 598 249 30 39: SEQUENCE { 599 251 06 9: OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1) 600 262 16 26: IA5String 'GostR3410-2001@example.com' 601 : } 602 : } 603 : } 604 290 30 99: SEQUENCE { 605 292 30 28: SEQUENCE { 606 294 06 6: OBJECT IDENTIFIER id-GostR3410-2001 (1 2 643 2 2 19) 607 302 30 18: SEQUENCE { 608 304 06 7: OBJECT IDENTIFIER 609 : id-GostR3410-2001-CryptoPro-XchA-ParamSet 610 : (1 2 643 2 2 36 0) 611 313 06 7: OBJECT IDENTIFIER 612 : id-GostR3411-94-CryptoProParamSet 613 : (1 2 643 2 2 30 1) 614 : } 615 : } 616 322 03 67: BIT STRING 0 unused bits, encapsulates { 617 325 04 64: OCTET STRING 618 : 84 95 68 75 60 02 1A 40 75 08 CD 13 8C 31 89 2C 619 : FD E5 05 03 7A 43 5C F4 6D 2B 0F E7 4F 32 7E 57 620 : 8F EB CC 16 B9 95 88 03 D0 9A 7C 85 AE 0F E4 8D 621 : EA A6 BB 7E 56 C7 CB B0 DF 0F 66 BC CA EA 1A 60 622 : } 623 : } 624 : } 625 391 30 8: SEQUENCE { 626 393 06 6: OBJECT IDENTIFIER 627 : id-GostR3411-94-with-GostR3410-2001 (1 2 643 2 2 3) 628 : } 629 401 03 65: BIT STRING 0 unused bits 630 : 3C 2F C9 09 44 B7 27 A9 EC A7 D5 E9 FB 53 6D D2 631 : C3 AA 64 7C 44 2E DE ED 31 16 45 4F BC 54 3F DD 632 : C1 DE 17 6E 8D 1B EC 71 B5 93 F3 DD 36 93 55 77 633 : 68 89 89 17 62 20 F4 DA B1 31 D5 B5 1C 33 DE E2 634 : } 636 In the public key of the above certificate, x equals to 637 0x577E324FE70F2B6DF45C437A0305E5FD2C89318C13CD0875401A026075689584 638 and y equals to 639 0x601AEACABC660FDFB0CBC7567EBBA6EA8DE40FAE857C9AD0038895B916CCEB8F 640 Corresponding private key d equals to 641 0x0B293BE050D0082BDAE785631A6BAB68F35B42786D6DDA56AFAF169891040F77 643 In the signature of the above certificate, r' equals to 644 0xC1DE176E8D1BEC71B593F3DD36935577688989176220F4DAB131D5B51C33DEE2 645 and s equals to 646 0x3C2FC90944B727A9ECA7D5E9FB536DD2C3AA647C442EDEED3116454FBC543FDD 648 5. IANA Considerations 650 No IANA actions are necessary. 652 6. Acknowledgments 654 This document was created in accordance with "Russian Cryptographic 655 Software Compatibility Agreement", signed by FGUE STC "Atlas", 656 CRYPTO-PRO, Factor-TS, MD PREI, Infotecs GmbH, SPRCIS (SPbRCZI), 657 Cryptocom, R-Alpha. The goal of this agreement is to achieve mutual 658 compatibility of the products and solutions. 660 The authors wish to thank the following: 662 Microsoft Corporation Russia for providing information about 663 company products and solutions, and also for technical consulting 664 in PKI. 666 RSA Security Russia and Demos Co Ltd for active collaboration and 667 critical help in creation of this document. 669 RSA Security Inc for compatibility testing of the proposed data 670 formats while incorporating them into the RSA Keon product. 672 Baltimore Technology plc for compatibility testing of the proposed 673 data formats while incorporating them into their UniCERT product. 675 Peter Gutmann for his helpful "dumpasn1" program. 677 Russ Hously (Vigil Security, LLC, housley@vigilsec.com) and 678 Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru) for encouraging the 679 authors to create this document. 681 Grigorij Chudov for navigating the IETF process for this document. 683 7. References 685 7.1. Normative references 687 [GOST28147] "Cryptographic Protection for Data Processing System", 688 GOST 28147-89, Gosudarstvennyi Standard of USSR, Gov- 689 ernment Committee of the USSR for Standards, 1989. (In 690 Russian) 692 [GOSTR341094] "Information technology. Cryptographic Data Security. 693 Produce and check procedures of Electronic Digital Sig- 694 natures based on Asymmetric Cryptographic Algorithm.", 695 GOST R 34.10-94, Gosudarstvennyi Standard of Russian 696 Federation, Government Committee of the Russia for 697 Standards, 1994. (In Russian) 699 [GOSTR341001] "Information technology. Cryptographic data security. 700 Signature and verification processes of [electronic] 701 digital signature.", GOST R 34.10-2001, Gosudarstvennyi 702 Standard of Russian Federation, Government Committee of 703 the Russia for Standards, 2001. (In Russian) 705 [GOSTR341194] "Information technology. Cryptographic Data Security. 706 Hashing function.", GOST R 34.10-94, Gosudarstvennyi 707 Standard of Russian Federation, Government Committee of 708 the Russia for Standards, 1994. (In Russian) 710 [CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, "Additional 711 Cryptographic Algorithms for Use with GOST 28147-89, 712 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 713 Algorithms", RFC 4357, January 2006. 715 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Inter- 716 net X.509 Public Key Infrastructure Certificate and 717 Certificate Revocation List (CRL) Profile", RFC 3280, 718 April 2002. 720 [PKALGS] L. Bassham, W. Polk, R. Housley, "Algorithms and 721 Identifiers for the Internet X.509 Public Key Infras- 722 tructure Certificate and Certificate Revocation List 723 (CRL) Profile", RFC 3279, April 2002. 725 [X.660] ITU-T Recommendation X.660 Information Technology - 726 ASN.1 encoding rules: Specification of Basic Encoding 727 Rules (BER), Canonical Encoding Rules (CER) and Distin- 728 guished Encoding Rules (DER), 1997. 730 7.2. Informative references 732 [Schneier95] B. Schneier, Applied cryptography, second edition, John 733 Wiley & Sons, Inc., 1995. 735 [RFDSL] Russian Federal Digital Signature Law, 10 Jan 2002 N 736 1-FZ. 738 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, March 1997. 741 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 742 3852, July 2004. 744 Contact Information 746 Serguei Leontiev 747 CRYPTO-PRO 748 38, Obraztsova, 749 Moscow, 127018, Russian Federation 751 EMail: lse@cryptopro.ru 753 Dennis Shefanovski 754 DEMOS Co Ltd 755 6/1, Ovchinnikovskaja naberezhnaya, 756 Moscow, 113035, Russian Federation 758 EMail: sdb@dol.ru 760 Grigorij Chudov 761 CRYPTO-PRO 762 38, Obraztsova, 763 Moscow, 127018, Russian Federation 764 EMail: chudov@cryptopro.ru 766 Alexandr Afanasiev 767 Factor-TS 768 office 711, 14, Presnenskij val, 769 Moscow, 123557, Russian Federation 771 EMail: afa1@factor-ts.ru 773 Nikolaj Nikishin 774 Infotecs GmbH 775 p/b 35, 80-5, Leningradskij prospekt, 776 Moscow, 125315, Russian Federation 778 EMail: nikishin@infotecs.ru 780 Boleslav Izotov 781 FGUE STC "Atlas" 782 38, Obraztsova, 783 Moscow, 127018, Russian Federation 785 EMail: izotov@nii.voskhod.ru 787 Elena Minaeva 788 MD PREI 789 build 3, 6A, Vtoroj Troitskij per., 790 Moscow, Russian Federation 792 EMail: evminaeva@mail.ru 794 Igor Ovcharenko 795 MD PREI 796 Office 600, 14, B.Novodmitrovskaya, 797 Moscow, Russian Federation 799 EMail: igori@mo.msk.ru 801 Serguei Murugov 802 R-Alpha 803 4/1, Raspletina, 804 Moscow, 123060, Russian Federation 805 EMail: msm@top-cross.ru 807 Igor Ustinov 808 Cryptocom 809 office 239, 51, Leninskij prospekt, 810 Moscow, 119991, Russian Federation 812 EMail: igus@cryptocom.ru 814 Anatolij Erkin 815 SPRCIS (SPbRCZI) 816 1, Obrucheva, 817 St.Petersburg, 195220, Russian Federation 819 EMail: erkin@nevsky.net 821 Disclaimer of Validity 823 This document and the information contained herein are provided on an 824 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 825 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 826 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 827 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 828 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 829 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 831 Full Copyright Statement 833 Copyright (C) The Internet Society (2006). This document is subject 834 to the rights, licenses and restrictions contained in BCP 78, and 835 except as set forth therein, the authors retain all their rights. 837 Intellectual Property 839 The IETF takes no position regarding the validity or scope of any 840 Intellectual Property Rights or other rights that might be claimed to 841 pertain to the implementation or use of the technology described in 842 this document or the extent to which any license under such rights 843 might or might not be available; nor does it represent that it has 844 made any independent effort to identify any such rights. Information 845 on the ISOC's procedures with respect to rights in ISOC Documents can 846 be found in BCP 78 and BCP 79. 848 Copies of IPR disclosures made to the IETF Secretariat and any 849 assurances of licenses to be made available, or the result of an 850 attempt made to obtain a general license or permission for the use of 851 such proprietary rights by implementers or users of this 852 specification can be obtained from the IETF on-line IPR repository at 853 http://www.ietf.org/ipr. 855 The IETF invites any interested party to bring to its attention any 856 copyrights, patents or patent applications, or other proprietary 857 rights that may cover technology that may be required to implement 858 this standard. Please address the information to the IETF at ietf- 859 ipr@ietf.org. 861 Acknowledgment 863 Funding for the RFC Editor function is provided by the IETF 864 Administrative Support Activity (IASA).