CLUG meeting 27 June 2002

[Drake Diedrich]

   And if there's interest (sounds like there is) I'll bring in a map of the
CLUG web-of-trust and how it links to some interesting keys (Linus, Kernel
Archives, GnuPG, Woz, mutt, SSH, PGP, the distributions).  Anyone not on the
attached list who wants to be mapped, let me know your key-id and upload
your latest signatures to the pgp.dtype.org keyserver before Thursday.

   Any interest in a discussion on best-practices, secret-key protection,
multiple keys, signing protocols, trust decisions, Keys-At-Work, long-term
signing keys, secure key storage, key escrow, session-key recovery, key
expiration, ... ?  I've been thinking of upgrading to a longer key length
(for signature purposes, not daily signing/encrypting).
   At the present, the only real (GnuPG) option for longer keys is RSA (DSA
is officially limited to 1024 by some accepted FIPS-or-something Standard).
2048R seems popular among Certificate Authorities and a few Debian
developers, usually signing a shorter 1024 bit key with an expiration time
of a year or two.  I've been thinking of going to a lifetime-length
key to gather signatures on, with no expiration date, and then a few-years
length on the daily use key, but, as a suggestion for discussion:

1) How many bits should a lifetime public key be?  Which algorithm(s)?
   RSA vs. DSA

2) What electronic and physical protection would be enough (I'd hate to have
   it compromised by some casual mistake or oversight and ruin ~40 years of
   key signatures in a second, and not realize it for another 20 years).

   a) Faraday cage, tamper-resistant building (Enemy of the State style).
   b) laptop/PDA in a locked safe, no network.  Probably on-disk system
      encryption or removed case to make trojaning very difficult.
   c) system that cold boots from read-only media
   d) non-networked system, key owner is sole admin/user
   e) networked
   f) networked, a few trusted admins/users (eg. family)
   g) networked, trusted admins, known users
   h) many users, not one of the administrators, or don't trust all

3) And then, two separate keys, or one key with multiple subkeys (this
   didn't quite work for me due to GnuPG implementation issues, can't delete
   primary key from working-secret-keyring, and can't sign with a subkey).

4) Expiration time on working-keyring.  Again, what level of security (same
   as question 2).



   Maybe we could have a poll or discussion along these lines.

[ do I really want to manipulate 8192-bit keys on an dedicated 486/25
  system, booting from a read-only floppy? Hmm.  Might need until Thursday
  to generate the key.]

-Drake

(er, Eyal, I think you need a new key already)

pub  1024D/63EF565E 
pub  1024R/154B8A6D 
pub  1024R/07792B2D 
pub  1024R/2A878271 
pub  1024D/27B464EA 
pub   917R/C817FEC9 
pub  1024D/A0B3E88B 
pub  1024D/3D08B612 
pub  1024D/685E3CE9 
pub  1024R/6C2BF4AD 
pub  1024D/58536791 
pub  1024D/E482EAB4 
pub  1024D/27EB604F 
pub  1024D/A236DDDD 
pub  1024D/49E2CF4C 
pub  1024D/72FDF9DF 
pub  1024D/1CF9471F 
pub   768R/CDE88AD9 
pub  1024D/A72CE1ED 
pub  1024R/60D74C7D 
pub  1024D/144A991C 
pub  1024D/DE89C75C 
pub  1024R/1A72475D 
pub  1024D/E25E479F 
pub  1024R/BD8C7805 
pub  1024D/7A9D7ED6 
pub  1024D/97B3BE12 
pub  1024D/3A2EC93E 
pub  1024D/5957F723 
pub  1024D/7A18E49D 
pub  1024D/815202AC 
pub  1024D/D33271B6 
pub  1024D/87BF34F4 
pub  1024D/FDDA6FC6 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux/attachments/20020625/ae39d219/attachment.bin