One document matched: draft-schmidt-brainpool-dnssec-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!--
XML2RFC offers an include feature described in the XML2RFC README
file. That syntax, however, contradicts the DTD requirements to
have <reference> elements within the <references> element, so an
XML parser is likely to find your XML file invalid. It may be
possible that XML2RFC will change their DTD so that the XML file
remains valid when their style of include is used.
In the meantime therefore, we use an alternative valid-XML approach
to includes, which unfortunately require that define your includes
at the beginning of the file. Since the biggest benefit of includes
is for references, this requires that your references be defined in
ENTITY clauses here before being "included" and cited elsewhere in
the file.
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY rfc2863 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2863.xml">
<!ENTITY rfc3418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3418.xml">
<!ENTITY rfc4181 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4181.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
<!ENTITY rfc2579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml">
<!ENTITY rfc2580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml">
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<!--
This template is for authors of IETF specifications containing MIB
modules. This template can be used as a starting point to produce
specifications that comply with the Operations & Management Area
guidelines for MIB module documents.
-->
<!--
Throughout this template, the marker "<xref target='TODO' />" is used to indicate an
element or text that requires replacement or removal.
-->
<!-- Intellectual Property section -->
<!--
The Intellectual Property section will be generated automatically by
XML2RFC, based on the ipr attribute in the rfc element.
-->
<!--
<xref target='TODO' />For Internet-drafts, indicate which intellectual property notice
to use per the rules of RFC3978.
Specify this in the ipr attribute. The value can be:
full3978 -
noModification3978 -
noDerivatives3978 -
<xref target='TODO' /> Specify the category attribute per RFC2026
options are info, std, bcp, or exp.
<xref target='TODO' /> if this document updates an RFC, specify the RFC in the
"updates" attribute
-->
<rfc category="info" submissionType="IETF" consensus="no" ipr="trust200902" docName="draft-schmidt-brainpool-dnssec-03" >
<front>
<title abbrev="ECC Brainpool Curves for TLS">ECC Brainpool Curves for DNSSEC</title>
<!-- see RFC2223 for guidelines regarding author names -->
<author fullname="Jörn-Marc Schmidt" initials="J.-M.S."
surname="Schmidt">
<organization>secunet Security Networks</organization>
<address>
<postal>
<street>Mergenthaler Allee 77</street>
<city>65760 Eschborn</city>
<country>Germany</country>
</postal>
<phone>+49 201 5454 3694</phone>
<email>joern-marc.schmidt@secunet.com</email>
</address>
</author>
<author fullname="Johannes Merkle" initials="J.M."
surname="Merkle">
<organization>secunet Security Networks</organization>
<address>
<postal>
<street>Mergenthaler Allee 77</street>
<city>65760 Eschborn</city>
<country>Germany</country>
</postal>
<phone>+49 201 5454 3091</phone>
<email>johannes.merkle@secunet.com</email>
</address>
</author>
<author fullname="Manfred Lochter" initials="M.L."
surname="Lochter">
<organization>BSI</organization>
<address>
<postal>
<street>Postfach 200363</street>
<city>53133 Bonn</city>
<country>Germany</country>
</postal>
<phone>+49 228 9582 5643</phone>
<email>manfred.lochter@bsi.bund.de</email>
</address>
</author>
<!-- <xref target='TODO' />: month and day will be generated automatically by XML2RFC;
be sure the year is current.
-->
<date year="2015" />
<workgroup></workgroup>
<keyword>DNSSEC, Elliptic Curve Cryptography, Brainpool</keyword>
<abstract>
<t>This document specifies the use of ECDSA with ECC Brainpool curves in DNS Security (DNSSEC). It comprises curves of two different sizes.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In <xref target='RFC5639' /> a new set of elliptic curve groups over finite prime fields for use in cryptographic applications is specified. These groups, denoted as ECC Brainpool curves, were generated in a verifiable pseudo-random way and comply with the security requirements of relevant standards from ISO <xref target='ISO1' /> <xref target='ISO2' />, ANSI <xref target='ANSI' />, NIST <xref target='FIPS-186-4' />, and SecG <xref target='SEC2' />. </t>
<t><xref target='RFC6605' /> defines the usage of the Elliptic Curve Digital Signature Algorithm (ECDSA) in DNSSEC with two specific NIST curves. This document specifies the use of two additional curves from <xref target='RFC5639' />. Details on Elliptic Curves and the implementation of ECDSA can be found e.g. in <xref target='SEC1' />, <xref target='HMV' />, <xref target='BSI' />, and <xref target='RFC6090' />.</t>
</section>
<section title="Requirements Terminology">
<t>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 <xref target='RFC2119'/>.</t>
</section>
<!--<section anchor="shaDS" title="SHA-384 DS Records">
<t>The SHA-384 record is defined according to <xref target='RFC6605' />. The algorithm SHA-384 is specified in <xref target='FIPS-180-4' /> and <xref target='RFC6234' />. It is implemented in DNSSEC the same way as SHA-256 in <xref target='RFC4509' />. For SHA-384 the digest size is 48 byte with digest type code 4.</t>
</section>-->
<section anchor="ecdsaParam" title="ECDSA Parameters">
<t>Signer and verifier of an ECDSA signature need to agree on a set of parameters. This document makes use of the Brainpool curves with bit-sizes 256 and 384, specified in Section 3.4 and 3.6 of <xref target='RFC5639' />, and denoted as brainpoolP256r1 and brainpoolP384r1, respectively.</t>
</section>
<section title="DNSKEY and RRSIG Resource Records for ECDSA">
<t>The records are defined as in <xref target='RFC6605' />: The ECDSA public key, denoted as "Q" in <xref target='FIPS-186-4'/>, is encoded as the bit string "x|y", representing the concatenation of the x and y coordinates of the uncompressed curve point. An ECDSA signature is composed of the integer values "r" and "s" (see <xref target='FIPS-186-4'/>). Each integer value is encoded as bit string of 32 octets for brainpoolP256r1 and of 48 octets for brainpoolP384r1. The conversion of integers to bit strings is specified in Section C.2 of <xref target='FIPS-186-4'/>. The signature for DNSSEC is encoded as concatenation of the bit strings of "r" and "s", i.e., as "r|s". Hence, the ECDSA signature has a fixed length of 64 octets for brainpoolP256r1 and 96 octets for brainpoolP384r1. </t>
<t>The IANA Considerations section defines the algorithm numbers used for DNSKEY and RRSIG resource records.
<list>
<t>Algorithm number TBD1 for using ECDSA with brainpoolP256r1 and SHA-256 for DNSKEY and RRSIG Resource Records.</t>
<t>Algorithm number TBD2 for using ECDSA with brainpoolP384r1 and SHA-384 for DNSKEY and RRSIG Resource Records.</t>
</list>
The use of these algorithms is OPTIONAL: an implementer can choose to support any subset.
</t>
</section>
<section title="Support for NSEC3 Denial of Existence">
<t>The statement of <xref target='RFC6605' /> applies. </t>
</section>
<section title="IANA Considerations">
<t>IANA is requested to assign numbers for ECDSA with ECC Brainpool curves listed in <xref target='ecdsaParam' /> to "Domain Name System Security (DNSSEC) Algorithm Numbers". In the following the two new entries are listed.</t>
<figure>
<artwork>
Number TBD1
Description ECDSA Curve brainpoolP256r1 with SHA-256
Mnemonic ECDSAbrainpoolP256r1SHA256
Zone Signing Y
Trans. Sec *
Reference This document
</artwork> </figure>
<figure>
<artwork>
Number TBD2
Description ECDSA Curve brainpoolP384r1 with SHA-384
Mnemonic ECDSAbrainpoolP384r1SHA384
Zone Signing Y
Trans. Sec *
Reference This document
</artwork> </figure>
<t>
<list>
<t>* There has been no determination of standardization of the use of this algorithm with Transaction Security.</t>
</list>
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The security considerations of <xref target='RFC5639' />, <xref target='RFC6605' />, and <xref target='RFC4509' /> apply accordingly. </t>
</section>
<!-- The Author's Addresses section will be generated automatically by XML2RFC from the front information -->
</middle>
<back>
<!-- References Section -->
<!-- Section 4.7f of <xref target='RFC2223bis' /> specifies the requirements for the
references sections. In particular, there MUST be separate lists of
normative and informative references, each in a separate section.
The style SHOULD follow that of recently published RFCs.
The standard MIB boilerplate available at
http://www.ops.ietf.org/mib-boilerplate.html includes lists of
normative and informative references that MUST appear in all IETF
specifications that contain MIB modules. If items from other MIB
modules appear in an IMPORTS statement in the Definitions section,
then the specifications containing those MIB modules MUST be included
in the list of normative references. When items are imported from an
IANA-maintained MIB module the corresponding normative reference
SHALL point to the on-line version of that MIB module. It is the
policy of the RFC Editor that all references must be cited in the
text; such citations MUST appear in the overview section where
documents containing imported definitions (other those already
mentioned in the MIB boilerplate) are required to be mentioned (cf.
Section 3.2).
In general, each normative reference SHOULD point to the most recent
version of the specification in question.
-->
<references title="Normative References">
<!--
<reference anchor="FIPS-180-4">
<front>
<title>Secure Hash Standard (SHS)</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="March" year="2012" />
</front>
<seriesInfo name="FIPS" value="PUB 180-4" />
</reference>
-->
<reference anchor="FIPS-186-4">
<front>
<title>Digital Signature Standard (DSS)</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="July" year="2013" />
</front>
<seriesInfo name="FIPS" value="PUB 186-4" />
</reference>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor="RFC4509">
<front>
<title>Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)</title>
<author initials="W." surname="Hardaker" fullname="W. Hardaker"><organization/></author>
<date year="2006" month="May"/>
<abstract><t>This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="4509"/>
<format type="TXT" octets="14155" target="http://www.rfc-editor.org/rfc/rfc4509.txt"/>
</reference>
<reference anchor='RFC5639'>
<front>
<title>Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation</title>
<author initials='M.' surname='Lochter' fullname='M. Lochter'>
<organization /></author>
<author initials='J.' surname='Merkle' fullname='J. Merkle'>
<organization /></author>
<date year='2010' month='March' />
<abstract>
<t>This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>
<seriesInfo name='RFC' value='5639' />
<format type='TXT' octets='50566' target='http://www.rfc-editor.org/rfc/rfc5639.txt' />
</reference>
<reference anchor="RFC6605"><front>
<title>Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC</title>
<author initials="P." surname="Hoffman" fullname="P. Hoffman"><organization/></author>
<author initials="W.C.A." surname="Wijngaards" fullname="W.C.A. Wijngaards"><organization/></author>
<date year="2012" month="April"/>
<abstract><t>This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name="RFC" value="6605"/><format type="TXT" octets="14332" target="http://www.rfc-editor.org/rfc/rfc6605.txt"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="ANSI">
<front>
<title>
Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)
</title>
<author>
<organization>American National Standards Institute</organization>
</author>
<date month="" year="2005"/>
</front>
<seriesInfo name="ANSI" value="X9.62"/>
</reference>
<reference anchor="BSI">
<front>
<title>Minimum Requirements for Evaluating Side-Channel Attack Resistance of Elliptic Curve Implementations
</title>
<author>
<organization>Bundesamt fuer Sicherheit in der Informationstechnik</organization>
</author>
<date month="July" year="2011"/>
</front>
</reference>
<reference anchor="HMV">
<front>
<title>
Guide to Elliptic Curve Cryptography
</title>
<author initials="D" surname="Hankerson">
<organization>
</organization>
</author>
<author initials="A" surname="Menezes">
<organization>
</organization>
</author>
<author initials="S" surname="Vanstone">
<organization>
</organization>
</author>
<date month="" year="2004"/>
</front>
<seriesInfo name="Springer" value="Verlag"/>
</reference>
<reference anchor="ISO1">
<front>
<title>
Information Technology - Security Techniques - Digital Signatures with Appendix - Part 3: Discrete Logarithm Based Mechanisms
</title>
<author>
<organization>International Organization for Standardization </organization>
</author>
<date month="" year="2006"/>
</front>
<seriesInfo name="ISO/IEC" value="14888-3"/>
</reference>
<reference anchor="ISO2">
<front>
<title>
Information Technology - Security Techniques - Cryptographic Techniques Based on Elliptic Curves - Part 2: Digital signatures
</title>
<author>
<organization>International Organization for Standardization </organization>
</author>
<date month="" year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="15946-2"/>
</reference>
<reference anchor='RFC6090'>
<front>
<title>Fundamental Elliptic Curve Cryptography Algorithms</title>
<author initials='D.' surname='McGrew' fullname='D. McGrew'>
<organization /></author>
<author initials='K.' surname='Igoe' fullname='K. Igoe'>
<organization /></author>
<author initials='M.' surname='Salter' fullname='M. Salter'>
<organization /></author>
<date year='2011' month='February' />
<abstract>
<t>This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>
<seriesInfo name='RFC' value='6090' />
<format type='TXT' octets='75993' target='http://www.rfc-editor.org/rfc/rfc6090.txt' />
</reference>
<!-- <reference anchor="RFC6234"><front><title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title><author initials="D." surname="Eastlake" fullname="D. Eastlake"><organization/></author><author initials="T." surname="Hansen" fullname="T. Hansen"><organization/></author><date year="2011" month="May"/><abstract><t>Federal Information Processing Standard, FIPS</t></abstract></front><seriesInfo name="RFC" value="6234"/><format type="TXT" octets="236573" target="http://www.rfc-editor.org/rfc/rfc6234.txt"/></reference> -->
<reference anchor="SEC1">
<front>
<title>
Elliptic Curve Cryptography, Version 2.0
</title>
<author>
<organization>Certicom Research
</organization>
</author>
<date month="May" year="2009"/>
</front>
<seriesInfo name="Standards for Efficient Cryptography (SEC)" value="1"/>
</reference>
<reference anchor="SEC2">
<front>
<title>
Recommended Elliptic Curve Domain Parameters, Version 2.0
</title>
<author>
<organization>Certicom Research
</organization>
</author>
<date month="January" year="2010"/>
</front>
<seriesInfo name="Standards for Efficient Cryptography (SEC)" value="2"/>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 05:38:12 |