gpgpgsm merging public kbx / exporting all keys

Bernhard Reiter bernhard at intevation.de
Mon May 14 15:07:54 CEST 2007


On Friday 11 May 2007 10:29, Werner Koch wrote:
> On Thu, 10 May 2007 13:02, bernhard at intevation.de said:
> > gpgsm --export >exported-x509-keys
> > does not work.
> > gpgsm: exporting more than one certificate is not possible in binary mode
>
> That is because most X.509 tools will take only the first ANS.1 object
> and ignore any concatenated objects.  This is actually correct for an
> ASN.1 based system.  There is no widely used standard for putting
> severeal keys int one object, thus we better allow only for one key.
>
> >     gpgsm --armor --export >exported-x509-keys
> > and gpgsm --import exported-x509-keys works.
>
> ...no standard except for PEM encoded certificates - thus this works.
>
> > While doing so I looked up the documentation "export [PATTERN]"
> > and searching for PATTERN did not result into the section that
> > explains how to select a user id. I suggest to add a sentence
> > which contains "PATTERN" to this section.
>
> Reads now:
>
> `--export [PATTERN]'
>      Export all certificates stored in the Keybox or those specified by
>      the optional PATTERN. Those pattern consist of a list of user ids
>      (*note how-to-specify-a-user-id::).  When used along with the
>      `--armor' option a few informational lines are prepended before
>      each block.  There is one limitation: As there is no commonly
>      agreed upon way to pack more than one certificate into an ASN.1
>      structure, the binary export (i.e. without using `armor') works
>      only for the export of one certificate.  Thus it is required to
>      specify a PATTERN which yields exactly one certificate.

Wonderful, thanks for the change!
I also suggest to change the how-to-specify-a-user-id:: section to include
the string "PATTERN" so that string searching would also produce that section.

>> > Also with gpg you can just
> > gpg --import pubring.gpg which makes merging a lot easier.
>
> Most people here can guess my reply: No, no, no. This is an undocumented
> feature which works only due to the coincidence that the external and
> internal format is very similar.  The inetrnal format may be changed at
> any time.  The only way to access the keyrings is by using --import and
> export.

Okay, I did not know. :)
Well as long as it works, it is quite handy, I suggest to add
something in the documentation to not rely on this for anything automated
because there will be no consideration of backwards compatibility.

> > For the gpg trust-list there are command line options for exporting
> > and importing. So I would suggest to add least add the example
> > of the recommended way to the manual and textinfo documentation.
>
> You mean: Howto migrate a key from one system to the other?  Well, I can
> add a short howto.  The new GnuPG manual has anyway a section with
> hotwos.

There is 
a) How to migrate a secret key
b) How to merge public keys with trustlist, e.g. for backups or
   several machines.

Best Regards,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1310 bytes
Desc: not available
Url : /pipermail/attachments/20070514/c2269e71/attachment.bin 


More information about the Gnupg-users mailing list