idnits 2.17.1 draft-ietf-pkix-gost-cppk-02.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 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 879. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 871), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. 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. ** The abstract seems to contain references ([RFC3280], [RFC3279]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (February 5, 2005) is 7020 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GOST3411' is mentioned on line 100, but not defined == Missing Reference: 'GOST341094' is mentioned on line 115, but not defined == Missing Reference: 'GOST34102001' is mentioned on line 116, but not defined == Missing Reference: 'GOSTR3411' is mentioned on line 150, but not defined -- Looks like a reference, but probably isn't: '0' on line 431 -- Looks like a reference, but probably isn't: '63' on line 436 == Unused Reference: 'GOST28147' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'GOSTR341194' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'TLS' is defined on line 771, but no explicit reference was found in the text -- No information found for draft-popov-crypto-pro-cpalgs - is the name correct? ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 18 errors (**), 0 flaws (~~), 9 warnings (==), 7 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 Shefanovskij, DEMOS Co Ltd 4 Expires August 5, 2005 February 5, 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, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3668. 21 This document is an Internet Draft and is subject to all provisions 22 of Section 10 of RFC2026. Internet Drafts are working documents of 23 the Internet Engineering Task Force (IETF), its areas, and its 24 working groups. Note that other groups may also distribute working 25 documents as Internet Drafts. Internet Drafts are draft documents 26 valid for a maximum of 6 months and may be updated, replaced, or 27 obsoleted by other documents at any time. It is inappropriate to use 28 Internet Drafts as reference material or to cite them other than as a 29 "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 Copyright (C) The Internet Society (2005). All Rights Reserved. 39 Abstract 41 This document describes identifiers and appropriate parameters for 42 the algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94, 43 and also ASN.1 encoding scheme for digital signatures and public 44 keys, used in Internet X.509 Public Key Infrastructure (PKI). This 45 specification extends [RFC3279], "Algorithms and Identifiers for the 46 Internet X.509 Public Key Infrastructure Certificate and Certificate 47 Revocation List (CRL) Profile" and, correspondingly, [RFC3280], 48 "Internet X.509 Public Key Infrastructure: Certificate and 49 Certificate Revocation List (CRL) Profile". All implementations of 50 this specification MUST also satisfy the requirements of [RFC3280]. 52 Table of Contents 54 1 Introduction. . . . . . . . . . . . . . . . . . . . . . 2 55 2 Algorithm Support . . . . . . . . . . . . . . . . . . . 3 56 2.1 One-way Hash Function . . . . . . . . . . . . . . . . . 3 57 2.1.1 One-way Hash Function GOST R 34.11-94 . . . . . . . . . 3 58 2.2 Signature Algorithms. . . . . . . . . . . . . . . . . . 4 59 2.2.1 Signature Algorithm GOST R 34.10-94 . . . . . . . . . . 4 60 2.2.2 Signature Algorithm GOST R 34.10-2001 . . . . . . . . . 5 61 2.3 Subject Public Key Algorithms . . . . . . . . . . . . . 6 62 2.3.1 GOST R 34.10-94 Keys. . . . . . . . . . . . . . . . . . 6 63 2.3.2 GOST R 34.10-2001 Keys. . . . . . . . . . . . . . . . . 8 64 3 Security Considerations . . . . . . . . . . . . . . . . 10 65 4 Appendix Examples . . . . . . . . . . . . . . . . . . . 11 66 4.1 GOST R 34.10-94 Certificate . . . . . . . . . . . . . . 11 67 4.2 GOST R 34.10-2001 Certificate . . . . . . . . . . . . . 13 68 5 References. . . . . . . . . . . . . . . . . . . . . . . 16 69 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 17 70 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 18 71 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19 73 1 Introduction 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 This document defines identifiers and corresponding algorithm 80 parameters and attributes proposed by CRYPTO-PRO Company within 81 "Russian Cryptographic Software Compatibility Agreement" community 82 for the algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST R 83 34.11-94, key derivation algorithms based on GOST R 34.10-94 public 84 keys, key derivation algorithms based on GOST R 34.10-2001 public 85 keys, and also ASN.1 encoding [X.660] for digital signatures and 86 public keys, used in Internet X.509 Public Key Infrastructure (PKI). 88 This specification extends [RFC3279], "Algorithms and Identifiers for 89 the Internet X.509 Public Key Infrastructure Certificate and 90 Certificate Revocation List (CRL) Profile" and, correspondingly, 91 [RFC3280], "Internet X.509 Public Key Infrastructure: Certificate and 92 Certificate Revocation List (CRL) Profile". All implementations of 93 this specification MUST also satisfy the requirements of [RFC3280]. 95 This specification defines the content of the signatureAlgorithm, 96 signatureValue, signature, and subjectPublicKeyInfo fields within 97 Internet X.509 certificates and CRLs. 99 This document defines the use of one-way hash-function GOST R 100 34.11-94 [GOST3411] with digital signatures. This algorithm is used 101 in conjunction with digital signature algorithms. 103 This specification describes the encoding of digital signatures, 104 generated with the following cryptographic algorithms: 106 * GOST R 34.10-94; 107 * GOST R 34.10-2001. 109 This document also defines the contents of the subjectPublicKeyInfo 110 field for Internet X.509 certificates. For each algorithm, the 111 appropriate alternatives for the keyUsage extension are provided. 112 This specification describes encoding formats for public keys used 113 with the following cryptographic algorithms: 115 * GOST R 34.10-94 [GOST341094]; 116 * GOST R 34.10-2001 [GOST34102001]; 117 * Key derivation algorithm VKO GOST R 34.10-94 [CPALGS]; 118 * Key derivation algorithm VKO GOST R 34.10-2001 [CPALGS]; 120 ASN.1 modules, including all the definitions used in this document 121 can be found in [CPALGS]. 123 2 Algorithm Support 125 This section is an overview of cryptographic algorithms, that may be 126 used within the Internet X.509 certificates and CRL profile 127 [RFC3280]. It describes one-way hash functions and digital signature 128 algorithms, that may be used to sign certificates and CRLs, and 129 identifies OIDs and ASN.1 encoding for public keys contained in a 130 certificate. 132 The conforming CAs and/or applications MUST fully support digital 133 signatures and public keys for at least one of the specified 134 algorithms. 136 2.1 One-way Hash Function 138 This section identifies the use of one-way, collision free hash 139 function GOST R 34.11-94 - the only one that can be used in digital 140 signature algorithms GOST R 34.10-94/2001. The data that is hashed 141 for certificates and CRL signing is fully described in [RFC3280]. 143 2.1.1 One-way Hash Function GOST R 34.11-94 145 GOST R 34.11-94 has been developed by "GUBS of Federal Agency 146 Government Communication and Information" and "All-Russian Scientific 147 and Research Institute of Standardization". The algorithm GOST R 148 34.11-94 produces a 256-bit hash value of the arbitrary finite bit 149 length input. This document does not contain GOST R 34.11-94 full 150 specification, which can be found in [GOSTR3411] in Russian. It's 151 brief technical description in english can be found in [Schneier95], 152 ch. 18.11, p. 454. 154 This function is always used with default parameter set 155 gostR3411CryptoProParamSetAI (see section 8.2 of [CPALGS]). 157 2.2 Signature Algorithms 159 Conforming CAs may use GOST R 34.10-94 or GOST R 34.10-2001 signature 160 algorithms to sign certificates and CRLs. The signatureAlgorithm 161 field of Certificate or CertificateList indicates the signature 162 algorithm ID, and associated parameters. This section also defines 163 algorithm identifiers and parameters that MUST be used in the 164 signatureAlgorithm field in a Certificate or CertificateList. 166 Signature algorithms are always used conjointly with a one-way hash 167 function GOST R 34.11-94 as indicated in [GOSTR341094] and 168 [GOSTR34102001]. 170 This section identifies OIDs for GOST R 34.10-94 and GOST R 171 34.10-2001 algorithms. The contents of the parameters component for 172 each algorithm may vary and details are provided below for each 173 algorithm separately. 175 2.2.1 Signature Algorithm GOST R 34.10-94 177 GOST R 34.10-94 has been developed by "GUBS of Federal Agency 178 Government Communication and Information" and "All-Russian Scientific 179 and Research Institute of Standardization". This signature algorithm 180 MUST be used conjointly with one-way, collision free hash function 181 GOST R 34.11-94. This document does not contain GOST R 34.10-94 182 standard description, which is fully described in [GOSTR341094] in 183 Russian, and brief description in English could be found in 184 [Schneier95] ch. 20.3, p. 495. 186 The ASN.1 OID used to identify GOST R 34.10-94 signature algorithm in 187 fields signatureAlgorithm in Certificate and CertificateList is: 189 id-CryptoPro-algorithms OBJECT IDENTIFIER ::= 190 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) } 192 id-GostR3411-94-with-GostR3410-94 OBJECT IDENTIFIER ::= 193 { id-CryptoPro-algorithms gostR3411-94-with-gostR3410-94(4)} 195 GostR3410-94-CertificateSignatureAlgorithms 196 ALGORITHM-IDENTIFIER ::= { 197 { NULL IDENTIFIED BY 198 id-GostR3411-94-with-GostR3410-94 } | 199 { GostR3410-94-PublicKeyParameters IDENTIFIED BY 200 id-GostR3411-94-with-GostR3410-94 } } 202 GostR3410-94-PublicKeyParameters are defined in section 2.3.1. 204 When the id-GostR3411-94-with-GostR3410-94 algorithm identifier 205 appears in an AlgorithmIdentifier and parameters are omitted, the 206 parameters from the public key of the signer's certificate MUST be 207 used. If the parameters from the public key of the signer's 208 certificate are also omited, and it's issuer's certificate has the 209 same public key algorithm, parameters from the public key of the 210 issuer's certificate MUST be used, and so on. 212 Signature algorithm GOST R 34.10-94 generates digital signature in 213 the form of a binary 512-bit vector (256||256). That is, the 214 least-significant (1-st) bit of signatureValue BIT STRING contains 215 the least-significant (1-st) bit of , and the most-significant 216 (512th) bit of signatureValue contains the most-significant (256th) 217 bit of . 219 2.2.2 Signature Algorithm GOST R 34.10-2001 221 GOST R 34.10-2001 was developed by "GUBS of Federal Agency Government 222 Communication and Information" and "All-Russian Scientific and 223 Research Institute of Standardization". This signature algorithm 224 MUST be used conjointly with one-way, collision free hash function 225 GOST R 34.11-94. This document does not contain GOST R 34.10-2001 226 standard description, which is fully described in [GOSTR34102001]. 228 The ASN.1 OID used to identify GOST R 34.10-2001 signature algorithm 229 in fields signatureAlgorithm of Certificate and CertificateList is: 231 id-GostR3411-94-with-GostR3410-2001 OBJECT IDENTIFIER ::= 232 { id-CryptoPro-algorithms gostR3411-94-with-gostR3410-2001(3) } 234 GostR3410-2001-CertificateSignatureAlgorithms 235 ALGORITHM-IDENTIFIER ::= { 236 { NULL IDENTIFIED BY 237 id-GostR3411-94-with-GostR3410-2001 } | 238 { GostR3410-2001-PublicKeyParameters IDENTIFIED BY 239 id-GostR3411-94-with-GostR3410-2001 } } 241 GostR3410-2001-PublicKeyParameters are defined in section 2.3.2. 243 When the id-GostR3411-94-with-GostR3410-2001 algorithm identifier 244 appears in an AlgorithmIdentifier and parameters are omitted, the 245 parameters from the public key of the signer's certificate MUST be 246 used. If the parameters from the public key of the signer's 247 certificate are also omited, and it's issuer's certificate has the 248 same public key algorithm, parameters from the public key of the 249 issuer's certificate MUST be used, and so on. 251 Signature algorithm GOST R 34.10-2001 generates digital signature in 252 the form of a binary 512-bit vector (256||256). That is, the 253 least-significant (1-st) bit of signatureValue BIT STRING contains 254 the least-significant (1-st) bit of , and the most-significant 255 (512th) bit of signatureValue contains the most-significant (256th) 256 bit of . 258 2.3 Subject Public Key Algorithms 260 In according to [RFC3280] the certificates may contain a public key 261 for any algorithm. Within the framework of this specification the 262 only GOST R 34.10-94 and GOST R 34.10-2001 public key algorithms 263 defined. The algorithm and associated parameters are definable as OID 264 in certificate through ASN.1 structure AlgorithmIdentifier. 266 This section identifies defines OID and public key parameters for the 267 GOST R 34.10-94 and GOST R 34.10-2001 algorithms. The appropriate CA 268 MUST use the predefined OID issuing certificates containing public 269 keys for these algorithms. The appropriate applications supporting 270 any of these algorithms MUST fully recognize the OID identified in 271 this section 273 2.3.1 GOST R 34.10-94 Keys 275 This section defines OID and parameter encoding for inclusion of GOST 276 R 34.10-94 public key in certificate. Such public key can be used 277 for digital signature validation algorithm GOST R 34.10-94 278 [GOSTR341094], and for key derivation algorithm VKO GOST R 34.10-94 279 [CPALGS]. 281 An assumed cryptographic key usage MAY be specified by keyUsage 282 extension [RFC3280]. The usage of the same key for signature and key 283 derivation is NOT RECOMMENDED, but possible. 285 Public key OID for GOST R 34.10-94 declared in this document is: 287 id-GostR3410-94 OBJECT IDENTIFIER ::= 288 { id-CryptoPro-algorithms gostR3410-94(20) } 290 SubjectPublicKeyInfo.algorithm.algorithm field (see [RFC3280]) for 291 GOST R 34.10-94 keys MUST be id-GostR3410-94; 293 SubjectPublicKeyInfo.algorithm.parameters in this case MUST have the 294 following structure: 296 GostR3410-94-PublicKeyParameters ::= 297 SEQUENCE { 298 publicKeyParamSet 299 OBJECT IDENTIFIER, 300 digestParamSet 301 OBJECT IDENTIFIER, 302 encryptionParamSet 303 OBJECT IDENTIFIER OPTIONAL 304 } 306 where: 307 * publicKeyParamSet - public key parameters identifier for GOST R 308 34.10-94 (see section 8.3 of [CPALGS]) 309 * digestParamSet - parameters identifier for GOST R 34.11-94 (see 310 section 8.2 of [CPALGS]) 311 * encryptionParamSet - optional parameters identifier for GOST 312 28147-89 (see section 8.1 of [CPALGS]) MAY be present in any 313 certificate and MUST be present if keyUsage includes keyAgreement or 314 keyEnchiperment. 316 If GOST R 34.10-94 algorithm parameters are omitted in 317 subjectPublicKeyInfo, and CA signs subject certificate using GOST R 318 34.10-94, then GOST R 34.10-94 parameters taken from 319 subjectPublicKeyInfo field of issuer certificate are applicable to 320 public key of GOST R 34.10-94 subject. That is, cryptographic 321 parameters inheritance takes place. If subjectPublicKeyInfo 322 AlgorithmIdentifier field contain no parameters, but CA sign 323 certificate using signature algorithm different from GOST R 34.10-94, 324 such certificate MUST be rejected by conforming applications. 326 Public key GOST R 34.10-94 MUST be ASN.1 encoded in following way. 328 In GOST R 34.10-94 public key is a number y = a^x (mod p), where a 329 and p - parameters, and y is a bit-vector (1024), at that 330 encoding should present 1024 (BIT STRING) as a vector holding 331 data in a little-endian. At first, a key is presented as an OCTET 332 STRING, and then, being DER-encoded, presented as a BIT STRING. 334 GostR3410-94-PublicKey ::= BIT STRING 336 GostR3410-94-PublicKeyOctetString ::= OCTET STRING 338 If the keyUsage extension is present in an end-entity certificate, 339 which contains a GOST R 34.10-94 public key, the following values MAY 340 be present: 342 digitalSignature; 343 nonRepudiation. 344 keyEncipherment; 345 keyAgreement. 347 If the keyAgreement or keyEnchiperment extension is present in a 348 certificate GOST R 34.10-94 public key, the following values MAY be 349 present as well: 351 encipherOnly; 352 decipherOnly. 354 The keyUsage extension MUST NOT assert both encipherOnly and 355 decipherOnly. 357 If the keyUsage extension is present in an CA or CRL signer 358 certificate which contain a GOST R 34.10-94 public key, the following 359 values MAY be present: 361 digitalSignature; 362 nonRepudiation; 363 keyCertSign; 364 cRLSign. 366 2.3.2 GOST R 34.10-2001 Keys 368 This section defines OID and parameter encoding for inclusion of GOST 369 R 34.10-2001 public key in certificate. Such public key can be used 370 for digital signature validation algorithm GOST R 34.10-2001 371 [GOSTR34102001], and for key derivation algorithm VKO GOST R 372 34.10-2001 [CPALGS]. 374 An assumed cryptographic key usage MAY be specified by keyUsage 375 extension [RFC3280]. The usage of the same key for signature and key 376 derivation is NOT RECOMMENDED, but possible. 378 Public key OID for GOST R 34.10-2001 declared in this document is: 380 id-GostR3410-2001 OBJECT IDENTIFIER ::= 381 { id-CryptoPro-algorithms gostR3410-2001(19) } 383 SubjectPublicKeyInfo.algorithm.algorithm field (see [RFC3280]) for 384 GOST R 34.10-2001 keys MUST be id-GostR3410-2001; 386 SubjectPublicKeyInfo.algorithm.parameters in this case MUST have the 387 following structure: 389 GostR3410-2001-PublicKeyParameters ::= 390 SEQUENCE { 391 publicKeyParamSet 392 OBJECT IDENTIFIER, 393 digestParamSet 394 OBJECT IDENTIFIER, 395 encryptionParamSet 396 OBJECT IDENTIFIER OPTIONAL 397 } 399 where: 400 * publicKeyParamSet - public key parameters identifier for GOST R 401 34.10-2001 (see section 8.4 of [CPALGS]) 402 * digestParamSet - parameters identifier for GOST R 34.11-94 (see 403 section 8.2 of [CPALGS]) 404 * encryptionParamSet - optional parameters identifier for GOST 405 28147-89 (see section 8.1 of [CPALGS]) MAY be present in any 406 certificate and MUST be present if keyUsage includes keyAgreement or 407 keyEnchiperment. 409 If GOST R 34.10-2001 algorithm parameters are omitted in 410 subjectPublicKeyInfo, and CA signs subject certificate using GOST R 411 34.10-2001, then GOST R 34.10-2001 parameters taken from 412 subjectPublicKeyInfo field of issuer certificate are applicable to 413 public key of GOST R 34.10-2001 subject. That is, cryptographic 414 parameters inheritance takes place. If subjectPublicKeyInfo 415 AlgorithmIdentifier field contain no parameters, but CA sign 416 certificate using signature algorithm different from GOST R 417 34.10-2001, such certificate MUST be rejected by conforming 418 applications. 420 GOST R 34.10-2001 public key MUST be ASN.1 encoded in a following 421 way. GOST R 34.10-2001 specifies that public key is a point on the 422 elliptic curve Q = dP, where d is a private key, P is a base point, 423 and Q presents in a way of 512-bit vector (256||256). This 424 vector is DER-encoded as two data blocks. At first, 256 block, 425 then 256 block. subjectPublicKey field BIT STRING type is 426 presented as a taken up object GostR3410-2001-PublicKeyOctetString. 428 At that, least-significant of the first octet 429 (GostR3410-2001-PublicKeyOctetString[0]) corresponds to least- 430 significant (1-st) of vector 256||256 (Yq1 = 431 (GostR3410-2001-PublicKeyOctetString[0] & 1)). 433 Whereas most-significant of 64-th octet 434 (GostR3410-2001-PublicKeyOctetString[63]) corresponds to most- 435 significant (512-d) of vector 256||256 (Xq256 = 436 ((GostR3410-2001-PublicKeyOctetString[63] & 0x80)>>7)). 438 In other words, 256||256 vector is stored in little-endian, 439 that correspond binary vector form and their concatenation in GOST R 440 34.10-2001 ch. 5.3. At first, key is placed in OCTET STRING, than is 441 DER-encoded and placed in BIT STRING. 443 GostR3410-2001-PublicKey ::= BIT STRING 445 GostR3410-2001-PublicKeyOctetString ::= OCTET STRING 447 If the keyUsage extension is present in an end-entity certificate, 448 which conveys a GOST R 34.10-2001 public key, the following values 449 MAY be present: 451 digitalSignature, 452 nonRepudiation, 453 keyEncipherment, 454 keyAgreement. 456 If the keyAgreement or keyEnchiperment extension is present in a 457 certificate, the following values MAY be present: 459 encipherOnly, 460 decipherOnly. 462 The keyUsage extension MUST NOT assert both encipherOnly and 463 decipherOnly. 465 If the keyUsage extension is present in an CA or CRL signer 466 certificate which contain a GOST R 34.10-2001 public key, the 467 following values MAY be present: 469 digitalSignature, 470 nonRepudiation, 471 keyCertSign, 472 cRLSign. 474 3 Security Considerations 476 It is RECCOMENDED, that applications verify signature values and 477 subject public keys to conform to [GOSTR34102001], [GOSTR341094] 478 standards prior to their use. 480 When certificate is used as analogue to a manual signing, in the 481 context of Russian Federal Digital Signature Law [RFDSL], certificate 482 MUST contain keyUsage extension, it MUST be critical, and keyUsage 483 MUST NOT include keyEncipherment and keyAgreement. 485 When certificate validity period (typicaly 5 years for end entities 486 and 7 years for CAs in Russia) is not equal to the private key 487 validity period (typicaly 15 months in Russia) it is RECOMENDED to 488 use private key usage period extension. 490 For security discussion concerning use of algorithm parameters, see 491 section Security Considerations from [CPALGS]. 493 4 Appendix Examples 495 4.1 GOST R 34.10-94 Certificate 497 0 30 527: SEQUENCE { 498 4 30 444: SEQUENCE { 499 8 02 16: INTEGER 500 : 17 31 2A C2 1B D2 08 58 BC 04 1E 52 37 D0 74 50 501 26 30 10: SEQUENCE { 502 28 06 6: OBJECT IDENTIFIER 503 : id_GostR3411_94_with_GostR3410_94 504 : ( 1 2 643 2 2 4) 505 36 05 0: NULL 506 : } 507 38 30 105: SEQUENCE { 508 40 31 29: SET { 509 42 30 27: SEQUENCE { 510 44 06 3: OBJECT IDENTIFIER 511 : commonName (2 5 4 3) 512 49 0C 20: UTF8String 'GostR3410-94 example' 513 : } 514 : } 515 71 31 18: SET { 516 73 30 16: SEQUENCE { 517 75 06 3: OBJECT IDENTIFIER 518 : organizationName (2 5 4 10) 519 80 0C 9: UTF8String 'CryptoPro' 520 : } 521 : } 522 91 31 11: SET { 523 93 30 9: SEQUENCE { 524 95 06 3: OBJECT IDENTIFIER 525 : countryName (2 5 4 6) 526 100 13 2: PrintableString 'RU' 527 : } 528 : } 529 104 31 39: SET { 530 106 30 37: SEQUENCE { 531 108 06 9: OBJECT IDENTIFIER 532 : emailAddress (1 2 840 113549 1 9 1) 533 119 16 24: IA5String 'GostR3410-94@example.com' 534 : } 535 : } 536 : } 537 145 30 30: SEQUENCE { 538 147 17 13: UTCTime '050203151651Z' 539 162 17 13: UTCTime '150203151651Z' 540 : } 541 177 30 105: SEQUENCE { 542 179 31 29: SET { 543 181 30 27: SEQUENCE { 544 183 06 3: OBJECT IDENTIFIER 545 : commonName (2 5 4 3) 546 188 0C 20: UTF8String 'GostR3410-94 example' 547 : } 548 : } 549 210 31 18: SET { 550 212 30 16: SEQUENCE { 551 214 06 3: OBJECT IDENTIFIER 552 : organizationName (2 5 4 10) 553 219 0C 9: UTF8String 'CryptoPro' 554 : } 555 : } 556 230 31 11: SET { 557 232 30 9: SEQUENCE { 558 234 06 3: OBJECT IDENTIFIER 559 : countryName (2 5 4 6) 560 239 13 2: PrintableString 'RU' 561 : } 562 : } 563 243 31 39: SET { 564 245 30 37: SEQUENCE { 565 247 06 9: OBJECT IDENTIFIER 566 : emailAddress (1 2 840 113549 1 9 1) 567 258 16 24: IA5String 'GostR3410-94@example.com' 568 : } 569 : } 570 : } 571 284 30 165: SEQUENCE { 572 287 30 28: SEQUENCE { 573 289 06 6: OBJECT IDENTIFIER 574 : id_GostR3410_94 ( 1 2 643 2 2 20) 576 297 30 18: SEQUENCE { 577 299 06 7: OBJECT IDENTIFIER 578 : id_GostR3410_94_CryptoPro_A_ParamSet 579 : ( 1 2 643 2 2 32 2) 580 308 06 7: OBJECT IDENTIFIER 581 : id_GostR3411_94_CryptoProParamSet 582 : ( 1 2 643 2 2 30 1) 583 : } 584 : } 585 317 03 132: BIT STRING 0 unused bits, encapsulates { 586 321 04 128: OCTET STRING 587 : BB 84 66 E1 79 9E 5B 34 D8 2C 80 7F 13 A8 19 66 588 : 71 57 FE 8C 54 25 21 47 6F 30 0B 27 77 46 98 C6 589 : FB 47 55 BE B7 B2 F3 93 6C 39 B5 42 37 26 84 E2 590 : 0D 10 8A 24 0E 1F 0C 42 4D 2B 3B 11 2B A8 BF 66 591 : 39 32 5C 94 8B C1 A8 FE 1B 63 12 F6 09 25 87 CC 592 : 75 1B F4 E5 89 8A 09 82 68 D3 5C 77 A6 0F B6 90 593 : 10 13 8D E3 3E 7C 9C 91 D6 AC 0D 08 2C 3E 78 C1 594 : B5 C2 B6 B7 1A A8 2A 8B 45 81 93 32 32 76 FA 7B 595 : } 596 : } 597 : } 598 452 30 10: SEQUENCE { 599 454 06 6: OBJECT IDENTIFIER 600 : id_GostR3411_94_with_GostR3410_94 ( 1 2 643 2 2 4) 601 462 05 0: NULL 602 : } 603 464 03 65: BIT STRING 0 unused bits 604 : 71 28 D8 4E 9A 38 33 FE 2E 42 12 02 CE C8 AC B3 605 : F6 91 46 90 37 1A CA 6B 16 61 05 95 BF B0 99 D2 606 : 94 CC F0 8C CC CE 45 01 5B 71 87 B1 48 C2 16 96 607 : A7 15 90 DF 83 6C EE 37 ED E4 4F EE BD E2 7F 41 608 : } 610 4.2 GOST R 34.10-2001 Certificate 612 0 30 468: SEQUENCE { 613 4 30 385: SEQUENCE { 614 8 02 16: INTEGER 615 : 48 E9 54 A5 CF E9 69 F5 C9 5C F7 55 E7 83 41 AF 616 26 30 10: SEQUENCE { 617 28 06 6: OBJECT IDENTIFIER 618 : id_GostR3411_94_with_GostR3410_2001 619 : ( 1 2 643 2 2 3) 620 36 05 0: NULL 621 : } 622 38 30 109: SEQUENCE { 623 40 31 31: SET { 624 42 30 29: SEQUENCE { 625 44 06 3: OBJECT IDENTIFIER 626 : commonName (2 5 4 3) 627 49 0C 22: UTF8String 'GostR3410-2001 example' 628 : } 629 : } 630 73 31 18: SET { 631 75 30 16: SEQUENCE { 632 77 06 3: OBJECT IDENTIFIER 633 : organizationName (2 5 4 10) 634 82 0C 9: UTF8String 'CryptoPro' 635 : } 636 : } 637 93 31 11: SET { 638 95 30 9: SEQUENCE { 639 97 06 3: OBJECT IDENTIFIER 640 : countryName (2 5 4 6) 641 102 13 2: PrintableString 'RU' 642 : } 643 : } 644 106 31 41: SET { 645 108 30 39: SEQUENCE { 646 110 06 9: OBJECT IDENTIFIER 647 : emailAddress (1 2 840 113549 1 9 1) 648 121 16 26: IA5String 'GostR3410-2001@example.com' 649 : } 650 : } 651 : } 652 149 30 30: SEQUENCE { 653 151 17 13: UTCTime '050203151646Z' 654 166 17 13: UTCTime '150203151646Z' 655 : } 656 181 30 109: SEQUENCE { 657 183 31 31: SET { 658 185 30 29: SEQUENCE { 659 187 06 3: OBJECT IDENTIFIER 660 : commonName (2 5 4 3) 661 192 0C 22: UTF8String 'GostR3410-2001 example' 662 : } 663 : } 664 216 31 18: SET { 665 218 30 16: SEQUENCE { 666 220 06 3: OBJECT IDENTIFIER 667 : organizationName (2 5 4 10) 668 225 0C 9: UTF8String 'CryptoPro' 669 : } 670 : } 671 236 31 11: SET { 672 238 30 9: SEQUENCE { 673 240 06 3: OBJECT IDENTIFIER 674 : countryName (2 5 4 6) 675 245 13 2: PrintableString 'RU' 676 : } 677 : } 678 249 31 41: SET { 679 251 30 39: SEQUENCE { 680 253 06 9: OBJECT IDENTIFIER 681 : emailAddress (1 2 840 113549 1 9 1) 682 264 16 26: IA5String 'GostR3410-2001@example.com' 683 : } 684 : } 685 : } 686 292 30 99: SEQUENCE { 687 294 30 28: SEQUENCE { 688 296 06 6: OBJECT IDENTIFIER 689 : id_GostR3410_2001 ( 1 2 643 2 2 19) 690 304 30 18: SEQUENCE { 691 306 06 7: OBJECT IDENTIFIER 692 : id_GostR3410_2001_CryptoPro_XchA_ParamSet 693 : ( 1 2 643 2 2 36 0) 694 315 06 7: OBJECT IDENTIFIER 695 : id_GostR3411_94_CryptoProParamSet 696 : ( 1 2 643 2 2 30 1) 697 : } 698 : } 699 324 03 67: BIT STRING 0 unused bits, encapsulates { 700 327 04 64: OCTET STRING 701 : 84 95 68 75 60 02 1A 40 75 08 CD 13 8C 31 89 2C 702 : FD E5 05 03 7A 43 5C F4 6D 2B 0F E7 4F 32 7E 57 703 : 8F EB CC 16 B9 95 88 03 D0 9A 7C 85 AE 0F E4 8D 704 : EA A6 BB 7E 56 C7 CB B0 DF 0F 66 BC CA EA 1A 60 705 : } 706 : } 707 : } 708 393 30 10: SEQUENCE { 709 395 06 6: OBJECT IDENTIFIER 710 : id_GostR3411_94_with_GostR3410_2001 ( 1 2 643 2 2 3) 711 403 05 0: NULL 712 : } 713 405 03 65: BIT STRING 0 unused bits 714 : 1F 0E 5D C3 F6 B0 FC E8 8D BC 7C 8E 13 AE 64 BF 715 : 2A 38 1E 9D 2C 7F 3D DC B0 CE 94 52 4A 75 D1 53 716 : B6 E3 BA 1F 34 92 B7 B6 C2 DB 1C E2 E3 51 AA B3 717 : 79 FA E5 19 BD 75 5A 91 D8 AE F5 85 83 E1 5C 2C 718 : } 720 5 References 722 [GOST28147] "Cryptographic Protection for Data Processing Sys- 723 tem", GOST 28147-89, Gosudarstvennyi Standard of 724 USSR, Government Committee of the USSR for Standards, 725 1989. (In Russian); 727 [GOSTR341094] "Information technology. Cryptographic Data Security. 728 Produce and check procedures of Electronic Digital 729 Signatures based on Asymmetric Cryptographic Algo- 730 rithm.", GOST R 34.10-94, Gosudarstvennyi Standard of 731 Russian Federation, Government Committee of the Rus- 732 sia for Standards, 1994. (In Russian); 734 [GOSTR34102001] "Information technology. Cryptographic data security. 735 Signature and verification processes of [electronic] 736 digital signature.", GOST R 34.10-2001, Gosudarstven- 737 nyi Standard of Russian Federation, Government Com- 738 mittee of the Russia for Standards, 2001. (In Rus- 739 sian); 741 [GOSTR341194] "Information technology. Cryptographic Data Security. 742 Hashing function.", GOST R 34.10-94, Gosudarstvennyi 743 Standard of Russian Federation, Government Committee 744 of the Russia for Standards, 1994. (In Russian); 746 [RFDSL] Russian Federal Digital Signature Law, 10 Jan 2002 747 N1-FZ 749 [CPALGS] "Additional cryptographic algorithms for use with 750 GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, 751 and GOST R 34.11-94 algorithms", V. Popov, I. Kurep- 752 kin, S. Leontiev, February 2004, draft-popov-crypto- 753 pro-cpalgs-01.txt work in progress; 755 [Schneier95] B. Schneier, Applied cryptography, second edition, 756 John Wiley & Sons, Inc., 1995; 758 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, 759 "Internet X.509 Public Key Infrastructure Certificate 760 and Certificate Revocation List (CRL) Profile", RFC 761 3280, April 2002. 763 [RFC3279] Algorithms and Identifiers for the Internet X.509 764 Public Key Infrastructure Certificate and Certificate 765 Revocation List (CRL) Profile. L. Bassham, W. 766 Polk, R. Housley. April 2002. 768 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 769 Requirement Levels", BCP 14, RFC 2119, March 1997. 771 [TLS] The TLS Protocol Version 1.0. T. Dierks, C. Allen. 772 January 1999, RFC 2246. 774 [X.660] ITU-T Recommendation X.660 Information Technology - 775 ASN.1 encoding rules: Specification of Basic Encoding 776 Rules (BER), Canonical Encoding Rules (CER) and Dis- 777 tinguished Encoding Rules (DER), 1997. 779 Acknowledgments 781 This document was created in accordance with "Russian Cryptographic 782 Software Compatibility Agreement", signed by FGUE STC "Atlas", 783 CRYPTO-PRO, Factor-TC, MD PREI, Infotecs GmbH, SPRCIS (SPbRCZI), 784 Cryptocom, R-Alpha. The goal of this agreement is to achieve mutual 785 compatibility of the products and solutions. 787 The authors wish to thank: 789 Microsoft Corporation Russia for provided information about 790 company products and solutions, and also for technical consulting 791 in PKI. 793 RSA Security Russia and Demos Co Ltd for active colaboration and 794 critical help in creation of this document. 796 RSA Security Inc for compatibility testing of the proposed data 797 formats while incorporating them into RSA Keon product. 799 Baltimore Technology plc for compatibility testing of the proposed 800 data formats while incorporating them into UniCERT product. 802 Russ Hously (Vigil Security, LLC, housley@vigilsec.com) and 803 Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru) for initiative 804 creating this document. 806 This document is based on a contribution of CRYPTO-PRO company. Any 807 substantial use of the text from this document must reference CRYPTO- 808 PRO. CRYPTO-PRO requests that all material mentioning or referencing 809 this document identify this as "CRYPTO-PRO CPPK". 811 Author's Addresses 813 Serguei Leontiev 814 CRYPTO-PRO 815 38, Obraztsova, 816 Moscow, 127018, Russian Federation 817 EMail: lse@cryptopro.ru 819 Dennis Shefanovski 820 DEMOS Co Ltd 821 6/1, Ovchinnikovskaja naberezhnaya, 822 Moscow, 113035, Russian Federation 823 EMail: sdb@dol.ru 825 Alexandr Afanasiev 826 Factor-TC 827 office 711, 14, Presnenskij val, 828 Moscow, 123557, Russian Federation 829 EMail: aaaf@factor-ts.ru 831 Nikolaj Nikishin 832 Infotecs GmbH 833 p/b 35, 80-5, Leningradskij prospekt, 834 Moscow, 125315, Russian Federation 835 EMail: nikishin@infotecs.ru 837 Boleslav Izotov 838 FGUE STC "Atlas" 839 38, Obraztsova, 840 Moscow, 127018, Russian Federation 841 EMail: izotov@stcnet.ru 843 Elena Minaeva 844 MD PREI 845 build 3, 6A, Vtoroj Troitskij per., 846 Moscow, Russian Federation 847 EMail: evminaeva@mo.msk.ru 849 Serguei Murugov 850 R-Alpha 851 4/1, Raspletina, 852 Moscow, 123060, Russian Federation 853 EMail: msm@office.ru 855 Igori Ustinov 856 Cryptocom 857 office 239, 51, Leninskij prospekt, 858 Moscow, 119991, Russian Federation 859 EMail: igus@cryptocom.ru 861 Anatolij Erkin 862 SPRCIS (SPbRCZI) 863 1, Obrucheva, 864 St.Petersburg, 195220, Russian Federation 865 EMail: erkin@nevsky.net 867 Full Copyright Statement 869 Copyright (C) The Internet Society (2005). This document is subject 870 to the rights, licenses and restrictions contained in BCP 78, and 871 except as set forth therein, the authors retain all their rights. 873 This document and the information contained herein are provided on an 874 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 875 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 876 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 877 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 878 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 879 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.