Re: [dane] I-D Action: draft-ietf-dane-openpgpkey-01.txt: keyring format definition

Petr Spacek <pspacek@redhat.com> Mon, 12 January 2015 15:38 UTC

Return-Path: <pspacek@redhat.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6772B1ABD3B for <dane@ietfa.amsl.com>; Mon, 12 Jan 2015 07:38:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 LaCnyP2FjLsx for <dane@ietfa.amsl.com>; Mon, 12 Jan 2015 07:38:17 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02C71AC3E2 for <dane@ietf.org>; Mon, 12 Jan 2015 07:38:02 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0CFc0Yq007705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 12 Jan 2015 10:38:01 -0500
Received: from pspacek.brq.redhat.com ([10.34.249.150]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0CFbwDP016056 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2015 10:38:00 -0500
Message-ID: <54B3EA56.3020006@redhat.com>
Date: Mon, 12 Jan 2015 16:37:58 +0100
From: Petr Spacek <pspacek@redhat.com>
Organization: Red Hat
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Paul Wouters <paul@nohats.ca>
References: <20141027233636.24734.41333.idtracker@ietfa.amsl.com> <54B3D197.7040808@redhat.com> <alpine.LFD.2.10.1501121005040.16886@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1501121005040.16886@bofh.nohats.ca>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/i_wW5NgNbkAUXKoLkeUY8tAXzvE>
Cc: dane@ietf.org
Subject: Re: [dane] I-D Action: draft-ietf-dane-openpgpkey-01.txt: keyring format definition
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jan 2015 15:38:19 -0000

On 12.1.2015 16:06, Paul Wouters wrote:
> On Mon, 12 Jan 2015, Petr Spacek wrote:
> 
>> I would like to see a clarification for section:
>>
>> http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-01#section-2.1
>> 2.1. The OPENPGPKEY RDATA component
>>   The RDATA (or RHS) of an OPENPGPKEY Resource Record contains a single
>>   value consisting of a [RFC4880] formatted OpenPGP public keyring.
>>
>>
>> I'm struggling with definition of "formatted OpenPGP public keyring". After a
>> quick glance I have found only this:
>>
>> http://tools.ietf.org/html/rfc4880#section-3.6
>> 3.6. Keyrings
>>   A keyring is a collection of one or more keys in a file or database.
>>   Traditionally, a keyring is simply a sequential list of keys, but may
>>   be any suitable database.  It is beyond the scope of this standard to
>>   discuss the details of keyrings or other databases.
>>
>> I did not read whole RFC 4880 so it is possible that I have missed some
>> related definitions but IMHO this reference deserves clarification.
>>
>> Where is the actual keyring format defined?
> 
> That's it. You're looking at it. There is not a better reference that
> I'm aware of. I have been looking for it myself as well.

Ooooh, that is bad. I would say too bad for any implementation which wants to
be interoperable.

So, what do we do next? I can see three ways:
1) Write a new RFC to standardize keyring format. Is it worth the effort? I'm
not sure.

2) We could move forward with some simplified single-purpose definition of
keyring based on
- Key Material Packet
http://tools.ietf.org/html/rfc4880#section-5.5
- User ID Packet
http://tools.ietf.org/html/rfc4880#section-5.11

3) Do something in between first two approaches:
It seems that it should be relatively simple to define totally simple
universal keyring simply as sequence of OpenPGP packets defined on:
http://tools.ietf.org/html/rfc4880#section-5.5

That definition would allow us to add revocation data in future or possibly
add other extensions. I assume that RFC written today would say: A application
MUST ignore all packet types except A,B,C,D.

Later, when a new packet format is standardized and new tag assigned to it, we
can add this new tag to list of non-ignored tags (and define meaning of it) in
separate RFC.

-- 
Petr^2 Spacek