drafts: Add more RFC references to common/
authorWerner Koch <wk@gnupg.org>
Wed, 27 May 2015 15:29:21 +0000 (17:29 +0200)
committerWerner Koch <wk@gnupg.org>
Wed, 27 May 2015 15:29:21 +0000 (17:29 +0200)
13 files changed:
misc/id/common/reference.ISO.10646-1.1993.xml [new file with mode: 0644]
misc/id/common/reference.RFC.1423.xml [new file with mode: 0644]
misc/id/common/reference.RFC.1950.xml [new file with mode: 0644]
misc/id/common/reference.RFC.1951.xml [new file with mode: 0644]
misc/id/common/reference.RFC.1991.xml [new file with mode: 0644]
misc/id/common/reference.RFC.2045.xml [new file with mode: 0644]
misc/id/common/reference.RFC.2144.xml [new file with mode: 0644]
misc/id/common/reference.RFC.2440.xml [new file with mode: 0644]
misc/id/common/reference.RFC.2822.xml [new file with mode: 0644]
misc/id/common/reference.RFC.3156.xml [new file with mode: 0644]
misc/id/common/reference.RFC.3447.xml [new file with mode: 0644]
misc/id/common/reference.RFC.3629.xml [new file with mode: 0644]
misc/id/common/reference.RFC.4086.xml [new file with mode: 0644]

