Protocol Action: 'OpenPGP Message Format' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'OpenPGP Message Format '
   <draft-ietf-openpgp-rfc2440bis-22.txt> 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-22.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.


_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce