idnits 2.17.1 draft-chudov-cryptopro-cpxmldsig-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. ** The abstract seems to contain references ([XMLDSIG]), 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 == Line 37 has weird spacing: '...ic keys with ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (April 7, 2004) is 7325 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'XML' is mentioned on line 78, but not defined == Missing Reference: 'XML-ns' is mentioned on line 109, but not defined == Missing Reference: '0-2' is mentioned on line 339, but not defined == Missing Reference: '1-3' is mentioned on line 339, but not defined == Missing Reference: '0-9' is mentioned on line 339, but not defined == Outdated reference: A later version (-09) exists of draft-eastlake-xmldsig-uri-05 == Outdated reference: A later version (-04) exists of draft-popov-cryptopro-cpalgs-01 == Outdated reference: A later version (-05) exists of draft-ietf-pkix-gost-cppk-01 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XMLDSIG Working Group Grigorij Chudov, CRYPTO-PRO 3 Internet Draft Serguei Leontiev, CRYPTO-PRO 4 Expires October 7, 2004 April 7, 2004 5 Intended Category: Informational 7 Using algorithms GOST R 34.10-2001, GOST R 34.10-94 8 and GOST R 34.11-94 for XML Digital Signatures 10 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or made obsolete by other documents at 24 any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 This document specifies how to use Russian national cryptographic 36 standards GOST R 34.10-2001, GOST R 34.10-94 and GOST R 34.11-94 37 digital signatures and public keys with XML Signatures [XMLDSIG]. 38 The mechanism specified provides integrity, message authentication, 39 and/or signer authentication services for data of any type, whether 40 located within the XML that includes the signature or included by 41 reference. 43 Table of Contents 45 1 Introduction. . . . . . . . . . . . . . . . . . . . . . . 2 46 2 GOST R 34.10-94/2001. . . . . . . . . . . . . . . . . . . 3 47 3 Specifying GOST within XMLDSIG. . . . . . . . . . . . . . 3 48 3.1 Version, Namespaces and Identifiers . . . . . . . . . . . 3 49 3.2 XML Schema Preamble and DTD Replacement . . . . . . . . . 3 50 3.2.1 XML Schema Preamble . . . . . . . . . . . . . . . . . . . 3 51 3.2.2 DTD Replacement . . . . . . . . . . . . . . . . . . . . . 3 52 3.3 SignatureMethod Algorithms. . . . . . . . . . . . . . . . 3 53 3.3.1 Public Key Signature Algorithms . . . . . . . . . . . . . 3 54 3.3.2 Message Authentication Code Algorithms. . . . . . . . . . 3 55 3.4 DigestMethod Algorithms . . . . . . . . . . . . . . . . . 4 56 3.5 GOST Key Values . . . . . . . . . . . . . . . . . . . . . 4 57 3.5.1 Key Value Root Element. . . . . . . . . . . . . . . . . . 4 58 3.5.2 GOST Parameters . . . . . . . . . . . . . . . . . . . . . 4 59 4 Security Considerations . . . . . . . . . . . . . . . . . 8 60 Appendix A: Aggregate XML Schema. . . . . . . . . . . . . . . . 9 61 Appendix B: Aggregate DTD . . . . . . . . . . . . . . . . . . . 9 62 References. . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12 64 Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . 12 65 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 14 67 1 Introduction 69 This document specifies how to use GOST R 34.10-2001, GOST R 34.10-94 70 and GOST R 34.11-94 digital signatures and public keys with XML 71 Signatures [XMLDSIG]. Therein only two digital signature methods are 72 defined: RSA signatures and DSA (DSS) signatures, one message digest 73 method: SHA-1 and one message authentification method: HMAC-SHA1. 74 This document introduces GOST R 34.10-94/2001 signatures as 75 additional methods. 77 This document uses both XML Schemas [XML-schema] (normative) and DTDs 78 [XML] (informational) for specifying the corresponding XML 79 structures. 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 82 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 83 this document are to be interpreted as described in [RFC 2119]. 85 2 GOST R 34.10-94/2001 87 Algorithms GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 88 have been developed by Russian Federal Agency of Governmental 89 Communication and Information (FAGCI) and "All-Russian Scientific and 90 Research Institute of Standardization". They are described in 91 [GOSTR341094], [GOSTR34102001] and [GOSTR341194]. Recomended 92 parameters for those algorithms are described in [CPALGS]. 94 The only hash function used with GOST R 34.10-94/2001 is GOST R 95 34.11-94. 97 3 Specifying GOST within XMLDSIG 99 This section specifies the details of how to use GOST algorithms with 100 XML Signature Syntax and Processing [XMLDSIG]. It relies heavily on 101 the syntax and namespace defined in [XMLDSIG]. 103 3.1 Version, Namespaces and Identifiers 105 This specification makes no provision for an explicit version number 106 in the syntax. If a future version is needed, it will use a different 107 namespace. 109 The XML namespace [XML-ns] URI that MUST be used by implementations 110 of this (dated) specification is: 111 http://www.w3.org/2001/04/xmldsig-more# 113 Elements in the namespace of the [XMLDSIG] specification are marked 114 as such by using the namespace prefix "dsig" in the remaining 115 sections of this document. 117 3.2 XML Schema Preamble and DTD Replacement 119 3.2.1 XML Schema Preamble 121 The subsequent preamble is to be used with the XML Schema definitions 122 given in the remaining sections of this document. 124 125 132 3.2.2 DTD Replacement 134 In order to include GOST in XML-signature syntax, the following 135 definition of the entity Key.ANY SHOULD replace the one in [XMLDSIG]: 137 139 3.3 SignatureMethod Algorithms 141 3.3.1 Public Key Signature Algorithms 143 The input to the GOST R 34.10-94/2001 algorithms is the canonicalized 144 representation of the dsig:SignedInfo element as specified in Section 145 3 of [XMLDSIG]. 147 The output consists of a pair of integers usually referred by the 148 pair (r, s). The signature value (text value of element 149 dsig:SignatureValue - see section 4.2 of [XMLDSIG]) consists of the 150 base64 encoding of the concatenation of two octet-streams that 151 respectively result from the octet-encoding of the values r and s. 152 This concatenation is described in section 2.2 of [CPPK]. 154 The identifier for the GOST R 34.10-94 signature algorithm is: 155 http://www.w3.org/2001/04/xmldsig-more#gostr341094-gostr3411 157 The identifier for the GOST R 34.10-2001 signature algorithm is: 158 http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411 160 3.3.2 Message Authentication Code Algorithms 162 GOST R 34.11-94 can also be used in HMAC as described in section 163 2.2.1 of [XMLURI] for HMAC-MD5. 165 Identifier: 166 http://www.w3.org/2001/04/xmldsig-more#hmac-gostr3411 168 3.4 DigestMethod Algorithms 170 The identifier for the GOST R 34.11-94 digest algorithm is: 171 http://www.w3.org/2001/04/xmldsig-more#gostr3411 173 GOST R 34.11-94 digest is a 256-bit string. The content of the 174 DigestValue element shall be the base64 encoding of this bit string 175 viewed as a 32-octet octet stream. 177 3.5 GOST Key Values 179 The syntax used for GOST key values closely follows the ASN.1 syntax 180 defined in [CPPK]. 182 3.5.1 Key Value Root Element 184 Elements GOST3410-94-KeyValue and GOST3410-2001-KeyValue are used for 185 encoding GOST public keys. For use with XMLDSIG simply use these 186 elements inside dsig:KeyValue, such as the predefined elements 187 dsig:RSAKeyValue or dsig:DSAKeyValue. 189 The elements consist of an optional subelement Parameters and the 190 mandatory subelement PublicKey. If Parameters are missing in an 191 instance, this means that the application knows about them from other 192 means (implicitly). 194 Schema Definition: 196 198 201 202 203 206 207 208 209 210 211 214 215 216 218 DTD Definition: 220 222 224 226 3.5.2 GOST Parameters 228 Gost paramaters contain three OIDs: publicKeyParamSet, digestParamSet 229 and optional encryptionParamSet. Parameter values, corresponding to 230 these OIDs, can be found in [CPALGS]. 232 Schema Definition: 234 236 238 239 240 243 245 248 249 250 251 252 254 256 259 260 262 263 264 265 266 268 DTD Definition: 270 273 276 277 278 280 4 Security Considerations 282 It is RECCOMENDED, that applications verify signature values and 283 subject public keys to conform to [GOSTR34102001], [GOSTR341094] 284 standards prior to their use. 286 For security discussion concerning use of algorithm parameters, see 287 section Security Considerations from [CPALGS]. 289 Appendix A: Aggregate XML Schema 290 291 298 299 300 303 304 305 306 307 308 311 312 313 315 316 317 319 321 324 325 326 327 328 330 332 335 336 337 338 339 340 341 343 Appendix B: Aggregate DTD 345 347 349 350 353 356 357 358 360 References 362 [GOSTR341094] "Information technology. Cryptographic Data Security. 363 Produce and check procedures of Electronic Digital 364 Signatures based on Asymmetric Cryptographic Algo- 365 rithm.", GOST R 34.10-94, Gosudarstvennyi Standard of 366 Russian Federation, Government Committee of the Rus- 367 sia for Standards, 1994. (In Russian); 369 [GOSTR34102001] "Information technology. Cryptographic Data Secu- 370 rity.Signature and verification processes of [elec- 371 tronic] digital signature.", GOST R 34.10-2001, Gosu- 372 darstvennyi Standard of Russian Federation, Govern- 373 ment Committee of the Russia for Standards, 2001. (In 374 Russian); 376 [GOSTR341194] "Information technology. Cryptographic Data Security. 377 Hashing function.", GOST R 34.10-94, Gosudarstvennyi 378 Standard of Russian Federation, Government Committee 379 of the Russia for Standards, 1994. (In Russian); 381 [RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, March 1997. 384 [XMLDSIG] Eastlake, D., Reagle, J., and Solo, D., XML-Signature 385 Syntax and Processing. W3C Recommendation, February 386 2002. http://www.w3.org/TR/2002/REC-xmldsig- 387 core-20020212/ 389 [XML-schema] Beech, D., Maloney, M., Mendelsohn, N., and Thompson, 390 H., XML Schema Part 1: Structures, W3C Recommenda- 391 tion, May 2001. http://www.w3.org/TR/2001/REC- 392 xmlschema-1-20010502/ Biron, P., and Malhotra, A., ML 393 Schema Part 2: Datatypes, W3C Recommendation, May 394 2001. http://www.w3.org/TR/2001/REC- 395 xmlschema-2-20010502/ 397 [XMLURI] Donald E. Eastlake 3rd "Additional XML Security 398 URIs", draft-eastlake-xmldsig-uri-05.txt 400 [CPALGS] V. Popov, I. Kurepkin, S. Leontiev "Additional cryp- 401 tographic algorithms for use with GOST 28147-89, GOST 402 R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 403 algorithms.", draft-popov-cryptopro-cpalgs-01.txt 405 [CPPK] S. Leontiev, D. Shefanovskij, "Algorithms and Identi- 406 fiers for the Internet X.509 Public Key Infrastruc- 407 ture Certificates and Certificate Revocation List 408 (CRL), corresponding to the algorithms GOST R 409 34.10-94, GOST R 34.10-2001, GOST R 34.11-94", draft- 410 ietf-pkix-gost-cppk-01.txt 412 Acknowledgments 414 This document was created in accordance with "Russian Cryptographic 415 Software Compatibility Agreement", signed by FGUE STC "Atlas", 416 CRYPTO-PRO, Factor-TC, MD PREI, Infotecs GmbH, SPRCIS (SPbRCZI), 417 Cryptocom, R-Alpha. The aim of this agreement is to achieve mutual 418 compatibility of the products and solutions. 420 The authors wish to thank: 422 Microsoft Corporation Russia for provided information about 423 company products and solutions, and also for technical consulting 424 in PKI. 426 RSA Security Russia and Demos Co Ltd for active colaboration and 427 critical help in creation of this document. 429 NIP Informzachita for compatibility testing of the proposed data 430 formats while incorporating them into company products. 432 Citrix Inc for help in compatibility testing Citrix products for 433 Microsoft Windows. 435 Russ Hously (Vigil Security, LLC, housley@vigilsec.com) and 436 Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru) for initiative, 437 creating this document. 439 This document is based on a contribution of CRYPTO-PRO company. Any 440 substantial use of the text from this document must acknowledge 441 CRYPTO-PRO. CRYPTO-PRO requests that all material mentioning or 442 referencing this document identify this as "CRYPTO-PRO CPTLS". 444 Author's Addresses 446 Serguei Leontiev 447 CRYPTO-PRO 448 38, Obraztsova, 449 Moscow, 127018, Russian Federation 450 EMail: lse@cryptopro.ru 452 Grigorij Chudov 453 CRYPTO-PRO 454 38, Obraztsova, 455 Moscow, 127018, Russian Federation 456 EMail: chudov@cryptopro.ru 458 Full Copyright Statement 460 Copyright (C) The Internet Society (2003). All Rights Reserved. 462 This document and translations of it may be copied and furnished to 463 others, and derivative works that comment on or otherwise explain it 464 or assist in its implementation may be prepared, copied, published 465 and distributed, in whole or in part, without restriction of any 466 kind, provided that the above copyright notice and this paragraph are 467 included on all such copies and derivative works. However, this 468 document itself may not be modified in any way, such as by removing 469 the copyright notice or references to the Internet Society or other 470 Internet organizations, except as needed for the purpose of 471 developing Internet standards in which case the procedures for 472 copyrights defined in the Internet Standards process must be 473 followed, or as required to translate it into languages other than 474 English. 476 The limited permissions granted above are perpetual and will not be 477 revoked by the Internet Society or its successors or assigns. 479 This document and the information contained herein is provided on an 480 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 481 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 482 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 483 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 484 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.