OpenPGP Message Format
Draft of message to be sent after approval:
From: The IESG
To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , openpgp mailing list , openpgp chair Subject: Protocol Action: 'OpenPGP Message Format' to Proposed Standard The IESG has approved the following document: - 'OpenPGP Message Format ' as a Proposed Standard This document is the product of the An Open Specification for Pretty Good Privacy Working Group. The IESG contact persons are Sam Hartman and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-23.txt
Technical Summary OpenPGP 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. This document is an update to RFC 2440 based on implementation experience and advances in the field. Working Group Summary The OpenPGP working group had consensus to advance this document as a proposed standard. Protocol Quality This document was reviewed for the IESG by Sam Hartman. The changes since RFC 2440 are of sufficient quality to be published as a proposed standard. Note to RFC Editor Please move the reference to RFC 1991 to an informative reference and the reference to 1951 to a normative reference. Add to the end of section 15: * OpenPGP does not put limits on the size of RSA public keys. However, large keys are not necessarily good. Larger keys take more computation time to use, and this can quickly be unusable. Most OpenPGP implementations set an upper bound of 4096 bits in RSA public keys. Some have allowed 8K or 16K, which are large enough to have problems in many environments. If an implementation creates keys larger than 4096 bits, it will sacrifice interoperability with most other implementations. * ASCII armor is an optional feature of OpenPGP. The OpenPGP working group strives for a minimal set of mandatory-to-implement features, and since there could be useful implementations that only use binary object formats, this is not a "MUST" feature for an implementation. For example, an implementation that is using OpenPGP as a mechanism for file signatures may find ASCII armor unnecessary. OpenPGP permits an implementation to declare what features it does and does not support, but ASCII armor is not one of these. Since most implementations allow binary and armored objects to be used indiscriminately, an implementation that does not implement ASCII armor may find itself with compatibility issues with general-purpose implementations. Moreover, implementations of OpenPGP-MIME [RFC3156] already have a requirement for ASCII armor so those implementations will necessarily have support.