Charles Breed | 22 Jul 1997 18:39
Favicon

IETF "Open-PGP" Birds of a Feather

IETF Munich, "Open-PGP" Birds of a Feather Meeting Notice
---------------------------------------------------------
	http://www.imc.org/ietf-open-pgp/

This is to confirm one session for OPEN-PGP BOF as follows:

    Tuesday, August 12 at 0900-1115 (opposite charset ipvbi, idr, 
                                     rsvp, ssh 2000, calsch)

Marcia
**********************************************************************
Marcia Beaulieu <mbeaulie <at> ietf.org>
IETF Meeting Coordinator
Voice: 703-620-8990 ext. 210
Fax: 703-758-5913

Ben Cox | 23 Jul 1997 21:18

Key search

(Is this list "open for business" yet?)

Hello all,

I am interested in a key search mechanism by which I can ask a
key server for a chain of keys which leads between a desired key
and a key that I trust.

For example, if I trust A's key, and I am interested in finding
a chain by which I can trust D, I can ask the key server for the
chain and it will return B and C (where A has signed B's key, B
has signed C's key, and C has signed D's).

I actually have code that will do this for a PGP 2.6 key ring,
and am willing to contribute it to whomever is interested in it.

Basically it builds a directed graph whose vertices are the keys
and whose edges point from a key to all keys that have signed it.
It then does a breadth-first search of the graph, starting at the
requested key, stopping when it finds one of the keys listed as
"trusted".  When it finds a trusted key, it returns all the keys
on the path from the starting vertex to the ending vertex.

Is anyone interested in seeing this code?

__
Ben Cox
cox <at> transarc.com

(Continue reading)

Charles Breed | 23 Jul 1997 21:42
Favicon

Re: Key search

Hello Ben,

You might want to check out 	http://akpublic.research.att.com/~reiter/PathServer/
written by Mike Reiter and Stuart Stubblebine

This list will be used for discussing new features and functionality to be in the next, open,
standards-track pgp spec, hopefully from the IETF working group called open-pgp.

At 03:18 PM 7/23/97 -0400, you wrote:
>(Is this list "open for business" yet?)
>
>Hello all,
>
>I am interested in a key search mechanism by which I can ask a
>key server for a chain of keys which leads between a desired key
>and a key that I trust.
>
>For example, if I trust A's key, and I am interested in finding
>a chain by which I can trust D, I can ask the key server for the
>chain and it will return B and C (where A has signed B's key, B
>has signed C's key, and C has signed D's).
>
>I actually have code that will do this for a PGP 2.6 key ring,
>and am willing to contribute it to whomever is interested in it.
>
>Basically it builds a directed graph whose vertices are the keys
>and whose edges point from a key to all keys that have signed it.
>It then does a breadth-first search of the graph, starting at the
>requested key, stopping when it finds one of the keys listed as
>"trusted".  When it finds a trusted key, it returns all the keys
(Continue reading)

Wolfgang Ley | 23 Jul 1997 21:50
Picon

Re: Key search


Ben Cox wrote:
>
> (Is this list "open for business" yet?)
>
> Hello all,
>
> I am interested in a key search mechanism by which I can ask a
> key server for a chain of keys which leads between a desired key
> and a key that I trust.
>
> For example, if I trust A's key, and I am interested in finding
> a chain by which I can trust D, I can ask the key server for the
> chain and it will return B and C (where A has signed B's key, B
> has signed C's key, and C has signed D's).
>
> I actually have code that will do this for a PGP 2.6 key ring,
> and am willing to contribute it to whomever is interested in it.
>
> Basically it builds a directed graph whose vertices are the keys
> and whose edges point from a key to all keys that have signed it.
> It then does a breadth-first search of the graph, starting at the
> requested key, stopping when it finds one of the keys listed as
> "trusted".  When it finds a trusted key, it returns all the keys
> on the path from the starting vertex to the ending vertex.
>
> Is anyone interested in seeing this code?

Hi,

(Continue reading)

Ben Cox | 23 Jul 1997 22:35

Re: Key search

Charles Breed <cbreed <at> pgp.com> writes:
>You might want to check out 	http://akpublic.research.att.com/~reiter/PathServer/
>written by Mike Reiter and Stuart Stubblebine

Thanks; this looks very similar to what I have.

>This list will be used for discussing new features and functionality to be
>in the next, open, standards-track pgp spec, hopefully from the IETF
>working group called open-pgp.

...and, to quote the charter:

