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

[ianG <[e-mail]>]

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"
>      crypto?
>    - 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
>    RECOMMEND.


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


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

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!

iang