summaryrefslogtreecommitdiff
path: root/kiki-Proposed-UI.txt
diff options
context:
space:
mode:
Diffstat (limited to 'kiki-Proposed-UI.txt')
-rw-r--r--kiki-Proposed-UI.txt743
1 files changed, 743 insertions, 0 deletions
diff --git a/kiki-Proposed-UI.txt b/kiki-Proposed-UI.txt
new file mode 100644
index 0000000..b54c1e3
--- /dev/null
+++ b/kiki-Proposed-UI.txt
@@ -0,0 +1,743 @@
1Below follows the "PROPOSED INTERFACE" written by catsup
2and the "CURRENTLY IMPLEMENTED" interface written by joe.
3
4Catsup's notion neglected the cross-merging capabilities of
5the currently implented --keypairs, --keyrings, and --wallets
6documented in the my "Merging" section. These are special
7because information flow is either or both ways (creation in the
8case of non existance). On IRC, we came up with a sensible way
9to incorporate this functionality, described as follows:
10
11 Instead of a primitive (--keypairs, --keyrings, or --wallets)
12 followed by a bunch of arguments, we would repeat a command.
13
14 For exmaple:
15
16 current ui:
17
18 kiki sync --keypairs "tor=/var/lib/samizdat/torkey{openssl --create-key}"
19 ssh-client=/home/joe/.ssh/id_rsa
20
21 kiki --create="openssl --create-key" \
22 --keypairs tor=/var/lib/samizdat/torkey \
23 --no-create ssh-client=/home/joe/.ssh/id_rsa
24
25 kiki --sync-key='tor:/var/lib/samizdat/torkey:openssl --create-key'
26
27 proposed ui:
28
29 kiki --sync-key --usage=tor --create="openssl --create-key" /var/lib/samizdat/torkey
30 --sync-key --usage=ssh-client /home/joe/.ssh/id_rsa
31
32 PROPOSAL2:
33
34 kiki sync-secret tor=/var/lib/samizdat/torkey{open-ssl --create-key} \
35 ssh-client=/home/joe/.ssh/id_rsa
36
37With catsup's interface, it is intuitive to imagine that commands happen in order.
38My current interface tries to take a bunch of information on the command line and then
39synthesize it all with cross-merging and attempting to order things sensibly.
40
41My new notion to reconcile the two ideas is to expose a UI where the user expects things
42to happen in order, but to slurp all contiguous --sync-* commands into single operations.
43
44
45
46PROPOSED INTERFACE:
47
48kiki - a bridge between keys
49
50 Kiki turns your OpenGPG key into a single sign-on (SSO) identity
51 for all cryptographically-authenticated services.
52
53 It also enables you to accept such identities for your own services.
54
55 Fuck Google, fuck Facebook, and fuck Verisign. [TODO: enlarge list]
56
57Synopsis:
58
59 kiki [command] [options] [[command] [options]]...
60
61 [TODO: show the most useful commands as examples.]
62
63Description:
64
65 Kiki creates a cryptographic chain of trust, _from_ a foundation of
66 the OpenPGP web of trust, _to_ all other key types.
67
68 The following key types are currently supported:
69
70 * ssh (host and client)
71 * ipsec
72 * DNSKEY (DNSSEC)
73 * x509 (TLS/SSL, client and server authentication; HTTP/SMTP)
74 * Tor hidden service (.onion)
75 * I2P hidden service (.b32.i2p)
76 * GNUNet hidden service (.gnu, .zkey)
77 * Bitcoin address (and other cryptocoins)
78 * OpenPGP subkeys (merge subkeys from multiple keyrings into one)
79
80 Kiki allows such keys to be taken from an existing system and imported
81 into an OpenPGP key so that they can be shared easily.
82
83 In the other direction, Kiki will determine the OpenPGP UID(s)
84 cryptographically chained to any public key in any format, so that
85 services with cryptographic authentication can be easily modified
86 to accept OpenPGP identities by calling Kiki. Kiki can also export
87 public keys into convenient formats, ready for use by services that do
88 not call Kiki.
89
90 In addition to supporting the traditional OpenPGP web of trust,
91 Kiki recognizes the possibility of _self-authenticating_ OpenPGP
92 signatures. These are signatures which assert ownership of UIDs which
93 are provably owned by the signer. For example, an OpenPGP key which
94 claims the UID <root@hiotuxliwisbp6mi.onion> is self-authenticating
95 if the private key corresponding to 'hiotuxliwisbp6mi' has signed the
96 UID. Such OpenPGP keys do not need to be validated by an external
97 signature. They can be validated using their own internal data, and
98 trusted immediately.
99
100Tutorial:
101
102 To get started with Kiki, yada yada, [TODO]
103
104Commands:
105
106 If no command is given, the default command is 'show-working-key'.
107
108 For options common to multiple commands, see _Options_.
109
110 import-key [options] [file]
111 PROPOSAL2: import-public [options] [SPEC=file] -- [file] (recommended)
112 PROPOSAL2: import-secret [options] [SPEC=file] -- [file] (allowed)
113 PROPOSAL2: (Same options, and behavior as described, below)
114 PROPOSAL2: (SPEC acts as a filter, only matching keys are touched
115 by the import, import-public ensures secret keyring is
116 not touched)
117
118 options: --autosign --sign-key --authentic-only
119
120 Import an OpenPGP key into the default keyring, optionally signing
121 it with the default key. If no file is specified, the key is read
122 from stdin.
123 PROPOSAL2: If no SPEC=file is specified, the key is read from stdin.
124
125 With --authentic-only, import the key only if it is
126 self-authenticating or can be authenticated by already-trusted keys.
127 With --autosign, import the key either way, but only sign it if it
128 is self-authenticating (as if 'autosign' were run).
129
130[21:10] <raoul> i guess i didn't say anything about --sign-key
131[21:11] <raoul> it should say, 'With --sign-key, signs the imported key(s) unconditionally.'
132
133 For a detailed description of the requirements for
134 self-authenticated keys, see section _Self-authentication_.
135
136 import-subkey [options] [public key filename | private key filename] [...]
137 PROPOSAL2: import-secret [options] [SPEC=file] -- [file]
138
139 options: [--usage=<type>] [--set-notation <name=value>] [--no-usage] [key format]
140
141 Import keys from an external file, or from stdin, into the keyring,
142 as subkeys of the working key. The keys will be signed by the
143 master key, and cross-certification will be performed (i.e., the
144 keys will be used to sign the master key). PROPOSAL2: Same.
145
146 Without a private key, cross-certification is impossible, and a
147 confirmation will be required, which can be overridden with --yes.
148 PROPOSAL2: Same.
149
150 The --usage option can be used to specify the 'usage@' notation,
151 which is used by Kiki and Samizdat to determine what functions the
152 key should have outside of PGP. If neither --usage nor --no-usage
153 is specified, the usage will be inferred from the filename and/or
154 key format.
155 PROPOSAL2: Infer usage from the SPEC as in 't:tor'
156 PROPOSAL2: In the case of files without specs, and subkeys without
157 any tags, import them without tags, and put ??? in the ui where
158 the usage tag would usually appear.
159
160 When the input is a file, the internal timestamp of the subkey will
161 be set to match its mtime. The subkey timestamp is not altered if
162 the subkey already exists.
163 PROPOSAL2: Same.
164
165 export-subkey [options] <uid | master keyprint | subkey keyprint> [output path]
166 PROPOSAL2: export-secret [[options] SPEC=file{CMD}] -- [file]
167
168 options: [--public[=file]] [--private[=file]] [--usage=string] [key format]
169 PROPOSAL2: options: [--format format] [--with-public=file]
170
171 Export the explicitly specified subkey, or the newest subkey
172 indicated by the usage option, in the explicitly specified format,
173 or the format indicated by the usage option. If no output file
174 specification is supplied, stdout is used, but this may require
175 --public or --private, depending on the key format. (Not all key
176 formats allow public and private keys to be appended in a single
177 file in a reasonable way.)
178 PROPOSAL2: If the format only allows one key, it is the secret
179 key. If a file is specified with --with-public it will be
180 updated with the public key. (Even if the secret key
181 file already has that information.)
182 --with-public only applies to the very next SPEC=file.
183
184 Alternatively,
185 export-public --format blah SPEC=file could be
186 run as a separate command.
187
188 If a uid or master key is specified, then the usage option is
189 mandatory; it is required to select which subkey to export. Only
190 one of --public or --private can be specified unless both have
191 arguments.
192 PROPOSAL2: export-secret may export master keys and all their
193 subkeys, such as when the file is in pgp format.
194
195 If --public or --private is specified without arguments, then the
196 public or private key is written to the specified output path. If
197 neither is specified, then the output path is where the private key
198 will be written. In that case, the public key will be also written,
199 to a path determined by that of the private key, by a mechanism
200 specified by the key format.
201 PROPOSAL2: If they want the public key written to a separate
202 path, they must say so with --with-public.
203
204 When --public or --private have arguments, these are the locations
205 where the public and private keys are written. A path of '-' can be
206 specified for output to stdout.
207 PROPOSAL2: Allow a - to appear in one and only one file slot
208 and use stdout for that file.
209
210 When the output is a file, the mtime on the file will be set to
211 match OpenPGP's internal subkey timestamp.
212 PROPOSAL2: Same.
213
214 For more information about key formats, see _Key formats_.
215
216 [TODO: generic 'authorize' command?]
217 PROPOSAL2: Definitely favor a generic authorize.
218 || In fact, lets figure out the semantics of the
219 || generic form, so our UI is at least aware of
220 || our future direction.
221
222 || In keeping with the idea, that export and sync
223 || commands modify files outside of GNUPGHOME, while
224 || import comands only affect GNUPGHOME, lets create
225 || a new set of commands:
226
227 || At first the following will only work when SPEC is
228 || referring to an ssh_client key.
229
230 || authorize [--delete] [--masters] SPEC
231 || - add a SPEC_auth key under the working key
232 || corresponding to the specified key. Or if --delete
233 || is indicated, then remove any such key. In the case
234 || of --masters, the SPEC_auth key should correspond
235 || to a corresponding master key instead, creating a
236 || 'ghost' master if necessary.
237
238 || - IF SPEC matched a uid to a master, use the email
239 || address of the indicated master to tag
240 || the new SPEC_auth key with appropriate meta data.
241
242 || - if configured with an authorized key file and
243 || format, then update the file, otherwise it is
244 || a keyring only operation. Note that this means
245 || the authorize command can behave as either a sync
246 || or an import commmand, depending on kiki config.
247 || Unlike explicit sync commands, it should probably
248 || fallback to import when there are permission problems.
249 || If falling back, issue a warning, rather than an error.
250
251 || - If --masters, then remove all SPEC_auth keys which are
252 || subkeys of masters replacing them with SPEC_auth keys
253 || which are the masters instead. (If SPEC specifies a subkey
254 || of an existing master, then the SPEC_auth created will be
255 || for its master.) Non existent masters will be created as
256 || 'ghost' masters which have entries but lack keys
257
258 || * As a matter of Roadmap, --masters may not be implemented until
259 || later, and then we may choose to make it the default. and add
260 || --subkeys for the old behavior.
261
262 || - use the present moment as the timestamp of the
263 || SPEC_auth key
264
265 || - Note, this command is only useful for authorizing keys
266 || which are already found in your keyring.
267
268 || Example: kiki authorize jim@samwise/ssh_client
269
270 || - Assuming jim@oxio4inifatsetlx.onion is the working
271 || key and jim@samwise appears as a substring of a uid
272 || of one of the master keys, the above command authorizes
273 || jim@samwise to ssh in to oxio4inifatsetlx.onion as user
274 || jim.
275
276 || import-auth [--format FORMAT] [--delete SPEC2] [--masters] SPEC=file
277 || - Assume file in format specified.
278 || - Import all keys from specified file as subkeys
279 || of working (in public keyring), but not as SPEC
280 || but rather as SPEC_auth. To each SPEC_auth key
281 || tag it with additional meta from the file, such
282 || as the user@host.
283 || - If the --delete option is used, delete any
284 || SPEC_AUTH keys which are singled out by SPEC2. If
285 || SPEC2 indicates a master key, delete all SPEC_auth
286 || keys under the working key which are also subkeys
287 || of the master specified by SPEC2. The file is not
288 || touched as this is an import command.
289 || - In the --masters case, do not add any subkeys as SPEC_auth,
290 || instead search for corresponding masters and add them as
291 || SPEC_auth. Create ghost master entries for subkeys
292 || which do not have them. Add a ghost SPEC_auth sub key
293 || referring to the ghost master.
294 || - If the key already exists as a SPEC subkey under
295 || a master key in the ring, and the uid does not
296 || match the address specified, then add a new uid
297 || to that master with the given address(user@host),
298 || if it does match, then update the meta tag with
299 || the full uid. (Treating user@host like an email)
300 || - use the mtime of the specified file for the keys.
301
302 || export-auth [--format FORMAT] SPEC=file
303 || - Export all SPEC_auth keys under the working key
304 || to indicated file in the given
305 || file format.(skip keys if they are already there.)
306 || - Whenever a SPEC_auth key matches a master key,
307 || don't write it to the file, but rather write entries
308 || for all the SPEC subkeys under the indicated master.
309 || - set mtime on file to match newest key
310 ||
311 || sync-auth [--format FORMAT] [--delete SPEC2] [--masters] SPEC=file
312 || sync-auth [--format FORMAT] [--delete SPEC2] [--masters] SPEC
313 || - If set in a config file, then the file can be inferred from
314 || SPEC alone.
315 || - Add any keys missing from the file but present in
316 || the public gpg keyring to the file and add any keys
317 || missing from the keyring but present in the file to
318 || the keyring.
319 || - If a key in the file, is a subkey of a master that already
320 || already has a SPEC_auth in the keyring, do not add it to the
321 || keyring, but add any other SPEC subkeys under that master to
322 || the indicated file.
323 || - In the --masters case, do not add any subkeys as SPEC_auth,
324 || instead search for corresponding masters and add them as
325 || SPEC_auth. Create ghost master entries for subkeys
326 || which do not have them. Add a ghost SPEC_auth sub key
327 || referring to the ghost master.
328 || - Also with --masters, remove any SPEC_auth subkeys of the
329 || working key and replace them with SPEC_auth keys which are
330 || also masters in the key ring.
331 || - If the --delete option is used, delete any
332 || SPEC_AUTH keys which are singled out by SPEC2. If
333 || SPEC2 indicates a master key, delete all SPEC_auth
334 || keys under the working key which are also subkeys
335 || of the master specified by SPEC2. Naturally, their
336 || entries in the file should also be removed.
337 || - set mtime on the file to match newest key.
338 || - all keys added to the keyring will have timestamp set
339 || to match the mtime of file prior to sync.
340 ||
341 || I think it is most convenient if we allow auth keys not to be
342 || back signed, as users may not want to spread their secret keys
343 || to every computer that they have auth access.
344
345 || PROBLEM: What about user accounts? It is not presently clear
346 || how kiki is supposed to treat users of the same unix
347 || system which are not root. Presumeably, each user would
348 || have it's own master entry in root's public gpg keyring.
349 || Since root has access to their home folders etc, it may
350 || be nice to facilate root using the above commands and
351 || simply use the master portion of the spec to indicate
352 || which user is being referred to, and then the _auth keys
353 || would be added to that user, but then somewhere
354 || kiki must remember which masters are local to the box.
355 || (Actualy, kiki may have this information already as
356 || for example username@hiotuxliwisbp6mi.onion may match
357 || unix users on the same box.) If we did this,
358 || then there is the added complication of also updating
359 || the gnupghome of the specified user.
360
361 || It strikes me as somewhat error-prone to operate that
362 || way. Perhaps it is better for root to su to the
363 || given user before updating the _auth subkeys etc.
364 || if the root database should have all the public key
365 || masters of all the users on the system, it can run an
366 || import-public command to grab users keyrings.
367 || (Of course, root can take private keys too, but that seems
368 || messy to me. I think it is best practice if keyrings
369 || only have private keys of a single unix user.)
370 || In fact, a user may theoretically opt to take their own
371 || private keyring with them on some portable media.
372 ||
373 || Another possibility, is to give write access to root's
374 || public keyring, and make it users responsibility to keep
375 || root abreast rather than the other way around.
376 || OR nobody writes to anyone elses GNUHOME and instead, we
377 || simply mail announcements with the public key info.
378 END PROPOSAL2
379
380 ssh-authorize [options] <uid | master keyprint | subkey keyprint>
381
382 options: --user=user
383
384 Authorize ssh access for the specified user by appending the
385 appropriate key to $HOME/.ssh/authorized_keys unless it already
386 exists there.
387
388 Without --user, access to the current user account is granted.
389 Otherwise, root is required, and access to the specified user
390 account is granted.
391
392 A comment will be written indicating the UID prepended with
393 '[samizdat]'.
394
395 ssh-unauthorize [uid]
396
397 options: --user=user --authorized_keys=<file>
398
399 Without a uid argument, revoked keys, expired keys, and expired
400 subkeys, will have their corresponding ssh keys removed from
401 $HOME/.ssh/authorized_keys, or the specified file. Additionally,
402 auth lines tagged [samizdat] for keys that are missing from the
403 keyring will be removed.
404
405 With a uid argument, all subkeys of the specified UID will be
406 removed.
407
408 Without --user, access to the current user account is removed.
409 Otherwise, root is required, and access to the specified user
410 account is removed.
411
412 autosign [key] [...]
413 PROPOSAL2: behaves exactly the same... Use SPEC to indicate the key
414
415 This command will operate on all keys if none are specified.
416
417 The working key is used to sign the specified keys if they can be
418 self-authenticated. This tells GnuPG to trust such keys, which it
419 would not otherwise do.
420
421 For a detailed description of the requirements for
422 self-authenticated keys, see section _Self-authentication_.
423
424 show-working-key
425 PROPOSAL2: show --working
426 PROPOSAL2: same as show SPEC where SPEC indicates the master key that is the working key
427
428 Show all available information about the default working key.
429
430 Equivalent to 'show --all' with no uid argument.
431
432 show [options] [uid or keyprint]
433 PROPOSAL2: show [options] SPEC
434
435 options: [--all | key format]
436 PROPOSAL2: options: --all | --list | --working | --color | --native-fingerprint | --base64
437 PROPOSAL2: --native-fingerprint will replace gpg fingerprints with
438 possibly more appropriate fingerprints given the usage of
439 the keys in question.
440 --base64 should not be used in conjunction with --native-fingerprint
441 it will show all fingerprints in base64
442 --all means all masters and all their subkeys with trust relations
443 --list (if a subkey is indicated, it shows all it's siblings and their
444 master key, otherwise it is a nop)
445 --color, make untrusted keys red, keys directly trusted (nesting 0) are
446 green, and all the inbetweens are white.
447
448 With '--all' or without a key format option, display a listing
449 showing all keys and UIDs associated with a given UID, indicating
450 trust-chain relationships between them.
451
452 With a key format option, output a machine-useable version of the
453 key type specified. If a UID or master keyprint is specified, then
454 the 'usage@' annotation will be used to decide which subkey to
455 display. If a subkey fingerprint is specified, then that key will
456 be output in the specified format. If multiple keys are available
457 with a matching 'usage@' annotation, the most recent key is chosen.
458 PROPOSAL2: This belongs under one of the export commands
459 using a --format option, show is reserved only for
460 displaying to the user. SPEC=- can be used if they
461 want to export to the stdout.
462
463 Untrusted or unrequested data may be output via stderr. Only
464 trusted and requested data is output via stdout.
465
466 For more information about key formats, see _Key formats_.
467
468 list <uid | master keyprint | subkey keyprint> <key format>
469 PROPOSAL2: list can be a synonym for show --list, key format is not
470 used here as that functionality is covered by export-public
471 and export-secret. If nothing is indicated, i would have
472 list default to show --all
473
474 List all subkeys of the specified master key, or of the master key
475 of the specified subkey, tagged with the usage specified by the key
476 format.
477
478 For more information about key formats, see _Key formats_.
479
480PROPOSAL2: The rest of this proposal can be added to PROPOSAL2 as
481 it is described here.
482
483 verify [options] [file or network resource]
484
485 options: [key format | --challenge] --uid --short-uid --keyprint --datetime
486
487 Output the verified identity of the signer of the data. If no file
488 is specified, then the data is read from stdin.
489
490 A key format can be specified to indicate the format of the data.
491 Otherwise, an attempt is made to infer the key format from the data
492 itself, in which case it must not contain extraneous information.
493 For network resources, it can always be inferred.
494
495 Supported network resources are:
496
497 ssh://server[:port]
498 https://[SNI domain@]server[:port]
499 tls://[SNI domain@]server[:port]
500 dnskey://[domain][@dns server:port]
501
502 For DNSKEY network resources, all DNSKEY responses must validate;
503 but ZSK's might be validated indirectly, through RRSIG records made
504 with validated ZSK's.
505
506 Identities are output on stdout, with one identity per line. Stderr
507 may contain additional information. Special characters in UIDs
508 (such as newline) are escaped.
509
510 By default, or with --uid, show the full UID. With --short-uid,
511 show only the email part of the UID, without brackets. With
512 --keyprint, show the keyprint of the master key.
513
514 With both --keyprint and one of --uid or --short-uid, show the
515 keyprint, followed by a space, followed by the UID in the specified
516 form.
517
518 With '--challenge', a cryptographic challenge response is verified.
519 In this case, the stdout output is not necessarily an OpenPGP UID or
520 keyprint, but is specific to the challenge type.
521
522 Kiki will exit with failure if verification fails.
523
524 For more information about key formats, see _Key formats_.
525
526 challenge [options] <challenge type> <uid>
527
528 options: --language=[lang] --short --no-instructions --shell --validity-period=[interval]
529 challenge types: --bitcoin --tor --i2p --pgp
530
531 Output to stdout a human-readable challenge which can be completed
532 only with the appropriate private key. Creating the challenge may
533 require generating a PGP signature, in which case the working key
534 will be used. The response to the challenge can be verified with
535 the 'verify --challenge' command.
536
537 With --validity-period, the challenge will expire after the
538 specified interval. The interval is specified in DNS zone file
539 format. The current system time is used to calculate an absolute
540 expiration time in the future.
541
542 Unless --no-instructions is specified, the challenge will contain
543 detailed instructions intended for unsophisticated recipients. If
544 --short is specified, the instructions will be less detailed. If
545 --shell is specified, the "instructions" take the form of a Bourne
546 shell script.
547
548 response [file]
549
550 A challenge generated from 'challenge' is read from the specified
551 file, or via stdin, and an identity-proving response is generated
552 automatically and output to stdout.
553
554 help
555
556Key formats:
557
558 [TODO: determine, and document, the precise relationship between key
559 formats and usage notations.]
560
561 --pem --ssh --wallet --dnskey --ipsec --pgp
562
563 --wallet
564
565 Bitcoin wallet input format. These cryptocoins are also supported:
566
567 [...]
568
569 --ssh
570
571 OpenSSH key format. For public keys, this is the format used in
572 authorized_keys. The "comment" section, which is output via stderr,
573 contains a UID with special characters (such as newline) escaped.
574
575Options:
576
577 These options are common to multiple commands. Options specific to
578 commands are documented with the commands.
579
580 --homedir
581 --passphrase-fd
582 --keyring
583 --no-default-keyring
584 --primary-keyring
585 --default-key
586 --trustdb-name
587 --verbose
588 --quiet
589 --no-tty
590 --yes
591 --no
592
593Environment:
594
595 HOME
596 GNUPGHOME
597 GPG_AGENT_INFO
598 PINENTRY_USER_DATA
599
600Files:
601
602 $HOME/.gnupg
603
604 $GNUPGHOME/{pub,sec}ring.gpg
605
606 /etc/ssh/ssh_host*_key
607
608 /etc/ipsec.d/private/*.pem
609
610 etc.
611
612Self-authentication:
613
614 [Explain the criteria of self-authentication in precise terms.]
615
616Author:
617
618 Kiki by Joe Crayne. This manual by Andrew Cady.
619
620Copyright:
621
622 (C) 2014 Joe Crayne. All Rights Reserved.
623
624 When released, Kiki will be released under a free software license.
625 This version is a pre-release.
626
627Reporting Bugs:
628
629 Bugs? Impossible.
630
631 "From key to shining key..."
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647CURRENTLY IMPLEMENTED:
648
649
650kiki [OPTIONS]
651
652 kiki merges a set of keyring files into a combined database and then
653 uses the database to update the files so that they have the most complete
654 information.
655
656 The files pubring.gpg and subring.gpg in the directory specified by the
657 --homedir option are implicitly included in the keyring set.
658
659 kiki can also import or export secret subkeys by using the --keypairs option.
660
661 Subkeys that are imported with kiki are given an annotation "usage@" which
662 indicates what the key is for. This tag can be used as a SPEC to select a
663 particular key. Master keys may be specified by using fingerprints or by
664 specifying a substring of an associated UID.
665
666Flags:
667 --homedir DIR
668 Where to find the the files secring.gpg and pubring.gpg. The
669 default location is taken from the environment variable
670 GNUPGHOME.
671
672 --passphrase-fd N
673 Read passphrase from the given file descriptor.
674
675 --import Add master keys to pubring.gpg. Without this option, only UID
676 and subkey data is updated.
677
678 --import-if-authentic
679 Add signed master keys to pubring.gpg. Like --import except that
680 only keys with signatures from the working key (--show-wk) are
681 imported.
682
683 --autosign Sign all cross-certified tor-style UIDs.
684 A tor-style UID is of the form:
685 Anonymous <root@HOSTNAME.onion>
686 It is considered cross certified if there exists a cross-certified
687 'tor' subkey corresponding to the address HOSTNAME.onion.
688
689Merging:
690 --keyrings FILE FILE...
691 Provide keyring files other than the implicit secring.gpg and
692 pubring.gpg in the --homedir. This option is implicit unless
693 --keypairs or --wallets is used.
694
695 --wallets FILE FILE...
696 Provide wallet files with secret crypto-coin keys in Wallet
697 Import Format. The keys will be treated as subkeys of your
698 current working key (the one shown by --show-wk).
699
700 --keypairs KEYSPEC KEYSPEC...
701 Each KEYSPEC specifies that a key should match the content and
702 timestamp of an external PKCS #1 private RSA key file.
703
704 KEYSPEC ::= SPEC=FILE{CMD}
705
706 If neither SPEC or FILE match any keys, then the CMD will be
707 executed in order to create the FILE.
708
709 2B9F3D5A99EF9E0BB50252C3C07428D3FCD7BFB7/tor
710 joe/tor
711 joe/9166F90FA7E4311088FA84BC9E6AFE3F58C673C2
712 joe/fp:C673C2
713
714
715Output:
716 --show-wk Show fingerprints for the working key (which will be used to
717 make signatures) and all its subkeys and UID.
718
719 --show-key SPEC
720 Show fingerprints for the specified key and all its subkeys
721 and UID.
722
723 --show-all Show fingerprints and UIDs and usage tags for all known keys.
724
725 --show-whose-key
726 Shows the fingerprint and UIDs of the key that owns the one that
727 is input on stdin in ssh-rsa format.
728
729 --show-pem SPEC
730 Outputs the PKCS #8 public key corresponding to SPEC.
731
732 --show-ssh SPEC
733 Outputs the ssh-rsa blob for the specified public key.
734
735 --show-wip SPEC
736 Outputs the secret crypto-coin key in Wallet Input Format.
737
738 --help Shows this help screen.
739
740
741
742
743
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-05 01:38:00 +0000