Editor's note: These minutes have not been edited. "MIME Security with Pretty Good Privacy" (PGP/MIME) Minutes from the 961213 PGP/MIME BOF at the 37th IETF Meeting (San Jose) + Introductions + PGP/MIME Status Quo + Overview of RFC 2015 + Discussion of RFC 2015 + Known Implementations + Future Directions N.B.: Items in the minutes which are preceded by a bang (!) are flagged as potential dicussion items for the ietf-pgp-mime mailing list. =2E........__________________________________________________________.......= =2E. + Introductions Co-Chairs: Charles Breed - (PGP Inc) Director of Technical Marketing Dave Del Torto - (PGP Inc) Technical Evangelist, BOF/WG organizer Expert Panel: Michael Elkins - (TIS Inc) RFC 2015 Author, Engineer Raph Levien - (UC Berkeley) PGP/MIME proponent, CS Grad Student Derek Atkins - (Sun) PGP3 engineer, cryptographer =2E........__________________________________________________________.......= =2E. + PGP/MIME Status Quo (Charles Breed) Why is a PGP/MIME format needed? - Convenient transport of PGP messages for large number of Internet users. Why does the IETF need a PGP/MIME BOF or Working Group? - BOF: review draft, finalize status of RFC 2015. - WG: finalize PGP/MIME Standard as per IETF guidelines. State of Affairs: - BOF is occurring after RFC: atypical but legitimate (used "last call" mechanism for RFC approval). Obvious public demand for solution. - Expect RFC 2015 to be finalized into IETF "Draft" in early 1997. - PGP/MIME Working Group Charter will be developed: - establish standard PGP/MIME processes. - Provide for smooth interoperability with RFC 1847. - Ensure human-readability of PGP/MIME format. Preliminary Comments from BOF attendees: - (Metzger) Since the proposed format is acceptable, the WG charter should stick to the continued development of the PGP/MIME standard, and not try to establish anything "new." - (Noerenberg) WG's Charter must include milestones/deliverables: Draft by 3/97, Standard by 4 months later: 7/97. Current P/M mailing list has few objections to current RFC, all should progress quickly. - (Hoffmann) A reminder: we need two independent, interoperable implementations (see below). - (Del Torto) Reminder: December 96 Cypherpunks meeting will be hosted by PGP at Hotel Sofitel tomorrow. See: . =2E........__________________________________________________________.......= =2E. + Overview of RFC 2015 (Michael Elkins) Why RFC 2015 was created: - Motivation: no clear standard existed for doing PGP in Internet msgs. - Need a way to apply PGP's strong crypto to Internet multimedia data. - Needed improved successor after Borenstein PGP/MIME RFC withdrawn for lack of PGP-signed msg recovery. - RFC 1847 (Secure Multiparts for MIME) provided a good model/foundation for producing signed multiparts. - Any MIME client should be able to ignore PGP format artifacts, shorten msgs by removing all traces, but retain verifiability. - MTA modifications of mail destroys PGP-sigs, PGP/MIME protects them. Summary of RFC 2015 MIME content-types: - application/pgp-encrypted - application/pgp-signed - application/pgp-key =2E........__________________________________________________________.......= =2E. + Discussion of RFC 2015 (Chairs, Panel) (by Section#) (Questions/Comments/Suggestions by the BOF Attendees) (? =3D name unknown or person not visible) - Section 1: - (Del Torto) Improve intro/history for novice readers. - Section 2: - (?) Needs to be more clear on requirements for: - data to be signed vs signature data in application/pgp-signed. - (?) Sect 5 has this correct. - Section 3: - (?) CTE (Content Type Encoding) restrictions should be 7-bit. - Section 4: - (?) All headers + body are used for sig/encrypt calculation. - Section 5 (Signed Data, Hash Algorithms): (?) Q: Specify MD5 vs SHA-1 MICALG, or no need to store whole msg before checking ? (Atkins) MICALG info is already in sig-block. (?) Q: If 2015-compliant, must implementation use both MD5 and SHA-1? Consider SHA-1 as preferred? (Elkins) A: MD5 required for current PGP 2.6.x compatibility. (?) Q: When receiving: MD5 is a must, and SHA-1 supported also? (?) A: When sending: accept both, be able to send SHA-1. (?) Q: can 2015 be extended for SHA-2? (Elkins) Yes (Levien) Actually ASN.1 encoded (?) Q: Mention additional hash symbols for MICALG: (?) A: S/MIME has broken out pieces vs profile/musts, plus enumerated list: better to use UNenumerated list so nothing breaks later, so you know something else is coming. (Schiller) Q: If msg requires SHA-1 does that require PGP3? Users would have to get pre-alpha PGP3 to be 2015-compliant? (T'so) Q: Can't build PGP/MIME compliant version w/o PGP3?! (Noerenberg) A: No, allow for MD5, but prefer SHA-1. (Schiller) A: 2015 should allow installed base to use PGP 2.6.x. (?) Q: only acceptable solution is go back to MD5? (?) Q: 2015 can go fwd w/o SHA as requirement? (General Agreement) (Stewart) A: 2015 can encourage implementation of SHA-1, without invalidating current users (Schiller) A: For sending: MUST be able to send MD5, and send msg that will return SHA-1. Receive: require MD5, should accept SHA (?) Q: Is discussion based on assumption that MD5 will fall? (Del Torto) A: attacks on MD5 are not trivial, but plan ahead. 2015 should be usable by PGP 2.6.x installed base. (?) Q: Is there a problem with requiring MD5? (Schiller) A: Not good idea for implementation to require MD5: constraining of user base. (?) Q: How about generating two sigs with MD5 _and_ SHA-1? (?) Probably need mechanism to support multiple sigs w/diff. algo's (Elkins) A: more of an RFC 1847 issue, outside scope of 2015. (?) A: 1847 says second part is sig-block, you could make it multiple sigs within that part. (?) A: Declare MICALG in 1st field as MD5 or SHA-1, then add data in 2nd part. ! (Elkins) Recommend we take this to the list. (General Agreement) Rough Consensus: Incoming: "Must" accept MD5, "Should" accept SHA-1 Outgoing: "Must" send MD5, "Should" send SHA-1 - (Elkins) 2015 is unclear on charset conversions: - message should be canonicalized before signing - will reference RFC's 1847 & 1521 (MIME) for canonicalization - (?) Q: ASCII is Base64, "armor" sounds like a "PGP word" (sect 2 for sig not for data) (Noerenberg) Implementors say "MIME compliant." (Atkins) Not Base64, just for PGP output, PGP sig is ASCII armor. (?) It's two items: wrapper and B64, state that explicitly. (Atkins) Not Base64. (?) Then re-word Sect 2: gave impression body part was also supposed to be Base64/armored? (?) Second multipart gets this, also needs to be protected. (?) distinguish between PGP's ASCII, state that Base64 should be used for actual data (Elkins) RFC 1847 says multipart signed/encrypted should not be altered. Int'l countries dislike QP, but should not destroy it, or will lose sigs. Signed msgs should be 7-bit: ONLY encrypted msgs should be 8-bit. Preserve sigs: Encrypt during transfer, put in employee mboxes. Before sign/encrypt, convert to MIME canonical format (define later) Two parts to PGP/MIME msg: 1. Control info part ("Version 1" indicates 2015-compliance) 2. Data part - (Del Torto) The "From=3D20" example msg begs more presentation clarity, perhaps a N.B. that the example is self-referential. - (Elkins) Sigs must use canonical line endings, possible weakness is that char-set conversions are not specified: could end up with two interpretations, need to spec charset conversions, line ends (?) Q: Is this different from canonical licenses in 1847? (Elkins) A: Yes. (?) 2015 references 1847 Std on charsets: better not to list it. Don't introduce document dependencies (Elkins) Should reference 1847 canonicalization, though. (?) Q: why should charset conversion be an issue: more than plain ASCII should be MIME encapsulated (happens with 8-bit anyway). (Elkins): ISO-Latin + conversion ! (All) Take UTF8/UNICODE solution possibility to list. (Elkins) Q: Encrypted AND Signed issue: PGP uses internal format Valid for implementors to use: - 1847 encapsulation (PGP/MIME encrypt first, then sign) OR - Do encryption + sign in PGP then label MIME part as such. - Ambiguity comes from using combined method. (Levien) A: Draft calls for signed part to be 7-bit ASCII safe format: no need to spec char conversions. - Section 6: - (Yamamoto) 2015 has cononicalization problems with Japanese: - There are "Old" and "New" Japanese text formats, J comm'ty mostly uses Old version of J text. - ISO-2022-JP includes Old+New+Restricted charset encodings (super-/subsets) - Sig calculation is only possible on Restricted charset - Therefore, to ensure sig-verification, Japanese community prefers the "Restricted" charset. - J must break Old/New into separate multiparts (2022, Restricted) to verify sig but PGP has no feature for this (T'so) Q: is Old/New->Restricted transform published somewhere? Should reference 2022 as part of canonicalization step. (?) Can you calculate sig on a transform of what you send? (Elkins) Could do sig over canonicalized version, but if you sign over ISO-Latin1 8-bit QP would require undoing the coding to verify the sig. (?) Sig is what you send, Japanese request says to re-hash it: with either Old or New text, do transform. Problem is not sending the text used for the sig. (Atkins) If MUA is involved, should be done in PGP step. (Newman) Charset issues are orthagonal to PGP/MIME: it's better handled by MIME Japanese charset labelling. (Yamamoto) Separate sig and encrypt services clearly (_____?) (Elkins) Need extra info to define how to get to valid signature. (Levien) Intention of 2015's combined format was to allow strictly for interoperability of existing PGP versions: we're "uncomfortable" with the Japanese proposal. (Elkins) You can't insert something other than what you send: put your signed data in the first part. Signed body part is ONE step, can't sign what you didn't send. 2015's intention is correct, J proposal is "illegal", no change required. - Section 7: - (?) Any issues for key distribution? (Del Torto) Just label key: receiving MIME MUA should handle it. ! (All) Take further key distribution discussion to mailing list. - Section 8: - (Blaze) Q:Will a PGP-compatible mailers require trademark notification? (Breed) A: No, PGP Inc wants to support wide adoption/usage, will not restrict by holding on too tight. (Del Torto) Strength of PGP is openness, wide availability. (Atkins) Moot: RFC 1991 defines "-----BEGIN PGP" as part of open std. - (Hoffmann) Q: Is "PGP-compatible" OK as well as RFC 1991-compatible? (Del Torto) A: Yes. - Other Issues: - (?) Q: S/MIME gateways can break multiparts illegally:=20 should/will PGP/MIME allow this? (Elkins) A: No, don't worry about broken vendor implementations: gateways are dead, PGP/MIME can't account for gateways that don't properly support MIME. - (Yamamoto) Q: Is a protocol version number in content-type needed for signed only? (Elkins) A: 1847 says first part has control information: first, hash over data; second, don't need to know protocol version number, nothing will change. ! (?) Move to list: might need to add version# to app/pgp-signature line (Elkins) A: info is in PGP sig block: unnecessary to add version#. - Additional Info: - Univ of Chicago's existing PGP/MIME mailing list: - , body =3D subscribe - archive is needed for that list, wherever it is hosted (see below). - Raph Levien has some history and info on PGP/MIME at: - =2E........__________________________________________________________.......= =2E. + Known Implementations - Two interoperable implementations are required for an IETF Standard. - Several already exist for PGP/MIME: - 1 through 3 below were demonstrated to interoperate at the BOF 1. "Premail" by Raph Levien - Transparent layer between MUA ad MTA, hides PGP processing from users. (?) Q: If MUA can't find keys for sending, what do you do? (Levien) A: In Netscape, intgration is clean: NSCP wil display Premail key-not-found error, then move on. (Yamamoto) Q: Can you encrypt one part only? A: PGP/MIME allows this, but Premail doesn't do it. Strictly a design decision (keep it simple). (?) Q: Can you process a msg where only a small part has been signed? A: Not yet implemented. 2. "MUTT" by Michael Elkins - Clean, straightforward PGP/MIME mailer. - Interoperates well. 3. "MEW" by Kazu Yamamoto - Nice handling of multipart index in top of split window. - Suggestion: color coding of various parts. 4. "EPPI" (Eudora/PGP Plug-In) 5. "PGPClick" (?) Actually, this implementation isn't PGP/MIME compliant (yet?). =2E........__________________________________________________________.......= =2E. + Future Directions - Working Group: - A formal vote was taken on whether to establish a PGP/MIME WG: - Result: YES. - IETF PGP/MIME Working Group Mailing List: - Paul Hoffmann of the Internet Mail Consortium offered to host a new PGP/MIME WG mailing list. This list will henceforward be the official forum for posting of information and discussion of the progress of the WG and will focus its activities specifically on RFC 2015. - Anyone interested in the PGP/MIME standard can join the "ietf-pgp-mime" mailing list discussion by sending a message To: ietf-pgp-mime-request@imc.org with a message Body consisting of only the word: subscribe - The list is accepting subscription commands, and a recent automated notification message signalled that the discussion can begin any time. The list address is: ietf-pgp-mime@imc.org - Note: if you're participating in another discussion on PGP/MIME, you might at least CC this list as well. - The list's web site, including an Archive of the mailing list and the relevant drafts, is at: . [please send corrections/info regarding these minutes to ] =2Eend. -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv Comment: Verbum sapienti satis est. iQCVAwUBMtThQ6HBOF9KrwDlAQEJcQQAsN+fmD1HMve0FcZdvS6eT1+/5IVUvJNv iirKQKxh0yU+xTmS3wXZQ7jLTvbuy7J+JyrKIeSfbZWhZI7ckifVtXM6GVaXgHL9 HDaKZN6+a/yDPUlznyTRq4HYpxU0yYx6ShoJRiUCVppg83t5j2IIjd1lS5GK/qq5 EeN7C591ogk=3D =3Dtf37 -----END PGP SIGNATURE-----