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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp