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