My comments inline:

> 
> 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)

There's a separate thread on the structure -- I replied to it myself.

There was also a mention somewhere of removing the timestamp from the fingerprint, and that's what I really want to comment on.

When 2440 started, removing the timestamp was one of the things I wanted to do. However, it's not such a bad thing. If you make a fingerprint merely be a function of the key (it has no variable data), then you lose the ability to alias the key, which is actually useful.

Presently, Alice can use the same key material for "alice@example.com" and "info@example.com" and it's not obvious that it's the same key from the fingerprint. If the fingerprint algorithm forces them to be the same fingerprint, there's an unnecessary information leak. An attacker learns they can attack Alice by attacking Info.

The fingerprint is an analogue of the serial number in X.509. It's desirable to be able to reuse keys in whatever PKI you use. It gives some people heartburn, but it's done all the time for practical reasons.

If we get rid of the timestamp, there ought to be something like salt put in in its place. "Randomized Hashing" is not a bad thing.

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

There's no *need* to do that.

An implementation must (not MUST, but an actual must) consider that there will be a collision and handle it appropriately. Remarkably few of them do, but this is a bug.

> 
> c) deprecate MD5, SHA1, and RIPEMD160

No argument there. I will observe along with Shamir's observation that there are no first or second-preimage collisions in SHA1. Some SHA1 uses (like fingerprint calculation) are still secure.

MD5 was deprecated in 2440; it is *only* there for backwards-compatibility with RFC 1991, and that grudgingly. 4880 actively spits on MD5.

Deprecating SHA1 is something that can be an actual deprecation -- saying "please don't do that" rather than banning it.

Nonetheless, as I said in the fingerprint discussion, there are places where you can design the expression of it that mean it never has to be redesigned again. Why should we go through this all over again for SHA-4, instead of just letting people put in a new algorithm ID?

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

That's basically there now. There's some weasel-wording because of people who still wanted to use Shift JIS and other character sets, but that's there now. Section 3.4.

(By the way, in PGP, we started off with a dictatorial view that everything was UTF-8, and ended up having to deal with the edge condition of Shift JIS etc.) 

The WG can sweep this under the rug, but implementers will still have a problem. I suggest in the name of practicality, keep it mostly the way it is. You really need to have a shallow bow to Japan and the rest of us will all use Unicode, just like another shallow bow is needed in the form of Camellia.

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

Agree completely on just using PBKDF2.

You could put other more modern password grinders in, or even leave it open for new technologies to be introduced easily.

> 
> 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)

I have no problem putting in parameters for those, but similarly to the hash issue, the EC Curve issue is not settled. There's a NIST conference in June, and personally I expect my favorite curve, 41417, to get widely used because it's both really fast and secure as well as not overly large (I think 521 is overly large).

> 
> g) remove compression entirely

That would be a huge relief. Or at the very least just say SHOULD NOT on it. 

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

This would be good, but it touches upon a political third rail here. That problem really needs to be cleaned up.

When 2440 started, there was an agreement with the Security Area that OpenPGP would not be a "PKI" (whatever the heck that means), because there was already a PKI, namely PKIX.

That means that OpenPGP has these language issues. It has to be a public key infrastructure without being a PKI. That's the reason why there's no trust model, while having the atomic components needed to have infrastructure, should one want to do that.

There are a number of things that really need to have documents, either on their own or sections in some document. They include:

* Trust model(s)
* Key/certificate servers
* Key/certificate transport (yes, they're different)

But that deserves its own topic.

The bottom line is that you can't talk about trust/validity issue without admitting that it's a public key instrstructure. I believe that you can personally solve this problem merely by saying, "yeah, whatever" but that's the underlying unspoken issue that the previous working group was *forbidden* from solving that problem.

On the key/certificate language issue, the term "Key" as we use it comes from Whit Diffie. It's a brilliant bit of wordsmithing because everyone knows what a key is, but no one knows what a certificate is, let alone the difference between a certificate and a certification. The problem with an "OpenPGP Key" is that it contains at least one key, and almost always at least two keys. So one is stuck having to know the difference between a Key and a key -- or an OpenPGP Key and a public key. Capitalization is not the answer. 

There were a few places where it really, really made sense to use the word "certificate." That word occurs only in eight places in 4880. The important one is section 5.5.1.1 that says (in toto):

   A Public-Key packet starts a series of packets that forms an OpenPGP
   key (sometimes called an OpenPGP certificate).

That sentence contains in it much of the No PKI issue. We couldn't go the other way around -- we couldn't say that an OpenPGP certificate was sometimes called an OpenPGP key because if we had certificates, that meant we were a PKI. Also, the OpenPGP community really likes the term "Key" because it's a great word, and no one actually wanted to retire "key" for certificate anyway.

Nonetheless, we couldn't say up front early in the document that there's going to be a couple of places where your head will hurt less if we just say "certificate" so we're going to do that. We had to bury it in 5.5.1.1. if you take that line as a definition -- "OpenPGP key" and "certificate" are synonyms, then there's no problem.

If the new WG wants to get rid of "certificate" there's only eight places. 


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

Better yet -- just say it's binary only. Get rid of all that FTP and other pre-ASCII baggage for good.

Making an "m" data type is really only a bandaid, and long-term makes the underlying problem (that we're making semantic choices in the wrong layer) worse.

I think it's far more important to toss out all that crap with canonicalization and what it means and all than to make it worse with a new data type. Bits. It's all just bits, collected into bytes. Excuse me, octets.

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

No problem.

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

Well, obviously some of has to be done, since the MTI is 3DES, SHA1.

However, making ECC be MTI is something that ought to have discussion. (I'm in favor of it, but I know otherwise-sane people who have reasonable objections.)

	Jon