diff --git a/misc/id/common/reference.ISO.10646-1.1993.xml b/misc/id/common/reference.ISO.10646-1.1993.xml
new file mode 100644 (file)
index 0000000..9bc0a86
--- /dev/null
@@ -0,0 +1,14 @@
+<?xml version="1.0" encoding='UTF-8'?>
+
+<reference anchor="ISO10646">
+<front>
+<title>Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane</title>
+<author>
+<organization>International Organization for Standardization</organization>
+</author>
+<date month="May" year="1993" />
+</front>
+
+<seriesInfo name="ISO" value="Standard 10646-1" />
+
+</reference>
diff --git a/misc/id/common/reference.RFC.1423.xml b/misc/id/common/reference.RFC.1423.xml
new file mode 100644 (file)
index 0000000..7fb6a57
--- /dev/null
@@ -0,0 +1,26 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC1423'>
+
+<front>
+<title abbrev='PEM: Algorithms, Modes and Identifiers'>Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers</title>
+<author initials='D.' surname='Balenson' fullname='David Balenson'>
+<organization>Trusted Information Systems</organization>
+<address>
+<postal>
+<street>3060 Washington Road</street>
+<city>Glenwood</city>
+<region>MD</region>
+<code>21738</code>
+<country>US</country></postal>
+<phone>+1 301 854 6889</phone>
+<email>balenson@tis.com</email></address></author>
+<date year='1993' month='February' />
+<abstract>
+<t>This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail (PEM) in the Internet community.  It is intended to become one member of the set of related PEM RFCs.  This document is organized into four primary sections, dealing with message encryption algorithms, message integrity check algorithms, symmetric key management algorithms, and asymmetric key management algorithms (including both asymmetric encryption and asymmetric signature algorithms).</t>
+<t>Some parts of this material are cited by other documents and it is anticipated that some of the material herein may be changed, added, or replaced without affecting the citing documents.  Therefore, algorithm-specific material has been placed into this separate document.</t>
+<t>Use of other algorithms and/or modes will require case-by-case study to determine applicability and constraints.  The use of additional algorithms may be documented first in Prototype or Experimental RFCs. As experience is gained, these protocols may be considered for incorporation into the standard.  Additional algorithms and modes approved for use in PEM in this context will be specified in successors to this document.</t></abstract></front>
+
+<seriesInfo name='RFC' value='1423' />
+<format type='TXT' octets='33277' target='http://www.rfc-editor.org/rfc/rfc1423.txt' />
+</reference>
diff --git a/misc/id/common/reference.RFC.1950.xml b/misc/id/common/reference.RFC.1950.xml
new file mode 100644 (file)
index 0000000..1ee4737
--- /dev/null
@@ -0,0 +1,30 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC1950'>
+
+<front>
+<title>ZLIB Compressed Data Format Specification version 3.3</title>
+<author initials='L.P.' surname='Deutsch' fullname='L. Peter Deutsch'>
+<organization>Aladdin Enterprises</organization>
+<address>
+<postal>
+<street>203 Santa Margarita Ave.</street>
+<city>Menlo Park</city>
+<region>CA</region>
+<code>94025</code>
+<country>US</country></postal>
+<phone>+1 415 322 0103</phone>
+<facsimile>+1 415 322 1734</facsimile>
+<email>ghost@aladdin.com</email></address></author>
+<author initials='J-L.' surname='Gailly' fullname='Jean-Loup Gailly'>
+<organization /></author>
+<date year='1996' month='May' />
+<abstract>
+<t>This specification defines a lossless compressed data format.  The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage.  The format presently uses the DEFLATE compression method but can be easily extended to use
+   other compression methods.  It can be implemented readily in a manner not covered by patents.  This specification also defines the ADLER-32 checksum (an extension and improvement of the Fletcher checksum), used for detection of data corruption, and provides an algorithm for computing it.</t></abstract></front>
+
+<seriesInfo name='RFC' value='1950' />
+<format type='TXT' octets='20502' target='http://www.rfc-editor.org/rfc/rfc1950.txt' />
+<format type='PS' octets='37768' target='http://www.rfc-editor.org/rfc/rfc1950.ps' />
+<format type='PDF' octets='36393' target='http://www.rfc-editor.org/rfc/rfc1950.pdf' />
+</reference>
diff --git a/misc/id/common/reference.RFC.1951.xml b/misc/id/common/reference.RFC.1951.xml
new file mode 100644 (file)
index 0000000..5efee70
--- /dev/null
@@ -0,0 +1,27 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC1951'>
+
+<front>
+<title>DEFLATE Compressed Data Format Specification version 1.3</title>
+<author initials='P.' surname='Deutsch' fullname='L. Peter Deutsch'>
+<organization>Aladdin Enterprises</organization>
+<address>
+<postal>
+<street>203 Santa Margarita Ave.</street>
+<city>Menlo Park</city>
+<region>CA</region>
+<code>94025</code>
+<country>US</country></postal>
+<phone>+1 415 322 0103</phone>
+<facsimile>+1 415 322 1734</facsimile>
+<email>ghost@aladdin.com</email></address></author>
+<date year='1996' month='May' />
+<abstract>
+<t>This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.  The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage.  The format can be implemented readily in a manner not covered by patents.</t></abstract></front>
+
+<seriesInfo name='RFC' value='1951' />
+<format type='TXT' octets='36944' target='http://www.rfc-editor.org/rfc/rfc1951.txt' />
+<format type='PS' octets='57408' target='http://www.rfc-editor.org/rfc/rfc1951.ps' />
+<format type='PDF' octets='56620' target='http://www.rfc-editor.org/rfc/rfc1951.pdf' />
+</reference>
diff --git a/misc/id/common/reference.RFC.1991.xml b/misc/id/common/reference.RFC.1991.xml
new file mode 100644 (file)
index 0000000..d6ad4de
--- /dev/null
@@ -0,0 +1,43 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC1991'>
+
+<front>
+<title>PGP Message Exchange Formats</title>
+<author initials='D.' surname='Atkins' fullname='Derek Atkins'>
+<organization>MIT</organization>
+<address>
+<postal>
+<street>12 Rindge Ave. #1R</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02140</code>
+<country>US</country></postal>
+<phone>+1 617 868 4469</phone>
+<email>warlord@MIT.EDU</email></address></author>
+<author initials='W.' surname='Stallings' fullname='William Stallings'>
+<organization>Comp-Comm Consulting</organization>
+<address>
+<postal>
+<street>P. O. Box 2405</street>
+<city>Brewster</city>
+<region>MA</region>
+<code>02631</code>
+<country>US</country></postal>
+<email>stallings@ACM.org</email></address></author>
+<author initials='P.' surname='Zimmermann' fullname='Philip Zimmermann'>
+<organization>Boulder Software Engineering</organization>
+<address>
+<postal>
+<street>3021 Eleventh Street</street>
+<city>Boulder</city>
+<region>CO</region>
+<code>80304</code>
+<country>US</country></postal>
+<phone>+1 303 541 0140</phone>
+<email>prz@acm.org</email></address></author>
+<date year='1996' month='August' /></front>
+
+<seriesInfo name='RFC' value='1991' />
+<format type='TXT' octets='46255' target='http://www.rfc-editor.org/rfc/rfc1991.txt' />
+</reference>
diff --git a/misc/id/common/reference.RFC.2045.xml b/misc/id/common/reference.RFC.2045.xml
new file mode 100644 (file)
index 0000000..4b45bdf
--- /dev/null
@@ -0,0 +1,45 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC2045'>
+
+<front>
+<title abbrev='Internet Message Bodies'>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
+<author initials='N.' surname='Freed' fullname='Ned Freed'>
+<organization>Innosoft International, Inc.</organization>
+<address>
+<postal>
+<street>1050 East Garvey Avenue South</street>
+<city>West Covina</city>
+<region>CA</region>
+<code>91790</code>
+<country>US</country></postal>
+<phone>+1 818 919 3600</phone>
+<facsimile>+1 818 919 3614</facsimile>
+<email>ned@innosoft.com</email></address></author>
+<author initials='N.S.' surname='Borenstein' fullname='Nathaniel S. Borenstein'>
+<organization>First Virtual Holdings</organization>
+<address>
+<postal>
+<street>25 Washington Avenue</street>
+<city>Morristown</city>
+<region>NJ</region>
+<code>07960</code>
+<country>US</country></postal>
+<phone>+1 201 540 8967</phone>
+<facsimile>+1 201 993 3032</facsimile>
+<email>nsb@nsb.fv.com</email></address></author>
+<date year='1996' month='November' />
+<abstract>
+<t>STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text.  This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for</t>
+<t>(1)   textual message bodies in character sets other than US-ASCII,</t>
+<t>(2)   an extensible set of different formats for non-textual message bodies,</t>
+<t>(3)   multi-part message bodies, and</t>
+<t>(4)   textual header information in character sets other than US-ASCII.</t>
+<t>These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them.  Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.</t>
+<t>This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance
+  criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.</t>
+<t>These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342.  An appendix in RFC 2049 describes differences and changes from previous versions.</t></abstract></front>
+
+<seriesInfo name='RFC' value='2045' />
+<format type='TXT' octets='72932' target='http://www.rfc-editor.org/rfc/rfc2045.txt' />
+</reference>
diff --git a/misc/id/common/reference.RFC.2144.xml b/misc/id/common/reference.RFC.2144.xml
new file mode 100644 (file)
index 0000000..2ec24f7
--- /dev/null
@@ -0,0 +1,25 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC2144'>
+
+<front>
+<title>The CAST-128 Encryption Algorithm</title>
+<author initials='C.' surname='Adams' fullname='Carlisle Adams'>
+<organization>Entrust Technologies</organization>
+<address>
+<postal>
+<street>750 Heron Road</street>
+<city>Ottawa</city>
+<region>Ontario</region>
+<code>K1V 1A7</code>
+<country>CA</country></postal>
+<phone>+1 613 763 9008</phone>
+<email>cadams@entrust.com</email></address></author>
+<date year='1997' month='May' />
+<abstract>
+<t>There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols.</t>
+<t>This document describes an existing algorithm that can be used to satisfy this requirement.  Included are a description of the cipher and the key scheduling algorithm (Section 2), the s-boxes (Appendix A), and a set of test vectors (Appendix B).</t></abstract></front>
+
+<seriesInfo name='RFC' value='2144' />
+<format type='TXT' octets='37532' target='http://www.rfc-editor.org/rfc/rfc2144.txt' />
+</reference>
diff --git a/misc/id/common/reference.RFC.2440.xml b/misc/id/common/reference.RFC.2440.xml
new file mode 100644 (file)
index 0000000..738996d
--- /dev/null
@@ -0,0 +1,100 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC2440'>
+
+<front>
+<title>OpenPGP Message Format</title>
+<author initials='J.' surname='Callas' fullname='Jon Callas'>
+<organization>Network Associates, Inc.</organization>
+<address>
+<postal>
+<street>3965 Freedom Circle</street>
+<street>Santa Clara</street>
+<street>CA 95054</street>
+<country>USA</country></postal>
+<phone>+1 408-346-5860</phone>
+<email>jon@pgp.com</email></address></author>
+<author initials='L.' surname='Donnerhacke' fullname='Lutz Donnerhacke'>
+<organization>IKS GmbH</organization>
+<address>
+<postal>
+<street>Wildenbruchstr. 15</street>
+<street>07745 Jena</street>
+<country>Germany</country></postal>
+<phone>+49-3641-675642</phone>
+<email>lutz@iks-jena.de</email></address></author>
+<author initials='H.' surname='Finney' fullname='Hal Finney'>
+<organization>Network Associates, Inc.</organization>
+<address>
+<postal>
+<street>3965 Freedom Circle</street>
+<street>Santa Clara</street>
+<street>CA 95054</street>
+<country>USA</country></postal>
+<email>hal@pgp.com</email></address></author>
+<author initials='R.' surname='Thayer' fullname='Rodney Thayer'>
+<organization>EIS Corporation</organization>
+<address>
+<postal>
+<street>Clearwater</street>
+<street>FL 33767</street>
+<country>USA</country></postal>
+<email>rodney@unitran.com</email></address></author>
+<date year='1998' month='November' />
+<area>Security</area>
+<keyword>pretty good privacy</keyword>
+<keyword>PGP</keyword>
+<keyword>security</keyword>
+<abstract>
+<t>
+   This document defines many tag values, yet it doesn&apos;t describe a
+   mechanism for adding new tags (for new features).  Traditionally the
+   Internet Assigned Numbers Authority (IANA) handles the allocation of
+   new values for future expansion and RFCs usually define the procedure
+   to be used by the IANA.  However, there are subtle (and not so
+   subtle) interactions that may occur in this protocol between new
+   features and existing features which result in a significant
+   reduction in over all security.  Therefore, this document does not
+   define an extension procedure.  Instead requests to define new tag
+   values (say for new encryption algorithms for example) should be
+   forwarded to the IESG Security Area Directors for consideration or
+   forwarding to the appropriate IETF Working Group for consideration.
+</t>
+<t>
+   This document is maintained in order to publish all necessary
+   information needed to develop interoperable applications based on the
+   OpenPGP format. It is not a step-by-step cookbook for writing an
+   application. It describes only the format and methods needed to read,
+   check, generate, and write conforming packets crossing any network.
+   It does not deal with storage and implementation questions.  It does,
+   however, discuss implementation issues necessary to avoid security
+   flaws.
+</t>
+<t>
+   Open-PGP software uses a combination of strong public-key and
+   symmetric cryptography to provide security services for electronic
+   communications and data storage.  These services include
+   confidentiality, key management, authentication, and digital
+   signatures. This document specifies the message formats used in
+   OpenPGP.
+</t></abstract>
+<note title='IESG Note'>
+<t>
+   This document defines many tag values, yet it doesn&apos;t describe a
+   mechanism for adding new tags (for new features).  Traditionally the
+   Internet Assigned Numbers Authority (IANA) handles the allocation of
+   new values for future expansion and RFCs usually define the procedure
+   to be used by the IANA.  However, there are subtle (and not so
+   subtle) interactions that may occur in this protocol between new
+   features and existing features which result in a significant
+   reduction in over all security.  Therefore, this document does not
+   define an extension procedure.  Instead requests to define new tag
+   values (say for new encryption algorithms for example) should be
+   forwarded to the IESG Security Area Directors for consideration or
+   forwarding to the appropriate IETF Working Group for consideration.
+</t></note></front>
+
+<seriesInfo name='RFC' value='2440' />
+<format type='TXT' octets='141371' target='http://www.rfc-editor.org/rfc/rfc2440.txt' />
+<format type='XML' octets='137322' target='http://xml.resource.org/public/rfc/xml/rfc2440.xml' />
+</reference>
diff --git a/misc/id/common/reference.RFC.2822.xml b/misc/id/common/reference.RFC.2822.xml
new file mode 100644 (file)
index 0000000..afba0b2
--- /dev/null
@@ -0,0 +1,15 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC2822'>
+
+<front>
+<title>Internet Message Format</title>
+<author initials='P.' surname='Resnick' fullname='P. Resnick'>
+<organization /></author>
+<date year='2001' month='April' />
+<abstract>
+<t>This document specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. [STANDARDS-TRACK]</t></abstract></front>
+
+<seriesInfo name='RFC' value='2822' />
+<format type='TXT' octets='110695' target='http://www.rfc-editor.org/rfc/rfc2822.txt' />
+</reference>
diff --git a/misc/id/common/reference.RFC.3156.xml b/misc/id/common/reference.RFC.3156.xml
new file mode 100644 (file)
index 0000000..c4bdcbe
--- /dev/null
@@ -0,0 +1,21 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC3156'>
+
+<front>
+<title>MIME Security with OpenPGP</title>
+<author initials='M.' surname='Elkins' fullname='M. Elkins'>
+<organization /></author>
+<author initials='D.' surname='Del Torto' fullname='D. Del Torto'>
+<organization /></author>
+<author initials='R.' surname='Levien' fullname='R. Levien'>
+<organization /></author>
+<author initials='T.' surname='Roessler' fullname='T. Roessler'>
+<organization /></author>
+<date year='2001' month='August' />
+<abstract>
+<t>This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK]</t></abstract></front>
+
+<seriesInfo name='RFC' value='3156' />
+<format type='TXT' octets='26809' target='http://www.rfc-editor.org/rfc/rfc3156.txt' />
+</reference>
diff --git a/misc/id/common/reference.RFC.3447.xml b/misc/id/common/reference.RFC.3447.xml
new file mode 100644 (file)
index 0000000..814cbaf
--- /dev/null
@@ -0,0 +1,17 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC3447'>
+
+<front>
+<title>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</title>
+<author initials='J.' surname='Jonsson' fullname='J. Jonsson'>
+<organization /></author>
+<author initials='B.' surname='Kaliski' fullname='B. Kaliski'>
+<organization /></author>
+<date year='2003' month='February' />
+<abstract>
+<t>This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process.  The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process.  This memo provides information for the Internet community.</t></abstract></front>
+
+<seriesInfo name='RFC' value='3447' />
+<format type='TXT' octets='143173' target='http://www.rfc-editor.org/rfc/rfc3447.txt' />
+</reference>
diff --git a/misc/id/common/reference.RFC.3629.xml b/misc/id/common/reference.RFC.3629.xml
new file mode 100644 (file)
index 0000000..f7ce20e
--- /dev/null
@@ -0,0 +1,16 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC3629'>
+
+<front>
+<title>UTF-8, a transformation format of ISO 10646</title>
+<author initials='F.' surname='Yergeau' fullname='F. Yergeau'>
+<organization /></author>
+<date year='2003' month='November' />
+<abstract>
+<t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems.  The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo.  UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.  This memo obsoletes and replaces RFC 2279.</t></abstract></front>
+
+<seriesInfo name='STD' value='63' />
+<seriesInfo name='RFC' value='3629' />
+<format type='TXT' octets='33856' target='http://www.rfc-editor.org/rfc/rfc3629.txt' />
+</reference>
diff --git a/misc/id/common/reference.RFC.4086.xml b/misc/id/common/reference.RFC.4086.xml
new file mode 100644 (file)
index 0000000..c4bec85
--- /dev/null
@@ -0,0 +1,20 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC4086'>
+
+<front>
+<title>Randomness Requirements for Security</title>
+<author initials='D.' surname='Eastlake' fullname='D. Eastlake'>
+<organization /></author>
+<author initials='J.' surname='Schiller' fullname='J. Schiller'>
+<organization /></author>
+<author initials='S.' surname='Crocker' fullname='S. Crocker'>
+<organization /></author>
+<date year='2005' month='June' />
+<abstract>
+<t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.&lt;/t>&lt;t> Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
+
+<seriesInfo name='BCP' value='106' />
+<seriesInfo name='RFC' value='4086' />
+<format type='TXT' octets='114321' target='http://www.rfc-editor.org/rfc/rfc4086.txt' />
+</reference>