openpgp minutes, 7/18/2016 chairs: DKG, Barry Leiba minutes: Melinda Shore High points and to-dos: . proposal to expand registry to two octets will be taken to mailing list . looking for volunteer to draft up text for encrypted-to subpacket . need conversation with CFRG regarding argon2 . need to go through list of proposed deprecations on the mailing list . need to come to agreement on whether to specify STRONG profile or COMPAT profile as MTI . need text on fingerprinting proposals . need volunteers to write text on new signature scheme chairs: intro, note well, welcome Barry, agenda bashing Agenda: . agenda bashing . document status review . registry management . 4880bis changes . PGP/MIME vs S/MIME from mailing list . AOB Document review =============== draft-ietf-openpgp-rfc4880bis now a working group draft. Integrates elliptic curve stuff. Draft is written in markdown, changes can be contributed using pull requests or in text sent to mailing list. New text should always be sent to the mailing list even if a pull request is submitted. Registry management (DKG) =================== Going to get requests for codepoints that may not be MTI. Very limited codepoint space (7 bits). There's interest in relaxing conditions for codepoint assignment but that would mean expanding the codepoint space. Proposal to expand to 14 bits, use high bit in current octet to indicate that it's a two-octet value. Would give enough space so that codepoints could be assigned FCFS rather than arguing on the mailing list. PHB would rather have a divide between stuff the IETF cares about and everything else, and rather than changing the registry, have one additional codepoint have the algorithm specified by an OID, then stick the OID in a part of the package you don't care about. That moves the tagging of the crypto completely outside the IETF. Stephen Farrell: not convinced by Phill's argument. Guesses it would probably work but copying the TLS approach seems like a better way. Werner says we already use OIDs to identify the curves. Paul Wouters says we already do that in IPSec, but it's during a live conversation rather than an asynchronous situation where data may be looked at hours or possibly years later, so not sure it maps onto this openpgp problem. PHB: part of the idea here is to avoid having another registry. Every crypto library already has a mechanism to map OIDs to algorithms, using a registry would mean adding new functionality to code. DKG: the proposal does not mandate adding any new registries. Columns would be added to existing registry. Increases *size* of registry, to allow FCFS codepoint assignment. Barry pointed out that the proposal says designated expert review, not FCFS. DKG will post proposal to mailing list. 4880bis changes (Werner Koch) ============================ MIME flag: add new literal data packet tag 'm'. It's in the issue tracker and there's a proposal on the mailing list. David Shaw proposed explicitly stating that the file name, file data, and tag are not covered by the signature. Issuer fingerprint: proposal to put the issuer fingerprint into a new subpacket, to fix problems related to short 64-bit key ID. Proposal has been sent to the mailing list and is in the issue tracker. Encrypted-to: new encryption subpacket - put list of recipient keys into the signature. No proposal for this yet. Werner would appreciate someone writing text/proposal for this. Barry asked value of having key. Werner - you can later prove or show the original recipient. Appears related to provenance issues. DKG asked for volunteers, got none. S2K: want a new codepoint for argon2i, another for "no S2K", deprecate all other S2K modes. Stephen asked that work be kept in sync with work being done in CFRG. Hanno Böck asked if we want to wait until CFRG has produced an argon2 RFC. DKG said he had the impression that argon2i has already been modified there. Stephen suggested making requirements clear to CFRG. Deprecate: lots of stuff, 3DES, MD5, SHA1, SHA224, RM160, Twofish, Blowfish, Symmetrically Encrypted Data Packet, OpenPGP v3, all S2k except argon, cleartext, and "no S2K," and certain key sizes for algorithms with arbitrary length. Take to mailing list. Nobody spoke up for keeping any. Deprecation strategy: have classes of deprecated algorithms and parameter values. Need to be able to decrypt old data, so specify MUST NOT produce, but MAY consume. Stephen: "is there anything else we can get rid of?" Asked about Camillia. DKG: suggested clarity about what goes into the registry - that is to say, values for the columns so that we have something concrete to say. Barry: difference between deprecated and obsolete. Stephen: maybe you need a slightly different set of columns from TLS MTI profiles: STRONG proposed MTI algorithms and COMPAT proposed MTI algorithms. DKG asked if the proposal is to have both or to choose one. Werner said to choose one. Barry: should the MTI profile be forward-looking or compatible. ? asked if quantum safety was under consideration. Werner said "no, it's too early to put this in the standard." Stephen agreed it's premature. PHB: can see us burning through 50-100 codepoints while working this out, better get the registry questions settled quickly. Hanno Böck: with the symmetric part of the STRONG proposal, we're already nearly there with quantum resistance, and all that would need to be done is the asymmetric part. Stephen: if the wg chooses the STRONG proposal, how many people wouldn't implement the COMPAT stuff anyway? Werner said probably Javascript implementations would use only one of the profiles. Barry said that the worry with the STRONG proposal is generating things nobody will be able to decrypt, but DKG said that if we're primarily concerned about compatibility we'll never be able to move to newer stuff. Stephen: I'd be good with whatever people writing code are doing. Take it to mailing list. v5 fingerprint: Questions about what needs to be included, and what the transformation should be. Proposal: no creation time, and use SHA-512 truncated to 200 bits. DKG: much bikeshedding on mailing list already, not sure how to move forward. What would happen if there are four competing proposals and no consensus. PHB: resolve this thing by adding more requirements. Brief bikeshedding ensued. Chairs asked for text. Features subpacket: "support modification detection code" supported by flag in features subpacket, which is a preference. Add "support AEAD for v4 keys only. v5 keys MUST NOT have a Features subpacket. Can do same thing with Notations, which should be used in the future. AEAD: should use AES-GCM or AES-OCB, or both? Does it need to be streamable? POET/AEZ/ElmD new and should be considered. May be some patent problems around all this. Open for discussion. DKG: is the GCM text in pull request form? New signature class: the signature Literal Data Packet is not usable because it's not protected by the signature. Idea is to define new sigature class, looking for proposals to hash everything into a literal data packet. Anybody interested in writing a proposal? No hands. Werner said he will do an implementation if it's specified. DKG: One thing that hasn't been brought up here is Ed448. Werner hasn't looked into it in detail but we need another hash algorithm. We don't need a code point because for elliptic curves we're using OIDs. DKG: but we'd at least need to indicate which OID to use - there is a CFRG draft for Ed448 but it's not an RFC yet. PGP/MIME vs S/MIME ================== Message formats: out of scope for this working group Certificate formats: openpgp will not adopt X.509. If someone wants to write text on X.509 certs and it won't delay the work of the working group that's fine, but it shouldn't distract from crypto revisions. No objections to not dealing with it. If we want to talk about rechartering that's a separate conversation but we're overdue on current work. AOB === Question for Werner: has he looked at the 15 held-for-document-update errata on 4880? "Yes."