Last Modified: 2004-02-11
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.
The whole purpose of Open-PGP is to provide security services.
|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|
|RFC2440||PS||OpenPGP Message Format|
|RFC3156||PS||MIME Security with OpenPGP|
used.OpenPGP 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 validation. 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 authors. * 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.