trunk/Docs/reference.RFC.2440.xml

<?xml version='1.0'?>

<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 month='November' year='1998' />
<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='HTML' octets='157503' target='http://xml.resource.org/public/rfc/html/rfc2440.html' />
<format type='XML' octets='137186' target='http://xml.resource.org/public/rfc/xml/rfc2440.xml' />
</reference>
1	<?xml version='1.0'?>
2
3	<reference anchor='RFC2440'>
4
5	<front>
6	<title>OpenPGP Message Format</title>
7	<author initials='J.' surname='Callas' fullname='Jon Callas'>
8	<organization>Network Associates, Inc.</organization>
9	<address>
10	<postal>
11	<street>3965 Freedom Circle</street>
12	<street>Santa Clara</street>
13	<street>CA 95054</street>
14	<country>USA</country></postal>
15	<phone>+1 408-346-5860</phone>
16	<email>jon@pgp.com</email></address></author>
17	<author initials='L.' surname='Donnerhacke' fullname='Lutz Donnerhacke'>
18	<organization>IKS GmbH</organization>
19	<address>
20	<postal>
21	<street>Wildenbruchstr. 15</street>
22	<street>07745 Jena</street>
23	<country>Germany</country></postal>
24	<phone>+49-3641-675642</phone>
25	<email>lutz@iks-jena.de</email></address></author>
26	<author initials='H.' surname='Finney' fullname='Hal Finney'>
27	<organization>Network Associates, Inc.</organization>
28	<address>
29	<postal>
30	<street>3965 Freedom Circle</street>
31	<street>Santa Clara</street>
32	<street>CA 95054</street>
33	<country>USA</country></postal>
34	<email>hal@pgp.com</email></address></author>
35	<author initials='R.' surname='Thayer' fullname='Rodney Thayer'>
36	<organization>EIS Corporation</organization>
37	<address>
38	<postal>
39	<street>Clearwater</street>
40	<street>FL 33767</street>
41	<country>USA</country></postal>
42	<email>rodney@unitran.com</email></address></author>
43	<date month='November' year='1998' />
44	<area>Security</area>
45	<keyword>pretty good privacy</keyword>
46	<keyword>PGP</keyword>
47	<keyword>security</keyword>
48	<abstract>
49	<t>
50	This document defines many tag values, yet it doesn't describe a
51	mechanism for adding new tags (for new features). Traditionally the
52	Internet Assigned Numbers Authority (IANA) handles the allocation of
53	new values for future expansion and RFCs usually define the procedure
54	to be used by the IANA. However, there are subtle (and not so
55	subtle) interactions that may occur in this protocol between new
56	features and existing features which result in a significant
57	reduction in over all security. Therefore, this document does not
58	define an extension procedure. Instead requests to define new tag
59	values (say for new encryption algorithms for example) should be
60	forwarded to the IESG Security Area Directors for consideration or
61	forwarding to the appropriate IETF Working Group for consideration.
62	</t>
63	<t>
64	This document is maintained in order to publish all necessary
65	information needed to develop interoperable applications based on the
66	OpenPGP format. It is not a step-by-step cookbook for writing an
67	application. It describes only the format and methods needed to read,
68	check, generate, and write conforming packets crossing any network.
69	It does not deal with storage and implementation questions. It does,
70	however, discuss implementation issues necessary to avoid security
71	flaws.
72	</t>
73	<t>
74	Open-PGP software uses a combination of strong public-key and
75	symmetric cryptography to provide security services for electronic
76	communications and data storage. These services include
77	confidentiality, key management, authentication, and digital
78	signatures. This document specifies the message formats used in
79	OpenPGP.
80	</t></abstract>
81	<note title='IESG Note'>
82	<t>
83	This document defines many tag values, yet it doesn't describe a
84	mechanism for adding new tags (for new features). Traditionally the
85	Internet Assigned Numbers Authority (IANA) handles the allocation of
86	new values for future expansion and RFCs usually define the procedure
87	to be used by the IANA. However, there are subtle (and not so
88	subtle) interactions that may occur in this protocol between new
89	features and existing features which result in a significant
90	reduction in over all security. Therefore, this document does not
91	define an extension procedure. Instead requests to define new tag
92	values (say for new encryption algorithms for example) should be
93	forwarded to the IESG Security Area Directors for consideration or
94	forwarding to the appropriate IETF Working Group for consideration.
95	</t></note></front>
96
97	<seriesInfo name='RFC' value='2440' />
98	<format type='HTML' octets='157503' target='http://xml.resource.org/public/rfc/html/rfc2440.html' />
99	<format type='XML' octets='137186' target='http://xml.resource.org/public/rfc/xml/rfc2440.xml' />
100	</reference>