--G+8BWByj2p3OxnB7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 21, 2005 at 11:32:14AM +0200, Manuel Freire wrote:

> we're looking for use cases that would be nice to add to BPG. We'd like
> to know your opinion about which features would you like to be included.
> The current use cases list can be read here:
> http://netbsd-soc.sf.net/projects/bpg/doc/use-cases.txt.

NB:  The following comments pertain to rev. 1.5 of use-cases.txt:

  %esha1sum use-cases.txt=20
  05111700573015bd24cdadbf65f27bbfe7cc2eb4        9503    use-cases.txt

[Delegated Trust Model, paragraph 3]
The trust db entries may as well be individually signed (and
timestamped).  For speed, use HMACs (RFC2104) for "signing" and
store the secret HMAC key encrypted to (and signed by) the owner's
public OpenPGP key in the trust db.  (Signing the trust db with one
overall signature requires that the entire db be verified before
trusting any of its entries, kept in RAM to prevent continually
re-checking the on-disk file for modifications, etc.)

("Keys from Arbitrary Sources" seems to contradict the level of
paranoia present in "Delegated Trust Model" and elsewhere in the
document.)

"Trusting Your Trust Database" essentially boils down to checking
a fingerprint/hash every time one invokes bpg (and assuming the
rest of the system is secure).  If memorizing something like
0xD6E6A97D8BE21D4FCDBACD3E4B2A4897D39DA0E3 is too hard and
0x4B2A4897D39DA0E3 isn't secure enough, BubbleBabble may do nicely.
For example (albeit of a MD5 hash):

  %ssh-keygen -B -f ~/.ssh/id_dsa.pub
  1024 xocac-mehin-hesih-fitun-kameg-cubug-tuvyd-zufof-nyfiv-zupoc-nexex ...

Likewise, bpg's configuration file (a la ~/.gnupg/gpg.conf) should
be signed to protect against modification.

Regarding "Encryption/Signing Beyond Files and E-mail," it would be
great if the bpg sources and docs were signed in CVS.  For my own
website stored in CVS, I use ./code/check-sigs-and-sign{.,asc}
(see my website) as a make(1) target.  It currently invokes GPG
repeatedly, but eventually "bpg --verify-or-sign <file list>" could
do the same thing in a single process.  Each .asc file is updated
in the repo. with (or after, if using keyword expansion) each checkin
of the signed files.  Generic mtree(1) output (stripped of comments
(at least on FreeBSD)):

  %mtree -c -k sha1digest,link,flags,mode,size,time | grep -v ^#
  /set type=3Dfile mode=3D0644 flags=3Dnone
  .               type=3Ddir mode=3D0755 size=3D512 time=3D1121987816.0
      0           size=3D0 time=3D1121987814.0 \
                  sha1digest=3Dda39a3ee5e6b4b0d3255bfef95601890afd80709
  ..

on a clean[ed] checkout/working copy can record/verify (and even reset)
mtimes and permissions and make sure all files are present.  This file
can be [Open]PGP-signed and used to verify the integrity of CVS checkouts
of the specific revision/tag or time.

(However, subversion[.tigris.org] does diffs without generating network
traffic, has atomic commits, and probably supports PGP-signing of files
in its repos even better.  Likewise, .svn/entries can be PGP-signed and
used to verify the integrity of a subversion checkout/working copy
independently of mtree(1).  While .svn/entries isn't normally checked
back into subversion, publising a signature or hash for it at each
revision should work well.)

--=20
Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
jharris@widomaker.com _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004

--G+8BWByj2p3OxnB7
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)

iJ0EARECAF0FAkLgO7lWGGh0dHA6Ly9rZXlzZXJ2ZXIua2pzbC5jb206MTEzNzEv
cGtzL2xvb2t1cD9vcD1nZXQmc2VhcmNoPTB4RDM5REEwRTMmd2VoYXZleW91bm93
PXRydWUACgkQSypIl9OdoOP1CACeKeUJaxG5VF1XzeBZX1SEOmkgtUAAnArIPnVP
JI7UcR30BMave6MJpefg
=OMdm
-----END PGP SIGNATURE-----

--G+8BWByj2p3OxnB7--