GPG features, interface, and applications
QingLong
QingLong at Bolizm.ihep.su
Tue Nov 17 22:05:03 CET 1998
Hello All!
I've been lurking on the list a while to become acquainted,
and while lurking I've had a private email conversation to Werner Koch
on gpg features and interface. Werner has given me permission to post
a digest of that talk as it would make interest to gpg developers and users.
On Thu, 5 Nov 1998 17:35:47 I wrote to Werner:
+------------------------------------------------------------------
|
| ... is it possible to to persuade you to add new command line options
| along with the correspondent feature?
| ...[skipped]...
| I would like gpg to have the following functionality:
| 1. Check if an object (a message, detached sign, public key, or whatever)
| is signed by definite user, i.e. define user
| (userid, or any other unique identification) on command line.
| 2. Check if an object have a given level of trust:
| either just return the calculated level of trust on exit,
| or take the threshold trust level value from command line
| and return success on exit.
| 3. Add charset (and possibly `end of line' type) tag to a signed message
| (or to a detached sign), or force conversion of text being
| encrypted/signed to some standard format (e.g. unicode) to gain
| charset (and operating system) independance (e.g. although there is
| only one Internet standard charset for russian (KOI8-R, see RFC1489),
| #^&*$% m$ invented _two_ extra (non-standard):
| one for m$dos, and the other for m$win).
|
| It would be nice to have these features in gpg,
| and have ability to use them in a batch mode.
|
+------------------------------------------------------------------
On Sun, 8 Nov 1998 18:18:59 Werner answered:
+------------------------------------------------------------------
|
| > I would like gpg to have the following functionality:
| > 1. Check if an object (a message, detached sign, public key,
| > ...[skipped]...
|
| A simple tool would be sufficient for such goals, maybe gpg introduces
| too much overhead. But makes sense.
|
| > 2. Check if an object have a given level of trust:
| > ...[skipped]...
|
| --list-keys --with-colons should do that already.
|
| > 3. Add charset (and possibly ``end of line'' type) tag
| > to a signed message
|
| And of line is defined as CR,LF (0x0d, 0x10) in OpenPGP and we can't
| change this.
| ...[skipped]...
| OpenPGP specifies that all texts are to be stored in UTF-8 which is an
| Unicode enconding - I recently changed the username generation to take
| this into account. But of course we need some output/input function
| to do more than simple Latin-1/UTF-8 conversion.
|
+------------------------------------------------------------------
And this is my last followup on Tue, 16 Nov 1998 21:40:37:
+------------------------------------------------------------------
|
| >
| > > 1. Check if an object (a message, detached sign, public key, or whatever)
| > > is signed by definite user,...
| >
| > A simple tool would be sufficient for such goals, maybe gpg introduces
| > too much overhead. But makes sense.
| >
| This your idea to write dedicated application for the particular goal
| has lead me to an idea of GPG design: it would be vey useful to have all
| GPG power available in a (well documented) library to give people
| an opportunity to create simple dedicated applications for their particular
| needs. AFAIK PGP has already implemented this idea in 5.5.
| I think the best example of libgpg application would be GPG itself,
| if all the GPG code would be excessively and clearly {docu,com}mented:
| like ``HOWTO to use libgpg, a working example''.
|
| Quick glance through the GPG code makes me think that GPG is already
| highly structured and the architecture design is already very close to
| this model: core functionality (library) + command line arguments to
| functionality parser (main control module).
| Correct me if I have misunderstood it.
|
| Your idea has also triggered another one: a list of possible GPG
| (or libgpg) applications along with their design explanations or howto's.
| Such a list would serve two goals:
| 1. Source for TODO list.
| 2. GPG popularization and documentation.
| What do you think about it?
|
| Let me present a possible list beginning:
| 1. (obvious) Use GPG to protect your email privaty.
| Howto: use encryption, command line option: .....
| You can use various cryptos: ....
| 2. (obvious) Use GPG for email authentication.
| Howto: use signatures....
| 3. Use your GPG keys to authenticate yourself to computer systems.
| Howto: use GPG PAM...
| 4. Use your GPG authentification to build secure push systems,
| e.g. to trigger backuping/mirroring/etc remotely via email.
| Howto: write a simple procmail rule to check if mail arrived contains
| valid sequence number and current date, check if it is gpg-signed
| and the signature belongs to you...
| 5. Use GPG to create and verify blind signatures.
| Howto: ......
| 6. Use GPG to create reliable voting systems.
| Howto: e.g. open voting booth:
| publish voting poles texts,
| let people sign one of the alternatives and send you detached signatures,
| check the received signatures for trust level, ......
| 7. Use GPG to create public keyservers,
| that can also handle pgp2 and pgp5 keys.
| Howto: ask Fabio Coatti <cova at felix.unife.it> to share the secret. :)
|
| Have you caught the idea?
|
| >
| > > 2. Check if an object have a given level of trust:
| > > ...[skipped]...
| >
| > --list-keys --with-colons should do that already.
| >
| Yes, it will do the job, but it will require parsing overhead:
| I have asked this feature for use in a batch mode.
| Again, it would be better (to produce more efficient application) to use
| GPG functionality via calls to libgpg functions...
|
| >
| > ... But of course we need some output/input function
| > to do more than simple Latin-1/UTF-8 conversion.
| >
| I've been pretty sure that GNU libc has had this functionality.
| How about checking for it during autoconfiguration and using it if available?
|
+------------------------------------------------------------------
What do you think about these ideas?
Thank You.
QingLong.
More information about the Gnupg-devel
mailing list