ietf-openpgp
[Top] [All Lists]

Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th

2015-04-01 15:31:08
On Wed 2015-04-01 14:57:49 -0400, Stephen Farrell wrote:
option 2: do maintenance work on rfc4880 - produce a 4880bis
with better crypto options at least, and debate any further
detailed changes during chartering - the charter will contain
a list of specific things to do and other things will be out
of scope (for now)

I think i favor this approach, ideally *without* adding trust model work
into the mix.

Trying to explicitly declare a standardized trust model would be a
mistake for the WG.  it's a huge rat hole, and a "one trust model fits
all" approach is probably illegitimate at some deeper level, since
different people have different adversaries.

If there's any work to be done with trust models, it would be to write a
document that tries to describe one or more of the more common
approaches to trust models (e.g. the GnuPG default arrangement, or
whatever sort of TOFU mechanism that PHB thinks is what everyone
"actually uses").  I do *not* think that needs to be in the WG charter,
that can be an independent submission any time by anyone with an
interest in clarifying trust models they use.



For option 2, i have the following specific items i'd like to see
addressed (though they may not need to all be in a new charter):


a) update the fingerprint format (avoid inclusion of creation date, use
   stronger digest algorithm; i'm dubious about embedding algorithm
   agility in the fingerprint itself, but explicit version info in the
   fingerprint might be reasonable so we don't have to keep guessing by
   fpr structure for future versions)

b) get rid of keyids entirely -- when referring to a key, use the
   fingerprint where a compact hint is needed (e.g. in a replacement of
   the issuer subpacket) or the full primary key where it is more
   sensitive (e.g. in designated revoker).  With EC keys, we could
   consider using the full key (not the full cert) even in the issuer
   subpacket case, which could make things cleaner.

c) deprecate MD5, SHA1, and RIPEMD160

d) clarify that cleartext signatures should all use charset/encoding
   UTF-8.

e) update S2K with something more modern (PBKDF2, HKDF, scrypt?),
   deprecate all the other mechnanisms explicitly

f) standardize the two new curves coming out of the CFRG: 25519 and
   curve448 ("goldilocks") for both signatures and encryption (Werner
   has already started this process for 25519 signatures)

g) remove compression entirely

h) clean up the language: clearly distinguish between "public key" and
   "certificate", and ensure that the use of the terms "trust" and
   "validity", if still present, are used unambiguously.

i) declare a literal data packet type "m" that means "MIME content" so
   that we can punt on the rest of the message
   structure/format/encoding/type craziness to MIME.

j) deprecate 3DES, IDEA, and as many of the weaker ciphers as we can
   get away with.

k) provide a modern streamable/chunkable AEAD replacement for
   Symmetrically-Encrypted Integrity-Protected Data (SEIPD) packets

l) change MTI algorithms: SHA512, the two new ECs, and the new AEAD
   mechanism should be the baseline.

Could be other incremental changes too, but that's the top of my stack
at the moment.

I know i was the one who brought the MIME message-structuring question
("memoryhole") to this list recently, but i'm now having second thoughts
about whether this is the right place for it -- the above work seems
concrete and reasonably well-scoped, and a lot of the feedback in Dallas
seemed to be that e-mail header protection could be nice to handle more
generally, possibly in collaboration with S/MIME people.  I'm not sure
where the right place to put that would be, but the work seems
orthogonal to the discussions above.

   --dkg

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp