THOUGHTS

   1 How often have we to do a key lookup by mailaddress?.
   2 can this be accomplished by an external program?
   3
   4
   5
   6 What about using S-Exp to describe the interface to the ciphers instead
   7 of simply iterating over them. This way we can easy register a name which
   8 can be used as the "hintstr" for --load-extension.
   9
  10 EGD
  11 ====
  12 Oh, and on embedding egd into the gpg package: I think if you just unpack it
  13 into, say, util/egd/* then you can put something like this into configure.in:
  14
  15 AC_CHECK_PROG(perl_present, perl, true, false)
  16 if $perl_present; then
  17  AC_PATH_PROG(PERL, perl)
  18  (cd util/egd; $PERL Makefile.PL FULLPERL=$PERL INSTALLBIN=$sbindir)
  19 fi
  20 AM_CONDITIONAL(WITH_EGD, $perl_present)
  21
  22 and add util/egd to the top-level Makefile directory list inside a WITH_EGD
  23 conditional.
  24
  25     * What shall we do if we have a valid subkey revocation certificate
  26       but no subkey binding?  Is this a valid but revoked key?
  27
  28     * use a mmaped file for secure memory if mlock does not work and
  29       make sure that this file is always wiped out.  Is this really
  30       more secure than swapping out to the swap disk?  I don't
  31       believe so because if an attacker has access to the physical
  32       box (and he needs this to look at the swap area) he can also
  33       leave a Trojan horse which is far more easier than to analyze
  34       memory dumps.  Question:  Is it possible that a Unix pages
  35       an old (left over by some other process) swap page in for
  36       another process - this should be considered a serious design
  37       flow/bug.
  38
  39 Date: Mon, 4 Jan 1999 19:34:29 -0800 (PST)
  40 From: Matthew Skala <mskala@ansuz.sooke.bc.ca>
  41
  42 - Signing with an expired key doesn't work by default, does work with a
  43   special option.
  44 - Verifying a signature that appears to have been made by an expired key
  45   after its expiry date but is otherwise good reports the signature as BAD,
  46   preferably with a message indicating that it's a key-expiry problem rather
  47   than a cryptographically bad signature.
  48 - Verifying a signature from a key that is now expired, where the
  49   signature was made before the expiry date, reports the signature as
  50   GOOD, possibly with a warning that the key has since expired.
  51 - Encrypting to an expired key doesn't work by default, does work with a
  52   special option.
  53 - Decrypting always works, if you have the appropriate secret key and
  54   passphrase.
  55
  56
  57
  58 ==============================
  59 [ "-->" indicates a comment by me (wk) ]
  60
  61 Hi Werner..
  62
  63 I was looking at some of the PROJECTS items in the recent gpg CVS and wanted
  64 to comment on one of them:
  65
  66   * Add a way to override the current cipher/md implementations
  67     by others (using extensions)
  68
  69 As you know I've been thinking about how to use a PalmPilot or an iButton in
  70 some useful way in GPG. The two things that seem reasonable are:
  71  1) keep the secret key in the device, only transferring it to the host
  72     computer for the duration of the secret-key operation (sign or decrypt).
  73     The key is never kept on disk, only in RAM. This removes the chance that
  74     casual snooping on your office workstation will reveal your key (it
  75     doesn't help against an active attack, but the attacker must leave a
  76     tampered version of GPG around or otherwise get their code to run while
  77     the key-storage device is attached to attack the key)
  78  2) perform the secret-key operation on the device, so the secret key never
  79     leaves the confines of that device. There are still attacks possible,
  80     based upon talking to the device while it is connected and trying to
  81     convince the device (and possibly the user) that it is the real GPG,
  82     but in general this protects the key pretty strongly. Any individual
  83     message is still vulnerable, but that's a tradeoff of the convenience of
  84     composing that message on a full-sized screen+keyboard (plus the added
  85     speed of encryption) vs. the security of writing the message on a
  86     secure device.
  87
  88 I think there are a variety of ways of implementing these things, but a few
  89 extension mechanisms in GPG should be enough to try various ways later on.
  90
  91 1) pass an argument string to loadable extension modules (maybe
  92     gpg --load-extension foofish=arg1,arg2,arg3 ?)
  93     --> could also be achived by S-Exps
  94
  95 2) allow multiple instances of the same extension module (presumably with
  96    different arguments)
  97    --> set an alias name when loading them
  98 3) allow extension modules to use stdin/stdout/stderr as normal (probably
  99    already in there), for giving feedback to the user, or possibly asking them
 100    for a password of some sort
 101    --> there should really be some kind of callback mechanism.
 102
 103 4) have an extension to provide secret keys:
 104
 105    It looks like most of the hooks for this are already in place, it just
 106    needs an extension module which can register itself as a keyblock resource.
 107
 108    I'm thinking of a module for this that is given an external program name as
 109    an argument. When the keyblock resource is asked to enumerate its keys, it
 110    runs the external program (first with a "0" argument, then a "1", and so on
 111    until the program reports that no more keys are available). The external
 112 --> better use a cookie:  This way we are also stateless but have a more
 113    general interface.
 114
 115    program returns one (possibly armored) secret key block each time. The
 116    program might have some kind of special protocol to talk to the storage
 117    device.  One thing that comes to mind is to simply include a random number
 118    in the message sent over the serial port: the program would display this
 119    number, the Pilot at the other end would display the number it receives, if
 120    the user sees that both are the same they instruct the Pilot to release the
 121    key, as basic protection against someone else asking for the key while it
 122    is attached. More sophisticated schemes are possible depending upon how
 123    much processing power and IO is available on the device. But the same
 124    extension module should be able to handle as complex a scheme as one could
 125    wish.
 126    --> authenticate the session on startup, using DH and the mentioned
 127        cookie/screen/keyboard authentication.
 128
 129    The current keyblock-resource interface would work fine, although it
 130    might be more convenient if a resource could be asked for a key by id
 131    instead of enumerating all of them and then searching through the resulting
 132    list for a match. A module that provided public keys would have to work this
 133    way (imagine a module that could automatically do an http fetch for a
 134    particular key.. easily-added automatic key fetching). Without that ability
 135    to fetch by id (which would require it to fall back to the other keyblock
 136    resources if it failed), the user's device might be asked to release the
 137    key even though some other secret key was the one needed.
 138    --> Right.
 139
 140
 141 5) have an extension to perform a secret-key operation without the actual
 142    secret key material
 143    --> Define a clear interface to do this and in the first step write
 144        a daemon which does exactly this.
 145
 146  basically something to indicate that any decrypt or sign operations that
 147  occur for a specific keyid should call the extension module instead. The
 148  secret key would not be extracted (it wouldn't be available anyway). The
 149  module is given the keyid and the MPI of the block it is supposed to sign
 150  or decrypt.
 151
 152  The module could then run an external program to do the operation. I'm
 153  imagining a Pilot program which receives the data, asks the user if it can go
 154  along with the operation (after displaying a hash of the request, which is
 155  also displayed by the extension module's program to make sure the Pilot is
 156  being asked to do the right operation), performs the signature or decryption,
 157  then returns the data. This protocol could be made arbitrarily complex, with
 158  a D-H key to encrypt the link, and both sides signing requests to
 159  authenticate one to the other (although this transforms the the problem of
 160  getting your secret key off your office workstation into the problem of
 161  your workstation holding a key tells your Pilot that it is allowed to perform
 162  the secret key operation, and if someone gets a hold of that key they may
 163  be able to trick your pilot [plugged in somewhere else] to do the same thing
 164  for them).
 165
 166  This is basically red/black separation, with the Pilot or iButton having the
 167  perimeter beyond which the red data doesn't pass. Better than the secret-key
 168  storage device but requires a lot more power on the device (the new iButtons
 169  with the exponentiator could do it, but it would take way too much code space
 170  on the old ones, although they would be fine for just carrying the keys).
 171
 172 The signature code might need to be extended to verify the signature you just
 173 made, since an active intruder pretending to the the Pilot wouldn't be able to
 174 make a valid signature (but they might sign your message with a different key
 175 just to be annoying).
 176
 177 Anyway, just wanted to share my thoughts on some possibilities. I've been
 178 carrying this little Java iButton on my keyring for months now, looking for
 179 something cool to do with it, and I think that secure storage for my GPG key
 180 would be just the right application.
 181
 182 cheers,
 183  -Brian
 184
 185 -----BEGIN PGP SIGNATURE-----
 186 Version: GnuPG v0.4.5 (GNU/Linux)
 187 Comment: For info finger gcrypt@ftp.guug.de
 188
 189 iD8DBQE2c5oZkDmgv9E5zEwRArAwAKDWV5fpTtbGPiMPgl2Bpp0gvhbfQgCgzJuY
 190 AmIQTk4s62/y2zMAHDdOzK0=
 191 =jr7m
 192 -----END PGP SIGNATURE-----
 193
 194
 195
 196 About a new Keyserver  (discussion with Allan Clark <allanc@sco.com>):
 197 =====================
 198
 199 Some ideas:
 200
 201 o  the KS should verify signatures and only accept those
 202    which are good.
 203
 204 o  Keep a blacklist of known bad signatures to minimize
 205    the time needed to check them
 206
 207 o  Should be fast - I'm currently designing a new storage
 208    system called keybox which takes advantage of the fact
 209    that the keyID is highly random and can directly be
 210    used as a hash value and this keyID is (for v4 keys)
 211    part of the fingerprint: So it is possible to use the
 212    fingerprint as key but do an lookup by the keyID.
 213
 214 o  To be used as the "public keyring" in a LAN so that there
 215    is no need to keep one on every machine.
 216
 217 o  Allow more that one file for key storage.
 218
 219 o  Use the HKS protocol and enhance it in a way that binary
 220    keyrings can be transmitted.  (I already wrote some
 221    http server and client code which can be used for this)
 222    And extend it to allow reuse of a connection.
 223
 224 o  Keep a checksum (hash) of the entire keyblock so that a
 225    client can easy check whether this keyblock has changed.
 226    (keyblock = the entire key with all certificates etc.)
 227    Transmitted in the HEAD info.
 228
 229 o  Allow efficient propagation of new keys and revocation
 230    certificates.
 231
 232
 233 Probably more things but this keyserver is not a goal for the
 234 1.0 release. Someone should be able to fix some of the limitations
 235 of the existing key servers (I think they bail out on some rfc2440
 236 packet formats).
 237
 238
 239 DJGPP
 240 =====
 241 Don't use symlinks but try to do the preprocessing in the config-links script.
 242 DJPGG has problems to distinguish betwen .s and .S becaus the FAT filesystem
 243 is not case sensitive (Mark Elbrecht).
 244 Well, it runs only on one architecture and therefor it might be possible
 245 to add a special case for it, completely bypassing the symlink autselection
 246 trick.
 247
 248 Special procmail addresses
 249 ==========================
 250   * foo+bar@example.net:  Try to match the address without the "+bar".
 251     Should be done by the MUA, but maybe we can do this.
 252     --> Yep.  Another reason to utilize a directory service or something
 253         else for keylookup.
 254
 255
 256
 257 Suggested things which I will not do:
 258 =====================================
 259   * Let take --help an option to select some topics.
 260     Using grep is much easier
 261   * Check if an object (a message, detached sign, public key, or whatever)
 262     is signed by definite user, i.e. define user
 263     (userid, or any other unique identification) on command line.
 264     --> Use a script and --status-fd
 265
 266
 267  Copyright 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
 268
 269  This file is free software; as a special exception the author gives
 270  unlimited permission to copy and/or distribute it, with or without
 271  modifications, as long as this notice is preserved.
 272
 273  This file is distributed in the hope that it will be useful, but
 274  WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
 275  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.