On Friday 11 May 2007 10:29, Werner Koch wrote: > On Thu, 10 May 2007 13:02, [EMAIL PROTECTED] 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
