Commands are not distinguished from options execpt for the fact that only one command is allowed.
This is command is required for certain maintaining tasks of the dirmngr where a dirmngr must be able to call back to gpgsm. See the Dirmngr manual for details.
GPGSM comes features a bunch ofoptions to control the exact behaviour and to change the default configuration.
These options are used to change the configuraton and are usually found in the option file.
When used along with --import, a validation of the certificate to import is done and only imported if it succeeds the test. Note that this does not affect an already available cwertificate in the DB. This option is therefore useful to simply verify a certificate.
How these messages are mapped to the actual debugging flags is not specified and may change with newer releaes of this program. They are however carefully selected to best aid in debugging.
Note, that all flags set using this option may get overriden by --debug-level.
All the long options may also be given in the configuration file after stripping off the two leading dashes.
There are different ways to specify a user ID to GnuPG. Some of them are only valid for gpg others are only good for gpgsm. Here is the entire list of ways to specify a key:
When using gpg an exclamation mark may be appended to force using the specified primary or secondary key and not to try and calculate which primary or secondary key to use.
The last four lines of the example give the key ID in their long form as internally used by the OpenPGP protocol. You can see the long key ID using the option --with-colons.
234567C4 0F34E556E 01347A56A 0xAB123456 234AABBCC34567C4 0F323456784E56EAB 01AB3FED1347A5612 0x234AABBCC34567C4
When using gpg an exclamation mark may be appended to force using the specified primary or secondary key and not to try and calculate which primary or secondary key to use.
The best way to specify a key Id is by using the fingerprint. This avoids any ambiguities in case that there are duplicated key IDs.
1234343434343434C434343434343434 123434343434343C3434343434343734349A3434 0E12343434343434343434EAB3484343434343434 0xE12343434343434343434EAB3484343434343434
(gpgsm also accepts colons between each pair of hexadecimal digits because this is the de-facto standard on how to present X.509 fingerprints.)
=Heinrich Heine <
<
+Heinrich Heine duesseldorf
/CN=Heinrich Heine,O=Poets,L=Paris,C=FR
#/CN=Root Cert,O=Poets,L=Paris,C=FR
#4F03/CN=Root Cert,O=Poets,L=Paris,C=FR
&D75F22C3F86E355877348498CDC92BD21010A480
Heine *Heine
Please note that we have reused the hash mark identifier which was used in old GnuPG versions to indicate the so called local-id. It is not anymore used and there should be no conflict when used with X.509 stuff.
Using the RFC-2253 format of DNs has the drawback that it is not possible to map them back to the original encoding, however we don't have to do this because our key database stores this encoding as meta data.
$ gpgsm -ergpgsm is often used as a backend engine by other software. To help with this a machine interface has been defined to have an unambiguous way to do this. This is most likely used with the --server command but may also be used in the standard operation mode by using the --status-fd option.
It is very important to understand the semantics used with signature verification. Checking a signature is not as simple as it may sound and so the ooperation si a bit complicated. In mosted cases it is required to look at several status lines. Here is a table of all cases a signed message may have:
There are a few configuration files to control certain aspects of gpgsm's operation. Unless noted, they are expected in the current home directory (see: [option --homedir]).
For example, to allow only the policy 2.289.9.9, the file should look like this:
# Allowed policies 2.289.9.9
Note that even if a certificate is listed in this file, this does not mean that thecertificate is trusted; in general the certificates listed in this file need to be listed also in `trustlist.txt'.
This is a global file an installed in the data directory (e.g. `/usr/share/gnupg/qualified.txt'). GnuPG installs a suitable file with root certificates as used in Germany. As new Root-CA certificates may be issued over time, these entries may need to be updated; new distributions of this software should come with an updated list but it is still the responsibility of the Administrator to check that this list is correct.
Everytime gpgsm uses a certificate for signing or verification this file will be consulted to check whether the certificate under question has ultimately been issued by one of these CAs. If this is the case the user will be informed that the verified signature represents a legally binding (``qualified'') signature. When creating a signature using such a certificate an extra prompt will be issued to let the user confirm that such a legally binding signature shall really be created.
Because this software has not yet been approved for use with such certificates, appropriate notices will be shown to indicate this fact.
Note that on larger installations, it is useful to put predefined files into the directory `/etc/skel/.gnupg/' so that newly created users start up with a working configuration. For existing users the a small helper script is provided to create these files (see: [addgnupghome]).
For internal purposes gpgsm creates and maintaines a few other files; They all live in in the current home directory (see: [option --homedir]). Only gpgsm may modify these files.
The full documentation for this tool is maintained as a Texinfo manual. If GnuPG and the info program are properly installed at your site, the command
info gnupg
should give you access to the complete manual including a menu structure and an index.