= RFC XML v2 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
:status: informational
:name: rfc-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

[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 **MUST** be taken (such as data encryption) when avian carriers
are used in a tactical environment.<<RFC7253>>, <<ISO.IEC.10118-3>>

[bibliography]
== Normative References
++++
<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>
++++

[bibliography]
== Infomative References
++++
<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>
++++