OpenPGP Message Format
RFC 2440
| Document | Type |
RFC - Proposed Standard
(November 1998; No errata)
Obsoleted by RFC 4880
|
|
|---|---|---|---|
| Authors | Hal Finney , Rodney Thayer , Lutz Donnerhacke , Jon Callas | ||
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 2440 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group J. Callas
Request for Comments: 2440 Network Associates
Category: Standards Track L. Donnerhacke
IN-Root-CA Individual Network e.V.
H. Finney
Network Associates
R. Thayer
EIS Corporation
November 1998
OpenPGP Message Format
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
IESG Note
This document defines many tag values, yet it doesn'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.
Abstract
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,
Callas, et. al. Standards Track [Page 1]
RFC 2440 OpenPGP Message Format November 1998
however, discuss implementation issues necessary to avoid security
flaws.
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.
Table of Contents
Status of this Memo 1
IESG Note 1
Abstract 1
Table of Contents 2
1. Introduction 4
1.1. Terms 5
2. General functions 5
2.1. Confidentiality via Encryption 5
2.2. Authentication via Digital signature 6
2.3. Compression 7
2.4. Conversion to Radix-64 7
2.5. Signature-Only Applications 7
3. Data Element Formats 7
3.1. Scalar numbers 8
3.2. Multi-Precision Integers 8
3.3. Key IDs 8
3.4. Text 8
3.5. Time fields 9
3.6. String-to-key (S2K) specifiers 9
3.6.1. String-to-key (S2k) specifier types 9
3.6.1.1. Simple S2K 9
3.6.1.2. Salted S2K 10
3.6.1.3. Iterated and Salted S2K 10
3.6.2. String-to-key usage 11
3.6.2.1. Secret key encryption 11
3.6.2.2. Symmetric-key message encryption 11
4. Packet Syntax 12
4.1. Overview 12
Show full document text