Keyrings file format

[David Paleino]

Thank you for your reply.
No need to CC me, though :)

On Tue, 6 Jan 2009 08:27:23 -0500, David Shaw wrote:

> On Jan 6, 2009, at 4:58 AM, David Paleino wrote:
>   
> > Is the format documented anywhere?  
> 
> A GnuPG keyring is defined in RFC-4880 (http://tools.ietf.org/html/rfc4880 
> ).  

ACK.
I was already trying to understand the format of the files resulting from
"gpgsplit", but the RFC is a bit obscure in some points, at least to me ;)

> Basically the pubring is a series of "Transferable Public  
> Keys" (section 11.1) concatenated together.  The secring is a series  
> of "Transferable Secret Keys" (section 12.1) concatenated together.  

This is a really useful bit of information, thank you.

> Note, though, section 3.6 of the RFC:
> 
> 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.  

Agreed.

> It is perfectly legal for a program to use some internal method for  
> storing keys that isn't the traditional "file with a lot of key  
> packets" method.  The only thing that is required is that the  
> transferable (i.e. exported) format conforms to the spec.  If you  
> really want to really future-proof yourself against potential storage  
> format changes, avoid reading pubring.gpg or secring.gpg yourself, and  
> instead have your library parse the output of "gpg --export" or "gpg -- 
> export-secret-keys".  Today, these are identical, but in the future,  
> they might not be.  

Thank you for clarifying this.

> All that said, what are you trying to do, exactly?  What information  
> do you need to get from the keys that isn't available now?  

Nothing, probably I wasn't that much clear in my original post. Let me do an
example, with some pseudo-code.

A CLI (i.e. C#, VB.Net, IronPython, Nemerle, Boo, and other languages)
developer wanting to provide signing/crypting/decrypting/... functionalities,
would *currently* do (again, pseudo-code):

---
raw_output = system("gpg --my arguments");
uid = do_some_magic(raw_output);
---

What I want other developers to do is:

---
using OpenPGP-Sharp; // that's the name of my library
id = GetPrimaryID("0xAABBCCDD");
---

That is, I'm creating [0] a library with an easy-to-use API for other
developers to use.

[0] it basically works, because I'm providing an API, and do some "magic"
mangling of the output of "gpg --with-colons --[..]" -- for "reading
procedures". I haven't yet implemented any of the crypting/decrypting/signing
things.

So long, where's the problem in parsing --with-colons? -- you might ask. As
there is no certainty on the format of the keyring itself, surely there isn't
on the format of the output of --with-colons either.

Also, I could've written a binding to libgpgme -- but that too reads gpg's
output, so I preferred doing that myself to avoid one more layer of complexity /
bugs / whatever.

So, being both --with-colons and the keyring format uncertain, why adding one
more layer (i.e. forking the gpg process from my current code, read its output,
act consequently) to the code, if I can directly read the keyrings?

The conclusion is: if it's too difficult, or does not give concrete advantages
over the method I'm using now, then all the argumentation above is moot. But,
if it gives concrete advantages (in terms of speed, for example), it might be
worth a try, at least. Or, an option could be giving developers the chance to
use whichever implementation they prefer/trust.

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: </pipermail/attachments/20090106/1c9f13d0/attachment.pgp>