2.6.5 An Open Specification for Pretty Good Privacy (openpgp)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-11

Derek Atkins <derek@ihtfp.com>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Steven Bellovin <smb@research.att.com>
Mailing Lists:
General Discussion: ietf-openpgp@imc.org
To Subscribe: ietf-openpgp-request@imc.org
In Body: Only the word subscribe
Archive: http://www.imc.org/ietf-open-pgp/mail-archive/
Description of Working Group:
PGP, or Pretty Good Privacy, first appeared on the Internet in 1991. It has enjoyed significant popularity amongst the Internet Community.

PGP is used both for protecting E-mail and File Storage. It presents a way to digitally sign and encrypt information "objects." As such it is well suited for any store and forward application.

The goal of the OpenPGP working group is to provide IETF standards for the algorithms and formats of PGP processed objects as well as providing the MIME framework for exchanging them via e-mail or other transport protocols.

Because there is a significant installed base of PGP users, the working group will consider compatibilty issues to avoid disenfranchising the existing community of PGP users.

Security Issues:

The whole purpose of Open-PGP is to provide security services.

Goals and Milestones:
Done  Submit Internet-Draft for PGP Key Format & Message Specification
Done  Submit Internet Draft for MIME encapsulation of PGP Messages Specification
Done  Issue WG Last Call for PGP Key Format & Message Specification Internet-Draft documents
Done  Submit PGP Key Format & Message Specification Internet-Draft to IESG for consideration as a Proposed Standard.
Done  WG Last Call for PGP/MIME draft
Done  Submit PGP/MIME draft to IESG for consideration as PROPOSED standard
May 01  Submit Multiple Sig draft to IESG for consideration as PROPOSED standard
Jul 01  Begin RFC2440, PGP/MIME Interoperability testing
Aug 01  Request DRAFT status for RFC2440
  • - draft-ietf-openpgp-rfc2440bis-09.txt
  • Request For Comments:
    RFC2440 PS OpenPGP Message Format
    RFC3156 PS MIME Security with OpenPGP

    Current Meeting Report

    IETF-59 Seoul
    South Korea
    March 2, 2004 1300-1400
    minutes by: Jim Schaad
    Derek opened the meeting with agenda bashing and appointment of a 
    meeting secretary.
    STATUS OF RFC 2440BIS:  The document has been around since 2001 and the 
    group needs to finish it.  The current draft is -09 with one update known to 
    be coming.  Derek presented the issues on the document since the editor was 
    not able to attend the IETF meeting.
    Derek covered the set of closed issues on the document.  These issues are:
    * Clarifications on the construction of compressed messages * 
    Non-Textual User IDs, they must now be UTF-8 strings only * Addition of a 
    discrete log hash, no strong support for doing this so it   will not be 
    done. * Comment line length - no consensus for this issue developed on the 
    mailing   list so no changes are going to be made for this issue. 
    Derek covered the set of open issues on the document.  (Titles of the 
    items correspond to the mail thread subject name.) These issues are:
    * Signature woes & Reconciliation: Text has been proposed to resolve this 
    issue.  This was accepted without comment from the attendees.
    * Trailing White Space: The issue is that some e-mail gateways strip 
    trailing white space on lines when processing mail messages.  This cause 
    signature validation failure at later date.  The question is whether this is 
    an issue that needs to be addressed.
    One proposal is to strip EOL characters where the character <= 0x20.  From 
    the floor it was pointed out that this could cause problems from two 
    things. 1) there are some control characters that may be part of the text 
    stream (such as page feeds) that should not be stripped and 2) for some 
    languages escape characters for local language processing might produce 
    characters that are in this character range and thus produce 
    corruption of the text.
    One suggestion was to do the standard MIME time 
    canonicalization and ignore the rest of the issues.  If the message is 
    changed by stripping spaces in a gateway, then the message correctly fails 
    As no text has been proposed or was proposed from the floor the issue was 
    punted back to the authors to propose some text.
    * IDEA in the v3-v4 algorithm conflict:  Major issue the question of what 
    support needs to be given to PGP 2 implementations.  No proposed text was 
    presented so issue was punted back to the author.
    * 3rd party signatures in a one-pass signed message:  This issue is not 
    currently addressed in -09.  Text has been proposed to address this issue 
    and was accepted.
    *Obsolete 1991:  Question is should rfc2440-bis obsolete RFC 1991 as well as 
    RFC 2440 when it progresses.  This was the consensus of the room.   * 
    Back-signatures from a signing sub-key onto the primary key:  Text has been 
    supplied to address this issue by the author, the text was accepted by the 
    working group.
    * Non UTF-8 Text in Message Body:  Should a charset on the armor header be 
    specified for non UTF-8 text?  No text has been proposed to address this 
    issue.  This has been punted back for proposed text by either Felix or the 
    * Remove Elgamal signatures (type 20):  Some security weaknesses have been 
    identified in the Elgamal signature scheme used.  The 
    recommendation is to remove it from the standard.  The group accepted this 
    without comment.
    * Partial length chucks and 5-byte lengths:  One reading of the text 
    appears to disallow 5-byte length items.  Authors have proposed a new text to 
    deal with this issue.  Text was accepted by the group.
    * "cleartext signatures" naming convention:  This is just and 
    editorial issue.  The proposal is to move from several different ways of 
    describing the cleartext signature concept by a single string.  The list of 
    locations has been provided and the author is to make the changes.
    * MDC Inconsistent in bis-09:  There are two places where this process is 
    described and they are inconsistent with each other.  Section 5.14 is the 
    one that does not match existing code so it will be modified to match the 
    other section.
    * Secret Key Packet Formats:  This is just a set of editorial changes, and 
    were accepted by the group.
            - 2440bis to IESG: May 04 - Proposed
            - multiple sig draft - Remove this from the milestone list as it's 
    purpose and authors are not known
            - Interop testing to start Aug 2004
            - Advance to draft about Feb 05.