Minutes for OPENPGP at IETF-96
minutes-96-openpgp-1

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."