idnits 2.17.1 draft-ietf-pkix-gost-cppk-03.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 842. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (September 8, 2005) is 6798 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GOSTR3411' is mentioned on line 133, but not defined == Unused Reference: 'GOST28147' is defined on line 680, but no explicit reference was found in the text == Unused Reference: 'GOSTR341194' is defined on line 698, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3280 (ref. 'PROFILE') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 4 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 March 8, 2006 September 8, 2005 5 Intended Category: Informational 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 a "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 March 8, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . 5 59 2.3 Subject Public Key Algorithms . . . . . . . . . . . . . 5 60 2.3.1 GOST R 34.10-94 Keys. . . . . . . . . . . . . . . . . . 6 61 2.3.2 GOST R 34.10-2001 Keys. . . . . . . . . . . . . . . . . 7 62 3 Security Considerations . . . . . . . . . . . . . . . . 9 63 4 Appendix Examples . . . . . . . . . . . . . . . . . . . 10 64 4.1 GOST R 34.10-94 Certificate . . . . . . . . . . . . . . 10 65 4.2 GOST R 34.10-2001 Certificate . . . . . . . . . . . . . 12 66 5 References. . . . . . . . . . . . . . . . . . . . . . . 15 67 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16 68 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 17 69 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 71 1 Introduction 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 This document supplements RFC 3279 [PKALGS]. It describes the 78 conventions for using the GOST R 34.10-94 and GOST R 34.10-2001 79 signature algorithms, VKO GOST R 34.10-94 and VKO GOST R 34.10-2001 80 key derivation algorithms, and GOST R 34.11-94 one-way hash function 81 in the Internet X.509 Public Key Infrastructure (PKI) [PROFILE]. 83 This document is a proposal put forward by the CRYPT-PRO Company to 84 provide supplemental information and specifications needed by the 85 "Russian Cryptographic Software Compatibility Agreement" community. 87 The algorithm identifiers and associated parameters for subject 88 public keys that employ the GOST R 34.10-94 [GOSTR341094] / VKO GOST 89 R 34.10-94 [CPALGS] or the GOST R 34.10-2001 [GOSTR341001] / VKO GOST 90 R 34.10-2001 [CPALGS] algorithms, and the encoding format for the 91 signatures produced by these algorithms are specified. Also, the 92 algorithm identifiers for using the GOST R 34.11-94 one-way hash 93 function with the GOST R 34.10-94 and GOST R 34.10-2001 signature 94 algorithms are specified. 96 This specification defines the contents of the signatureAlgorithm, 97 signatureValue, signature, and subjectPublicKeyInfo fields within 98 Internet X.509 Certificates and CRLs. For each algorithm, the 99 appropriate alternatives for the keyUsage certificate extension are 100 provided. 102 ASN.1 modules, including all the definitions used in this document 103 can be found in [CPALGS]. 105 2 Algorithm Support 107 This section is an overview of cryptographic algorithms, that may be 108 used within the Internet X.509 certificates and CRL profile 109 [PROFILE]. It describes one-way hash functions and digital signature 110 algorithms, that may be used to sign certificates and CRLs, and 111 identifies OIDs and ASN.1 encoding for public keys contained in a 112 certificate. 114 The conforming CAs and/or applications MUST fully support digital 115 signatures and public keys for at least one of the specified 116 algorithms. 118 2.1 One-way Hash Function 120 This section identifies the use of one-way, collision free hash 121 function GOST R 34.11-94 - the only one that can be used in digital 122 signature algorithms GOST R 34.10-94/2001. The data that is hashed 123 for certificates and CRL signing is fully described in RFC 3280 124 [PROFILE]. 126 2.1.1 One-way Hash Function GOST R 34.11-94 128 GOST R 34.11-94 has been developed by "GUBS of Federal Agency 129 Government Communication and Information" and "All-Russian Scientific 130 and Research Institute of Standardization". The algorithm GOST R 131 34.11-94 produces a 256-bit hash value of the arbitrary finite bit 132 length input. This document does not contain the full GOST R 34.11-94 133 specification, which can be found in [GOSTR3411] in Russian. 134 [Schneier95] ch. 18.11, p. 454. contains a brief technical 135 description in English. 137 This function MUST always be used with parameter set identified by 138 id-GostR3411-94-CryptoProParamSet (see section 8.2 of [CPALGS]). 140 2.2 Signature Algorithms 142 Conforming CAs may use GOST R 34.10-94 or GOST R 34.10-2001 signature 143 algorithms to sign certificates and CRLs. 145 These signature algorithms MUST always be used with a one-way hash 146 function GOST R 34.11-94 as indicated in [GOSTR341094] and 147 [GOSTR341001]. 149 This section defines algorithm identifiers and parameters to be used 150 in the signatureAlgorithm field in a Certificate or CertificateList. 152 2.2.1 Signature Algorithm GOST R 34.10-94 154 GOST R 34.10-94 has been developed by "GUBS of Federal Agency 155 Government Communication and Information" and "All-Russian Scientific 156 and Research Institute of Standardization". This document does not 157 contain the full GOST R 34.10-94 specification, which can be found in 158 [GOSTR341094] in Russian. [Schneier95] ch. 20.3, p. 495 contains a 159 brief technical description in English. 161 The ASN.1 object identifier used to identify this signature algorithm 162 is: 164 id-GostR3411-94-with-GostR3410-94 OBJECT IDENTIFIER ::= 165 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 166 gostR3411-94-with-gostR3410-94(4) } 168 When the id-GostR3411-94-with-GostR3410-94 algorithm identifier 169 appears as the algorithm field in an AlgorithmIdentifier, the 170 encoding SHALL omit the parameters field. That is, the 171 AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OBJECT 172 IDENTIFIER id-GostR3411-94-with-GostR3410-94. 174 The parameters in the subjectPublicKeyInfo field of the certificate 175 of the issuer SHALL apply to the verification of the signature. 177 Signature algorithm GOST R 34.10-94 generates digital signature in 178 the form of two 256-bit numbers r' and s. Its octet string 179 representation consists of 64 octets, where first 32 octets contain 180 big endian representation of s and second 32 octets contain big 181 endian representation of r'. 183 Signature values in CMS [CMS] are represented as octet strings, and 184 the output is used directly. However, signature values in 185 certificates and CRLs [PROFILE] are represented as bit strings, and 186 conversion is needed. 188 To convert a signature value to a bit string, the most significant 189 bit of the first octet of the signature value SHALL become the first 190 bit of the bit string, and so on through the least significant bit of 191 the last octet of the signature value, which SHALL become the last 192 bit of the bit string. 194 2.2.2 Signature Algorithm GOST R 34.10-2001 196 GOST R 34.10-2001 was developed by "GUBS of Federal Agency Government 197 Communication and Information" and "All-Russian Scientific and 198 Research Institute of Standardization". This document does not 199 contain the full GOST R 34.10-2001 specification, which can be found 200 in [GOSTR341001] in Russian. 202 The ASN.1 object identifier used to identify this signature algorithm 203 is: 205 id-GostR3411-94-with-GostR3410-2001 OBJECT IDENTIFIER ::= 206 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 207 gostR3411-94-with-gostR3410-2001(3) } 209 When the id-GostR3411-94-with-GostR3410-2001 algorithm identifier 210 appears as the algorithm field in an AlgorithmIdentifier, the 211 encoding SHALL omit the parameters field. That is, the 212 AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OBJECT 213 IDENTIFIER id-GostR3411-94-with-GostR3410-2001. 215 The parameters in the subjectPublicKeyInfo field of the certificate 216 of the issuer SHALL apply to the verification of the signature. 218 Signature algorithm GOST R 34.10-2001 generates digital signature in 219 the form of two 256-bit numbers r' and s. Its octet string 220 representation consists of 64 octets, where first 32 octets contain 221 big endian representation of s and second 32 octets contain big 222 endian representation of r'. 224 Signature values in CMS [CMS] are represented as octet strings, and 225 the output is used directly. However, signature values in 226 certificates and CRLs [PROFILE] are represented as bit strings, and 227 conversion is needed. 229 To convert a signature value to a bit string, the most significant 230 bit of the first octet of the signature value SHALL become the first 231 bit of the bit string, and so on through the least significant bit of 232 the last octet of the signature value, which SHALL become the last 233 bit of the bit string. 235 2.3 Subject Public Key Algorithms 237 This section defines OIDs and public key parameters for public keys 238 that employ the GOST R 34.10-94 [GOSTR341094] / VKO GOST R 34.10-94 239 [CPALGS] or the GOST R 34.10-2001 [GOSTR341001] / VKO GOST R 240 34.10-2001 [CPALGS] algorithms. 242 Use of the same key for both signature and key derivation is NOT 243 RECOMMENDED. The intended application for the key MAY be indicated in 244 the keyUsage certificate extension (see [PROFILE], Section 4.2.1.3). 246 2.3.1 GOST R 34.10-94 Keys 248 GOST R 34.10-94 public keys can be used for signature algorithm GOST 249 R 34.10-94 [GOSTR341094] and for key derivation algorithm VKO GOST R 250 34.10-94 [CPALGS]. 252 GOST R 34.10-94 public keys are identified by the following OID: 254 id-GostR3410-94 OBJECT IDENTIFIER ::= 255 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 256 gostR3410-94(20) } 258 SubjectPublicKeyInfo.algorithm.algorithm field (see RFC 3280 259 [PROFILE]) for GOST R 34.10-94 keys MUST be id-GostR3410-94. 261 When the id-GostR3410-94 algorithm identifier appears as the 262 algorithm field in an AlgorithmIdentifier, the encoding MAY 263 completely omit the parameters field or set it to null. Otherwise 264 this field MUST have the following structure: 266 GostR3410-94-PublicKeyParameters ::= 267 SEQUENCE { 268 publicKeyParamSet 269 OBJECT IDENTIFIER, 270 digestParamSet 271 OBJECT IDENTIFIER, 272 encryptionParamSet 273 OBJECT IDENTIFIER DEFAULT 274 id-Gost28147-89-CryptoPro-A-ParamSet 275 } 277 where: 278 * publicKeyParamSet - public key parameters identifier for GOST R 279 34.10-94 (see section 8.3 of [CPALGS]) 280 * digestParamSet - parameters identifier for GOST R 34.11-94 (see 281 section 8.2 of [CPALGS]) 282 * encryptionParamSet - parameters identifier for GOST 28147-89 (see 283 section 8.1 of [CPALGS]) 285 Absence of parameters SHALL be processed as described in RFC 3280 286 [PROFILE], section 6.1, that is, parameters are inherited from the 287 issuer certificate if possible. 289 The GOST R 34.10-94 public key MUST be ASN.1 DER encoded as an OCTET 290 STRING; this encoding shall be used as the contents (i.e., the value) 291 of the subjectPublicKey component (a BIT STRING) of the 292 SubjectPublicKeyInfo data element. 294 GostR3410-94-PublicKey ::= OCTET STRING -- public key, Y 296 GostR3410-94-PublicKey MUST must contain 128 octets of the little- 297 endian representation of the public key Y = a^x (mod p), where a and 298 p - parameters. 300 If the keyUsage extension is present in an end-entity certificate, 301 which contains a GOST R 34.10-94 public key, the following values MAY 302 be present: 304 digitalSignature; 305 nonRepudiation. 306 keyEncipherment; 307 keyAgreement. 309 If the keyAgreement or keyEnchiperment extension is present in a 310 certificate GOST R 34.10-94 public key, the following values MAY be 311 present as well: 313 encipherOnly; 314 decipherOnly. 316 The keyUsage extension MUST NOT assert both encipherOnly and 317 decipherOnly. 319 If the keyUsage extension is present in an CA or CRL signer 320 certificate which contains a GOST R 34.10-94 public key, the 321 following values MAY be present: 323 digitalSignature; 324 nonRepudiation; 325 keyCertSign; 326 cRLSign. 328 2.3.2 GOST R 34.10-2001 Keys 330 GOST R 34.10-2001 public keys can be used for signature algorithm 331 GOST R 34.10-2001 [GOSTR341001] and for key derivation algorithm VKO 332 GOST R 34.10-2001 [CPALGS]. 334 GOST R 34.10-2001 public keys are identified by the following OID: 336 id-GostR3410-2001 OBJECT IDENTIFIER ::= 337 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 338 gostR3410-2001(19) } 340 SubjectPublicKeyInfo.algorithm.algorithm field (see RFC 3280 341 [PROFILE]) for GOST R 34.10-2001 keys MUST be id-GostR3410-2001. 343 When the id-GostR3410-2001 algorithm identifier appears as the 344 algorithm field in an AlgorithmIdentifier, the encoding MAY 345 completely omit the parameters field or set it to null. Otherwise 346 this field MUST have the following structure: 348 GostR3410-2001-PublicKeyParameters ::= 349 SEQUENCE { 350 publicKeyParamSet 351 OBJECT IDENTIFIER, 352 digestParamSet 353 OBJECT IDENTIFIER, 354 encryptionParamSet 355 OBJECT IDENTIFIER DEFAULT 356 id-Gost28147-89-CryptoPro-A-ParamSet 357 } 359 where: 360 * publicKeyParamSet - public key parameters identifier for GOST R 361 34.10-2001 (see section 8.4 of [CPALGS]) 362 * digestParamSet - parameters identifier for GOST R 34.11-94 (see 363 section 8.2 of [CPALGS]) 364 * encryptionParamSet - parameters identifier for GOST 28147-89 (see 365 section 8.1 of [CPALGS]) 367 Absence of parameters SHALL be processed as described in RFC 3280 368 [PROFILE], section 6.1, that is, parameters are inherited from the 369 issuer certificate if possible. 371 The GOST R 34.10-2001 public key MUST be ASN.1 DER encoded as an 372 OCTET STRING; this encoding shall be used as the contents (i.e., the 373 value) of the subjectPublicKey component (a BIT STRING) of the 374 SubjectPublicKeyInfo data element. 376 GostR3410-2001-PublicKey ::= OCTET STRING -- public key vector, Q 378 According to [GOSTR341001], public key is a point on the elliptic 379 curve Q = (x,y). 381 GostR3410-2001-PublicKey MUST must contain 64 octets, where first 32 382 octets contain little endian representation of x and second 32 octets 383 contain little endian representation of y. This corresponds to the 384 binary representation of (256||256) from [GOSTR341001], ch. 385 5.3. 387 If the keyUsage extension is present in an end-entity certificate, 388 which contains a GOST R 34.10-2001 public key, the following values 389 MAY be present: 391 digitalSignature, 392 nonRepudiation, 393 keyEncipherment, 394 keyAgreement. 396 If the keyAgreement or keyEnchiperment extension is present in a 397 certificate, the following values MAY be present: 399 encipherOnly, 400 decipherOnly. 402 The keyUsage extension MUST NOT assert both encipherOnly and 403 decipherOnly. 405 If the keyUsage extension is present in an CA or CRL signer 406 certificate which contains a GOST R 34.10-2001 public key, the 407 following values MAY be present: 409 digitalSignature, 410 nonRepudiation, 411 keyCertSign, 412 cRLSign. 414 3 Security Considerations 416 It is RECOMMENDED, that applications verify signature values and 417 subject public keys to conform to [GOSTR341001] [GOSTR341094] 418 standards prior to their use. 420 When certificate is used as analogue to a manual signing, in the 421 context of Russian Federal Digital Signature Law [RFDSL], certificate 422 MUST contain keyUsage extension, it MUST be critical, and keyUsage 423 MUST NOT include keyEncipherment and keyAgreement. 425 When certificate validity period (typicaly 5 years for end entities 426 and 7 years for CAs in Russia) is not equal to the private key 427 validity period (typicaly 15 months in Russia) it is RECOMMENDED to 428 use private key usage period extension. 430 For security discussion concerning use of algorithm parameters, see 431 section Security Considerations from [CPALGS]. 433 4 Appendix Examples 434 4.1 GOST R 34.10-94 Certificate 436 -----BEGIN CERTIFICATE----- 437 MIICCzCCAboCECMO42BGlSTOxwvklBgufuswCAYGKoUDAgIEMGkxHTAbBgNVBAMM 438 FEdvc3RSMzQxMC05NCBleGFtcGxlMRIwEAYDVQQKDAlDcnlwdG9Qcm8xCzAJBgNV 439 BAYTAlJVMScwJQYJKoZIhvcNAQkBFhhHb3N0UjM0MTAtOTRAZXhhbXBsZS5jb20w 440 HhcNMDUwODE2MTIzMjUwWhcNMTUwODE2MTIzMjUwWjBpMR0wGwYDVQQDDBRHb3N0 441 UjM0MTAtOTQgZXhhbXBsZTESMBAGA1UECgwJQ3J5cHRvUHJvMQswCQYDVQQGEwJS 442 VTEnMCUGCSqGSIb3DQEJARYYR29zdFIzNDEwLTk0QGV4YW1wbGUuY29tMIGlMBwG 443 BiqFAwICFDASBgcqhQMCAiACBgcqhQMCAh4BA4GEAASBgLuEZuF5nls02CyAfxOo 444 GWZxV/6MVCUhR28wCyd3RpjG+0dVvrey85NsObVCNyaE4g0QiiQOHwxCTSs7ESuo 445 v2Y5MlyUi8Go/htjEvYJJYfMdRv05YmKCYJo01x3pg+2kBATjeM+fJyR1qwNCCw+ 446 eMG1wra3Gqgqi0WBkzIydvp7MAgGBiqFAwICBANBABHHCH4S3ALxAiMpR3aPRyqB 447 g1DjB8zy5DEjiULIc+HeIveF81W9lOxGkZxnrFjXBSqnjLeFKgF1hffXOAP7zUM= 448 -----END CERTIFICATE----- 450 0 30 523: SEQUENCE { 451 4 30 442: SEQUENCE { 452 8 02 16: INTEGER 453 : 23 0E E3 60 46 95 24 CE C7 0B E4 94 18 2E 7E EB 454 26 30 8: SEQUENCE { 455 28 06 6: OBJECT IDENTIFIER 456 : id-GostR3411-94-with-GostR3410-94 (1 2 643 2 2 4) 457 : } 458 36 30 105: SEQUENCE { 459 38 31 29: SET { 460 40 30 27: SEQUENCE { 461 42 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 462 47 0C 20: UTF8String 'GostR3410-94 example' 463 : } 464 : } 465 69 31 18: SET { 466 71 30 16: SEQUENCE { 467 73 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 468 78 0C 9: UTF8String 'CryptoPro' 469 : } 470 : } 471 89 31 11: SET { 472 91 30 9: SEQUENCE { 473 93 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 474 98 13 2: PrintableString 'RU' 475 : } 476 : } 477 102 31 39: SET { 478 104 30 37: SEQUENCE { 479 106 06 9: OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1) 480 117 16 24: IA5String 'GostR3410-94@example.com' 481 : } 482 : } 483 : } 484 143 30 30: SEQUENCE { 485 145 17 13: UTCTime '050816123250Z' 486 160 17 13: UTCTime '150816123250Z' 487 : } 488 175 30 105: SEQUENCE { 489 177 31 29: SET { 490 179 30 27: SEQUENCE { 491 181 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 492 186 0C 20: UTF8String 'GostR3410-94 example' 493 : } 494 : } 495 208 31 18: SET { 496 210 30 16: SEQUENCE { 497 212 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 498 217 0C 9: UTF8String 'CryptoPro' 499 : } 500 : } 501 228 31 11: SET { 502 230 30 9: SEQUENCE { 503 232 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 504 237 13 2: PrintableString 'RU' 505 : } 506 : } 507 241 31 39: SET { 508 243 30 37: SEQUENCE { 509 245 06 9: OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1) 510 256 16 24: IA5String 'GostR3410-94@example.com' 511 : } 512 : } 513 : } 514 282 30 165: SEQUENCE { 515 285 30 28: SEQUENCE { 516 287 06 6: OBJECT IDENTIFIER id-GostR3410-94 (1 2 643 2 2 20) 517 295 30 18: SEQUENCE { 518 297 06 7: OBJECT IDENTIFIER 519 : id-GostR3410-94-CryptoPro-A-ParamSet 520 : (1 2 643 2 2 32 2) 521 306 06 7: OBJECT IDENTIFIER 522 : id-GostR3411-94-CryptoProParamSet 523 : (1 2 643 2 2 30 1) 524 : } 525 : } 526 315 03 132: BIT STRING 0 unused bits, encapsulates { 527 319 04 128: OCTET STRING 528 : BB 84 66 E1 79 9E 5B 34 D8 2C 80 7F 13 A8 19 66 529 : 71 57 FE 8C 54 25 21 47 6F 30 0B 27 77 46 98 C6 530 : FB 47 55 BE B7 B2 F3 93 6C 39 B5 42 37 26 84 E2 531 : 0D 10 8A 24 0E 1F 0C 42 4D 2B 3B 11 2B A8 BF 66 532 : 39 32 5C 94 8B C1 A8 FE 1B 63 12 F6 09 25 87 CC 533 : 75 1B F4 E5 89 8A 09 82 68 D3 5C 77 A6 0F B6 90 534 : 10 13 8D E3 3E 7C 9C 91 D6 AC 0D 08 2C 3E 78 C1 535 : B5 C2 B6 B7 1A A8 2A 8B 45 81 93 32 32 76 FA 7B 536 : } 537 : } 538 : } 539 450 30 8: SEQUENCE { 540 452 06 6: OBJECT IDENTIFIER 541 : id-GostR3411-94-with-GostR3410-94 (1 2 643 2 2 4) 542 : } 543 460 03 65: BIT STRING 0 unused bits 544 : 11 C7 08 7E 12 DC 02 F1 02 23 29 47 76 8F 47 2A 545 : 81 83 50 E3 07 CC F2 E4 31 23 89 42 C8 73 E1 DE 546 : 22 F7 85 F3 55 BD 94 EC 46 91 9C 67 AC 58 D7 05 547 : 2A A7 8C B7 85 2A 01 75 85 F7 D7 38 03 FB CD 43 548 : } 550 In the signature of the above certificate, r' equals to 551 0x22F785F355BD94EC46919C67AC58D7052AA78CB7852A017585F7D73803FBCD43 552 and s equals to 553 0x11C7087E12DC02F102232947768F472A818350E307CCF2E431238942C873E1DE 555 4.2 GOST R 34.10-2001 Certificate 557 -----BEGIN CERTIFICATE----- 558 MIIB0DCCAX8CECv1xh7CEb0Xx9zUYma0LiEwCAYGKoUDAgIDMG0xHzAdBgNVBAMM 559 Fkdvc3RSMzQxMC0yMDAxIGV4YW1wbGUxEjAQBgNVBAoMCUNyeXB0b1BybzELMAkG 560 A1UEBhMCUlUxKTAnBgkqhkiG9w0BCQEWGkdvc3RSMzQxMC0yMDAxQGV4YW1wbGUu 561 Y29tMB4XDTA1MDgxNjE0MTgyMFoXDTE1MDgxNjE0MTgyMFowbTEfMB0GA1UEAwwW 562 R29zdFIzNDEwLTIwMDEgZXhhbXBsZTESMBAGA1UECgwJQ3J5cHRvUHJvMQswCQYD 563 VQQGEwJSVTEpMCcGCSqGSIb3DQEJARYaR29zdFIzNDEwLTIwMDFAZXhhbXBsZS5j 564 b20wYzAcBgYqhQMCAhMwEgYHKoUDAgIkAAYHKoUDAgIeAQNDAARAhJVodWACGkB1 565 CM0TjDGJLP3lBQN6Q1z0bSsP508yfleP68wWuZWIA9CafIWuD+SN6qa7flbHy7Df 566 D2a8yuoaYDAIBgYqhQMCAgMDQQA8L8kJRLcnqeyn1en7U23Sw6pkfEQu3u0xFkVP 567 vFQ/3cHeF26NG+xxtZPz3TaTVXdoiYkXYiD02rEx1bUcM97i 568 -----END CERTIFICATE----- 570 0 30 464: SEQUENCE { 571 4 30 383: SEQUENCE { 572 8 02 16: INTEGER 573 : 2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21 574 26 30 8: SEQUENCE { 575 28 06 6: OBJECT IDENTIFIER 576 : id-GostR3411-94-with-GostR3410-2001 (1 2 643 2 2 3) 577 : } 578 36 30 109: SEQUENCE { 579 38 31 31: SET { 580 40 30 29: SEQUENCE { 581 42 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 582 47 0C 22: UTF8String 'GostR3410-2001 example' 583 : } 584 : } 585 71 31 18: SET { 586 73 30 16: SEQUENCE { 587 75 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 588 80 0C 9: UTF8String 'CryptoPro' 589 : } 590 : } 591 91 31 11: SET { 592 93 30 9: SEQUENCE { 593 95 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 594 100 13 2: PrintableString 'RU' 595 : } 596 : } 597 104 31 41: SET { 598 106 30 39: SEQUENCE { 599 108 06 9: OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1) 600 119 16 26: IA5String 'GostR3410-2001@example.com' 601 : } 602 : } 603 : } 604 147 30 30: SEQUENCE { 605 149 17 13: UTCTime '050816141820Z' 606 164 17 13: UTCTime '150816141820Z' 607 : } 608 179 30 109: SEQUENCE { 609 181 31 31: SET { 610 183 30 29: SEQUENCE { 611 185 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 612 190 0C 22: UTF8String 'GostR3410-2001 example' 613 : } 614 : } 615 214 31 18: SET { 616 216 30 16: SEQUENCE { 617 218 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 618 223 0C 9: UTF8String 'CryptoPro' 619 : } 620 : } 621 234 31 11: SET { 622 236 30 9: SEQUENCE { 623 238 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 624 243 13 2: PrintableString 'RU' 625 : } 626 : } 627 247 31 41: SET { 628 249 30 39: SEQUENCE { 629 251 06 9: OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1) 630 262 16 26: IA5String 'GostR3410-2001@example.com' 631 : } 632 : } 633 : } 634 290 30 99: SEQUENCE { 635 292 30 28: SEQUENCE { 636 294 06 6: OBJECT IDENTIFIER id-GostR3410-2001 (1 2 643 2 2 19) 637 302 30 18: SEQUENCE { 638 304 06 7: OBJECT IDENTIFIER 639 : id-GostR3410-2001-CryptoPro-XchA-ParamSet 640 : (1 2 643 2 2 36 0) 641 313 06 7: OBJECT IDENTIFIER 642 : id-GostR3411-94-CryptoProParamSet 643 : (1 2 643 2 2 30 1) 644 : } 645 : } 646 322 03 67: BIT STRING 0 unused bits, encapsulates { 647 325 04 64: OCTET STRING 648 : 84 95 68 75 60 02 1A 40 75 08 CD 13 8C 31 89 2C 649 : FD E5 05 03 7A 43 5C F4 6D 2B 0F E7 4F 32 7E 57 650 : 8F EB CC 16 B9 95 88 03 D0 9A 7C 85 AE 0F E4 8D 651 : EA A6 BB 7E 56 C7 CB B0 DF 0F 66 BC CA EA 1A 60 652 : } 653 : } 654 : } 655 391 30 8: SEQUENCE { 656 393 06 6: OBJECT IDENTIFIER 657 : id-GostR3411-94-with-GostR3410-2001 (1 2 643 2 2 3) 658 : } 659 401 03 65: BIT STRING 0 unused bits 660 : 3C 2F C9 09 44 B7 27 A9 EC A7 D5 E9 FB 53 6D D2 661 : C3 AA 64 7C 44 2E DE ED 31 16 45 4F BC 54 3F DD 662 : C1 DE 17 6E 8D 1B EC 71 B5 93 F3 DD 36 93 55 77 663 : 68 89 89 17 62 20 F4 DA B1 31 D5 B5 1C 33 DE E2 664 : } 666 In the public key of the above certificate, x equals to 667 0x577E324FE70F2B6DF45C437A0305E5FD2C89318C13CD0875401A026075689584 668 and y equals to 669 0x601AEACABC660FDFB0CBC7567EBBA6EA8DE40FAE857C9AD0038895B916CCEB8F 671 In the signature of the above certificate, r' equals to 672 0xC1DE176E8D1BEC71B593F3DD36935577688989176220F4DAB131D5B51C33DEE2 673 and s equals to 674 0x3C2FC90944B727A9ECA7D5E9FB536DD2C3AA647C442EDEED3116454FBC543FDD 676 5 References 678 Normative references: 680 [GOST28147] "Cryptographic Protection for Data Processing System", 681 GOST 28147-89, Gosudarstvennyi Standard of USSR, Gov- 682 ernment Committee of the USSR for Standards, 1989. (In 683 Russian); 685 [GOSTR341094] "Information technology. Cryptographic Data Security. 686 Produce and check procedures of Electronic Digital Sig- 687 natures based on Asymmetric Cryptographic Algorithm.", 688 GOST R 34.10-94, Gosudarstvennyi Standard of Russian 689 Federation, Government Committee of the Russia for 690 Standards, 1994. (In Russian); 692 [GOSTR341001] "Information technology. Cryptographic data security. 693 Signature and verification processes of [electronic] 694 digital signature.", GOST R 34.10-2001, Gosudarstvennyi 695 Standard of Russian Federation, Government Committee of 696 the Russia for Standards, 2001. (In Russian); 698 [GOSTR341194] "Information technology. Cryptographic Data Security. 699 Hashing function.", GOST R 34.10-94, Gosudarstvennyi 700 Standard of Russian Federation, Government Committee of 701 the Russia for Standards, 1994. (In Russian); 703 [CPALGS] "Additional cryptographic algorithms for use with GOST 704 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST 705 R 34.11-94 algorithms", V. Popov, I. Kurepkin, S. Leon- 706 tiev, September 2005, draft-popov-cryptopro- 707 cpalgs-04.txt work in progress; 709 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Inter- 710 net X.509 Public Key Infrastructure Certificate and 711 Certificate Revocation List (CRL) Profile", RFC 3280, 712 April 2002. 714 [PKALGS] L. Bassham, W. Polk, R. Housley, "Algorithms and 715 Identifiers for the Internet X.509 Public Key Infras- 716 tructure Certificate and Certificate Revocation List 717 (CRL) Profile", RFC 3279, April 2002. 719 [X.660] ITU-T Recommendation X.660 Information Technology - 720 ASN.1 encoding rules: Specification of Basic Encoding 721 Rules (BER), Canonical Encoding Rules (CER) and Distin- 722 guished Encoding Rules (DER), 1997. 724 Informative references: 726 [Schneier95] B. Schneier, Applied cryptography, second edition, John 727 Wiley & Sons, Inc., 1995; 729 [RFDSL] Russian Federal Digital Signature Law, 10 Jan 2002 730 N1-FZ 732 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 733 Requirement Levels", BCP 14, RFC 2119, March 1997. 735 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 736 3852, July 2004. 738 Acknowledgments 740 This document was created in accordance with "Russian Cryptographic 741 Software Compatibility Agreement", signed by FGUE STC "Atlas", 742 CRYPTO-PRO, Factor-TS, MD PREI, Infotecs GmbH, SPRCIS (SPbRCZI), 743 Cryptocom, R-Alpha. The goal of this agreement is to achieve mutual 744 compatibility of the products and solutions. 746 The authors wish to thank: 748 Microsoft Corporation Russia for provided information about 749 company products and solutions, and also for technical consulting 750 in PKI. 752 RSA Security Russia and Demos Co Ltd for active colaboration and 753 critical help in creation of this document. 755 RSA Security Inc for compatibility testing of the proposed data 756 formats while incorporating them into RSA Keon product. 758 Baltimore Technology plc for compatibility testing of the proposed 759 data formats while incorporating them into UniCERT product. 761 Russ Hously (Vigil Security, LLC, housley@vigilsec.com) and 762 Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru) for initiative 763 creating this document. 765 Grigorij Chudov for navigating the IETF process for this document. 767 This document is based on a contribution of CRYPTO-PRO company. Any 768 substantial use of the text from this document must reference CRYPTO- 769 PRO. CRYPTO-PRO requests that all material mentioning or referencing 770 this document identify this as "CRYPTO-PRO CPPK". 772 Author's Addresses 774 Serguei Leontiev 775 CRYPTO-PRO 776 38, Obraztsova, 777 Moscow, 127018, Russian Federation 778 EMail: lse@cryptopro.ru 780 Dennis Shefanovski 781 DEMOS Co Ltd 782 6/1, Ovchinnikovskaja naberezhnaya, 783 Moscow, 113035, Russian Federation 784 EMail: sdb@dol.ru 786 Grigorij Chudov 787 CRYPTO-PRO 788 38, Obraztsova, 789 Moscow, 127018, Russian Federation 790 EMail: chudov@cryptopro.ru 792 Alexandr Afanasiev 793 Factor-TS 794 office 711, 14, Presnenskij val, 795 Moscow, 123557, Russian Federation 796 EMail: afa1@factor-ts.ru 798 Nikolaj Nikishin 799 Infotecs GmbH 800 p/b 35, 80-5, Leningradskij prospekt, 801 Moscow, 125315, Russian Federation 802 EMail: nikishin@infotecs.ru 804 Boleslav Izotov 805 FGUE STC "Atlas" 806 38, Obraztsova, 807 Moscow, 127018, Russian Federation 808 EMail: izotov@nii.voskhod.ru 810 Elena Minaeva 811 MD PREI 812 build 3, 6A, Vtoroj Troitskij per., 813 Moscow, Russian Federation 814 EMail: evminaeva@mail.ru 816 Serguei Murugov 817 R-Alpha 818 4/1, Raspletina, 819 Moscow, 123060, Russian Federation 820 EMail: msm@top-cross.ru 822 Igor Ustinov 823 Cryptocom 824 office 239, 51, Leninskij prospekt, 825 Moscow, 119991, Russian Federation 826 EMail: igus@cryptocom.ru 828 Anatolij Erkin 829 SPRCIS (SPbRCZI) 830 1, Obrucheva, 831 St.Petersburg, 195220, Russian Federation 832 EMail: erkin@nevsky.net 834 Disclaimer of Validity 836 This document and the information contained herein are provided on an 837 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 838 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 839 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 840 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 841 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 842 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 844 Full Copyright Statement 846 Copyright (C) The Internet Society (2005). This document is subject 847 to the rights, licenses and restrictions contained in BCP 78, and 848 except as set forth therein, the authors retain all their rights. 850 Acknowledgment 852 Funding for the RFC Editor function is currently provided by the 853 Internet Society.