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

On Thu, 2015-03-12 at 13:31 +0100, Werner Koch wrote:
> Is there any interest in this?
There definitely is ... contrary to what some loud campaigners (recently
heise in Germany, or the advocates rubbish X.509 of crappy key pinning
technologies) try to make people believe, OpenPGP is still alive and
actually the only really securely usable PKI standard (anything strict
hierarchical like X.509 is IMHO inherently insecure, at least in
practical usage) for the masses. 
> There are several tasks the WG should do:
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.

In the later case:
- The basic meshed web of trust must obviously be retained, 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.


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
- ideally not using fingerprints in the signature subpacktes if that can
  be avoided (thinking of the Revocation Key subpacket

- the whole standard should be much more definite and strict, currently
  we have many places which are quite vague or which allow to do the
  same thing in different ways, examples:
  - the critical flag should become a non-critical flag (i.e. per
    default everything is considered critical unless something else is
    explicitly said.
  - other properties are simply not well enough defined or could at
    least be made better, e.g. what if a policy URI is used on a
    selfsig/direct key sig... is that then still the "the policy
    under which the signature was issued", which would be kinda
    useless... or should it be better they policy under which this
    key/user makes signatures?
  - there need to be a definite algorithm which decides which
    selfsig/direct key sig/user sig is to be used, if there are still
    multiple valid (IIRC, that wasn't defined, but it's some time ago
    since I last read through the RFC)
  - We have the direct key sig, which would make sense to be used for
    some things, but actually no one seems to really use it. So either
    drop it, or if it is kept, then it should be more clearly specified
    how the semantics change when some subpackets are used on a selfsig
    vs. a direct key sig?
    E.g. what happens if one has a key which a direct key sig (0x1F)
    that says "certification only key" while a 0x13 selfsig says
    "certification + encryption"). Similar for the other properties like
    Policy URL, where this could actually make sense, e.g. a PolicyURL
    on a 0x1F self-sig tells the "global Policy for all UIDs", while one
    on a 0x13 tells further policy rules when the signature is made with
    this specific UID[0].
  - It should be possible to select more key properties to be fixed
    (i.e. unchangable), like key expiration time, key usage.


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.

  I'd change this the following way:
  The UID is really just an ID for they key, which should be unique
  within the realm of they keys usage.
  That means, for globally public keys, we should make this a MUST to
  either a mail address (and I'd even say just the addr-spec) or a
  domain name.
  But for any non globally public usage, this could be something like as
  students ID number.
  It follows from that, that the UID would no longer be something what
  other really certify (in the sense that they've checked whether this
  is really my mail address or my students ID number). Of course they'd
  still sign it, but it wouldn't give the key any real trust.
  As said it would be more a technical ID, which can be used by
  applications in a given realm to easily distinguish/select keys.

- 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... but there things should be greatly extended.
  It shouldn't just be the name, picture or email address. Think of
  things like natural colour of hair/eyes, skin colour, body size,
  birthdate/place. All different forms of names, from the western first
  name(s), second names, middle names, family names, perhaps academic
  grades over e.g. Arabic style names maybe even to Tolkien's elven
  names where they have Epessë, Essi and Amilessë ;) .
  Ideally we'd have a separate and easily extensible registry for these
  fields, so that one can also easily add things like I don't know:
  "org.debian.developer=DDname" or "com.github.user=foo".
  People should be able to sign the personal information which they
  actually have from their peers (and github, for example, will probably
  never know my name for sure, but they know me by my account name).
  One could even think of different image types, starten from a face
  shot of the person (as we have now), over fringerprint or signature
  scans, perhaps even to heraldic devices of that person, or what they
  have in non-western cultures like the Japanese "inkan" respectively
  "hanko".
  Perhaps an example:
  family-name="Mitterer"
  first-name="Christoph"
  secondary-name="Anton"
  secondary-name="Foo"
  nicknames="Chris"
  nicknames="whatever"
  As you can see, for some fields it should be possible to give them
  multiple times.
  Since the rendering/usage of these separate naming fields is not
  universally defined, I'd probably suggest to add a mutliple usable
  field like:
  common-name="Christoph Anton Mitterer"
  common-name="Christoph Mitterer"
  The key owner could create whichever he things to be appropriate (e.g.
  someone might also add "Christoph A. Mitterer").
  And people signing that key could in principle also choose which of
  the keys they want to sign.
  Perhaps one would also need qualifiers for some fields like people
  from Russia have also given and family names, but obviously in
  Cyrillic, but there might be an official transliteration to the Latin
  Alphabet, so the key could contain both.

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


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.

- As said before, one might one to do such act (e.g. the signing or
certifying) with one specific role, e.g. I may want to sign someone
else's key as mail(_at_)christoph(_dot_)anton(_dot_)mitterer(_dot_)name, but 
not as
christoph(_dot_)anton(_dot_)mitterer(_at_)physik(_dot_)uni-muenchen(_dot_)de.

- Another typical use case: I have a primary key, which people sign and
trust, plus several subkeys for encryption/signing.
Now I may want to use some of the subkeys for certain "locations" only,
e.g. my smartphone (which is pretty insecure),... or at work (which is
perhaps more secure as my Google-friends-of-NSA™ Android, but still less
secure as my home systems). So I give only the respective private
subkeys to these locations nothing else.
But since right now people only look at the UID, they typically won't
notice whether my I've signed a message from my Android device (and
therefore the information can only be trusted to some extent).

I'm not really sure whether it should be a UID which can be connected to
subkeys,... probably not.
It should rather be something that is structurally similar to UIDs (i.e.
extensible) and which contains other properties like "usage" or a trust
indicator.


Cheers,
Chris.


[0] Obviously this only makes sense, if a future OpenPGP version would
allow to sign other keys specifically connected with one or more of the
UIDs - e.g. I want to verify someone else in my role as worker of
uni-muenchen.de, but not in my role as private person.

smime.p7s
Description: S/MIME cryptographic signature

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