>- enhanced methods for public pgp key / certificate exchange 
>  (search, retrieval, revocation)
    ^^^^^^^^^^^^^^^^^

Wolfgang Ley <ley <at> cert.dfn.de> writes:
>I don't know why this should be useful. In real life this won't help
[...]
>So the real life situation is most probably more like "get the key from
>D, add it to your keyring to check if you can verify with your existing
>keys/trust definitions". If you can't then have lost because the helper
>keys B and C are most probably from people you've never met in person
>before and therefor can't judge on their key management to use them
>as an introducer. On the other hand (if you're able to make that judge-
>ment) then you've met already and the other key is already inside your
>keyring to be sure that your trust judgement is really valid for that
>person and not just for a key with the name of person you met before.

I beg to differ.  Suppose I do the search for D given that I trust A
(Continue reading)

Steve Schear | 23 Jul 1997 23:31
Picon

Re: Key search

Wolfgang Ley <ley <at> cert.dfn.de>, wrote:
>I don't know why this should be useful. In real life this won't help
>you because if you trust A's key and want to find a path to D then
>the only way would be "A has signed D". In all other case you have
>to trust the keys on the path (in your example B and C) to act as an
>introducer.

Phil mentioned, at the June 14th Cypherpunks meeting, that an upcoming
version of PGP will support introducers.

--Steve

Steve Schear | 23 Jul 1997 23:27
Picon

Subject line

It is obvious that descriptive email Subject lines can offer a potential
security leak, aiding traffic analysis and eavesdropping.  Therefore
cautious crypto emailers either leave this line blank, use a
non-descriptive header line, etc.

Might it be possible to add a feature to the PGP cyphertext body so email
plug-ins could save the Subject line in the cyphertext, blank the email
field during transit and restore its value after decryption at the
receiptient end?

--Steve

William H. Geiger III | 23 Jul 1997 22:53

Re: Subject line


In <v03102801affc26f9a959 <at> [10.0.2.15]>, on 07/23/97 
   at 04:27 PM, Steve Schear <azur <at> netcom.com> said:

>It is obvious that descriptive email Subject lines can offer a potential
>security leak, aiding traffic analysis and eavesdropping.  Therefore
>cautious crypto emailers either leave this line blank, use a
>non-descriptive header line, etc.

>Might it be possible to add a feature to the PGP cyphertext body so email
>plug-ins could save the Subject line in the cyphertext, blank the email
>field during transit and restore its value after decryption at the
>receiptient end?

This can be doen quite easily by the client software as follows:

Create message
sign message
encrypt message with final recipiant's public key
Create new message where old message is a multipart/encrypted attachment.

[New Header multipart/mixed]

  [message/rfc822]

    [application/pgp-encrypted]
    [application/octet-stream]

The only information in the header of the new message is that which is
need to deliver the message. After this new message has been created one
(Continue reading)

Charles Breed | 24 Jul 1997 00:24
Favicon

Re: Subject line

Steve,

Encryption of SUBJECT LINES: can be useful, this was discussed on the PGP/MIME mail list. To the best of my
knowledge, there was no definitive conclusion. I'll keep track of these requests. MUA should allow
user's to sort mail and view subject lines without requiring decryption, or automating the process.
User's should be smart enough not to make subject_lines too descriptive, however, any subject adds to
traffic analysis.

cb

At 02:27 PM 7/23/97 -0700, Steve Schear wrote:
>It is obvious that descriptive email Subject lines can offer a potential
>security leak, aiding traffic analysis and eavesdropping.  Therefore
>cautious crypto emailers either leave this line blank, use a
>non-descriptive header line, etc.
>
>Might it be possible to add a feature to the PGP cyphertext body so email
>plug-ins could save the Subject line in the cyphertext, blank the email
>field during transit and restore its value after decryption at the
>receiptient end?
>
>--Steve
>
>
>
>

Tay Beng Kuan Steven | 25 Jul 1997 16:16
Picon
Picon

digest mode

Hi all,

	How do I receive in digest mode.
--------
Tay Beng Kuan Steven  [ ICQ: 1423100 ]
Url : Http://web.singnet.com.sg/~taylc/
Email : taylc <at> mbox2.singnet.com.sg  /  bkuan <at> post1.com
PGP Key-ID 4036268D Send message to me with subject "send pgp" for key
Key fingerprint = 65 6F 50 EB 09 7B C7 83  96 7C F9 82 5F E5 5F F6


Gmane