asciidoctor-rfc 0.1.0 → 0.2.0

data/spec/examples/example-v3.adoc

@@ -0,0 +1,185 @@
+= RFC XML v3 Example: A Standard for the Transmission of IP Datagrams on Avian Carriers
+David Waitzman <dwaitzman@BBN.COM>; Nick Nicholas <opoudjis@gmail.com>
+:doctype: rfc
+:abbrev: IP Datagrams on Avian Carriers
+:obsoletes: 10, 120
+:updates: 2010, 2120
+:name: rfc-1149
+:status: full-standard 1149
+:ipr: trust200902
+:area: Internet
+:workgroup: Network Working Group
+:keyword: this, that
+:revdate: 1990-04-01T00:00:00Z
+:organization: BBN STC
+:phone: (617) 873-4323
+:uri: http://bbn.com
+:street: 10 Moulton Street
+:city: Cambridge
+:code: MA 02238
+:organization_2: BBN STC
+:phone_2: (617) 873-4323
+:street_2: 10 Moulton Street
+:city_2: Cambridge
+:code_2: MA 02238
+:uri_2: http://opoudjis.net
+:link: http://example1.com,http://example2.com author
+
+[abstract]
+Avian carriers can provide high delay, low throughput, and low
+altitude service.  The connection topology is limited to a single
+point-to-point path for each carrier, used with standard carriers,
+but many carriers can be used without significant interference with
+each other, outside of early spring.  This is because of the 3D ether
+space available to the carriers, in contrast to the 1D ether used by
+IEEE802.3.  The carriers have an intrinsic collision avoidance
+system, which increases availability.  Unlike some network
+technologies, such as packet radio, communication is not limited to
+line-of-sight distance.  Connection oriented service is available in
+some cities, usually based upon a central hub topology.
+
+NOTE: Yes, this is an April Fool's RFC.
+
+[[frame]]
+== Frame Format
+
+The IP _datagram_ is *printed*, on a small scroll of paper, in
+hexadecimal, with each octet separated by whitestuff and blackstuff.
+The scroll of paper is wrapped around one leg of the avian carrier.
+A band of duct tape is used to secure the datagram's edges.  The
+bandwidth is limited to the leg length.  The MTU is variable, and
+paradoxically, generally increases with increased carrier age.  A
+typical MTU is 256 milligrams.  Some datagram padding may be needed.<<RFC7253,alt>>
+
+Upon receipt, the duct tape is removed and the paper copy of the
+datagram is optically scanned into a electronically transmittable
+form.<<RFC7253>>
+
+This document extends OpenPGP and its ECC extension to support SM2, SM3 and SM4:
+
+* support the SM3 hash algorithm for data validation purposes
+* support signatures utilizing the combination of SM3 with other digital
+  signing algorithms, such as RSA, ECDSA and SM2
+* support the SM2 asymmetric encryption algorithm for public key
+  operations
+* support usage of SM2 in combination with supported hash algorithms, such as
+  SHA-256 and SM3
+* support the SM4 symmetric encryption algorithm for data protection purposes
+* defines the OpenPGP profile "OSCCA-SM234" to enable usage of OpenPGP
+  in an OSCCA-compliant manner.
+
+Algorithm-Specific Fields for SM2DSA keys:
+
+* a variable-length field containing a curve OID, formatted
+  as follows:
+.. a one-octet size of the following field; values 0 and
+   0xFF are reserved for future extensions
+.. octets representing a curve OID.
+*  MPI of an EC point representing a public key
+
+
+===  Definitions
+
+OSCCA-compliant:: All cryptographic algorithms used are compliant with OSCCA  regulations.
+SM2DSA:: The elliptic curve digital signature algorithm. <<ISO.IEC.10118-3>>
+SM2KEP:: The elliptic curve key exchange protocol.
+SM2PKE:: The public key encryption algorithm.
+
+==== Elliptic Curve Formula
+
+[stem]
+++++
+y^2 = x^3 + ax + b
+++++
+
+==== Curve Parameters
+
+[[curveparam1]]
+.Curve Parameters Listing
+====
+....
+p   = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
+      FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
+a   = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
+      FFFFFFFF 00000000 FFFFFFFF FFFFFFFC
+b   = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7
+      F39789F5 15AB8F92 DDBCBD41 4D940E93
+n   = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
+      7203DF6B 21C6052B 53BBF409 39D54123
+x_G = 32C4AE2C 1F198119 5F990446 6A39C994
+      8FE30BBF F2660BE1 715A4589 334C74C7
+y_G = BC3736A2 F4F6779C 59BDCEE3 6B692153
+      D0A9877C C62A4740 02DF32E5 2139F0A0
+....
+====
+
+== Supported Algorithms
+
+=== Public Key Algorithms
+
+The SM2 algorithm is supported with the following extension.
+
+NOTE: ECDH is defined in Section 8 of this document.
+
+The following public key algorithm IDs are added to expand Section
+9.1 of RFC4880, "Public-Key Algorithms":
+
+.Table 2
+|===
+|ID | Description of Algorithm
+
+|TBD | SM2
+|===
+
+
+
+== Security Considerations
+
+Security is not generally a problem in normal operation, but special +
+measures [bcp14]#MUST# be taken (such as data encryption) when avian carriers
+are used in a tactical environment.<<RFC7253>>, <<ISO.IEC.10118-3>>
+
+[bibliography]
+== References
+* [[[RFC7253,1]]]
+* [[[ISO.IEC.10118-3,2]]]
+++++
+<reference anchor='ISO.IEC.10118-3' target='https://www.iso.org/standard/67116.html'>
+  <front>
+    <title>ISO/IEC FDIS 10118-3 -- Information technology -- Security techniques -- Hash-functions -- Part 3: Dedicated hash-functions</title>
+    <author>
+      <organization>International Organization for Standardization</organization>
+      <address>
+        <postal>
+          <street>BIBC II</street>
+          <street>Chemin de Blandonnet 8</street>
+          <street>CP 401</street>
+          <city>Vernier</city>
+          <region>Geneva</region>
+          <code>1214</code>
+          <country>Switzerland</country>
+        </postal>
+        <phone>+41 22 749 01 11</phone>
+        <email>central@iso.org</email>
+        <uri>https://www.iso.org/</uri>
+      </address>
+    </author>
+    <date day='15' month='September' year='2017'/>
+  </front>
+</reference>
+
+<reference anchor='RFC7253' target='https://tools.ietf.org/html/rfc7253'>
+  <front>
+    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
+    <author initials="T." surname="Krovetz">
+      <organization>Sacramento State</organization>
+    </author>
+    <author initials="P." surname="Rogaway">
+      <organization>UC Davis</organization>
+    </author>
+    <date month='May' year='2014'/>
+  </front>
+  <seriesInfo name="RFC" value="7253"/>
+</reference>
+++++
+

