Re: [openpgp] How to re-launch the OpenPGP WG
Christoph Anton Mitterer <calestyo@scientia.net> Fri, 13 March 2015 03:52 UTC
Return-Path: <calestyo@scientia.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9561A8A25 for <openpgp@ietfa.amsl.com>; Thu, 12 Mar 2015 20:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.691
X-Spam-Level:
X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RI589_bTE_B for <openpgp@ietfa.amsl.com>; Thu, 12 Mar 2015 20:52:52 -0700 (PDT)
Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7561A89FC for <openpgp@ietf.org>; Thu, 12 Mar 2015 20:52:52 -0700 (PDT)
Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.26]) by mailgw02.dd24.net (Postfix) with ESMTP id 0DB155FBBD for <openpgp@ietf.org>; Fri, 13 Mar 2015 03:52:51 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at mailpolicy-01.live.igb.homer.key-systems.net
Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id cvpBciXtyWQh for <openpgp@ietf.org>; Fri, 13 Mar 2015 03:52:48 +0000 (UTC)
Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA for <openpgp@ietf.org>; Fri, 13 Mar 2015 03:52:48 +0000 (UTC)
Message-ID: <1426218768.22326.80.camel@scientia.net>
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: openpgp@ietf.org
Date: Fri, 13 Mar 2015 04:52:48 +0100
In-Reply-To: <878uf2iehi.fsf@vigenere.g10code.de>
References: <878uf2iehi.fsf@vigenere.g10code.de>
Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-yhubnpTOUIi1tgIOd2g6"
X-Mailer: Evolution 3.12.9-1+b1
Mime-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/TFM6qRigt3MvLOdeghnMCFJwLTQ>
Subject: Re: [openpgp] How to re-launch the OpenPGP WG
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2015 03:52:56 -0000
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@christoph.anton.mitterer.name, but not as christoph.anton.mitterer@physik.uni-muenchen.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.
- Re: [openpgp] How to re-launch the OpenPGP WG Werner Koch
- Re: [openpgp] How to re-launch the OpenPGP WG DataPacRat
- Re: [openpgp] How to re-launch the OpenPGP WG James P. Howard
- Re: [openpgp] How to re-launch the OpenPGP WG Derek Atkins
- Re: [openpgp] How to re-launch the OpenPGP WG David Leon Gil
- Re: [openpgp] How to re-launch the OpenPGP WG David Leon Gil
- Re: [openpgp] How to re-launch the OpenPGP WG Christoph Anton Mitterer
- Re: [openpgp] How to re-launch the OpenPGP WG Christoph Anton Mitterer
- Re: [openpgp] How to re-launch the OpenPGP WG Kristian Fiskerstrand
- Re: [openpgp] How to re-launch the OpenPGP WG Christoph Anton Mitterer
- Re: [openpgp] How to re-launch the OpenPGP WG Benjamin Kaduk
- Re: [openpgp] How to re-launch the OpenPGP WG Christoph Anton Mitterer
- Re: [openpgp] How to re-launch the OpenPGP WG Benjamin Kaduk
- Re: [openpgp] How to re-launch the OpenPGP WG Phillip Hallam-Baker
- Re: [openpgp] How to re-launch the OpenPGP WG Wyllys Ingersoll
- Re: [openpgp] How to re-launch the OpenPGP WG Phillip Hallam-Baker
- Re: [openpgp] How to re-launch the OpenPGP WG ianG
- Re: [openpgp] How to re-launch the OpenPGP WG ianG
- Re: [openpgp] How to re-launch the OpenPGP WG Christoph Anton Mitterer
- Re: [openpgp] How to re-launch the OpenPGP WG Werner Koch
- Re: [openpgp] How to re-launch the OpenPGP WG ianG
- Re: [openpgp] How to re-launch the OpenPGP WG Christoph Anton Mitterer
- Re: [openpgp] How to re-launch the OpenPGP WG Derek Atkins
- [openpgp] How to re-launch the OpenPGP WG Werner Koch
- Re: [openpgp] How to re-launch the OpenPGP WG Daniel A. Nagy
- Re: [openpgp] How to re-launch the OpenPGP WG Kristian Fiskerstrand
- Re: [openpgp] How to re-launch the OpenPGP WG Derek Atkins
- Re: [openpgp] How to re-launch the OpenPGP WG Stephen Paul Weber
- Re: [openpgp] How to re-launch the OpenPGP WG Paul Wouters
- Re: [openpgp] How to re-launch the OpenPGP WG Johan van Selst
- Re: [openpgp] How to re-launch the OpenPGP WG Tom Ritter
- Re: [openpgp] How to re-launch the OpenPGP WG Werner Koch
- Re: [openpgp] How to re-launch the OpenPGP WG Jon Callas
- Re: [openpgp] How to re-launch the OpenPGP WG NIIBE Yutaka
- Re: [openpgp] How to re-launch the OpenPGP WG Daniel Kahn Gillmor
- Re: [openpgp] How to re-launch the OpenPGP WG Derek Atkins
- Re: [openpgp] How to re-launch the OpenPGP WG Paul Wouters
- Re: [openpgp] How to re-launch the OpenPGP WG Christoph Anton Mitterer
- Re: [openpgp] How to re-launch the OpenPGP WG Werner Koch
- Re: [openpgp] How to re-launch the OpenPGP WG Werner Koch
- Re: [openpgp] How to re-launch the OpenPGP WG Franklin Wang
- Re: [openpgp] How to re-launch the OpenPGP WG Derek Atkins
- Re: [openpgp] How to re-launch the OpenPGP WG Derek Atkins
- Re: [openpgp] How to re-launch the OpenPGP WG Werner Koch
- Re: [openpgp] How to re-launch the OpenPGP WG Paul Wouters
- Re: [openpgp] How to re-launch the OpenPGP WG DataPacRat
- Re: [openpgp] How to re-launch the OpenPGP WG Tom Ritter