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

Petr Spacek <> Mon, 12 January 2015 15:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6772B1ABD3B for <>; Mon, 12 Jan 2015 07:38:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LaCnyP2FjLsx for <>; Mon, 12 Jan 2015 07:38:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B02C71AC3E2 for <>; Mon, 12 Jan 2015 07:38:02 -0800 (PST)
Received: from ( []) by (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 ([]) by (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: <>
Date: Mon, 12 Jan 2015 16:37:58 +0100
From: Petr Spacek <>
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 <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on
Archived-At: <>
Subject: Re: [dane] I-D Action: draft-ietf-dane-openpgpkey-01.txt: keyring format definition
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:
>> 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:
>> 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
- User ID Packet

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:

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