OpenPGP Working Group Meeting Minutes 8-Dec-1997 Antonino N. Mione John Norenberg made openning comments and reviewed the agenda for the meeting. OpenPGP Meeting Agenda WG Goals (John Norenberg) Phil Zimmerman (Comments) Draft : PGP Message formats (Jon Callas) 2015 OP/MIME Trust model documents (John Norenberg) Additional topics or other business? 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. o Develop a cryptographic exchange protocol based on PGP packets. o Develop a protocol based on RFC 1873, RFC 2015 and PGP to encrypt and sign email. 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 & 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 dnt 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. 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: 1-Salt perturbs encryption of strings (same string encrypts to different values each time it is used) 2-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 infrastrucute 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 recieve 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 Identifity : Generic,Personal,Casual,Positive Other than Generic, no implementation has generated or handled these. As a result there is no history or experience on what the symantics 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 desireable, 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 alogrithm lists from Phil: We have multiple algoritms to ensure that if one breaks, users can continue operating securly by just changing preferences. We should, however, shoot for minimal # of algoritms. 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 2015 OP/MIME Draft Status Technical Changes 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. 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).