doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc5933.txt b/doc/rfc/rfc5933.txt
new file mode 100644
index 0000000..77bd232
--- /dev/null
+++ b/doc/rfc/rfc5933.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+