data/spec/examples/example-v3.xml

@@ -0,0 +1,1009 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<rfc ipr="trust200902" obsoletes="10, 120" updates="2010, 2120" submissionType="IETF" prepTime="2017-10-17T12:03:45Z" version="3">
+<link href="http://example1.com"/><link href="http://example2.com" rel="author"/>
+<front>
+
+  <title abbrev="IP Datagrams on Avian Carriers">RFC XML v3 Example: A Standard for the Transmission of IP Datagrams on Avian Carriers</title>
+
+  <seriesInfo name="RFC" status="full-standard 1149" stream="IETF" value="1149"/>
+
+  <author fullname="David Waitzman" surname="Waitzman">
+
+    <organization>BBN STC</organization>
+
+    <address>
+
+      <postal>
+
+        <street>10 Moulton Street</street>
+
+        <city>Cambridge</city>
+
+        <code>MA 02238</code>
+
+      </postal>
+
+      <phone>(617) 873-4323</phone>
+
+      <email>dwaitzman@BBN.COM</email>
+
+      <uri>http://bbn.com</uri>
+
+    </address>
+
+  </author>
+
+  <author fullname="Nick Nicholas" surname="Nicholas">
+
+    <organization>BBN STC</organization>
+
+    <address>
+
+      <postal>
+
+        <street>10 Moulton Street</street>
+
+        <city>Cambridge</city>
+
+        <code>MA 02238</code>
+
+      </postal>
+
+      <phone>(617) 873-4323</phone>
+
+      <email>opoudjis@gmail.com</email>
+
+      <uri>http://opoudjis.net</uri>
+
+    </address>
+
+  </author>
+
+  <date day="1" month="April" year="1990"/>
+
+  <area>Internet</area>
+
+  <workgroup>Network Working Group</workgroup>
+
+  <keyword>this</keyword>
+
+  <keyword>that</keyword>
+
+
+<abstract>
+<t>Avian carriers can provide high delay, low throughput, and low
+
+altitude service.  The connection topology is limited to a single
+
+point-to-point path for each carrier, used with standard carriers,
+
+but many carriers can be used without significant interference with
+
+each other, outside of early spring.  This is because of the 3D ether
+
+space available to the carriers, in contrast to the 1D ether used by
+
+IEEE802.3.  The carriers have an intrinsic collision avoidance
+
+system, which increases availability.  Unlike some network
+
+technologies, such as packet radio, communication is not limited to
+
+line-of-sight distance.  Connection oriented service is available in
+
+some cities, usually based upon a central hub topology.</t>
+</abstract>
+<note>
+
+  <t>Yes, this is an April Fool&amp;#8217;s RFC.</t>
+
+</note>
+</front><middle>
+<section anchor="frame" numbered="false"><name>Frame Format</name><t>The IP <em>datagram</em> is <strong>printed</strong>, on a small scroll of paper, in
+
+
+
+hexadecimal, with each octet separated by whitestuff and blackstuff.
+
+
+
+The scroll of paper is wrapped around one leg of the avian carrier.
+
+
+
+A band of duct tape is used to secure the datagram’s edges.  The
+
+
+
+bandwidth is limited to the leg length.  The MTU is variable, and
+
+
+
+paradoxically, generally increases with increased carrier age.  A
+
+
+
+typical MTU is 256 milligrams.  Some datagram padding may be needed.<xref target="RFC7253">alt</xref></t>
+
+<t>Upon receipt, the duct tape is removed and the paper copy of the
+
+
+
+datagram is optically scanned into a electronically transmittable
+
+
+
+form.<xref target="RFC7253"/></t>
+
+<t>This document extends OpenPGP and its ECC extension to support SM2, SM3 and SM4:</t>
+
+<ul>
+
+
+
+  <li>support the SM3 hash algorithm for data validation purposes</li>
+
+
+
+  <li>support signatures utilizing the combination of SM3 with other digital
+
+
+
+signing algorithms, such as RSA, ECDSA and SM2</li>
+
+
+
+  <li>support the SM2 asymmetric encryption algorithm for public key
+
+
+
+operations</li>
+
+
+
+  <li>support usage of SM2 in combination with supported hash algorithms, such as
+
+
+
+SHA-256 and SM3</li>
+
+
+
+  <li>support the SM4 symmetric encryption algorithm for data protection purposes</li>
+
+
+
+  <li>defines the OpenPGP profile "OSCCA-SM234" to enable usage of OpenPGP
+
+
+
+in an OSCCA-compliant manner.</li>
+
+
+
+</ul>
+
+<t>Algorithm-Specific Fields for SM2DSA keys:</t>
+
+<ul>
+
+
+
+  <li>
+
+
+
+    <t>a variable-length field containing a curve OID, formatted
+
+
+
+as follows:</t>
+
+
+
+    <ol type="a">
+
+
+
+
+
+
+
+  <li>a one-octet size of the following field; values 0 and
+
+
+
+
+
+
+
+0xFF are reserved for future extensions</li>
+
+
+
+
+
+
+
+  <li>octets representing a curve OID.</li>
+
+
+
+
+
+
+
+</ol>
+
+
+
+  </li>
+
+
+
+  <li>MPI of an EC point representing a public key</li>
+
+
+
+</ul>
+
+<section anchor="_definitions" numbered="false"><name>Definitions</name><dl>
+
+
+
+
+
+
+
+  <dt>OSCCA-compliant</dt>
+
+
+
+
+
+
+
+  <dd>All cryptographic algorithms used are compliant with OSCCA  regulations.</dd>
+
+
+
+
+
+
+
+  <dt>SM2DSA</dt>
+
+
+
+
+
+
+
+  <dd>The elliptic curve digital signature algorithm. <xref target="ISO.IEC.10118-3"/></dd>
+
+
+
+
+
+
+
+  <dt>SM2KEP</dt>
+
+
+
+
+
+
+
+  <dd>The elliptic curve key exchange protocol.</dd>
+
+
+
+
+
+
+
+  <dt>SM2PKE</dt>
+
+
+
+
+
+
+
+  <dd>The public key encryption algorithm.</dd>
+
+
+
+
+
+
+
+</dl>
+
+
+
+<section anchor="_elliptic_curve_formula" numbered="false">
+
+
+
+
+
+
+
+  <name>Elliptic Curve Formula</name>
+
+
+
+
+
+
+
+  <figure>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  <artwork type="ascii-art">y^2 = x^3 + ax + b</artwork>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+</figure>
+
+
+
+
+
+
+
+</section>
+
+
+
+<section anchor="_curve_parameters" numbered="false">
+
+
+
+
+
+
+
+  <name>Curve Parameters</name>
+
+
+
+
+
+
+
+  <figure anchor="curveparam1">
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  <name>Curve Parameters Listing</name>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  <artwork type="ascii-art">p   = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+      FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+a   = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+      FFFFFFFF 00000000 FFFFFFFF FFFFFFFC
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+b   = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+      F39789F5 15AB8F92 DDBCBD41 4D940E93
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+n   = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+      7203DF6B 21C6052B 53BBF409 39D54123
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+x_G = 32C4AE2C 1F198119 5F990446 6A39C994
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+      8FE30BBF F2660BE1 715A4589 334C74C7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+y_G = BC3736A2 F4F6779C 59BDCEE3 6B692153
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+      D0A9877C C62A4740 02DF32E5 2139F0A0</artwork>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+</figure>
+
+
+
+
+
+
+
+</section></section></section>
+<section anchor="_supported_algorithms" numbered="false">
+
+  <name>Supported Algorithms</name>
+
+  <section anchor="_public_key_algorithms" numbered="false"><name>Public Key Algorithms</name><t>The SM2 algorithm is supported with the following extension.<cref>ECDH is defined in Section 8 of this document.</cref></t>
+
+
+
+
+
+
+
+<t>The following public key algorithm IDs are added to expand Section
+
+
+
+
+
+
+
+9.1 of RFC4880, "Public-Key Algorithms":</t>
+
+
+
+<table>
+
+
+
+
+
+
+
+  <name>Table 2</name>
+
+
+
+
+
+
+
+  <thead>
+
+
+
+
+
+
+
+    <tr>
+
+
+
+
+
+
+
+      <th align="left">ID</th>
+
+
+
+
+
+
+
+      <th align="left">Description of Algorithm</th>
+
+
+
+
+
+
+
+    </tr>
+
+
+
+
+
+
+
+  </thead>
+
+
+
+
+
+
+
+  <tbody>
+
+
+
+
+
+
+
+    <tr>
+
+
+
+
+
+
+
+      <td align="left">TBD</td>
+
+
+
+
+
+
+
+      <td align="left">SM2</td>
+
+
+
+
+
+
+
+    </tr>
+
+
+
+
+
+
+
+  </tbody>
+
+
+
+
+
+
+
+</table></section>
+
+</section>
+<section anchor="_security_considerations" numbered="false">
+
+  <name>Security Considerations</name>
+
+  <t>Security is not generally a problem in normal operation, but special
+
+
+
+measures <bcp14>MUST</bcp14> be taken (such as data encryption) when avian carriers
+
+
+
+are used in a tactical environment.<xref target="RFC7253"/>, <xref target="ISO.IEC.10118-3"/></t>
+
+</section>
+</middle><back>
+<displayreference target="RFC7253" to="1"/>
+<displayreference target="ISO.IEC.10118-3" to="2"/>
+<references anchor="_references">
+<name>References</name>
+<reference anchor="ISO.IEC.10118-3" target="https://www.iso.org/standard/67116.html">
+  <front>
+    <title>ISO/IEC FDIS 10118-3 -- Information technology -- Security techniques -- Hash-functions -- Part 3: Dedicated hash-functions</title>
+    <author>
+      <organization>International Organization for Standardization</organization>
+      <address>
+        <postal>
+          <street>BIBC II</street>
+          <street>Chemin de Blandonnet 8</street>
+          <street>CP 401</street>
+          <city>Vernier</city>
+          <region>Geneva</region>
+          <code>1214</code>
+          <country>Switzerland</country>
+        </postal>
+        <phone>+41 22 749 01 11</phone>
+        <email>central@iso.org</email>
+        <uri>https://www.iso.org/</uri>
+      </address>
+    </author>
+    <date day="15" month="September" year="2017"/>
+  </front>
+</reference>
+
+<reference anchor="RFC7253" target="https://tools.ietf.org/html/rfc7253">
+  <front>
+    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
+    <author initials="T." surname="Krovetz">
+      <organization>Sacramento State</organization>
+    </author>
+    <author initials="P." surname="Rogaway">
+      <organization>UC Davis</organization>
+    </author>
+    <date month="May" year="2014"/>
+  </front>
+  <seriesInfo name="RFC" value="7253"/>
+</reference>
+</references>
+</back>
+</rfc>