ietf-openpgp
[Top] [All Lists]

Re: [openpgp] details of 4880bis work

2015-04-15 16:01:28
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(_at_)example(_dot_)com" and "info(_at_)example(_dot_)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


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

<Prev in Thread] Current Thread [Next in Thread>