+++ /dev/null
-DNS Extensions working group V.Dolmatov, Ed.
-Internet-Draft Cryptocom Ltd.
-Intended status: Standards Track March 06, 2010
-Expires: September 06, 2010
-
-
- Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
- for DNSSEC
- draft-ietf-dnsext-dnssec-gost-07
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on September 06 2010.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with
- respect to this document. Code Components extracted from this
- document must include Simplified BSD License text as described in
- Section 4.e of the Trust Legal Provisions and are provided without
- warranty as described in the Simplified BSD License.
-
-Abstract
-
- This document describes how to produce signature and hash using
- GOST (R 34.10-2001, R 34.11-94) algorithms foor DNSKEY, RRSIG and DS
- resource records for use in the Domain Name System Security
- Extensions (DNSSEC).
-
-V.Dolmatov Expires September 06, 2010 [Page 1]\f
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
- 2.1. Using a public key with existing cryptographic libraries. . 3
- 2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . . 3
- 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4
- 3.1 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 4
- 4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
- 4.1 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . . 5
- 5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5
- 5.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 5.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5
- 5.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . . 5
- 6. Implementation Considerations . . . . . . . . . . . . . . . . . 5
- 6.1. Support for GOST signatures . . . . . . . . . . . . . . . . 5
- 6.2. Support for NSEC3 Denial of Existence . . . . . . . . . . . 5
- 6.3. Byte order . . . . . . . . . . . . . . . . . . . . . . . . 5
- 7. Security consideration . . . . . . . . . . . . . . . . . . . . . 5
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6
- 10.2. Informative References . . . . . . . . . . . . . . . . . . 7
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical distributed
- database for Internet Naming. The DNS has been extended to use
- cryptographic keys and digital signatures for the verification of the
- authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034
- [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
- Extensions, called DNSSEC.
-
- RFC 4034 describes how to store DNSKEY and RRSIG resource records,
- and specifies a list of cryptographic algorithms to use. This
- document extends that list with the signature and hash algorithms
- GOST [GOST3410, GOST3411],
- and specifies how to store DNSKEY data and how to produce
- RRSIG resource records with these hash algorithms.
-
- Familiarity with DNSSEC and GOST signature and hash
- algorithms is assumed in this document.
-
- The term "GOST" is not officially defined, but is usually used to
- refer to the collection of the Russian cryptographic algorithms
- GOST R 34.10-2001[DRAFT1], GOST R 34.11-94[DRAFT2],
- GOST 28147-89[DRAFT3].
- Since GOST 28147-89 is not used in DNSSEC, "GOST" will only refer to
- the GOST R 34.10-2001 and GOST R 34.11-94 in this document.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-V.Dolmatov Expires September 06, 2010 [Page 2]\f
-
-2. DNSKEY Resource Records
-
- The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
-
- GOST R 34.10-2001 public keys are stored with the algorithm number
- {TBA1}.
-
- The wire format of the public key is compatible with
- RFC 4491 [RFC4491]:
-
- According to [GOST3410], a public key is a point on the elliptic
- curve Q = (x,y).
-
- The wire representation of a public key MUST contain 64 octets,
- where the first 32 octets contain the little-endian representation
- of x and the second 32 octets contain the little-endian
- representation of y.
- This corresponds to the binary representation of (<y>256||<x>256)
- from [GOST3410], ch. 5.3.
-
- Corresponding public key parameters are those identified by
- id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
- and the digest parameters are those identified by
- id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
-
-2.1. Using a public key with existing cryptographic libraries
-
- Existing GOST-aware cryptographic libraries at the time of this
- document writing are capable to read GOST public keys via a generic
- X509 API if the key is encoded according to RFC 4491 [RFC4491],
- section 2.3.2.
-
- To make this encoding from the wire format of a GOST public key
- with the parameters used in this document, prepend the 64 octets
- of key data with the following 37-byte sequence:
-
- 0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30
- 0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
- 0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
-
-2.2. GOST DNSKEY RR Example
-
- Given a private key with the following value (the value of GostAsn1
- field is split here into two lines to simplify reading; in the
- private key file it must be in one line):
-
- Private-key-format: v1.2
- Algorithm: {TBA1} (ECC-GOST)
- GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgp9c
- t2LQaNS1vMKPLEN9zHYjLPNMIQN6QB9vt3AghZFA=
-
-
-V.Dolmatov Expires September 06, 2010 [Page 3]\f
-
- The following DNSKEY RR stores a DNS zone key for example.net
-
- example.net. 86400 IN DNSKEY 256 3 {TBA1} (
- GtTJjmZKUXV+lHLG/6crB6RCR+EJR51Islpa
- 6FqfT0MUfKhSn1yAo92+LJ0GDssTiAnj0H0I
- 9Jrfial/yyc5Og==
- ) ; key id = 10805
-
-3. RRSIG Resource Records
-
- The value of the signature field in the RRSIG RR follows RFC 4490
- [RFC4490] and is calculated as follows. The values for the RDATA
- fields that precede the signature data are specified
- in RFC 4034 [RFC4034].
-
- hash = GOSTR3411(data)
-
- where "data" is the wire format data of the resource record set
- that is signed, as specified in RFC 4034 [RFC4034].
-
- Hash MUST be calculated with GOST R 34.11-94 parameters identified
- by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
- Signature is calculated from the hash according to the
- GOST R 34.10-2001 standard and its wire format is compatible with
- RFC 4490 [RFC4490].
-
- Quoting RFC 4490:
-
- "The signature algorithm GOST R 34.10-2001 generates a digital
- signature in the form of two 256-bit numbers, r and s. Its octet
- string representation consists of 64 octets, where the first 32
- octets contain the big-endian representation of s and the second 32
- octets contain the big-endian representation of r."
-
-3.1. RRSIG RR Example
-
- With the private key from section 2.2 sign the following RRSet,
- consisting of one A record:
-
- www.example.net. 3600 IN A 192.0.2.1
-
- Setting the inception date to 2000-01-01 00:00:00 UTC and the
- expiration date to 2030-01-01 00:00:00 UTC, the following signature
- should be created (assuming {TBA1}==249 until proper code is
- assigned by IANA)
-
- www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 (
- 20000101000000 10805 example.net.
- k3m0r5bm6kFQmcRlHshY3jIj7KL6KTUsPIAp
- Vy466khKuWEUoVvSkqI+9tvMQySQgZcEmS0W
- HRFSm0XS5YST5g== )
-
-V.Dolmatov Expires September 06, 2010 [Page 4]\f
-
- Note: Several ECC-GOST signatures calculated for the same message text
- will differ because of using of a random element is used in signature
- generation process.
-
-4. DS Resource Records
-
- GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest
- type {TBA2}.The wire format of a digest value is compatible with
- RFC4490 [RFC4490], that is digest is in little-endian representation.
-
-
- The digest MUST always be calculated with GOST R 34.11-94 parameters
- identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-4.1. DS RR Example
-
- For key signing key (assuming {TBA1}==249 until proper code is
- assigned by IANA)
-
- example.net. 86400 DNSKEY 257 3 {TBA1} (
- 1aYdqrVz3JJXEURLMdmeI7H1CyTFfPVFBIGA
- EabZFP+7NT5KPYXzjDkRbPWleEFbBilDNQNi
- q/q4CwA4WR+ovg==
- ) ; key id = 6204
-
- The DS RR will be
-
- example.net. 3600 IN DS 6204 {TBA1} {TBA2} (
- 0E6D6CB303F89DBCF614DA6E21984F7A62D08BDD0A05B3A22CC63D1B
- 553BC61E )
-
-5. Deployment Considerations
-
-5.1. Key Sizes
-
- According to RFC4357 [RFC4357], the key size of GOST public keys
- MUST be 512 bits.
-
-5.2. Signature Sizes
-
- According to the GOST signature algorithm specification [GOST3410],
- the size of a GOST signature is 512 bits.
-
-5.3. Digest Sizes
-
- According to the GOST R 34.11-94 [GOST3411], the size of a GOST
- digest is 256 bits.
-
-6. Implementation Considerations
-
-6.1. Support for GOST signatures
-
- DNSSEC aware implementations MAY be able to support RRSIG and
- DNSKEY resource records created with the GOST algorithms as
- defined in this document.
-
-V.Dolmatov Expires September 06, 2010 [Page 5]\f
-
-6.2. Support for NSEC3 Denial of Existence
-
- Any DNSSEC-GOST implementation MUST support both NSEC[RFC4035] and
- NSEC3 [RFC5155]
-
-6.3 Byte order
-
- Due to the fact that all existing industry implementations of GOST
- cryptographic libraries are returning GOST blobs without
- transformation from little-endian format and in order to avoid the
- necessity for DNSSEC developers to handle different cryptographic
- algorithms differently, it was chosen to send these blobs on the
- wire "as is" without transformation of endianness.
-
-7. Security considerations
-
- Currently, the cryptographic resistance of the GOST 34.10-2001
- digital signature algorithm is estimated as 2**128 operations
- of multiple elliptic curve point computations on prime modulus
- of order 2**256.
-
-
- Currently, the cryptographic resistance of GOST 34.11-94 hash
- algorithm is estimated as 2**128 operations of computations of a
- step hash function. (There is known method to reduce this
- estimate to 2**105 operations, but it demands padding the
- colliding message with 1024 random bit blocks each of 256 bit
- length, thus it cannot be used in any practical implementation).
-
-8. IANA Considerations
-
- This document updates the IANA registry "DNS Security Algorithm
- Numbers" [RFC4034]
- (http://www.iana.org/assignments/dns-sec-alg-numbers).
- The following entries are added to the registry:
- Zone Trans.
- Value Algorithm Mnemonic Signing Sec. References Status
- {TBA1} GOST R 34.10-2001 ECC-GOST Y * (this memo) OPTIONAL
-
- This document updates the RFC 4034 Digest Types assignment
- (section A.2)by adding the value and status for the GOST R 34.11-94
- algorithm:
-
- Value Algorithm Status
- {TBA2} GOST R 34.11-94 OPTIONAL
-
-9. Acknowledgments
-
- This document is a minor extension to RFC 4034 [RFC4034]. Also, we
- tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509],
- and RFC 4357 [RFC4357] for consistency. The authors of and
- contributors to these documents are gratefully acknowledged for
- their hard work.
-
-V.Dolmatov Expires September 06, 2010 [Page 6]\f
-
- The following people provided additional feedback and text: Dmitry
- Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen
- and Wouter Wijngaards.
-
-
-10. References
-
-10.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [RFC3110] Eastlake D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
- Name System (DNS)", RFC 3110, May 2001.
-
- [RFC4033] Arends R., Austein R., Larson M., Massey D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends R., Austein R., Larson M., Massey D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends R., Austein R., Larson M., Massey D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [GOST3410] "Information technology. Cryptographic data security.
- Signature and verification processes of [electronic]
- digital signature.", GOST R 34.10-2001, Gosudarstvennyi
- Standard of Russian Federation, Government Committee of
- the Russia for Standards, 2001. (In Russian)
-
- [GOST3411] "Information technology. Cryptographic Data Security.
- Hashing function.", GOST R 34.11-94, Gosudarstvennyi
- Standard of Russian Federation, Government Committee of
- the Russia for Standards, 1994. (In Russian)
-
- [RFC4357] Popov V., Kurepkin I., and S. Leontiev, "Additional
- Cryptographic Algorithms for Use with GOST 28147-89,
- GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
- Algorithms", RFC 4357, January 2006.
-
- [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89,
- GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001
- Algorithms with Cryptographic Message Syntax (CMS)",
- RFC 4490, May 2006.
-
- [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST
- R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
- Algorithms with the Internet X.509 Public Key
- Infrastructure Certificate and CRL Profile", RFC 4491,
- May 2006.
-
-V.Dolmatov Expires September 06, 2010 [Page 7]\f
-
-[RFC5155] B. Laurie, G. Sisson, R. Arends and D. Blacka, "DNS
- Security (DNSSEC) Hashed Authenticated Denial of
- Existence", RFC 5155, February 2008.
-
-10.2. Informative References
-
- [RFC4509] Hardaker W., "Use of SHA-256 in DNSSEC Delegation Signer
- (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
- [DRAFT1] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
- "GOST R 34.10-2001 digital signature algorithm"
- draft-dolmatov-cryptocom-gost34102001-08, 12.12.09
- work in progress.
-
-
- [DRAFT2] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
- "GOST R 34.11-94 Hash function algorithm"
- draft-dolmatov-cryptocom-gost341194-07, 12.12.09
- work in progress.
-
- [DRAFT3] Dolmatov V., Kabelev D., Ustinov I., Emelyanova I.,
- "GOST 28147-89 encryption, decryption and MAC algorithms"
- draft-dolmatov-cryptocom-gost2814789-08, 12.12.09
- work in progress.
-
-V.Dolmatov Expires September 06, 2010 [Page 8]\f
-
-
-Authors' Addresses
-
-
-Vasily Dolmatov, Ed.
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: dol@cryptocom.ru
-
-Artem Chuprina
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: ran@cryptocom.ru
-
-Igor Ustinov
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: igus@cryptocom.ru
-
-V.Dolmatov Expires September 06, 2010 [Page 9]\f
-
--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) V. Dolmatov, Ed.
+Request for Comments: 5933 A. Chuprina
+Category: Standards Track I. Ustinov
+ISSN: 2070-1721 Cryptocom Ltd.
+ July 2010
+
+
+ Use of GOST Signature Algorithms in DNSKEY
+ and RRSIG Resource Records for DNSSEC
+
+Abstract
+
+ This document describes how to produce digital signatures and hash
+ functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms
+ for DNSKEY, RRSIG, and DS resource records, for use in the Domain
+ Name System Security Extensions (DNSSEC).
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5933.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+Dolmatov, et al. Standards Track [Page 1]
+\f
+RFC 5933 Use of GOST Signatures in DNSSEC July 2010
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
+ 2.1. Using a Public Key with Existing Cryptographic
+ Libraries . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . . 4
+ 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 5
+ 4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 5
+ 5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 6
+ 5.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . . 6
+ 6. Implementation Considerations . . . . . . . . . . . . . . . . . 6
+ 6.1. Support for GOST Signatures . . . . . . . . . . . . . . . . 6
+ 6.2. Support for NSEC3 Denial of Existence . . . . . . . . . . . 6
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 8
+
+1. Introduction
+
+ The Domain Name System (DNS) is the global hierarchical distributed
+ database for Internet Naming. The DNS has been extended to use
+ cryptographic keys and digital signatures for the verification of the
+ authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034
+ [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
+ Extensions, called DNSSEC.
+
+ RFC 4034 describes how to store DNSKEY and RRSIG resource records,
+ and specifies a list of cryptographic algorithms to use. This
+ document extends that list with the signature and hash algorithms
+ GOST R 34.10-2001 ([GOST3410], [RFC5832]) and GOST R 34.11-94
+ ([GOST3411], [RFC5831]), and specifies how to store DNSKEY data and
+ how to produce RRSIG resource records with these algorithms.
+
+ Familiarity with DNSSEC and with GOST signature and hash algorithms
+ is assumed in this document.
+
+ The term "GOST" is not officially defined, but is usually used to
+ refer to the collection of the Russian cryptographic algorithms
+ GOST R 34.10-2001 [RFC5832], GOST R 34.11-94 [RFC5831], and
+
+
+
+Dolmatov, et al. Standards Track [Page 2]
+\f
+RFC 5933 Use of GOST Signatures in DNSSEC July 2010
+
+
+ GOST 28147-89 [RFC5830]. Since GOST 28147-89 is not used in DNSSEC,
+ "GOST" will only refer to GOST R 34.10-2001 and GOST R 34.11-94 in
+ this document.
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+2. DNSKEY Resource Records
+
+ The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
+
+ GOST R 34.10-2001 public keys are stored with the algorithm
+ number 12.
+
+ The wire format of the public key is compatible with RFC 4491
+ [RFC4491]:
+
+ According to [GOST3410] and [RFC5832], a public key is a point on the
+ elliptic curve Q = (x,y).
+
+ The wire representation of a public key MUST contain 64 octets, where
+ the first 32 octets contain the little-endian representation of x and
+ the second 32 octets contain the little-endian representation of y.
+
+ Corresponding public key parameters are those identified by
+ id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
+ and the digest parameters are those identified by
+ id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
+
+2.1. Using a Public Key with Existing Cryptographic Libraries
+
+ At the time of this writing, existing GOST-aware cryptographic
+ libraries are capable of reading GOST public keys via a generic X509
+ API if the key is encoded according to RFC 4491 [RFC4491],
+ Section 2.3.2.
+
+ To make this encoding from the wire format of a GOST public key with
+ the parameters used in this document, prepend the 64 octets of key
+ data with the following 37-byte sequence:
+
+ 0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30
+ 0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
+ 0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
+
+
+
+
+
+Dolmatov, et al. Standards Track [Page 3]
+\f
+RFC 5933 Use of GOST Signatures in DNSSEC July 2010
+
+
+2.2. GOST DNSKEY RR Example
+
+ Given a private key with the following value (the value of the
+ GostAsn1 field is split here into two lines to simplify reading; in
+ the private key file, it must be in one line):
+
+ Private-key-format: v1.2
+ Algorithm: 12 (ECC-GOST)
+ GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQg/9M
+ iXtXKg9FDXDN/R9CmVhJDyuzRAIgh4tPwCu4NHIs=
+
+ The following DNSKEY RR stores a DNS zone key for example.net:
+
+ example.net. 86400 IN DNSKEY 256 3 12 (
+ aRS/DcPWGQj2wVJydT8EcAVoC0kXn5pDVm2I
+ MvDDPXeD32dsSKcmq8KNVzigjL4OXZTV+t/6
+ w4X1gpNrZiC01g==
+ ) ; key id = 59732
+
+3. RRSIG Resource Records
+
+ The value of the signature field in the RRSIG RR follows RFC 4490
+ [RFC4490] and is calculated as follows. The values for the RDATA
+ fields that precede the signature data are specified in RFC 4034
+ [RFC4034].
+
+ hash = GOSTR3411(data)
+
+ where "data" is the wire format data of the resource record set that
+ is signed, as specified in RFC 4034 [RFC4034].
+
+ The hash MUST be calculated with GOST R 34.11-94 parameters
+ identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
+
+ The signature is calculated from the hash according to the
+ GOST R 34.10-2001 standard, and its wire format is compatible with
+ RFC 4490 [RFC4490].
+
+ Quoting RFC 4490:
+
+ "The signature algorithm GOST R 34.10-2001 generates a digital
+ signature in the form of two 256-bit numbers, r and s. Its octet
+ string representation consists of 64 octets, where the first
+ 32 octets contain the big-endian representation of s and the second
+ 32 octets contain the big-endian representation of r".
+
+
+
+
+
+
+Dolmatov, et al. Standards Track [Page 4]
+\f
+RFC 5933 Use of GOST Signatures in DNSSEC July 2010
+
+
+3.1. RRSIG RR Example
+
+ With the private key from Section 2.2, sign the following RRSet,
+ consisting of one A record:
+
+ www.example.net. 3600 IN A 192.0.2.1
+
+ Setting the inception date to 2000-01-01 00:00:00 UTC and the
+ expiration date to 2030-01-01 00:00:00 UTC, the following signature
+ RR will be valid:
+
+ www.example.net. 3600 IN RRSIG A 12 3 3600 20300101000000 (
+ 20000101000000 59732 example.net.
+ 7vzzz6iLOmvtjs5FjVjSHT8XnRKFY15ki6Kp
+ kNPkUnS8iIns0Kv4APT+D9ibmHhGri6Sfbyy
+ zi67+wBbbW/jrA== )
+
+ Note: The ECC-GOST signature algorithm uses random data, so the
+ actual computed signature value will differ between signature
+ calculations.
+
+4. DS Resource Records
+
+ The GOST R 34.11-94 digest algorithm is denoted in DS RRs by the
+ digest type 3. The wire format of a digest value is compatible with
+ RFC 4490 [RFC4490], that is, the digest is in little-endian
+ representation.
+
+ The digest MUST always be calculated with GOST R 34.11-94 parameters
+ identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
+
+4.1. DS RR Example
+
+ For Key Signing Key (KSK):
+
+ example.net. 86400 DNSKEY 257 3 12 (
+ LMgXRHzSbIJGn6i16K+sDjaDf/k1o9DbxScO
+ gEYqYS/rlh2Mf+BRAY3QHPbwoPh2fkDKBroF
+ SRGR7ZYcx+YIQw==
+ ) ; key id = 40692
+
+ The DS RR will be
+
+ example.net. 3600 IN DS 40692 12 3 (
+ 22261A8B0E0D799183E35E24E2AD6BB58533CBA7E3B14D659E9CA09B
+ 2071398F )
+
+
+
+
+
+Dolmatov, et al. Standards Track [Page 5]
+\f
+RFC 5933 Use of GOST Signatures in DNSSEC July 2010
+
+
+5. Deployment Considerations
+
+5.1. Key Sizes
+
+ According to RFC 4357 [RFC4357], the key size of GOST public keys
+ MUST be 512 bits.
+
+5.2. Signature Sizes
+
+ According to the GOST R 34.10-2001 digital signature algorithm
+ specification ([GOST3410], [RFC5832]), the size of a GOST signature
+ is 512 bits.
+
+5.3. Digest Sizes
+
+ According to GOST R 34.11-94 ([GOST3411], [RFC5831]), the size of a
+ GOST digest is 256 bits.
+
+6. Implementation Considerations
+
+6.1. Support for GOST Signatures
+
+ DNSSEC-aware implementations MAY be able to support RRSIG and DNSKEY
+ resource records created with the GOST algorithms as defined in this
+ document.
+
+6.2. Support for NSEC3 Denial of Existence
+
+ Any DNSSEC-GOST implementation MUST support both NSEC [RFC4035] and
+ NSEC3 [RFC5155].
+
+7. Security Considerations
+
+ Currently, the cryptographic resistance of the GOST R 34.10-2001
+ digital signature algorithm is estimated as 2**128 operations of
+ multiple elliptic curve point computations on prime modulus of order
+ 2**256.
+
+ Currently, the cryptographic resistance of the GOST R 34.11-94 hash
+ algorithm is estimated as 2**128 operations of computations of a step
+ hash function. (There is a known method to reduce this estimate to
+ 2**105 operations, but it demands padding the colliding message with
+ 1024 random bit blocks each of 256-bit length; thus, it cannot be
+ used in any practical implementation).
+
+
+
+
+
+
+
+Dolmatov, et al. Standards Track [Page 6]
+\f
+RFC 5933 Use of GOST Signatures in DNSSEC July 2010
+
+
+8. IANA Considerations
+
+ This document updates the IANA registry "DNS Security Algorithm
+ Numbers" [RFC4034]. The following entries have been added to the
+ registry:
+
+ Zone Trans.
+ Value Algorithm Mnemonic Signing Sec. References Status
+ 12 GOST R 34.10-2001 ECC-GOST Y * RFC 5933 OPTIONAL
+
+ This document updates the RFC 4034 Digest Types assignment
+ ([RFC4034], Section A.2) by adding the value and status for the
+ GOST R 34.11-94 algorithm:
+
+ Value Algorithm Status
+ 3 GOST R 34.11-94 OPTIONAL
+
+9. Acknowledgments
+
+ This document is a minor extension to RFC 4034 [RFC4034]. Also, we
+ tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509],
+ and RFC 4357 [RFC4357] for consistency. The authors of and
+ contributors to these documents are gratefully acknowledged for their
+ hard work.
+
+ The following people provided additional feedback, text, and valuable
+ assistance: Dmitry Burkov, Jaap Akkerhuis, Olafur Gundmundsson,
+ Jelte Jansen, and Wouter Wijngaards.
+
+10. References
+
+10.1. Normative References
+
+ [GOST3410] "Information technology. Cryptographic data security.
+ Signature and verification processes of [electronic]
+ digital signature.", GOST R 34.10-2001, Gosudarstvennyi
+ Standard of Russian Federation, Government Committee of
+ Russia for Standards, 2001. (In Russian).
+
+ [GOST3411] "Information technology. Cryptographic data security.
+ Hashing function.", GOST R 34.11-94, Gosudarstvennyi
+ Standard of Russian Federation, Government Committee of
+ Russia for Standards, 1994. (In Russian).
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Dolmatov, et al. Standards Track [Page 7]
+\f
+RFC 5933 Use of GOST Signatures in DNSSEC July 2010
+
+
+ [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
+ Domain Name System (DNS)", RFC 3110, May 2001.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, March 2005.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional
+ Cryptographic Algorithms for Use with GOST 28147-89,
+ GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
+ Algorithms", RFC 4357, January 2006.
+
+ [RFC4490] Leontiev, S., Ed. and G. Chudov, Ed., "Using the
+ GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and
+ GOST R 34.10-2001 Algorithms with Cryptographic Message
+ Syntax (CMS)", RFC 4490, May 2006.
+
+ [RFC4491] Leontiev, S., Ed. and D. Shefanovski, Ed., "Using the
+ GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
+ Algorithms with the Internet X.509 Public Key
+ Infrastructure Certificate and CRL Profile", RFC 4491,
+ May 2006.
+
+ [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+ Security (DNSSEC) Hashed Authenticated Denial of
+ Existence", RFC 5155, March 2008.
+
+10.2. Informative References
+
+ [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+ (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+ [RFC5830] Dolmatov, V., Ed., "GOST 28147-89: Encryption,
+ Decryption, and Message Authentication Code (MAC)
+ Algorithms", RFC 5830, March 2010.
+
+ [RFC5831] Dolmatov, V., Ed., "GOST R 34.11-94: Hash Function
+ Algorithm", RFC 5831, March 2010.
+
+
+
+
+
+Dolmatov, et al. Standards Track [Page 8]
+\f
+RFC 5933 Use of GOST Signatures in DNSSEC July 2010
+
+
+ [RFC5832] Dolmatov, V., Ed., "GOST R 34.10-2001: Digital Signature
+ Algorithm", RFC 5832, March 2010.
+
+Authors' Addresses
+
+ Vasily Dolmatov (editor)
+ Cryptocom Ltd.
+ 14/2, Kedrova St.
+ Moscow, 117218
+ Russian Federation
+
+ Phone: +7 499 124 6226
+ EMail: dol@cryptocom.ru
+
+
+ Artem Chuprina
+ Cryptocom Ltd.
+ 14/2, Kedrova St.
+ Moscow, 117218
+ Russian Federation
+
+ Phone: +7 499 124 6226
+ EMail: ran@cryptocom.ru
+
+
+ Igor Ustinov
+ Cryptocom Ltd.
+ 14/2, Kedrova St.
+ Moscow, 117218
+ Russian Federation
+
+ Phone: +7 499 124 6226
+ EMail: igus@cryptocom.ru
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dolmatov, et al. Standards Track [Page 9]
+\f
projects / thirdparty / bind9.git / commitdiff
