[Top] [All Lists]

Re: [openpgp] How to re-launch the OpenPGP WG

2015-03-23 20:31:36
On 13/03/2015 03:52 am, Christoph Anton Mitterer wrote:

Since people start to come up with their wishlists... here'd be mine:

1) More general things
- The WG should consider whether to just bring OpenPGP up to date... or
   whether to completely overhaul or even re-design it.

Re-design. It's still the late 1980s model, it's way behind current knowledge. No point in overhaul.

In the later case:
- The basic meshed web of trust must obviously be retained,

:) I would agree that it should remain firmly oriented towards the p2p channel.

but apart
   from that there should IMHO be no taboos, like dropping the old
   formats or perhaps even completely changing the format (if some people
   would think an XML representation would be better, discussions should
   be open for that - not that I'd be an advocate of this).

- OpenPGP should be made fit or at least extensible enough for any mid-
   or long-term developments in engineering and crypto, this might
   include things like:
   - Since the X.509 PKI infrastructure in the internet is inherently
     broken and since DANE would only partially improve things (one still
     has several CA's above which could be evil), the time may come in
     which at least some security conscious people would want to use TLS
     or similar with a fully meshable PKI as OpenPGP.
     For that we might need similar things as X.509 got eventually,...
     things like SubjectAlternativeNames for IP, DNS, email, etc.
   - Any preparations for PQ Crypto? Or for hybrids of PQ and "normal"
   - For the ultra-paranoid: Semantics that allow usage of multiple
     ciphers and hash algos (i.e. encrypt a message with AES first, then
     Serpent, then Cesar chiffre ;) ... or make signatures with SHA2 and
     SHA3 and require all to be valid.

The ultra paranoid can go off and do their own thing anyway. Let them compose their fantasies in their own code, no need to clutter up our own code with "made up algorithms".

2) More specific things:
- get rid of any SHA1
- fingerprints should allow to use different hash algos, in order to
   keep it easily up to crypto developments

Nah - just use Keccak and tie it to the current new version 5. Frankly we've had 2 decades of peace with the SHA 1 -> 2 -> 3 family. Worring about the hashes failing is sooooo overdone.

3) UIDs respectively the data that others actually verify/sign should be
    completely overhauled.
   Right now we have User ID Packet (13) and User Attribute Packet (17),
   with the later having only one actual attribute (the image) defined.

   The UID is by convention a mail address, but even the standard already
   says that this is just "by convention", it doesn't even use SHOULD or

That's how I like it. And in CAcert we came to the same conclusion - the NAME that is authenticated by the user is a single string, it is up to the humans to add any semantics on what that name is / means.

- Everything that really identifies the person behind the key (i.e. puts
   trust into the key) should be go into something like the attribute

In CAcert we concluded that there should just be multiple UIDs. No particular semantics like Attribute implied.

- It should be possible to connect these fields with a "valid from" date
   and it should be possible to revoke them later in a way that just
   means like "data superseded".
   E.g. people might merry and their family name changes, they may
   divorce and it changes again. Or one grows older and the image

Hmmm... this might be overthinking things.

4) one of the IMHO most important things:
It should be possible to connect a UID or something similar with
specific subkeys.

Right now, we have a key with multiple UIDs bound to the key via
selfsigs. If I sign someone else's key or sign some text, regardless of
which subkey I use,... I do this with all my identities, right?
That's quite limiting.

Now you're talking about a heirarchy. Typically what people do is create a key "Iang Signing Key" and another "Iang Contract key" signed by the first, and then use the latter only for contract signing.

What's useful is to deliver tools that can be composed by the user, less so to get all the composition possibilities into one single structure.

just some comments!


openpgp mailing list