NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 17-Dec-97
Chair(s):
John Noerenberg <jwn2@qualcomm.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>
Mailing Lists:
General Discussion:ietf-open-pgp@imc.org
To Subscribe: ietf-open-pgp-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 compatibility 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 |
Dec 97 |
|
Submit Internet Draft for MIME encapsulation of PGP Messages Specification |
Mar 98 |
|
Issue WG Last Call for PGP Key Format & Message Specification Internet-Draft documents |
May 98 |
|
Submit PGP Key Format & Message Specification Internet-Draft to IESG for consideration as a Proposed Standard. |
Internet-Drafts:
· OP Formats - OpenPGP Message Format
No Request For Comments
Minutes of the Open Specification for Pretty Good Privacy (openpgp) Working Group
John Norenberg made opening comments and reviewed the agenda for the meeting.
Agenda
I. WG Goals (John Norenberg)
II. Phil Zimmerman (Comments)
III. Draft : PGP Message formats (Jon Callas)
IV. 2015 OP/MIME
V. Trust model documents (John Norenberg)
VI. Additional topics or other business?
I. WG Goals (John Norenberg)
John read the Working Group Charter in order to review the goals of the group. John's comments: The goal of the OpenPGP group is to do two things:
· Develop a cryptographic exchange protocol based on PGP packets.
· Develop a protocol based on RFC 1873, RFC 2015 and PGP to encrypt and sign email.
II. Phil Zimmerman (Comments)
Phil Zimmerman was asked to make comments on PGP and the IETF working group.
Phil's comments mainly revolved around his original design goals. He has resisted throwing in just "any" proposed block cipher. He is also trying to preserve the "Grass roots" architecture of the original PGP implementation.
Question from WG attendee: Has X.509 compatibility been considered?
Phil: I would like to avoid it. It is bloated and expensive to implement. However, we would like to peacefully coexist with this technology and provide users an upgrade path from X.509 to OpenPGP.
Question from WG attendee: Did you mean this for the OpenPGP standard or just for PGP Inc.?
Phil: That is up to this Working group.
Question from WG attendee: Are you also designing a PKI and SPKI?
John N.: We are not defining an infrastructure. Just how keys work. There will have to be continual heavy pressure from outside the working group in order for us to take that on.
John N(Additional comments): A 'standard' must be well defined and widely deployed in order to be useful. Our goal is to have a standard for cryptographic message exchange.
III. Draft: PGP Message Formats (Jon Callas)
Jon discussed the most recent decisions on various open issues in the PGP Message formats draft (drafts-ietf-openpgp-formats-00.txt). There was some discussion on certain points. Some decisions by Jon, et al were reversed or modified during the discussion.
2.4 Armor - This needs to be moved to a separate chapter. Chapter 2 will say that implementations SHOULD support ARMOR. Armor headers - We need to have a table of these. We also need to flesh out generation of the message ids for multi-part messages.
2.6 Cleartext signatures - We are removing this x.x Counted strings - This will be removed. The type is not used except for one or two places. We will define it in those places and declare it as a simple type.
2.5.3.3 Iterated/Salted String-to-key - This is long, hairy and complicated to implement. We have considered removing it. The rationale for its use is that:
· Salt perturbs encryption of strings (same string encrypts to different values each time it is used)
· Iteration adds compute time for the craker program running a dictionary attack.
· We've seen 3 options mentioned
1. Remove it
2. Change 8-bit float to 32-bit int
3. Change it to a MAY
Request for comments from WG.
Comments from WG member: Options add complexity but is useful and important. The member would not have a problem with it if the float was changed to a 32-bit integer (2).
4.2 Encrypted Session Key - Will be changing the name of this to Public Encrypted Session Key to balance naming with Conventionally Encrypted Session Key.
5.3 Signatures - These will be put in a table and marked as required or optional as per comments on the mailing list.
ISSUER ID subpacket - This will be added to hashed subpackets ARR subpacket - This will be defined as optional. The draft will say explicitly that the implementation can do anything it wants with this. It does not have to use it.
Comments from WG attendee: Agrees with consensus. However, would like words to tell implementors what to do if they do not want to handle it.
Jon Callas response: Sounds good.
Critical flag: This section is confusing. Will rewrite to say that if the critical subpacket is not understood by the implementation, the signature must be ignored.
Comment from WG attendee: Criticality must be MUST. This means if the implementation does not understand the critical subpacket type, it must consider the signature invalid.
Phil: Disagrees. The signature is still valid and should be considered such. However, use of any semantic meaning of the signature is lost.
Preferred key server: Good to have a place to get most recent key.
Comments from WG attendee: This is starting us down a slippery slope.
John Norenberg: Yes, we have to be careful. But if we stick to defining how to represent keys, and leave the protocols for infrastructure to the infrastructure folks, we'll be ok.
Phil: This is good but we need more experience with protocols i.e., an implementation that does this.
Regular expressions: We need a syntax for regular expressions sub packet. Requested pointers to a description of a reg exp library to which the draft can refer. Negative preferences? (Editor's question) : Did not receive comments saying this was needed. As a result, we will not proceed with this.
UserId revocation subpackets: These will be deferred to v2. Other subpacket types (Editor's notes) : Jon had noted some packet types that were described (or reserved) in an earlier PGP implementation. These were never actually implemented. The question was, should we do any of them. Since nobody responded that they could not live without these features, they will be deferred.
5.2.2. Signature types
Identify: Generic, Personal, Casual, or Positive
Other than Generic, no implementation has generated or handled these. As a result there is no history or experience on what the semantics should be. Personal, Casual, and Positive will be dropped from the document.
Timestamp Signatures
· We shouldn't be taking this on. This is another Slippery Slope. We will, however, note that they exist.
Signatures that bind keys with subkeys
· We have not received a good definition of this. If we don't get a solid definition, we will leave this out.
Secret keys
· Encryption is done in PGP's variant of CFB. (Other comments not recorded).
Marker packet
· We will change text so that an implementation can put anything it wants into this packet. We will also suggest it should contain the impelmentor's name.
Trust packets
· These will explicitly mark them as implementation-defined.
Comments from Jeff Shiller (back to marker packet) : Can't this be used to leak out data (like the clear text message xor'ed with something)? Why have this at all. It is a security risk. Discussion followed. Jon Callas: We will state that it MUST be a constant to avoid it being exploited to subvert security.
Non-text UserIds:
· These will be deferred. They are not yet defined well enough.
Comments from Phil: These are going to be important. We need this in the spec now. Discussion followed concerning formatting problems, etc. Jon Callas (to Phil): Send a specification to the openpgp list.
SDSI names :
· These will be deferred.
Jon Callas : These are a good thing but we do not have enough time. Additional comments from Jon: This draft is supposed to go to last call sometime in March 98. Ideally, we will be AHEAD of that schedule. Jon is hoping to have a new draft up shortly, handle additional comments over then next month or so (through January) and go to last call in February of 98.
Comment packets :
· An implementation MAY display a comment but MUST NOT interpret contents.
Jeff Shiller: You may want to reconsider using UTF-8 for textbased userid's.
Jon Callas: This has already been specified in the draft (at least, he is pretty sure of this.)
Chris: Recommends that comments be removed altogether.
Jeff Shiller: agrees with this.
Jon Callas: Fine. We will remove them.
5.n: Interoperability packets:
· These are desirable, but deferred. The existing definitions are insufficient.
Subkeys (Comments unrecorded)
7.2 BNF:
- We need additional BNF for how signatures are formed.
Comments from WG attendee: Please include at least one example. Seconded...
Jon Callas: Noted...Security considerations: We will be adding description of stealth-mode and packet analysis avoidance.
Miscellaneous: (Comments not recorded)
Comments on algorithm lists from Phil: We have multiple algorithms to ensure that if one breaks, users can continue operating securely by just changing preferences. We should, however, shoot for minimal # of algorithms. We should not just put in everyone's pet algorithms. Comment from WG attendee: Other specs give one MUST and everything else MAY. Market should drive the algorithm selection. We should not limit it.
Phil: Maintained that WE should pick the algorithms. Attitude is: "I know cryptography, you don't."
Perry Metzger: Pick minimum # and types of algoritms for interoperability. Let market drive rest.
Chris?: We should provide a 'private algorithm #' with no content description. This allows others to use OIDs, etc to implement anything they want.
Ned: Agreed. Also, this is not the time to add tons of algorithms to the spec.
Jon Callas : This is already done. 11 things are reserved for private algorithms.
Algorithms:
- Blowfish
- GOST, needs sboxes specified
- Jon Callas: I can't specify these.
- AES : We have reserved an id
- Ellyptic Curve, IDEA-EDE - added.
Speculative (stealth mode) keyIDs - Cut's traffic analysis.
We need to write rationale sections
IV. 2015 OP/MIME
Draft Status:
Draft status: 80% complete
www.imc.org/ietf-pgp-mime/mail-archive/0081.html
New Draft will be in: www.imc.org/ietf-open-pgpg/draft-ietf-opengpg-mime-00.txt
Draft has been submitted to IETF.
Technical changes:
OP Msg formats now have details
New MIME constant types have been defined
- application/openpgp-encrypted
- application/openpgp-signature
Quick vote: Do we want these defined? : 4 against : 10+ for 2xx abstentions?
Content transfer encoding restrictions
- generate strictly, accept liberally
OpenPGP encrypted data
- Question : MIME or OP encryption first?
- Decision : MIME cannonicalized first, then encrypted
OpenPGP signed data
- protocol = application/openpgp-signature
= openpgp-md5
openpgp-sha1
openpgp-ripemd160
openpgp-haval (15 variants)
Parallel signatures are popular
RFC1847 based parallel signatures on the same data have been defined.
Distribution of PGP keys
This text will be moved to PGP certificate document.
Ned Freed: Ongoing issue with multipart signed messages. The issues concern gateways. He encouraged people to read and comment on his draft concerning this: drafts-freed-gsec-00.txt.
V. Trust Model Documents (John Norenberg)
There are numerous types of trust models. It would probably be good to have a document on this. The document would cover:
· What trust models are available.
· How they work.
· How they are implemented in the context of PGP.
Question for group: Do we need this?
Paul Hoffman: Agrees. Would be good to have a separate document on this.
John Norenberg : Should we vote here or defer this question to the list?
Rodney: Let's take these questions to the list and decide there.
Any other business? Blue sheet...all signed? About 40 not yet on list.
John Norenberg summarized what was covered at the meeting. He then closed the meeting at 3:10 PM (20 minutes ahead of schedule).
None Received