Re: [openpgp] OpenPGPv5 wish list

ianG <iang@iang.org> Mon, 29 April 2013 09:40 UTC

Return-Path: <iang@iang.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437B421F9D23 for <openpgp@ietfa.amsl.com>; Mon, 29 Apr 2013 02:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRDiSZiPAMbW for <openpgp@ietfa.amsl.com>; Mon, 29 Apr 2013 02:40:21 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 9733421F9CED for <openpgp@ietf.org>; Mon, 29 Apr 2013 02:40:21 -0700 (PDT)
Received: from tormenta.local (www2.futureware.at [78.41.115.142]) by virulha.pair.com (Postfix) with ESMTPSA id 200B26D4A0; Mon, 29 Apr 2013 05:40:14 -0400 (EDT)
Message-ID: <517E3FFE.1070005@iang.org>
Date: Mon, 29 Apr 2013 12:40:14 +0300
From: ianG <iang@iang.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: openpgp@ietf.org
References: <20121212104620.GA35659@redoubt.spodhuis.org> <50D0AB16.5020505@brainhub.org> <CAN+za=O4NcLtN=Etm-7UC4SY=ndan_0n167rkDfKqcpEp0W25g@mail.gmail.com> <2584059.Q9cNNqxsta@inno> <517E0250.1040708@sixdemonbag.org> <20130429111532.7e53c7f6@gmail.com>
In-Reply-To: <20130429111532.7e53c7f6@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [openpgp] OpenPGPv5 wish list
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 29 Apr 2013 09:40:22 -0000

On 29/04/13 12:15 PM, Jean-Jacques wrote:

> 2) What is the key used for?
>
> And I see at least 4 purposes :
>   - To authenticate itself through TLS  [RFC6091]
>   - Maybe To sign other certificates (subkeys on smartcard issues)
>   - To authenticate through HTTP (gpgauth or
>     https://github.com/Open-UDC/open-udc/blob/master/docs/HTTP_OpenPGP_Authentication.draft.txt)
>   - To sign an OpenUDC transaction.
>
> I work especially on the 2 last purposes. And having the possibility
> for the owner to set descriptions, or more flags on its (sub)keys inside
> its OpenPGP certificate, would be a more elegant solution than some
> workaround we have to manage.


Some comments from my experience/perspective, only.  In my work I have 
done this by using pgp's comment field aka uid.  Here's some:

$ gpg -k | grep uid

uid                  Iang [certification] (Africa-2012) <iang@iang.org>
uid                  Iang [contract] (lowsec-PIZZA-only) <iang@iang.org>
uid                  Systemics [operator] (Africa-2012) <iang@iang.org>
uid                  Systemics [server] (Babba-2012) <iang@iang.org>
uid                  Systemics [receipt] (Babba-2012) <iang@iang.org>
uid                  Systemics [receipt] (offa-20130101) <iang@iang.org>
uid                  Systemics [server] (offa-20130102) <iang@iang.org>


In my software I use the [tag] for the purpose, the (text) as a human 
comment, and everything else as the name of the keyholder.  You could do 
whatever tho.

Perhaps more on point, I do not want the OpenPGP system to provide me 
with bits that allow me to set purpose or anything else, because OpenPGP 
is too low-level.  My designed claims like "this is an operator key" are 
too involved in the business layer to be foisted onto anyone else.  The 
history of key-bits being used for human claims suggests this is a fast 
way to failure.  E.g., non-revocation and the infamous 
you-must-understand-me bit.

I don't know if this logic applies to anyone else.  But if it did, 
hypothetically, I might record your claims in my key uids as such:



uid                  Iang [HTTP-auth] (social-networks) <iang@iang.org>
uid                  Systemics [UDC-agent] (Black-2012) <iang@iang.org>





iang