Subject: Re: Principles and Principals
From: Pat Richard <[email-masked]>
To: "William H. Geiger III" <[email-masked]>
Cc: [email-masked]
Date: Fri, 26 Sep 1997 21:33:03 -0700

William H. Geiger III wrote:
> 
> :). Signatures on a blankID could be used to provide authority and
> would not be affected by changes to other userID's. 

These blank IDs are exactly what I was referring to in the previous
emails (tag-centric). On other mailing lists they have been discussed as
"meta-IDs", "meta-certs" (although that name has now been usurped by
another technology) and more typically "guids". :-)

In any case, William is correct, MIDs solve both the classic naming and
revocation problems inherent in many PKIs. In fact, some companies have
built their entire product infrastructures on this notion :-)

I think Jon is also in agreement here...

-- 
Pat Richard - [email-masked]
Public Key Available via LDAP
http://www.xcert.com

"Every information object known to modern man is a candidate for
PKI-based ACL" - Young Etheridge

Date: Fri, 26 Sep 1997 21:29:12 -0700
From: Pat Richard <[email-masked]>
To: Jon Callas <[email-masked]>
CC: [email-masked]
Subject: Re: Principles and Principals
Sender: [email-masked]

Jon Callas wrote:
> 
> At 03:28 PM 9/26/97 -0700, Patrick Richard wrote:
> 
>    Not necessarily if you use a non key-centric approach.
> 
>    [...]
> 
>    (not to stir up the semantic flames again)
> 
>    I know this is kind of semantic BS, but the above is not a
>    key-as-principal system (key-centric is another term used to
> describe
>    this). I was referring to key-centric systems when I stated that
>    "you can't solve revocation in a key-as-principal system".
> 
>    (supporting both 'revoked-key centric' and 'key-centric' means that
>    you are in actual fact supporting tagged-centric systems which
>    means that they aren't key-centric, they are tag-centric and that
>    the tags just happen to refer to keys :-))
> 
>    I guess this should all be taken with the original message in mind,
>    which was one in which a poster mentioned something like "wouldn't
>    it be great if the whole PKI was based on hashing someone's key"...
> 
> Sorry to turn the semantic BS table on you, Patrick, but what is the
> major
> problem, then? (insert smirk here) 

No, there is no problem. I was just doing some semantic clarification.

:-)

> I don't see how the problem is
> different
> for name-centric or key-centric systems. 

Name-centric systems have the "naming problem", key-centric have the
"revocation problem" (we already know all of this). I guess I am trying
to point this out for the benefit of those one the list who advocate in
favour of either DN-centric or key-centric systems. The best system is
neither: provide tags and map to solve both problems.

> I think we're in violent agreement here. 

Definitely. 

-- 
Pat Richard - [email-masked]
Public Key Available via LDAP
http://www.xcert.com

"Every information object known to modern man is a candidate for
PKI-based ACL" - Young Etheridge

Date: Fri, 26 Sep 1997 19:26:30 -0500
From: Peter Williams <[email-masked]>
To: Charles Breed <[email-masked]>
CC: [email-masked]
Subject: Re: 
Sender: [email-masked]

Charles,

Does the OpenPGP concept embrace key distribution techniques
other than certificate-based mechanisms, or mechanisms exploiting
asymmetric cryptography?

Date: Fri, 26 Sep 1997 17:16:33 -0700
To: Patrick Richard <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Principles and Principals
Cc: [email-masked]
Sender: [email-masked]

At 03:28 PM 9/26/97 -0700, Patrick Richard wrote:
   
   Not necessarily if you use a non key-centric approach.
   
   [...]
   
   (not to stir up the semantic flames again)
   
   I know this is kind of semantic BS, but the above is not a
   key-as-principal system (key-centric is another term used to describe
   this). I was referring to key-centric systems when I stated that
   "you can't solve revocation in a key-as-principal system".
   
   (supporting both 'revoked-key centric' and 'key-centric' means that
   you are in actual fact supporting tagged-centric systems which
   means that they aren't key-centric, they are tag-centric and that
   the tags just happen to refer to keys :-))
   
   I guess this should all be taken with the original message in mind,
   which was one in which a poster mentioned something like "wouldn't
   it be great if the whole PKI was based on hashing someone's key"...
   
Sorry to turn the semantic BS table on you, Patrick, but what is the major
problem, then? (insert smirk here) I don't see how the problem is different
for name-centric or key-centric systems. Perhaps this is because I really
don't see the difference on some level; I see a DN and a key fingerprint to
each be a binary string that is not my name. All the other stuff is just
falderal to check the validity of an assertion.

I think we're in violent agreement here. No one is saying tags aren't
important. No one is saying names aren't important. Furthermore, I haven't
heard anyone say they think that signed statements without names are a bad
idea. This is why 509 has attribute certs, as someone said before.

	Jon

-----
Jon Callas                                         [email-masked]
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 26 Sep 97 18:06:48 -0400
Subject: Re: Principles and Principals
To: [email-masked]
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

In <[email-masked]>, on 09/25/97 
   at 07:05 PM, Jon Callas <[email-masked]> said:

>At 11:05 PM 9/24/97 -0700, Patrick Richard wrote:

>   The major problem with 'key-principal' architectures is the
>   revocation problem.

>   When my key is revoked/changed/upgraded/whathaveyou all bindings
>   are lost.
>   
>I think the revocation problem is the major problem with *all*
>architectures. 
>   
>   If you develop a system that goes around this, then the key is
>   not the principal...
>   
>I disagree. One of the things that I want to see in PGP is an
>"I-used-to-be" certificate. With proper setup of one of those, you have a
>key-as-principal system, but delegation of authority with transfer of
>authority, it all flows.

Hi Jon,

I am not quit sure that I like this idea of "I-used-to-be" certificate.

If I sign John Doe's userID [email-masked] and he changes his userID to
[email-masked] do I really want my signature transfered to
this new ID?

Perhaps a better approach would be to have a signature block that just
signed the key but not any of the userID's. This in conjunction with the
UserID signatures would provide you with the best of both worlds:

[KeyBlock]
  [Signature]
  [Signature]
  [Signature]
[UserID]
  [Signature]
  [Signature]
  [Signature]
[UserID]
  [Signature]
  [Signature]
  [Signature]

The signatures on the keyblock could be used for key-as-principle based
system for providing key authority while signatures on the userID's would
be used are they are now as certification of "who" the key belongs to.

Hmmmm the more I think about this I see a way this could be implemented
without modifying the curent key structure by just using a blank userID
:). Signatures on a blankID could be used to provide authority and would not be affected by changes to other userID's. This need not be a "blank" userID but any standarized userID for the system it was intended to be used with.

As an example take an SSH aplication that makes use of PGP keys:

- -- The SSH app would use userID "SSH" as the Authorization userID.

- -- The SSHd would only accept public keys with the above userID that had
been signed with the servers private authorization key.

By using this approach several issues are addressed:

- -- The type/level of authorization can be determined by the contents of
the userID:

    -- userID "SSH" could be used to give home access while "SSH ROOT"
could be used to give root access.

    -- colision between multiple application using the same userID is not
a problem as the current key structure supports mulitple signatures per
keyID.

        -- [KeyBlock]
           [UserID]
             [Sig]
             [Sig]
           [UserID] "SSH"
             [Sig]  "SSHd Sig domain1.com"
             [Sig]  "SSHd Sig domain2.com"
           [UserID] "SSH ROOT"
             [Sig]  "SSHd Sig domain3.com"

    -- Provides the greatest flexability as the same key can be used with
numerious aplications.

Of cource their is the question of wether a user would want to use one key
for all aplications. While it would provide the ease of having only one
key to manage it presents several issuse such as increase of keysize and
exposure of sensitive data (user is running SSH, SHTML, ...). These are
relativly minor issues that can be addressed by using multiple keys.

As far as revoked keys or "upgraded" keys I really see no easy solution.
Once the key itself (not userID's) changes one really needs to go through
the authorization process again.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------1

From: Patrick Richard <[email-masked]>
Subject: Re: Principles and Principals
To: [email-masked] (Jon Callas)
Date: Fri, 26 Sep 1997 15:28:09 -0700 (PDT)
Cc: [email-masked]
Sender: [email-masked]

Jon Callas wrote :
>    
> I think the revocation problem is the major problem with *all* architectures. 

Not necessarily if you use a non key-centric approach.

>    
>    If you develop a system that goes around this, then the key is
>    not the principal...
>    
> I disagree. One of the things that I want to see in PGP is an
> "I-used-to-be" certificate. With proper setup of one of those, you have a

(not to stir up the semantic flames again)

I know this is kind of semantic BS, but the above is not a
key-as-principal system (key-centric is another term used to describe
this). I was referring to key-centric systems when I stated that
"you can't solve revocation in a key-as-principal system".

(supporting both 'revoked-key centric' and 'key-centric' means that
you are in actual fact supporting tagged-centric systems which
means that they aren't key-centric, they are tag-centric and that
the tags just happen to refer to keys :-))

I guess this should all be taken with the original message in mind,
which was one in which a poster mentioned something like "wouldn't
it be great if the whole PKI was based on hashing someone's key"...

Date: Fri, 26 Sep 1997 13:33:52 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Sender: [email-masked]

  The posting with regards to the Open-PGP working group was in error.
  This was a draft release and should not have been sent out. There are
  still a few steps required before the Working Group can be announced.
  The quotes in the draft release were not approved by their respectful 
  owners.

  Charles

Date: Fri, 26 Sep 1997 12:34:49 -0700
To: Charles Breed <[email-masked]>
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: recent article 
Cc: [email-masked]
Sender: [email-masked]

At 11:56 AM 9/26/97 -0700, Charles Breed wrote:
>jazzy release. What's the big deal? Open-PGP is an IETF thing, NOT a PGP,
>Inc. thing. And this list is for Open-PGP IETF dialog.

	Charles, as a matter of well-established and strongly enforced IETF
policy, IETF mailing lists are prohibited from carrying explicitly
commercial content.  No product touting and no vendor touting.  It's part
of the reason for giving attendees from Marketing so much grief.  Press
releases touting a particular company do not constitute a marginal case,
even when the press release also discusses IETF activities.

d/
--------------------
Dave Crocker                                          [email-masked]
Internet Mail Consortium                               +1 408 246 8253
675 Spruce Dr.                                    fax: +1 408 249 6205
Sunnyvale, CA 94086 USA               [email-masked], http://www.imc.org

Member, interim Policy Oversight Committee     http://www.gtld-mou.org

To: Charles Breed <[email-masked]>
Cc: [email-masked]
Subject: Re: recent article 
Date: Fri, 26 Sep 1997 15:05:21 -0400
From: Bill Sommerfeld <[email-masked]>
Sender: [email-masked]

Most of us IETF'ers are engineers interested in content, not
presentation.  We're allergic to jazzy press releases which try to put
a spin on routine actions of the IESG.

As I understand the IETF process, the creation of the working group is
neither a necessary nor a sufficient condition for the protocols in
PGP to be put on the IETF standards track..

					- Bill

Date: Fri, 26 Sep 1997 11:56:51 -0700
To: Bill Sommerfeld <[email-masked]>
From: Charles Breed <[email-masked]>
Subject: Re: recent article 
Cc: [email-masked]
Sender: [email-masked]

Dear Bill,

Instead of retyping a bland message that informs all of us that the IESG
approved Open-PGP as an 'official' IETF Working Group, I just sent the more
jazzy release. What's the big deal? Open-PGP is an IETF thing, NOT a PGP,
Inc. thing. And this list is for Open-PGP IETF dialog.

Cheers,
Charles

At 02:44 PM 9/26/97 -0400, Bill Sommerfeld wrote:
>[retransmit as I botched the CC: the first time around]
>
>Is this the IETF Open PGP working group, or the PGP, Inc,
>press-release distribution list?
>
>for what it's worth, none of the other working groups I read regularly
>get press-release-type postings..
>
>			Just checking,
>
>				- Bill
>
>

To: Charles Breed <[email-masked]>
Cc: [email-masked]
Subject: Re: recent article 
Date: Fri, 26 Sep 1997 14:44:17 -0400
From: Bill Sommerfeld <[email-masked]>
Sender: [email-masked]

[retransmit as I botched the CC: the first time around]

Is this the IETF Open PGP working group, or the PGP, Inc,
press-release distribution list?

for what it's worth, none of the other working groups I read regularly
get press-release-type postings..

			Just checking,

				- Bill

Date: Fri, 26 Sep 1997 10:55:09 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: recent article
Sender: [email-masked]

                     by Simson Garfinkel 
                     4:59am  26.Sep.97.PDT Cracking encrypted email  just
                     got much easier - as long as the message was
                     encrypted with Netscape Navigator or Microsoft's
                     Outlook Express. 

                     Bruce Schneier, a cryptography consultant based
                     in Minnesota, has created a Windows 95
                     screensaver that cracks encrypted email
                     messages on computers that are otherwise
                     unused. "On average, it takes 35 days on a 166
                     MHz Pentium," said Schneier, who is also the
                     author of the book Applied Cryptography. 

                     The real power of Schneier's program is that it's
                     designed to work on multiple machines in parallel
                     over a local-area network. Got an office with a
                     dozen machines? You can crack a message in a
                     little less than three days. Got a thousand? Your
                     wait will be just 50 minutes. The program, which
                     began as a screensaver that searched for large
                     prime numbers, will be made available on
                     Schneier's Web site today. 

                     The program will only crack messages encrypted
                     with RSA Data Security's S/MIME mail encryption
                     standard, and at that, only messages that are
                     encrypted with a 40-bit key. But that's exactly  the
                     encryption that's being offered today by the most
                     commonly used versions of Netscape Messenger
                     and Microsoft Outlook Express. 

                     "What really pisses me off is that [these  products]
                     are being marketed as secure," said Schneier.
                     "The products don't say that they use 40-bit
                     encryption - be careful. They say this is security." 

                     The S/MIME standard implemented by Netscape
                     and Microsoft does provide for higher-level security
                     by using different encryption algorithms. But
                     Schneier maintains that messages encrypted with
                     these stronger algorithms cannot be exchanged
                     between the two vendors' products. "The S/MIME
                     security standard is really hard to work with," said
                     Schneier. "None of [the products] interoperate at
                     any level other than 40-bit RC2." 

                     Schneier says he's releasing his program to
                     demonstrate the fundamental vulnerabilities in the
                     S/MIME standard. But S/MIME's maker
                     disagrees, saying there is no problem using longer
                     keys. 

                     "Bruce is mistaken," said Scott Schnell, vice
                     president of marketing for RSA Data Security, the
                     co-author of the S/MIME specification. "We have
                     mail messages on file in our interoperability test
                     lab which demonstrate interpretability between
                     Outlook Express and Netscape's Messenger
                     using triple-DES," which has a 168-bit key. 

Courtney Macavinta 
Reporter || www.news.com || CNET: The Computer Network
p (415) 395-7805 x5218                                    
f  (415) 395-9254

Date: Fri, 26 Sep 1997 10:53:51 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: Working Group announcement
Sender: [email-masked]

"OPEN-PGP" APPROVED FOR STANDARDS TRACK BY INTERNET ENGINEERING TASK FORCE

Working Group formed to pave worldwide protocol for secure communication

SAN MATEO, Calif. (Sept. 25, 1997) -- In a milestone decision for the
standardization of secure electronic communications worldwide, the Internet
Engineering Steering Group today unanimously approved the formation of an
official IETF (Internet Engineering Task Force) Working Group to develop a
secure email specification called "Open-PGP."   The proposed Open-PGP
standard will build on Pretty Good Privacy, Inc.'s (PGP) encryption
technology, which already is used by millions of individuals around the globe.

To facilitate an international standard and promote growth of the Internet,
as well as related industries worldwide, PGP released change-control of its
technology to the Internet Society (ISOC), and the Internet Engineering
Steering Group (IESG).

"As the IETF Security Area Director, I'm very pleased that PGP Inc. yielded
change control to the standards body," said Dr. Jeff Schiller, manager of
Computer Services at MIT. "MIT has been a proponent of PGP from the very
start -- in 1991, MIT distributed the first non-commercial version of PGP
for free, and since then, has been hosting the public key (certificate)
server for worldwide access," he said.

Phil Dunkelberger, president of PGP, said, "This development is in keeping
with PGP's commitment to protecting security of business and personal
communications, and our founding principal of the universal right to
privacy.  We've never been interested in industry domination at the expense
of the users."

According to Charles Breed, director of security technology, PGP, and
co-chair of the IETF Working Group, "Despite the industry's reputation for
aggressive competition, there was unilateral support when Open-PGP was
first proposed at the Munich IETF meeting a month ago.  More than 150
people representing US companies were present, as well as businesses from
Singapore, Japan, the UK and Europe."

"Open-PGP" will tackle a major obstacle to the growth of the Internet,
plagued at present by policy and technical incompatibilities from country
to country.  The proposed standard is an unencumbered, non-proprietary
specification that will guarantee interoperability of encrypted and
digitally signed messages, and provide strong encryption and
non-repudiation with  digital signatures. Open-PGP will be developed by a
consortium of experts, using technology that has provided privacy to
Internet email and electronic files since 1991 in products from more than
80 manufacturers worldwide. The Open-PGP specification will be available
for peer and public review as it develops.

Alternative proposals that have failed in the past, such as PEM (Privacy
Enhanced Mail), MOSS (MIME object Security Systems) and most recently,
S/MIME (Secure MIME from RSA), depended on complex infrastructures or were
encumbered by legal patents, royalties, and export restrictions forcing the
use of weak encryption practices.

"I expect the Open-PGP specification will progress quickly, because it's
well understood, simple and our mailing list on the topic suggests it has a
great deal of vendor support already.  It has all the elements for a
comprehensive solution: trust models, certificate infrastructure, encoding
rules, securing MIME and the cryptographic algorithms," said Paul Hoffman,
director of the Internet Mail Consortium (IMC), a non-profit organization
that promotes the growth of Internet protocols. 

"Open-PGP applications will be easy for corporations and individuals to
use, and will be based on strong, freely available, well-known
cryptographic techniques that are the foundation of PGP's technology," said
John Noerenberg, senior development manager at Qualcomm's Eudora Division.
"Eudora is the top-selling Internet mail application and our users are very
pleased with the PGP-based security component." 

For more information about Open-PGP or subscribe to the IMC mail list,
visit the IMC worldwide web site at http://www.ietf-open-pgp.imc.org.

About PGP
San Mateo-based, Pretty Good Privacy, Inc. (PGP), is the pioneer and
worldwide de facto standard for business security and personal privacy,
with an estimated four million users of its encryption products, including
more than half of the Fortune 100 companies.  PGP is committed to providing
the most advanced security products for the digital age, safeguarding the
communication and storage of information.  For more information, visit our
website at http://www.pgp.com.

Contact: Robin Rootenberg/Monika Madrid
Access Communications
1-800-393-7737 ext. 282/227
[email-masked]/[email-masked]

Date: Fri, 26 Sep 97 00:06:36 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: Re: Principles and Principals
Sender: [email-masked]

> From: "Bonatti Chris" <[email-masked]>
>      This was one of the reasons that the attribute certificate
> emerged in X.509.  (There were other reasons too.)  It allowed a
> wide range of this "non-principal" binding data to be abstracted
> from the main structure.

Yes, this capability "tag" model is also the heart of SPKI.
Certification tags are signed separately.  The principal stays the same.

>      There is great strength in this kind of modularity.  We
> should consider this concept in Open-PGP.
>
PGP already has this modularity.  Each username is signed separately.
A particular username signature can be separately expire or be revoked.
The fields are all there!

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
[email-masked]
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Date: Thu, 25 Sep 1997 17:05:57 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Principles and Principals
Sender: [email-masked]

At 11:05 PM 9/24/97 -0700, Patrick Richard wrote:

   The major problem with 'key-principal' architectures is the
   revocation problem.

   When my key is revoked/changed/upgraded/whathaveyou all bindings
   are lost.
   
I think the revocation problem is the major problem with *all* architectures. 
   
   If you develop a system that goes around this, then the key is
   not the principal...
   
I disagree. One of the things that I want to see in PGP is an
"I-used-to-be" certificate. With proper setup of one of those, you have a
key-as-principal system, but delegation of authority with transfer of
authority, it all flows.

	Jon

-----
Jon Callas                                         [email-masked]
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

From: Patrick Richard <[email-masked]>
Subject: Re: Principles and Principals
To: [email-masked]
Date: Thu, 25 Sep 1997 15:18:34 -0700 (PDT)
Cc: [email-masked]
Sender: [email-masked]

Bonatti Chris wrote :
> 
>      There is great strength in this kind of modularity.  We 
> should consider this concept in Open-PGP.

Yup. 

or have the facility to have multiple principals in a single
infrastructure by using attribute<->signature bindings delivered by a 
'trusted' source (i.e. (over-simplified, no flames please) in
SDSI the trusted source is one's self, or one's friend, in X.509
the trusted source is the attribute CA, in PGP everyone is a
possible trusted source) where you treat the keys
as well as the namespace as possible attributes.

This is analagous to the notion that all a CA does is bind namespace...

Anyhow, 

> 
> Chris
> 
> 

-Pat

--
[email-masked]
Public Key Available via LDAP
http://www.xcert.com

Comments: Authenticated sender is <ieca2@[205.252.27.1]>
From: "Bonatti Chris" <[email-masked]>
Organization: IECA, Inc.
To: Patrick Richard <[email-masked]>
Date: Fri, 26 Sep 1997 00:14:15 +0100
Subject: Re: Principles and Principals
Reply-to: [email-masked]
CC: [email-masked]
Sender: [email-masked]

On Wed, 24 Sep 1997 23:05:30 -0700 (PDT), Patrick Richard <[email-masked]> wrote:

> Ian Brown wrote :
> > > The PGP public-key is the principal.
> > > 
> > ...
> > 
> > I think this is a great way to look at it. Using the public key, its
> > hash or fingerprint as *the* DN allows all sorts of important
> > functionality like authorisations.
> 
> The major problem with 'key-principal' architectures is the
> revocation problem.
> 
> When my key is revoked/changed/upgraded/whathaveyou all
> bindings are lost.

Pat,

     This is certainly not a major problem in the environments 
with which I am most familiar.  Certificate revokation (due to 
invalidation of one of the pieces of information bound into 
the certificate) is far more common than key revokation (due to 
loss or compromise of the key).  The former occurs when jobs, 
mailboxes, roles, or sometimes even authorizations change.  This 
happens at a much higher rate than key loss.

     The only real way to mitgate this is to bind very little to 
the key.  However, this gives up much of the value that the 
certificate offers.

     This was one of the reasons that the attribute certificate 
emerged in X.509.  (There were other reasons too.)  It allowed a 
wide range of this "non-principal" binding data to be abstracted 
from the main structure.  This help to facilitate separate 
certificates for various functions.  Thus you can have one cert 
that just binds permanent info like a name or perhaps a 
lifetime identification (i.e., SSN) number to a key.  Other 
certificates containing info of a less permanent nature 
(i.e., organizational affiliations, authorizations, e-mail 
addresses) could then be revoked without destroying the user's 
cryptographic identity.

     There is great strength in this kind of modularity.  We 
should consider this concept in Open-PGP.

Chris

 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti                 9010 Edgepark Road  |
 |  Vice-president                     Vienna, Virginia 22182  |
 |  [email-masked]   Tel: 301-212-9428   Fax: 703-506-8377  |
 |  PGP public key available from "http://www.ieca.com/"       |
 ---------------------------------------------------------------

Date: Thu, 25 Sep 1997 10:40:48 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: Hal Finney <[email-masked]>
CC: [email-masked]
Subject: Re: Principles and Principals
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

> One problem with [DNSSEC] is that the administrator may not be trustworthy,
> and/or that there may be too many users for the administrator to
> adequately check identity.  I don't know how many domain names there are,
> probably hundreds of thousands.  The administrator of .com is going to
> have a big job making sure that every tom-dick-and-harry.com has the right
> key registered.  Likewise it may be easy in some cases to persuade a
> low-level DNS administrator to put out a fake key.

Perhaps one way to reduce this problem would be to encourage high-level
zones such as .com, .net etc. to act as Policy Certificate Authorities
where they will only certify keys of organisations that agree to observe
certain standards such as how rigorous user checks are (see
http://www.cs.ucl.ac.uk/research/ice-tel/policy.html for an example)?

Ian :D

Date: Thu, 25 Sep 1997 10:26:08 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: Hal Finney <[email-masked]>
CC: [email-masked]
Subject: Re: Principles and Principals
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

> DNSSEC is better than nothing, but it is no substitute for key
> certifications by people you know and trust.
 
Absolutely. I'm just not sure how well the system can scale further than
people you know and trust. While the technology is there to do very
complex trust webs, incorporating large and small-scale CAs as well as
friends, I think the human concept of 'trust' is stretched a little by
this. SPKI is quite elegant in the way that all key trust is local; in
practice, I rarely currently find a key with a trusted certification
path to it. And that's in the rather incestuous Internet community. Once
significant percentages of the world's population are on-line, it could
all become horribly complex. I agree that the current PGP model is great
for guerilla groupings. I just wonder how good it will be for thousands
of millions of people who may want to write to (say) an address on a Web
page, or reply to a message on a mailing list - i.e. communicate with
someone entirely as a virtual entity rather than a physical one. There,
I think DNSSEC can be a big help, although of course not a panacea.

However, my main point is about distributing keys, not certifying
them...

> We looked into putting PGP certificates into the DNS as an alternative...
> You still have the reverse lookup problem

Might the IETF draft 'The DNS Inverse Key Domain'
(ftp://ietf.org/internet-drafts/draft-ietf-dnssec-in-key-00.txt) help
with this? However, if we set up an e-mail-only keyserver system, people
will always know the e-mail address of the sender. As I said, I'm not
sure if I can see many other situations where it is more efficient to
set up a full-scale key distribution system rather than simply supply
the relevant public key certificate along with a signed object.

> at this point it looks like LDAP and HTTP are more
> promising approaches for key distribution.

How are you planning to create a distributed system with this approach?
With a similar system to PGP5, putting an X key lookup header in a
message?

Ian >:)

Date: Wed, 24 Sep 1997 23:19:11 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Bill Frantz <[email-masked]>
Subject: Re: stego support
Sender: [email-masked]

At 12:46 PM -0700 9/24/97, Adam Back wrote:
>For an RSA encrypted key packet the encrypted value is less than N,
>the recipients RSA modulus by definition.  That is the RSA encrypted
>session key will be in the range 0..N-1.  That's not uniform.  An
>opponent seeing lots of otherwise "stealthed" messages would be able
>to accumulate this leaked information and reduce the plausible
>deniability of the covert correspondents.

Of course the value does not have to be less than N.  If the value is V,
then the transmitted value could be xN+V for any integer x.  The receiver
can do the modular reduction.

-------------------------------------------------------------------------
Bill Frantz       | Internal surveillance      | Periwinkle -- Consulting
(408)356-8506     | helped make the USSR the   | 16345 Englewood Ave.
[email-masked] | nation it is today.        | Los Gatos, CA 95032, USA

From: Patrick Richard <[email-masked]>
Subject: Re: Principles and Principals
To: [email-masked] (Ian Brown)
Date: Wed, 24 Sep 1997 23:05:30 -0700 (PDT)
Cc: [email-masked]
Sender: [email-masked]

Ian Brown wrote :
> > The PGP public-key is the principal.
> > 
> ...
> 
> I think this is a great way to look at it. Using the public key, its
> hash or fingerprint as *the* DN allows all sorts of important
> functionality like authorisations.

The major problem with 'key-principal' architectures is the
revocation problem.

When my key is revoked/changed/upgraded/whathaveyou all bindings
are lost.

If you develop a system that goes around this, then the key is
not the principal...

Just my $0.02

-Pat
---
[email-masked]
Public Key available via LDAP
http://www.xcert.com

Comments: Authenticated sender is <ieca2@[205.252.27.1]>
From: "Bonatti Chris" <[email-masked]>
Organization: IECA, Inc.
To: Ian Brown <[email-masked]>
Date: Wed, 24 Sep 1997 22:10:56 +0100
Subject: Re: Principles and Principals
Reply-to: [email-masked]
CC: [email-masked]
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 24 Sep 1997 16:47:15 +0100 Ian Brown <[email-masked]> wrote:

> Sorry, I didn't answer this explicitly enough. I did not mean
> that e-mail addresses should not be included in certificates. I
> was merely agreeing with (I think) Charles Breed or Jon Callas
> that a certificate shouldn't HAVE to include an address. This
> would make it difficult for a system-wide distributed keyserver
> scheme as you then need some other method to look up a key. An
> e-mail only keyserver scheme is fine, however; keys which are
> intended for use by e-mail can be certified, and looked up
> using their address as a hint where to go for the lookup. I'm
> not sure if there's enormous need for keyservers in areas not
> related to the DNS.

Okay, I guess I was reading too much into what you said.  I
would also concur that an "e-mail address" should not be a
mandatory part of a certificate.  However, I think that the
converse IS a requirement.  To wit, if you DO use the key for an
e-mail address, then it needs to be bound to the key.  This is
probably true for identifying names or addresses in other
potential PGP applications for which I cannot speak
definitively.  Does anybody else have some useful examples to
contribute?

> Which is what DNSSEC would allow; the domain of the e-mail
> address would certify (not directly within the certificate, but
> by providing the key as a trusted domain) that it at least
> believes the stated key belongs to the stated address. Which is
> a good start, and perhaps all that is necessary for the
> majority of correspondence between strangers.

This, however, I think misses the point a little.  Even if we
leave hierarchical certification out of the discussion, when I
download a PGP key, I'd really like to be able to verify the
signatures of various vouching parties.  I single integrity
check from a faceless service provider (who with DNSSEC
would not be MY service provide) carries a lot less weight than
the signature from a key that I already trust.  Who knows what
their local identity or key verification procedures are?

This is not to say that that DNSSEC is valueless.  I think the
DNS could be used quite well for this.  However, there are
probably at least as many political barriers as there are
technical issues involved in using the DNS for this.  (Probably
more, in fact.)  A lot of folks automatically rebel at any
suggestion or a new use for the DNS; although I am not one of
these.  :-)

Also, you need to consider the situation where the DNS
maintainer has relatively little control over the e-mail
addresses in a particular domain.  My domain, for instance,
makes fairly heavy use of wildcard MX records.  This allows
our company a lot of flexibility without having to maintain
our own full time servers.  My service provider maintains these
DNS entries, but has no way to verify what e-mail addresses
we are publishing and using.  From their point of view,
they don't associate the address to the mailbox until a
message hit the queue.  I think this style of usage is on the
rise because of the increased number of virtual domain in use on
the Internet.

I hope this helps!

Chris

 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti                 9010 Edgepark Road  |
 |  Vice-president                     Vienna, Virginia 22182  |
 |  [email-masked]   Tel: 301-212-9428   Fax: 703-506-8377  |
 |  PGP public key available from "http://www.ieca.com/"       |
 ---------------------------------------------------------------

Date: Wed, 24 Sep 1997 20:23:06 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Subject: non-transferable signatures
Sender: [email-masked]

Now that the rush is off for PGP getting pgp 3.0 lib out, perhaps I
could repeat my rant and generate some interest amongst the PGP Inc
people in thinking about adding support for a couple of privacy
features.

Transferable non-repudiation is actually not usually a desirable
property for digital signatures from a grass roots privacy point of
view.  All you really want is for the person receiving your mail to be
convinced that it came from you.  This does not mean that you would
like your recipient to be able to reveal your email to any third
parties and prove to them also that you wrote it.

(Note, to make clear we are talking about the same thing, some people
call non-transferable signatures "repudiable signatures".)

The transferability of non-repudiation is not in the interests of the
author of an email.  Say you express some unpopular opinions on a
mailing list, or in what you thought was private email, you probably
don't want people who are trying to cause trouble for you to be able
to prove to a high degree of confidence that you authored the disputed
content.

Examples might be that you made some extremely negative comments on
GAK, or opined that you wouldn't be that upset if a nuke took out
washington DC, or that someone posted some private email that you
would have preferred was not made public.  

The situation also arises in companies, where it is not a that
uncommon situation that an off the cuff comment made in email has come
back to haunt the company, when the recipient's company takes the
email and uses it as a basis for a court suit.

With a non-transferable digital signature, you would use
non-transferable signatures for normal email, and only use
transferable email if you particularly wanted to make a legally
binding statement.

Non-transferable email for maximum deniability of authorship should
really be delivered via remailers, otherwise mail logs by third
parties, or of the sending parties may be used to attempt to prove
authorship.

Here's a way to do non-transferable signatures with RSA:

Alice sending Bob a signed email.  We want:

        ( X ^ A_pub ) xor ( Y ^ B_pub ) = hash( message )

Alice chooses random Y, and computes X:

        X = [ ( Y ^ B_pub ) XOR hash( message ) ] ^ A_pri

Now the non-transferable digital signature is X and Y.

To verify the signature the recipient checks that:

        X ^ A_pub XOR Y ^ B_pub = hash( message )

The signature is not transferable because Bob could also produce that
same signature with knowledge of B_pri, for Bob X is a random number,
and Y is calculated:

        Y = [ ( X ^ A_pub ) XOR hash( message ) ] ^ B_pri

(I would put in an acknowledgement here with the algorithm, but I'm
not sure the acknowledgee would thank me, re ITAR/EAR).

There are a couple of technicalities with the above method:

i) You have two parts to the message X and Y, you would want to place
these packets in random order.  Or at least allow the software to put
them in the other order.  (If author comes first always, there is less
deniability).

ii) You should choose Y to be in the range 0..B_pub - 1, otherwise you
leak information about who the author is.  The more signatures the
less deniability you have left as the information is accumulated.

iii) You need to decide some padding rules to cope with different
sized keys.

Creating a non-transferable DSS signature is left as an exercise for
the reader :-)

That is I can't see an easy way to do it right now.

Also it's going to be harder to design a protocol to allow one to
create a non-transferable signature where Alice has a DSS key and Bob
an RSA key.

Next post is another old rant about building in stego support.

Adam
--
Now officially an EAR violation...
Have *you* violated EAR today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

Date: Wed, 24 Sep 1997 20:46:08 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Subject: stego support
Sender: [email-masked]

Here is my second rant, this one about another highly desirable
privacy feature: stego support built-in to PGP.

It would be useful to build into PGP support for messages which can be
plausibily claimed are random numbers.

There are lots of reasons a PGP message is not a random number.  The
obvious reasons are that it says "-----BEGIN blah" at the top, but
readers familiar with the packet formats will also know that even with
out that boiler plate there are constants in the text which inform the
recipient's PGP what type of message it is, how long the message is,
etc.

Someone with a nym of "Henry Hastur" wrote an application called
"stealth", it is utility which removes all this boiler-plate from PGP
2.x messages.

However there is another less obvious problem with PGP messages, they
have bias in signature and public key encrypted packets in the crypto
values.

For an RSA encrypted key packet the encrypted value is less than N,
the recipients RSA modulus by definition.  That is the RSA encrypted
session key will be in the range 0..N-1.  That's not uniform.  An
opponent seeing lots of otherwise "stealthed" messages would be able
to accumulate this leaked information and reduce the plausible
deniability of the covert correspondents.

Similar biases will be leaked by El Gamal (note terminology "PGP uses
DH" people) in that components will be less than the public prime
modulus.

Stealth 2.x fixes this problem for RSA encrypted messages with a
stealth normalisation transform designed by Hal Finney.

Stealth 2.x is at:

	http://www.dcs.ex.ac.uk/~aba/stealth/

The algorithm is described on Hal's pages at:

	http://www.rain.org/~hal/ I think.

The implementation of the algorithm is described in the source code
distribution for stealth2.

There are some restrictions with stealthing PGP packets.  It seems
like a waste of time to try to code the stealth transformations for
keyring packets, trust packets, signature packets, etc.  Anything like
that belongs inside the encryption envelope, otherwise you haven't got
plausible deniability anyway, as stealth transformations are
reversible by third parties, you don't want any plaintext sticking
out.

So if we restrict ourselves to encrypted packets, the remaining
problem is multiple crypto-recipients.

One ugly inefficient suggestion is that the largest public key block
is going to be 1024 bytes (right? 4096 bit El Gamal encrypted key
packet).  So you could code each stealthed public key encrypted packet
as 1k (+stealth transform expansion), and when you are trying to
decrypt, you try the first x blocks where x is the maximum number of
multiple recipients you think you are likely to see.

Then, once you've found a block encrypted to you, you try decrypting
at 1024 byte boundaries until you find the begining of the symmetric
cipher encrypted block.

(Once you've done that there will be an internal length count inside
that encrypted block, so you could then figure out if there are other
pgp packets after this block, and process them).

The other simpler option is just not to cope with multiple
crypto-recipients for stealthed messages.

Once you've got that lot built in to PGP, you have all you need to
build steganography applications.  And you can always fall back to
mailing what are ostensibly hex encoded random numbers if the GAKkers
succeed in legislating mandatory GAK in your country.

Adam
-- 
Now officially an EAR violation...
Have *you* violated EAR today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

Date: Wed, 24 Sep 97 16:59:22 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: Re: Principles and Principals
Sender: [email-masked]

> From: "Bonatti Chris" <[email-masked]>
> This is a good approach, although by itself it does not address
> the totality of the e-mail requirement.  You still need some way
> to bind the e-mail address to the key.  Whatever the principal
> is, this is a function that's got no better place to roost than
> the public key infrastructure.
>
Yes.  See the SPKI requirements.

> > I think this is a great way to look at it. Using the public
> > key, its hash or fingerprint as *the* DN allows all sorts of
> > important functionality like authorisations. E-mail is probably
> > the most widespread use of PGP at the moment, but can be
> > considered separately. E-mail users in effect can state to the
> > world (via keyservers) that their public key 'speaks' for a
> > certain address (to use SPKI lingo). So, if a key is to be used
> > for e-mail, it must contain such a 'tag' with an e-mail
> > address. If not, no problem.
>
> Unless I misunderstand you, the e-mail address is not then bound
> into the certificate structure.

You misunderstand.  When used for email, the email address is signed
as part of the certificate.

The email address is a "tag", signed by the principal (and other
introducers).  Think of it as a URI.  It says where to look for the key.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
[email-masked]
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Date: Wed, 24 Sep 1997 10:20:15 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: RE: Principles and Principals
Sender: [email-masked]

As far as validating email addresses, DNSSEC is an alternative to the PGP
web of trust model.  It basically uses a hierarchical key certification
structure based on the DNS hierarchy.  The idea is that the administrator
of pgp.com would be in the best position to validate addresses within that
domain, like [email-masked].

One problem with this is that the administrator may not be trustworthy,
and/or that there may be too many users for the administrator to
adequately check identity.  I don't know how many domain names there are,
probably hundreds of thousands.  The administrator of .com is going to
have a big job making sure that every tom-dick-and-harry.com has the right
key registered.  Likewise it may be easy in some cases to persuade a
low-level DNS administrator to put out a fake key.

DNSSEC is better than nothing, but it is no substitute for key
certifications by people you know and trust.

We looked into putting PGP certificates into the DNS as an alternative, so
that you would use DNS to find the keys (given an email address) but that
the keys could have other signatures on them (possibly in addition to the
DNSSEC domain signature).  You still have the reverse lookup problem (finding
key given keyid), and at this point it looks like LDAP and HTTP are more
promising approaches for key distribution.

Hal Finney
[email-masked]
[email-masked]

From: Rik Drummond <[email-masked]>
To: "'Ian Brown'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Principles and Principals
Date: Wed, 24 Sep 1997 10:52:02 -0500
Sender: [email-masked]

I agree with your last statement.  Thanks Rik

-----Original Message-----
From:	Ian Brown [SMTP:[email-masked]]
Sent:	Wednesday, September 24, 1997 10:47 AM
To:	Rik Drummond
Cc:	[email-masked]'; [email-masked]
Subject:	Re: Principles and Principals

-----BEGIN PGP SIGNED MESSAGE-----

Chris Bonatti wrote:

> Unless I misunderstand you, the e-mail address is not then bound
> into the certificate structure.  I'm reading out of what
> your last couple of messages that we would submit the e-mail
> address as an submission argument to the keyserver, but that
> this would be absent from the certificate.

Sorry, I didn't answer this explicitly enough. I did not mean that
e-mail addresses should not be included in certificates. I was merely
agreeing with (I think) Charles Breed or Jon Callas that a certificate
shouldn't HAVE to include an address. This would make it difficult for a
system-wide distributed keyserver scheme as you then need some other
method to look up a key. An e-mail only keyserver scheme is fine,
however; keys which are intended for use by e-mail can be certified, and
looked up using their address as a hint where to go for the lookup. I'm
not sure if there's enormous need for keyservers in areas not related to
the DNS.

Rik Drummond wrote:

> The email address must be tightly bound in the cert so that spoofing
> is not possible.

Which is what DNSSEC would allow; the domain of the e-mail address would
certify (not directly within the certificate, but by providing the key
as a trusted domain) that it at least believes the stated key belongs to
the stated address. Which is a good start, and perhaps all that is
necessary for the majority of correspondence between strangers.

Ian.

Date: Wed, 24 Sep 1997 16:47:15 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: Rik Drummond <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Principles and Principals
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Chris Bonatti wrote:

> Unless I misunderstand you, the e-mail address is not then bound
> into the certificate structure.  I'm reading out of what
> your last couple of messages that we would submit the e-mail
> address as an submission argument to the keyserver, but that
> this would be absent from the certificate.

Sorry, I didn't answer this explicitly enough. I did not mean that
e-mail addresses should not be included in certificates. I was merely
agreeing with (I think) Charles Breed or Jon Callas that a certificate
shouldn't HAVE to include an address. This would make it difficult for a
system-wide distributed keyserver scheme as you then need some other
method to look up a key. An e-mail only keyserver scheme is fine,
however; keys which are intended for use by e-mail can be certified, and
looked up using their address as a hint where to go for the lookup. I'm
not sure if there's enormous need for keyservers in areas not related to
the DNS.

Rik Drummond wrote:

> The email address must be tightly bound in the cert so that spoofing
> is not possible.

Which is what DNSSEC would allow; the domain of the e-mail address would
certify (not directly within the certificate, but by providing the key
as a trusted domain) that it at least believes the stated key belongs to
the stated address. Which is a good start, and perhaps all that is
necessary for the majority of correspondence between strangers.

Ian.

From: Rik Drummond <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Ian Brown <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Principles and Principals
Date: Wed, 24 Sep 1997 10:07:31 -0500
Sender: [email-masked]

-----Original Message-----
From:	Bonatti Chris [SMTP:[email-masked]]
Sent:	Tuesday, September 23, 1997 4:51 PM
To:	Ian Brown
Cc:	[email-masked]
Subject:	Re: Principles and Principals

-----BEGIN PGP SIGNED MESSAGE-----

[>>]  snip........ 
Unless I misunderstand you, the e-mail address is not then bound
into the certificate structure.  I'm reading out of what
your last couple of messages that we would submit the e-mail
address as an submission argument to the keyserver, but that
this would be absent from the certificate.  This is pretty weak
in the sense that it is dirt simple for a black-hat to assert a
bogus e-mail address (or worse usurp a real one) and provide his
own black-hat key ID.  This leaves open a lot of possibilities
for misuse.

I agree with the above. The email address must be tightly bound in the cert so that spoofing is not possible.

regards, rik[>>]  

[>>]  snip....

Date: Wed, 24 Sep 1997 14:48:36 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: [email-masked]
CC: [email-masked]
Subject: Re: Principles and Principals
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

> You still need some way
> to bind the e-mail address to the key.

I think this is where DNSSEC would be enormously useful, by allowing
trusted DNS-based lookups of public keys. We can leverage the work done
by domains in setting up trust networks to get trusted PGP public keys.

> I should think that we at least have to have the ability for
> 3rd party certifications of the public key have the ability to
> bind over the key ID and e-mail address

Of course - it's just that, an Internet-wide WoT could become enormously
unwieldy without some form of structure imposed. The DNS is already
there, so would be an ideal candidate.

> If I am misrepresenting what you propose, please set me
> straight.

I think I just proposed it in a confused way :-) My main point was that
e-mail is an important part, but not the totality, of what we want to do
with PGP. I think the keyserver system is something that is very
appropriate for e-mail, but in other circumstances such as providing
authorisations it would be better for the user to supply the key and
associated permissions when (s)he requests the capability <taking cover>
;-)

Ian.

Comments: Authenticated sender is <ieca2@[205.252.27.1]>
From: "Bonatti Chris" <[email-masked]>
Organization: IECA, Inc.
To: Ian Brown <[email-masked]>
Date: Tue, 23 Sep 1997 22:51:28 +0100
Subject: Re: Principles and Principals
Reply-to: [email-masked]
CC: [email-masked]
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Ian,

To take your points out of order:

> With this approach, the distributed keyserver problem becomes
> simpler. E-mail messages in RFC822 format should contain a
> From: field; users should simply ensure that the address in
> this field is included as a 'tag' on their public key. Or you
> could use a solution like PGP5 and include an X header that
> specifies exactly how the key can be looked up.
>
> Other protocols/message exchange systems can be considered
> separately.

This is a good approach, although by itself it does not address
the totality of the e-mail requirement.  You still need some way
to bind the e-mail address to the key.  Whatever the principal
is, this is a function that's got no better place to roost than
the public key infrastructure.

> I think this is a great way to look at it. Using the public
> key, its hash or fingerprint as *the* DN allows all sorts of
> important functionality like authorisations. E-mail is probably
> the most widespread use of PGP at the moment, but can be
> considered separately. E-mail users in effect can state to the
> world (via keyservers) that their public key 'speaks' for a
> certain address (to use SPKI lingo). So, if a key is to be used
> for e-mail, it must contain such a 'tag' with an e-mail
> address. If not, no problem.

Unless I misunderstand you, the e-mail address is not then bound
into the certificate structure.  I'm reading out of what
your last couple of messages that we would submit the e-mail
address as an submission argument to the keyserver, but that
this would be absent from the certificate.  This is pretty weak
in the sense that it is dirt simple for a black-hat to assert a
bogus e-mail address (or worse usurp a real one) and provide his
own black-hat key ID.  This leaves open a lot of possibilities
for misuse.

I should think that we at least have to have the ability for
3rd party certifications of the public key have the ability to
bind over the key ID and e-mail address (or other string).  This
would in effect be an authorization to use that e-mail address,
not a principal.

This seems to me a basic characteristic of any public key
infrastructure to associate the key with what the key is allowed
to do.

If I am misrepresenting what you propose, please set me
straight.

Chris

 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti                 9010 Edgepark Road  |
 |  Vice-president                     Vienna, Virginia 22182  |
 |  [email-masked]   Tel: 301-212-9428   Fax: 703-506-8377  |
 |  PGP public key available from "http://www.ieca.com/"       |
 ---------------------------------------------------------------

Date: Tue, 23 Sep 1997 11:24:20 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: William Allen Simpson <[email-masked]>
CC: [email-masked]
Subject: Re: Principles and Principals
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

> The PGP public-key is the principal.  The principal is used to
> "distinguish" all manipulations, such as signing and database
> maintenance.  A "hash" of the principal (really just the lower bits) can
> also be used for database lookup.
> 
> The PGP principal signs a "tag" called the username (or just PGP user).
> This tag is not really used to any degree, except for human recognition
> and database lookup.

I think this is a great way to look at it. Using the public key, its
hash or fingerprint as *the* DN allows all sorts of important
functionality like authorisations. E-mail is probably the most
widespread use of PGP at the moment, but can be considered separately.
E-mail users in effect can state to the world (via keyservers) that
their public key 'speaks' for a certain address (to use SPKI lingo). So,
if a key is to be used for e-mail, it must contain such a 'tag' with an
e-mail address. If not, no problem.

With this approach, the distributed keyserver problem becomes simpler.
E-mail messages in RFC822 format should contain a From: field; users
should simply ensure that the address in this field is included as a
'tag' on their public key. Or you could use a solution like PGP5 and
include an X header that specifies exactly how the key can be looked up. 

Other protocols/message exchange systems can be considered separately.

Ian >:)

Date: Fri, 19 Sep 1997 10:33:40 -0700
To: "Tony Mione" <[email-masked]>
From: "John W. Noerenberg" <[email-masked]>
Subject: Re: Charter submitted to IESG
Cc: [email-masked], "\"Jeffrey I. Schiller\"" <[email-masked]>, Charles Breed <[email-masked]>
Sender: [email-masked]

At 7:56 AM -0400 9/19/97, Tony Mione wrote:
>
>On Sep 18,  4:31pm, John W. Noerenberg wrote:
>> Subject: Charter submitted to IESG
>>
>>
>>
>> July 1998: WG last call on both drafts for Proposed Standard,
>                             ^^^^
>
>	I count only one draft (OPEN-PGP key format and  Or does this mean:
>
>	1) OPEN-PGP key formats
>	2) OPEN-PGP message specifications
>
>> (including RFC 2015 or its replacement).
>>
>
>	...or
>	1) OPEN-PGP key format and message specification
>	2) RFC 2015 and/or replacement
>
>	If this is the case, should we not have 'review of RFC2015' somewhere
>in the milestones?

Good point, Tony.  The IESG has called me to task on it, too.

Here the revised milestones I offered for their discussion:

>Our milestones outline the progress of two documents to Proposed Standard.
>
>1) RFC covering PGP Key format and PGP Message format
>2) PGP/MIME
>
>So Steve's on the right track with the milestones, but this is what we're
>after:
>
>Oct 97  Submit Internet-Draft for PGP Key Format & Message Format
>Oct 97  Submit revised PGP/MIME RFC
>
>Mar 98  Issue WG Last Call for both documents
>
>May 98  Submit PGP Key Format & Message Format Internet-Draft to IESG for
>consideration as a Proposed Standard.
>May 98  resubmit PGP/MIME Specification to IESG for  consideration as a
>Proposed Standard
>
>July 1998: IETF last call for PGP Key Format & PGP Message Specification
>July 1998: IETF last call for PGP/MIME (RFC 2015 or its replacement)

john noerenberg
[email-masked]
pager: [email-masked]
 --------------------------------------------------------------------
  "Try designing one set of outfits for the Spice Girls and the
  Chicago Symphony, and see if anyone is happy."
 -- Steve Dorner, private email, 1997
 --------------------------------------------------------------------

Date: Fri, 19 Sep 1997 15:44:19 +0200
To: [email-masked]
From: "Anthony E. Greene" <[email-masked]>
Subject: Re: An added E-Mail Issue
Sender: [email-masked]

At 16:34 18-09-1997 -0400, you wrote:
>>putting it differently, "signing" is a subset
>>of "encrypting", legally speaking
>
>Nothing personal but I hope the law isn't worded that way. :(

I'm not sure it's a law yet. The proposal is posted at

 <http://www.commerce.state.ut.us/web/commerce/digsig/dsmain.htm>

The wording of the proposal is consistent with accepted practice, and not
with the opinion quoted a few days ago on this list.

--
Anthony E. Greene <[email-masked]>

From: "Tony Mione" <[email-masked]>
Date: Fri, 19 Sep 1997 07:56:49 -0400
To: "John W. Noerenberg" <[email-masked]>, [email-masked]
Subject: Re: Charter submitted to IESG
Cc: "\"Jeffrey I. Schiller\"" <[email-masked]>, Charles Breed <[email-masked]>
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

On Sep 18,  4:31pm, John W. Noerenberg wrote:
> Subject: Charter submitted to IESG
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Our proposal for a WG is now being considered by the IESG.  I expect to hear
> after the next IESG meeting (9/25) whether we're in business.  The charter at
>...
>
> best,
>
> john noerenberg
> [email-masked]
> pager: [email-masked]
>  --------------------------------------------------------------------
>    "We need not to be left alone.  We need to be really
>     bothered once in a while."
>   -- Ray Bradbury, Farhenheit 451, 1953
>   --------------------------------------------------------------------
>
>
> OpenPGP charter:
>
>...
>
> Goals and Milestones:
>
> October 1997: Submit first internet draft of OPEN-PGP key format and
> message specification.
>
> March 1998: Submit OPEN-PGP key format and message specification for
> final call.
>
> May 1998: Submit OPEN-PGP key format and message specification for
> Proposed Standard
>
> July 1998: WG last call on both drafts for Proposed Standard,
                             ^^^^

	I count only one draft (OPEN-PGP key format and  Or does this mean:

	1) OPEN-PGP key formats
	2) OPEN-PGP message specifications

> (including RFC 2015 or its replacement).
>

	...or
	1) OPEN-PGP key format and message specification
	2) RFC 2015 and/or replacement

	If this is the case, should we not have 'review of RFC2015' somewhere
in the milestones?

>...
>
>-- End of excerpt from John W. Noerenberg

- --
Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
[email-masked]                 W3: http://www-ns.rutgers.edu/~mione/
PGP Fingerprint : E2 25 2C CD 28 73 3C 5B  0B 91 8A 4E 22 BA FA 9F
Editorial Advisor for Digital Systems Report   ***** Important: John 17:3 *****

CC: [email-masked]
Date: 19 Sep 1997 4:20:48 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: Charter submitted to IESG
To: [email-masked]
Sender: [email-masked]

>Leave the flaws, the optional extras, the extras for later.  Let's 
>get the
>defined PGP out there, and then let's look at building upon a solid, 
>exising
>definition.

Hear hear!

I've given up on S/MIME - the whole process seems bogged down in a endless
series of revisions & discussion on licensing, patents, PKCS XX structures,
methods for granting/revoking/reading keys & endless feature discussions.

I just looked at the draft OpenPGP spec - its *very* encouraging, as a
reasonably compent developer I have no problem with writing my own core
implementation. I feel confident that later specifications for PKI etc will
be easily integrated.

Looking forward to doing so,
--
Lindsay Mathieson
Black Paw Communications
	http://www.blackpaw.com/

From: [email-masked]
Date: 19 Sep 1997 03:02:57 -0000
To: [email-masked]
Subject: Re: Charter submitted to IESG
Sender: [email-masked]

John W. Noerenberg wrote:
> ...I expect to hear after the next IESG meeting (9/25) whether we're in
> business .... for files and for email.

> I know there are other things we need to tackle (PKI and Cert structure come
> to mind).  But other groups are also working those issues.  In order to make
> sure we get this group up and running, and to make sure we score some early
> success, I would like to see us focus in on the packet structure, and use in
> email.  No group is currently handling those, so let's see how fast we can get
> these two done.

I hear and concur.  Fully, without reservation.

People,

PGP has taken us this far without a PKI, and without a certificate
structure.  This is not to say that such potential enhancements are
not useful, but rather the beauty of PGP is that it can go *so* far
without such.

Let us consolidate what we have, in an open framework, in an Internet
spirit.

I believe that we need to take *existing* work and standardise it such
that developers across the Internet and across the world can produce
implementations that will deliver the privacy we need.

The need to deliver future works is pressing, and for this reason, I
would suggest that we need new teams, and new charters, and indeed, new
blood, to consider the difficult but necessary tasks of PKI, certificates,
and the like.

In doing so, I would also represent that such a mission necessarily
marches to a different drum, a different timetable.  The need for a
standard commercial means of determining identity, or of non-repudiation,
or of value, is such that it cannot accept the same assumptions as those
that make the core of the PGP web of trust.  The concepts that make up
the architecture of PGP were built on neighbourly trust, not commercial
transactions.  Door-to-door community, and not commercial advertising.

So be it - we have a number of different issues on the table.  I think that
most PGP hackers would agree that we can build the new requirements on top
of the base architecture.  I believe this, as I have participated in such
projects.  However, there is a fundamental difference between standardising
and building, between documenting and advancing.

The most pressing issue we have is the deployment of a standard in basic
packet communications.  That is, in deploying a packet format that allows
all the various implementations of privacy communications to exchange
messages.  Our task is only, in the short term, to define and standardise
what we can already do.  So that implementors can produce the basic
framework that allows the future needs to develop.  And so that builders
have a foundation upon which to build.

We need to document and standardise the *current* technology of PGP.

As far as I can see, there is only one short term decision.  And even
this may already be taken, as I was not present at Munich.  Is it PGP
2.6 or is it 5.0 ?

To my mind it is not important which.  I am only here, in this forum, to
represent the interests of the Cryptix Development Team in producing a
stable crypto architecture based on the lead that has been provided by
past hackers.  We, of the team, are looking for guidance, we do not
offer opinion on the goodness of the architecture, rather, we offer
crypto-labour and we wish to labour at this crypto.

It is unimportant that 5.0 is "PGP Inc" more than PGP, as long as the former
are willing to sign the former over to the latter.  What is important is that
we have, as a community of Internet crypto coders, a single document that
describes the packets we will interchange.

Leave the flaws, the optional extras, the extras for later.  Let's get the
defined PGP out there, and then let's look at building upon a solid, exising
definition.

> OpenPGP charter:
> 
> An Open Specification for Pretty Good Privacy (OpenPGP)

> October 1997: Submit first internet draft of OPEN-PGP key format and
> message specification.

Today, by the posting of this email, is 0500, 19th of September 1997.

Therefore, there are about 2 weeks until October, or say 6 weeks inclusive.

We simply must choose one of two bases.  We must choose the coding set.
And document it.  There is no time for anything else.

iang

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 18 Sep 97 18:56:08 -0400
To: "John W. Noerenberg" <[email-masked]>
Cc: [email-masked], "\"Jeffrey I. Schiller\"" <[email-masked]>, Charles Breed <[email-masked]>
Subject: Re: Charter submitted to IESG
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

In <v04001413b04761072eac@[129.46.137.118]>, on 09/18/97 
   at 06:31 PM, "John W. Noerenberg" <[email-masked]> said:

>Our proposal for a WG is now being considered by the IESG.  I expect to
>hear after the next IESG meeting (9/25) whether we're in business.  The
>charter at the end of the message covers the essential goal of
>standardizing the way PGP is used for files and for email.

>I know there are other things we need to tackle (PKI and Cert structure
>come to mind).  But other groups are also working those issues.  In order
>to make sure we get this group up and running, and to make sure we score
>some early success, I would like to see us focus in on the packet
>structure, and use in email.  No group is currently handling those, so
>let's see how fast we can get these two done.

what other groups??

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Thu, 18 Sep 1997 16:31:03 -0700
To: [email-masked]
From: "John W. Noerenberg" <[email-masked]>
Subject: Charter submitted to IESG
Cc: "\"Jeffrey I. Schiller\"" <[email-masked]>, Charles Breed <[email-masked]>
Sender: [email-masked]

Our proposal for a WG is now being considered by the IESG.  I expect to hear
after the next IESG meeting (9/25) whether we're in business.  The charter at
the end of the message covers the essential goal of standardizing the way PGP
is used for files and for email.

I know there are other things we need to tackle (PKI and Cert structure come
to mind).  But other groups are also working those issues.  In order to make
sure we get this group up and running, and to make sure we score some early
success, I would like to see us focus in on the packet structure, and use in
email.  No group is currently handling those, so let's see how fast we can get
these two done.

best,

john noerenberg
[email-masked]
pager: [email-masked]
 --------------------------------------------------------------------
   "We need not to be left alone.  We need to be really
    bothered once in a while."
  -- Ray Bradbury, Farhenheit 451, 1953
  --------------------------------------------------------------------

OpenPGP charter:

An Open Specification for Pretty Good Privacy (OpenPGP)

Last Modified:

9/18/97

Chair(s):

John W Noerenberg <[email-masked]>
Charles Breed <[email-masked]>

Security Area Director(s):

Jeffrey Schiller <[email-masked]>

Mailing Lists:

General Discussion: [email-masked]
To Subscribe: [email-masked]
Only the word "subscribe" in the body of the message.
Archive: http://www.imc.org/ietf-open-pgp/mail-archive/

Description of the Working Group:

PGP, or Pretty Good Privacy, first appeared on the Internet in 1991.
It has enjoyed significant popularity amongst the Internet Community.

PGP is used both for protecting E-mail and File Storage. It presents
a way to digitally sign and encrypt information "objects." As such
it is well suited for any store and forward application.

The goal of the OpenPGP working group is to provide IETF standards for
the algorithms and formats of PGP processed objects as well as providing
the MIME framework for exchanging them via e-mail or other transport
protocols.

Because there is a significant installed base of PGP users, the
working group will consider compatibilty issues to avoid disenfranchising
the existing community of PGP users.

Security Issues:

The whole purpose of Open-PGP is to provide security services.

Goals and Milestones:

October 1997: Submit first internet draft of OPEN-PGP key format and
message specification.

March 1998: Submit OPEN-PGP key format and message specification for
final call.

May 1998: Submit OPEN-PGP key format and message specification for
Proposed Standard

July 1998: WG last call on both drafts for Proposed Standard,
(including RFC 2015 or its replacement).

Date: Thu, 18 Sep 1997 15:02:37 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: An added E-Mail Issue
Sender: [email-masked]

William H. Geiger III, <[email-masked]>, writes:
> In common disscussion of public key encryption when one talks of
> "Encryption" of a message they are most definatly not speaking of
> encrypting with ones secret key.
>
> I guess one could encrypt the entire message with ones secret key and
> bypass the use of the hash but it is not a practice I would recomend and
> it clouds the distinction between standard "encryption" & "signatures"
> from a legal standpoint.

Furthermore, it is not meaningful in general to describe a signature as
encryption with the private key.  RSA signatures happen to work that way,
but discrete log signatures do not.  Rather, there is a verification
formula which takes the message hash, the public key, and the signature
values, and is used to check that the signature is correct.  It's very
different from either encryption or decryption.

Hal Finney
[email-masked]

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 18 Sep 97 16:34:05 -0400
To: Dan Geer <[email-masked]>
Cc: "William H. Geiger III" <[email-masked]>, [email-masked]
Subject: Re: An added E-Mail Issue
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

In <[email-masked]>, on 09/18/97 
   at 04:44 PM, Dan Geer <[email-masked]> said:

>    >I asked an author of the Utah Digital Signature Act
>    >last week whether encryption, of and by itself, would
>    >constitute the legal force of signature.  He said it
>    >would.
>    
>    Hmmmm that seems a little silly to me since anyone can encrypt a
>message.
>    Encryption alone does not provide authentication.

>for clarity, he/I meant that if m is encrypted
>in your private key then you've acknowledged
>authorship

>putting it differently, "signing" is a subset
>of "encrypting", legally speaking

Nothing personal but I hope the law isn't worded that way. :(

In common disscussion of public key encryption when one talks of
"Encryption" of a message they are most definatly not speaking of
encrypting with ones secret key.

I guess one could encrypt the entire message with ones secret key and
bypass the use of the hash but it is not a practice I would recomend and
it clouds the distinction between standard "encryption" & "signatures"
from a legal standpoint.

I really feel sorry for the poor shmucks when this stuff winds up in court
and they have to explain to a jury that "no they only ment if you
encrypted with your secret key ..."

- From what I have seen of the various Digital Signature Laws they are a bad
thing.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

To: "William H. Geiger III" <[email-masked]>
Cc: [email-masked]
Subject: Re: An added E-Mail Issue 
Date: Thu, 18 Sep 1997 16:44:53 -0400
From: Dan Geer <[email-masked]>
Sender: [email-masked]

    >I asked an author of the Utah Digital Signature Act
    >last week whether encryption, of and by itself, would
    >constitute the legal force of signature.  He said it
    >would.
    
    Hmmmm that seems a little silly to me since anyone can encrypt a message.
    Encryption alone does not provide authentication.

for clarity, he/I meant that if m is encrypted
in your private key then you've acknowledged
authorship

putting it differently, "signing" is a subset
of "encrypting", legally speaking

--dan

Date: Thu, 18 Sep 1997 13:26:24 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: Change Control
Cc: [email-masked]
Sender: [email-masked]

Just to make things 'crystal clear', let it be known that...

"PGP Inc. intends to turn change control of the PGP key and messages
formats over to the IETF in a similar way to the way Sun Microsystems
turned over RPC in RFC1790."

Charles Breed
Senior Director fo PGP technologies

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 18 Sep 97 11:20:33 -0400
To: Dan Geer <[email-masked]>
Cc: Hal Finney <[email-masked]>, [email-masked]
Subject: Re: An added E-Mail Issue
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

In <[email-masked]>, on 09/17/97 
   at 07:07 AM, Dan Geer <[email-masked]> said:

>    > One other clarification: in an encrypted and signed message...

>I asked an author of the Utah Digital Signature Act
>last week whether encryption, of and by itself, would
>constitute the legal force of signature.  He said it
>would.

>Just a datum...

Hmmmm that seems a little silly to me since anyone can encrypt a message.
Encryption alone does not provide authentication.

Personally I don't like the way any of these Digital Signature laws have
been written. Too many issues involved that have been given little or no
consideration by people who do not have a good understanding of the
subject.

Anyone wishing in discusing this further please e-mail me off list.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Wed, 17 Sep 1997 13:10:22 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Principles and Principals
Sender: [email-masked]

> From: "William Allen Simpson" <[email-masked]>
> 
> What PGP currently does is more akin to SPKI Principals than X.509
> Distinguished Names.
> 
> The PGP public-key is the principal.  The principal is used to
> "distinguish" all manipulations, such as signing and database
> maintenance.  A "hash" of the principal (really just the lower bits) can
> also be used for database lookup.
> 
> The PGP principal signs a "tag" called the username (or just PGP user).
> This tag is not really used to any degree, except for human recognition
> and database lookup.

"not really used, except for human recognition and database lookup" ???
Is that like "the car is not really used, except for commuting, vacationing,
and taxiing the kids to soccer practice."?

SPKI's primary failure (IMO) is it's central design feature: the failure
to allow a separation between principals and keyholders.  That is, the
identity of a principal is inextricably tied to the cryptographic key
being used by the principal.

I believe it can be accurately claimed that the "PGP user" (the
human-readable username) is defined to be the principal, regardless of
what cryptographic keys are being used by that principal.
"[email-masked]" is the same person you are accustomed to communicating
with, even if he changes his public key.  With the SPKI notion of the
public key being the principal, the old principal has to delegate to
the new one every time keypairs are changed.  The inconvenience of
managing delegation strongly discourages the use of good key management
practices.

Those more familiar with PGP operations than I am can judge whether
there is a good enough fit between the "cyber-principal to
physical-entity" mapping of SPKI vs. the "physical-principal to public
key" mapping of PGP and X.509.

Date: Wed, 17 Sep 1997 10:40:14 -0400
From: [email-masked]
To: [email-masked]
Subject: Re: An added E-Mail Issue
Sender: [email-masked]

On Tue, 16 Sep 1997, Jon Callas wrote:

>    Is there any actual restrictions that DSS *must* use SHA1? It should be
>    able to use any hash that the user selects. It is my understanding that
>    the hash algorithim & the encryption algorithm should be independent of
>    each other (I could be wrong as I have not done an indepth study of that
>    section of code in 5.0).
> 
> There is kinda sorta a restriction that DSS must use SHA1. DSS is the
> Digital Signature Standard, and part of that standard is the Secure Hash
> Algorithm. If you're not using SHA1, then you're not following that
> standard. So, as far as Layer Nine (the political layer) is concerned, you
> have to, but the math is a different question. A signature system that uses
> DSA with RIPEMD160 may be perfectly valid, but it's not DSS.
> 
> That's why I said "kinda sorta." It's certainly germane to this list to
> discuss DSS variants, but they're not DSS.

But PGP 5.0 has a test in DSAPubKey.c such that if the hash algorithm is
not SHA1, then it doesn't even bother doing the math (around line 172 if I
remember - for those with source). It might be better to give a
"nonstandard algorithm" warning. 

To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: An added E-Mail Issue 
Date: Wed, 17 Sep 1997 08:07:38 -0400
From: Dan Geer <[email-masked]>
Sender: [email-masked]

    > One other clarification: in an encrypted and signed message...

I asked an author of the Utah Digital Signature Act
last week whether encryption, of and by itself, would
constitute the legal force of signature.  He said it
would.

Just a datum...

--dan

Date: Tue, 16 Sep 1997 23:18:06 -0700
To: Hal Finney <[email-masked]>, [email-masked]
From: Bill Frantz <[email-masked]>
Subject: Re: An added E-Mail Issue
Cc: [email-masked]
Sender: [email-masked]

At 3:48 PM -0700 9/16/97, Hal Finney wrote:
>A possibly simpler way to do handle key preferences would be to allow
>a key to claim that it has higher priority than a specified list of
>other keys.  So if you had keys A, B, and C matching the desired userid,
>and A claimed it was higher priority than B, while C claimed to be higher
>priority than A or B, we would use C.

If B had signed the claim that A was higher priority and A had signed the
claim that C was higher priority, then we could even believe the claims.

-------------------------------------------------------------------------
Bill Frantz       | The Internet was designed  | Periwinkle -- Consulting
(408)356-8506     | to protect the free world  | 16345 Englewood Ave.
[email-masked] | from hostile governments.  | Los Gatos, CA 95032, USA

Date: Tue, 16 Sep 1997 17:15:40 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: An added E-Mail Issue
Sender: [email-masked]

One other clarification: in an encrypted and signed message there are
really four algorithms involved: the public-key signature algorithm,
the hash algorithm used for the signature, the public-key encryption
algorithm, and the conventional cipher algorithm used for encryption.

Generally the current PGP implementations assume that the signature
and hash algorithm will be chosen by the signer, without regard to
the recipient of the message.  This is particularly appropriate for
messages to large groups and clear-signed messages to public forums,
or for messages which may have a long lifetime and be shown to many
parties, such as contracts.  However for messages to one or a small
number of recipients, it might be useful for the sender to know which
signature and hash algorithms the recipient prefers or can handle.

With encryption, PGP currently chooses the public key and secret key
algorithms based on the recipient's preferences.  Where we are encrypting
to multiple recipients, it chooses a conventional secret key algorithm
which all recipients can handle, and aborts if no such algorithm exists.

In both cases, it is difficult to know how to balance the interests
of the sender of the message and the recipient(s) in terms of choice
of algorithms.  Each party could have preferences, and possibly vetoes,
in terms of what they would like to see used.  There may be multiple
recipients, and in the case of signatures there may be unknown recipients.

We could generalize the preferred-algorithm packets to allow the
recipient key to say things like "don't send me messages hashed with
MD5" or "only send messages signed with RSA or DSA keys".  This could
be handled similarly to the current specification of preferred secret
algorithms.  It is somewhat more awkward to implement because signing
is conceptually a distinct step from encryption, and so this requires
some internal information flow which would not otherwise be needed.

Hal Finney
[email-masked]

Date: Tue, 16 Sep 1997 16:56:45 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: An added E-Mail Issue
Sender: [email-masked]

Regarding SHA with DSA, there is also the issue of hash sizes.

DSA, for keys in the range 512-1024 bits (which are the only ones for
which it is defined currently) has 160 bits to hold the hash value.
SHA-1 produces a 160 bit hash, so that is a good match.

DSA is carefully balanced so that the difficulties of breaking the
discrete log in either of the two known ways are approximately equal,
and also are approximately equal to the difficulty of finding a signature
collision.  All involve a work factor of about 2^80.

If you wanted to use DSA with a hash of < 160 bits, you don't actually get
the cryptographic strength which the DSA algorithm is designed to provide.
Your hash becomes the weakest link.

Other 160 bit hashes than SHA-1, like RIPEMD-160, should be suitable for
use with DSA as far as cryptographic strength is concerned.  The question
of whether to allow non-SHA hashes with DSA is, as Jon says, more political
than technical, as long as you keep to consistent sizes.

Hal Finney
[email-masked]

Date: Tue, 16 Sep 1997 16:29:46 -0700
To: Marc Horowitz <[email-masked]>, Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: The purpose of this mailing list
Cc: Ian Brown <[email-masked]>, Charles Breed <[email-masked]>, [email-masked]
Sender: [email-masked]

At 11:56 AM 9/15/97 -0400, Marc Horowitz wrote:
   Jon Callas <[email-masked]> writes:
   
   I see one problem with this approach, and that is in looking up keys.
   If we use the email address as the DN, then DNS will make an excellent
   mechanism for looking up keys.  Of course, email addresses have
   certain problems as DN's, as Carl will point out of I don't.  If we
   think of the key as the DN, then we avoid those problems, but create a
   different one: given a signature, how do I find the key to use to
   verify it?  Past solutions are to carry certs around within every
   message, which is inefficient, or to have a global index, which
   doesn't scale.
   
   We need to solve this problem.  One option which comes to mind is to
   include a "domain name" for the a pgp cert RR with the message instead
   of the cert itself; this does not need to be signed, as the message
   verification will fail if it is modified.  Unfortunately, this has the
   problem that cert domain names may change or go away, making
   verification in the future difficult unless a long-term cert cache is
   kept near the message.
   
Actually, it is good to do both. Here's a quick example:

Suppose I want to send a message to my old college roommate, Tom. Unlike
Carl Ellison's quandry with his old roommate, Bob, I know precisely which
Tom he is. I know his name, address, email address, and phone number. I
just don't have his key. Using his email address as a DN with which to look
up his key is reasonable. Tom, on the other hand, should be able to use his
key with whatever user name (including no user name) he wants, depending on
the situation.

Once I have his key, I want to see if it's valid. The PGP software will do
this for me, and looks up each certification signature of his key using an
8-byte key id. If I phone Tom up to hand-verify it, then we'll use the
fingerprint. Each of these is a form of DN, and each has its place.

I concur that carrying around certs with messages is a bad solution. Some
machanisms for this actually increase the ability for people to do traffic
analysis on messages and carry plaintext information in the cert that makes
it worse than useless. If my PGP-encrypted mail carried in it my home
address and phone number, I think I'd stick to plaintext.

	Jon

-----
Jon Callas                                         [email-masked]
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065

Date: Tue, 16 Sep 1997 15:54:03 -0700
To: "William H. Geiger III" <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: An added E-Mail Issue
Sender: [email-masked]

At 04:53 PM 9/16/97 -0400, William H. Geiger III wrote:
   
   Is there any actual restrictions that DSS *must* use SHA1? It should be
   able to use any hash that the user selects. It is my understanding that
   the hash algorithim & the encryption algorithm should be independent of
   each other (I could be wrong as I have not done an indepth study of that
   section of code in 5.0).

There is kinda sorta a restriction that DSS must use SHA1. DSS is the
Digital Signature Standard, and part of that standard is the Secure Hash
Algorithm. If you're not using SHA1, then you're not following that
standard. So, as far as Layer Nine (the political layer) is concerned, you
have to, but the math is a different question. A signature system that uses
DSA with RIPEMD160 may be perfectly valid, but it's not DSS.

That's why I said "kinda sorta." It's certainly germane to this list to
discuss DSS variants, but they're not DSS.

	Jon

-----
Jon Callas                                         [email-masked]
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065

Date: Tue, 16 Sep 1997 15:48:00 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: An added E-Mail Issue
Cc: [email-masked]
Sender: [email-masked]

Each key determines the public key algorithm to be used to encrypt to
it.  To send to an RSA key, we use RSA, and to send to an ElGamal key,
we use ElGamal, etc.  There is also in PGP 5.0 a self-signature packet
which allows the key to describe which conventional algorithm(s) it
prefers to receive.

The issue of choosing a key comes about when multiple keys share a userid,
and we are looking up a key on that basis.  Then we have the question
of which key (or keys) to use to encrypt to that user.  If the user has
multiple keys which have the same userid, it is not obvious which ones
to use.

One idea we have discussed at PGP is to combine all the keys belonging to
a user into one "key cluster".  This would be a generalization of the
current structure where we have a signature key with an encryption subkey
attached to it.  With the key cluster there could be an extra packet which
indicated the user's preferences as to which keys to use.

This idea works well for email, but perhaps not so well for a capability
based model like SPKI.  In SPKI, keys have certain attributes or privileges
based on the signatures on them.  They don't necessarily have userids, and
may not be associated with a particular user.

There seems less value to clustering keys together in a SPKI-like model.
It adds complexity and would make interpreting the attributes of each
key more difficult.  If we think we will be moving towards a capability
system like SPKI, it would be better to avoid doing more with clustering.

A possibly simpler way to do handle key preferences would be to allow
a key to claim that it has higher priority than a specified list of
other keys.  So if you had keys A, B, and C matching the desired userid,
and A claimed it was higher priority than B, while C claimed to be higher
priority than A or B, we would use C.

Hal

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 16 Sep 97 16:53:28 -0400
Subject: Re: An added E-Mail Issue
To: [email-masked]
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

In <[email-masked]>, on 09/16/97 
   at 04:35 PM, [email-masked] said:

>On Tue, 16 Sep 1997, William H. Geiger III wrote:

>> -----BEGIN PGP SIGNED MESSAGE-----
>> 
>> Hi,
>> 
>> I forgot to add an important issue that can be addressed by the
>> e-mail<=>PGP Key lookup list.
>> 
>> With PGP 5.0's ability to uses multiple encryption/hash algortihms the
>> need has arose to be able to set the default algortihms to be used by an
>> application for a given e-mail address. This can be accomplished by adding
>> an extra field in the lookup list.
>> 
>> Things like:
>> 
>>   -- Owner of address is using 2.6.x therfore RSA/MD5 signatures should
>> only be used.

>This is the main thing necessary since it would be theoretically valid to
>use RSA/MD5 with new PGP 5.0 specific formats (such as the Hash: in the
>armored files and the new CTB and length format).

>>   -- Owner of address is using 5.0 but would prefer that RSA/MD5 be used.
>> 
>>   -- Owner of address has 5.0 but would prefer that RSA/SHA1 be used.
>> 
>> ... and so on and so forth.

>There is already a field in the new signature type packet that indicates
>the preferred conventional cipher.  My notes don't indicate that there is
>any yet defined for preferred PK cipher, but I think I remember seeing a
>preferred hash, though it might have been disabled since DSS requires
>SHA1, and RSA needs MD5 for backward compatibility.

>A final field would be the preferred signature algorithm, RSA, DSS, or
>ElGamal if they can get that working securely.

Is there any actual restrictions that DSS *must* use SHA1? It should be
able to use any hash that the user selects. It is my understanding that
the hash algorithim & the encryption algorithm should be independent of
each other (I could be wrong as I have not done an indepth study of that
section of code in 5.0).

Also a user may wish to use various combinations of Public Key, Session
Key, and Hash to be used. I see nothing preventing somone from using RSA
Public Key with CAST session key and a SHA1 hash. 

Now use such a non-standard combination there are two seperate issues that
need to be addressed:

- -- Myself as a receiver of data. If I wish to receive data in using the
above combination I need a mechanism to convay that to the users of my
public key. This is best handled with some type of preferance flags in my
public key. These settings should only be "preferances" and the sender
should have the option to override these (see below).

- -- Myself as a sender of data. If I wish to send all my messages out using
the above combination I need some method of telling PGP to use this
combination if possiable (obviously if I only have a DSS/DH key for the
receiver I can't use RSA). This should be both in the form of default
settings in the PGP configuration file and on the command line.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Tue, 16 Sep 1997 17:56:03 -0400
From: [email-masked]
To: [email-masked]
Subject: Re: Principles and Principals
Sender: [email-masked]

On Tue, 16 Sep 1997, William H. Geiger III wrote:

> >In the real world is the email address optional?  What do people want? 
> >In PGP5 the email address is effectively mandatory, if you want to use
> >the key for Eudora, for example.
> 
> >I'm asking what people THINK it should do not what people think of the
> >PGP5 UI.
> 
> E-Mail address is most definatly not manditory in the real world. It is
> not even maditory for an e-mail program. :)

AGREED!

> I don't know if I have posted to this list about my work/research in PGP
> integration but I have done quite a bit in this area.

As I have.

> Now as far as UserID's outside of e-mail use there are a multitude of
> uses. Internet E-Mail is only one form of message/data exchange. There are
> numerious propriatory E-Mail formats out there that do not use standard
> INet e-mail addresses that still can use PGP to encrypt the messages.

Some things I can think of:

Or to hold a random conventional key for disk or file encryption.

A CA style PGP cert - one I just use for signing other keys.

Or things simply for signing such as timestamps - I don't need to email
back, but I do need to verify the signature of a timestamp.

In general, once you have written any key handlers, it is easier to use
those style keys than rolling a new certificate format.  X509 is an
exception because it is very complex and limited.

So now that I can generate and pull DSS and DH keys to/from PGP keyrings
(I already had RSA style working), I am going to use those same routines,
and even some of the conventional stuff is easier to use via my PGPlib API
than another rewrite.

So there will be many different key types out there.

Date: Tue, 16 Sep 1997 17:35:15 -0400
From: [email-masked]
To: "William H. Geiger III" <[email-masked]>
cc: [email-masked]
Subject: Re: An added E-Mail Issue
Sender: [email-masked]

On Tue, 16 Sep 1997, William H. Geiger III wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Hi,
> 
> I forgot to add an important issue that can be addressed by the
> e-mail<=>PGP Key lookup list.
> 
> With PGP 5.0's ability to uses multiple encryption/hash algortihms the
> need has arose to be able to set the default algortihms to be used by an
> application for a given e-mail address. This can be accomplished by adding
> an extra field in the lookup list.
> 
> Things like:
> 
>   -- Owner of address is using 2.6.x therfore RSA/MD5 signatures should
> only be used.

This is the main thing necessary since it would be theoretically valid to
use RSA/MD5 with new PGP 5.0 specific formats (such as the Hash: in the
armored files and the new CTB and length format).

>   -- Owner of address is using 5.0 but would prefer that RSA/MD5 be used.
> 
>   -- Owner of address has 5.0 but would prefer that RSA/SHA1 be used.
> 
> ... and so on and so forth.

There is already a field in the new signature type packet that indicates
the preferred conventional cipher.  My notes don't indicate that there is
any yet defined for preferred PK cipher, but I think I remember seeing a
preferred hash, though it might have been disabled since DSS requires
SHA1, and RSA needs MD5 for backward compatibility.

A final field would be the preferred signature algorithm, RSA, DSS, or
ElGamal if they can get that working securely.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Tue, 16 Sep 1997 17:25:16 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: The purpose of this mailing list
Sender: [email-masked]

On Tue, 16 Sep 1997, Jon Callas wrote:

> It's presently possible to separately expire or replace a subkey. There is
> no reason that you can't have multiple subkeys, and in fact, I see it as
> inevitable. The present generation of software doesn't have a lot of
> support for that, but that's okay. The basic architecture, where a
> signature key provides a framework in which to use a collection of subkeys
> is a good one.

Actually it sounds like you are moving toward a model where there are
signature capable entities, and encryption capable entities (and things
that can do both), so you could mix and match.

>    Exactly - I was trying to get at this point.  If I take some of the
>    existing code handling X509 certs and replace that engine with one that
>    uses a PGP superset, maybe stretching the introducers model a little so
>    that CA chains would work like X509 intends, I have one program that can
>    handle both models.  If it sees an X509, it just checks the signature
>    chain such that the root CA is adequate to propogate trust.  If it sees a
>    PGPish cert, it asks a keyserver or user as necessary. 
>    
> Excellent. Actually, though, you don't ask the server for a validity check.
> Validity is in the eye of the beholder. You use the user's validity (trust)
> information for that.

To clarify, it would access the PGP keyserver so that the key with
signatures would be downloaded and any potential revocation! - even most
X509 implementations don't really do CRLs yet, so there is that function
that would be an immediate improvement.  Either it would have enough
validity (e.g. I am accessing your web server and I have more than enough
signatures of trusted introducers that I accept the key as valid), or it
would present to the user a dialog box similar to what netscape does when
it doesn't recognize the CA.

Date: Tue, 16 Sep 1997 14:15:43 -0700
To: Rodney Thayer <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Principles and Principals
Sender: [email-masked]

At 01:33 PM 9/16/97 -0400, Rodney Thayer wrote:
   In the real world is the email address optional?  What do people want?  In
   PGP5 the email address is effectively mandatory, if you want to use the key
   for Eudora, for example.
   
   I'm asking what people THINK it should do not what people think of the PGP5
   UI.
   
I want the email address to be optional. I want to be able to have a key
that has authorizations only.

	Jon

-----
Jon Callas                                         [email-masked]
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 16 Sep 97 13:49:27 -0400
Subject: An added E-Mail Issue
To: [email-masked]
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Hi,

I forgot to add an important issue that can be addressed by the
e-mail<=>PGP Key lookup list.

With PGP 5.0's ability to uses multiple encryption/hash algortihms the
need has arose to be able to set the default algortihms to be used by an
application for a given e-mail address. This can be accomplished by adding
an extra field in the lookup list.

Things like:

  -- Owner of address is using 2.6.x therfore RSA/MD5 signatures should
only be used.

  -- Owner of address is using 5.0 but would prefer that RSA/MD5 be used.

  -- Owner of address has 5.0 but would prefer that RSA/SHA1 be used.

... and so on and so forth.

In the settings either for PGP or the application there should be some
type of option of a general default algortihm to use when presented with
multiple choices:

  - Owner of address has both DSS & RSA keys but their preferances are
unknown. In such a senario it is up to the user to determine which
combination of algorithms should be used (Public key, Session key,
Private/Signature key, and Hash). This may vary between the different
applications that PGP is being used with for a variety of reasons.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 16 Sep 97 13:06:58 -0400
Subject: Re: Principles and Principals
To: [email-masked]
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

In <[email-masked]>, on 09/16/97 
   at 12:33 PM, Rodney Thayer <[email-masked]> said:

>In the real world is the email address optional?  What do people want? 
>In PGP5 the email address is effectively mandatory, if you want to use
>the key for Eudora, for example.

>I'm asking what people THINK it should do not what people think of the
>PGP5 UI.

E-Mail address is most definatly not manditory in the real world. It is
not even maditory for an e-mail program. :)

I don't know if I have posted to this list about my work/research in PGP
integration but I have done quite a bit in this area.

In any effective e-mail integration some type of list will be needed where
keys are crossreferenced with e-mail addresses. This is not needed for all
keys, only a minority of keys used. This list is used to handle the
following issues:

 -- Duplicate keys: This is where one will have multiple keys that contain
the same e-mail address in the userID fields. In such a case a default key
must be selected for use.

 -- No keys: This is where no key can be found to match the e-mail address
in the To:, CC: or Bcc: fields of the message. Several subtopics need to
be addressed here:

    -- No key: The owner of this e-mail address has no key. This covers
persons who are not using PGP and/or mailing list or other group postings
where encryption is not practical.

    -- Address Change: The owner of this e-mail address has a key (or
multiple keys) but his current address is not in his userID fields
(primary or aka).

    -- No Encryption: The owner of this e-mail address has a key that
matches the e-mail address but for whatever reason the user does not want
to encrypt mail to that address.( ie the recipiant has 2 userID's on his
key; one is his personal e-mail address and the other is his work e-mail
address. Due to company policy he is not allowed encrypted mail at work.)

This are some of the most common senarios that I have encountered I am
sure there are others you can come up with.

Now as far as UserID's outside of e-mail use there are a multitude of
uses. Internet E-Mail is only one form of message/data exchange. There are
numerious propriatory E-Mail formats out there that do not use standard
INet e-mail addresses that still can use PGP to encrypt the messages.

I am currently working on an Encrypted IRC private chat channel that uses
PGP keys for the session key exchange.

SSH is another program that could/should be modified to make use of PGP
keys for the session key exchange.

If you take a look at the PGP Keyserver you will se quite a few UserID's
that show FIDO addresses (Yes folks FIDO is alive and well thankyou <g>).

Nom de plume's are quite popular in conjuntion with anonymous remailers.
People still like to have an "identity" even when being "anonymous". As
governments world wide step up their efforts to crack down on the use of
encryption (and free speech in general) expect to see a dramtic increase
of this.

Basically anything required the exchange of encrypted data can take
advantage of the use of PGP keys with or without the use of e-mail
addresses. IMHO they are far from manditory in the UserID field. :)

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Tue, 16 Sep 1997 13:33:05 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Principles and Principals
Sender: [email-masked]

In the real world is the email address optional?  What do people want?  In
PGP5 the email address is effectively mandatory, if you want to use the key
for Eudora, for example.

I'm asking what people THINK it should do not what people think of the PGP5
UI.

>Date: Tue, 16 Sep 97 16:35:38 GMT
>From: "William Allen Simpson" <[email-masked]>
>To: [email-masked]
>Subject: Principles and Principals
>Sender: [email-masked]
>
>What PGP currently does is more akin to SPKI Principals than X.509
>Distinguished Names.
>
>The PGP public-key is the principal.  The principal is used to
>"distinguish" all manipulations, such as signing and database
>maintenance.  A "hash" of the principal (really just the lower bits) can
>also be used for database lookup.
>
>The PGP principal signs a "tag" called the username (or just PGP user).
>This tag is not really used to any degree, except for human recognition
>and database lookup.
>
>The optional email address part of the username tag is akin to the
>optional SPKI <location> or <uri> modifier for finding a principal
>subject or issuer.
>
>All fits rather nicely, actually....  no matter what Ellison says.
>
>Forget X.509.  No good equivalents in PGP.
>
>[email-masked]
>    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
>[email-masked]
>    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2
>
>

Date: Tue, 16 Sep 1997 10:20:52 -0700
To: [email-masked], Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: The purpose of this mailing list
Cc: [email-masked]
Sender: [email-masked]

At 12:46 PM 9/13/97 -0400, [email-masked] wrote:
   On Fri, 12 Sep 1997, Jon Callas wrote:
   
   > But wait, there's more. If you have two PGP certs that contain the
same key
   > material, PGP will merge them. I think this needs to change sooner or
   > later, but that's the way things are presently. So from this aspect, the
   > truest DN is the key itself. The notion that the fingerprint or key
itself
   > is the truest DN sounds pretty SPKI/SDSI-like to me. 
   
   The key material is now separated into the DSS section and the DH section.
   What if the DSS is the same and the DH is different - does PGP merge them
   or not?  Which DH material should it use?  It may be able to handle
   multiple userIDs, but what about multiple subkeys?

It's presently possible to separately expire or replace a subkey. There is
no reason that you can't have multiple subkeys, and in fact, I see it as
inevitable. The present generation of software doesn't have a lot of
support for that, but that's okay. The basic architecture, where a
signature key provides a framework in which to use a collection of subkeys
is a good one.

   Exactly - I was trying to get at this point.  If I take some of the
   existing code handling X509 certs and replace that engine with one that
   uses a PGP superset, maybe stretching the introducers model a little so
   that CA chains would work like X509 intends, I have one program that can
   handle both models.  If it sees an X509, it just checks the signature
   chain such that the root CA is adequate to propogate trust.  If it sees a
   PGPish cert, it asks a keyserver or user as necessary. 
   
Excellent. Actually, though, you don't ask the server for a validity check.
Validity is in the eye of the beholder. You use the user's validity (trust)
information for that.

	Jon

-----
Jon Callas                                         [email-masked]
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065

Date: Tue, 16 Sep 97 16:35:38 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: Principles and Principals
Sender: [email-masked]

What PGP currently does is more akin to SPKI Principals than X.509
Distinguished Names.

The PGP public-key is the principal.  The principal is used to
"distinguish" all manipulations, such as signing and database
maintenance.  A "hash" of the principal (really just the lower bits) can
also be used for database lookup.

The PGP principal signs a "tag" called the username (or just PGP user).
This tag is not really used to any degree, except for human recognition
and database lookup.

The optional email address part of the username tag is akin to the
optional SPKI <location> or <uri> modifier for finding a principal
subject or issuer.

All fits rather nicely, actually....  no matter what Ellison says.

Forget X.509.  No good equivalents in PGP.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
[email-masked]
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

To: "William H. Geiger III" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: The purpose of this mailing list
From: Marc Horowitz <[email-masked]>
Date: 15 Sep 1997 13:46:10 -0400
Lines: 57
Sender: [email-masked]

"William H. Geiger III" <[email-masked]> writes:

>> I see some serious problems with using the DNS for key lookups &
>> distribution.
>> 
>> - -- What do we do with keys than do not have a "domain"?

Manage them some other way, or not at all.  Once of the nice things
about PGP is that you don't need to follow the rules.  However, one
thing the IETF has learned is that to have global interoperability,
you need to have some ground rules, usually known in the IETF as a
"mandatory-to-implement" protocol/transform/whatever.  Implementations
are free to do other things as well, and domainless keys seem to fall
in that category.  Blacknet can get their key out by periodic posts to
cypherpunks, or whatever.

>> - -- What do we do with sites that do not wish to manage PGP keys?
>> (currently the PKI is being done on a volentary basis).

What did we do with sites that did not wish to manage DNS servers?

As clients began to use DNS and administrators stopped mainaining
HOSTS.TXT, such sites evolved or perished.  We certainly need a
transition period, where users with uncooperative domain admins can
still publish their keys.  Whatever is proposed (DNS, LDAP, or
something else), if it is distributed (as it must be, to scale),
getting sites to use it will require time and education.

>> - -- How do we solve the problem of redundance? ie where are the backups?

How do we solve the problem of redundance with DNS?  ie where are the
backups?

DNS inherently supports secondary servers.

>> - -- How do we handle keys that cover multiple domains?

How do we handle hosts named in multiple domains?

CNAMEs are the obvious answer, or you store the key in both domains
(similar to having multiple A records).

>> - -- What do we do about domains where PGP is illegal?? (Russia, France,
>> China, Cuba, ...)

The IETF does not concern itself with local politics.  IPsec is
mandatory for IPv6, and DES is mandatory for IPsec.  DES is illegal in
those countries, too, but IPsec and IPv6 are progressing on the
standards track with DES as a mandatory transform regardless.
Governments which insist on maintaining such policies can evolve or
perish :-)

All that said, I'm not conviced DNS is the right infrastructure.  But
you'll need to come up with some better objections.

		Marc

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 15 Sep 97 11:50:24 -0400
Subject: Re: The purpose of this mailing list
To: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

In <[email-masked]>, on 09/15/97 
   at 11:56 AM, Marc Horowitz <[email-masked]> said:

>Jon Callas <[email-masked]> writes:

>>> The biggest advantage of a PGP cert has is the way that it is "agile" as
>>> I've heard some people call it. If you want to look at how you fit PGP into
>>> a world that thinks names are important, you can use an email address as a
>>> DN. If you want to use PGP in a name where keys are important, use the
>>> fingerprint (or key proper) as a DN. No biggie. In fact, one of the central
>>> points of the way the web of trust is organized relates directly to
>>> resolving this apparent dichotomy. The PGP software, since its earliest
>>> days, manages this apparent dichotomy. The beauty of PGP as a PKI is that
>>> it can easily bridge an X.509-like, name-centric world to a SPKI-like,
>>> key-centric world.

>I see one problem with this approach, and that is in looking up keys. If
>we use the email address as the DN, then DNS will make an excellent
>mechanism for looking up keys.  Of course, email addresses have certain
>problems as DN's, as Carl will point out of I don't.  If we think of the
>key as the DN, then we avoid those problems, but create a different one:
>given a signature, how do I find the key to use to verify it?  Past
>solutions are to carry certs around within every message, which is
>inefficient, or to have a global index, which doesn't scale.

>We need to solve this problem.  One option which comes to mind is to
>include a "domain name" for the a pgp cert RR with the message instead of
>the cert itself; this does not need to be signed, as the message
>verification will fail if it is modified.  Unfortunately, this has the
>problem that cert domain names may change or go away, making verification
>in the future difficult unless a long-term cert cache is kept near the
>message.

I see some serious problems with using the DNS for key lookups &
distribution.

- -- What do we do with keys than do not have a "domain"?

- -- What do we do with sites that do not wish to manage PGP keys?
(currently the PKI is being done on a volentary basis).

- -- How do we solve the problem of redundance? ie where are the backups?

- -- How do we handle keys that cover multiple domains?

- -- What do we do about domains where PGP is illegal?? (Russia, France,
China, Cuba, ...)

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

To: Jon Callas <[email-masked]>
Cc: Ian Brown <[email-masked]>, Charles Breed <[email-masked]>, [email-masked]
Subject: Re: The purpose of this mailing list
From: Marc Horowitz <[email-masked]>
Date: 15 Sep 1997 11:56:35 -0400
Lines: 32
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

>> The biggest advantage of a PGP cert has is the way that it is "agile" as
>> I've heard some people call it. If you want to look at how you fit PGP into
>> a world that thinks names are important, you can use an email address as a
>> DN. If you want to use PGP in a name where keys are important, use the
>> fingerprint (or key proper) as a DN. No biggie. In fact, one of the central
>> points of the way the web of trust is organized relates directly to
>> resolving this apparent dichotomy. The PGP software, since its earliest
>> days, manages this apparent dichotomy. The beauty of PGP as a PKI is that
>> it can easily bridge an X.509-like, name-centric world to a SPKI-like,
>> key-centric world.

I see one problem with this approach, and that is in looking up keys.
If we use the email address as the DN, then DNS will make an excellent
mechanism for looking up keys.  Of course, email addresses have
certain problems as DN's, as Carl will point out of I don't.  If we
think of the key as the DN, then we avoid those problems, but create a
different one: given a signature, how do I find the key to use to
verify it?  Past solutions are to carry certs around within every
message, which is inefficient, or to have a global index, which
doesn't scale.

We need to solve this problem.  One option which comes to mind is to
include a "domain name" for the a pgp cert RR with the message instead
of the cert itself; this does not need to be signed, as the message
verification will fail if it is modified.  Unfortunately, this has the
problem that cert domain names may change or go away, making
verification in the future difficult unless a long-term cert cache is
kept near the message.

		Marc

Date: Mon, 15 Sep 1997 11:00:32 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: The purpose of this mailing list
Sender: [email-masked]

> From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
> 1) For the forseeable future, key/cert servers must be able to respond to both
>    "traditional" (PGPv5) requests and x.509 requests
> 2) This means that the server will need to be able to recognize a x.509 request
> 2a)This could require a special "x.509 request"
> 2b)or assume anything that is not "traditional" is x.509 (not a great idea).
> 
> As a result, for near term I would expect a server to be able to create both
> types of replies. Further would expect this to be a separate module or wrapper.
> 
> Since thusfar I have not seen any mention of a "request standard", would like
> to add this subject.
> 						Warmly,
> 							Padgett

The certificate retrieval protocols for X.509 are being hashed out
in the PKIX and ASID working groups, and LDAP certificate servers are
being rapidly rolled out by the big web server vendors and the big
PC LAN vendors.

Perhaps it would be cleaner for a keyserver machine to run a separate
PGP keyserver and LDAP X.509 certificate server, instead of trying
to merge both into a single executable and/or a single protocol
specification.  If open-PGP will support X.509 as a means of appealing
to commercial installations, open-PGP clients will have be able to
talk to the directories in use at those installations.  A PGP-specific
X.509 certificate retrieval protocol is likely to be a non-starter
in corporate environments, and developing one is probably not a good
use of this working group's time.

Date: Sat, 13 Sep 1997 12:46:00 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: The purpose of this mailing list
Sender: [email-masked]

On Fri, 12 Sep 1997, Jon Callas wrote:

> But wait, there's more. If you have two PGP certs that contain the same key
> material, PGP will merge them. I think this needs to change sooner or
> later, but that's the way things are presently. So from this aspect, the
> truest DN is the key itself. The notion that the fingerprint or key itself
> is the truest DN sounds pretty SPKI/SDSI-like to me. 

The key material is now separated into the DSS section and the DH section.
What if the DSS is the same and the DH is different - does PGP merge them
or not?  Which DH material should it use?  It may be able to handle
multiple userIDs, but what about multiple subkeys?

> The biggest advantage of a PGP cert has is the way that it is "agile" as
> I've heard some people call it. If you want to look at how you fit PGP into
> a world that thinks names are important, you can use an email address as a
> DN. If you want to use PGP in a name where keys are important, use the
> fingerprint (or key proper) as a DN. No biggie. In fact, one of the central
> points of the way the web of trust is organized relates directly to
> resolving this apparent dichotomy. The PGP software, since its earliest
> days, manages this apparent dichotomy. The beauty of PGP as a PKI is that
> it can easily bridge an X.509-like, name-centric world to a SPKI-like,
> key-centric world.

Exactly - I was trying to get at this point.  If I take some of the
existing code handling X509 certs and replace that engine with one that
uses a PGP superset, maybe stretching the introducers model a little so
that CA chains would work like X509 intends, I have one program that can
handle both models.  If it sees an X509, it just checks the signature
chain such that the root CA is adequate to propogate trust.  If it sees a
PGPish cert, it asks a keyserver or user as necessary. 

Date: Sat, 13 Sep 1997 12:36:34 -0400
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: X.509 and PGP (was: The purpose of this mailing list)
Sender: [email-masked]

On Fri, 12 Sep 1997, Hal Finney wrote:

> X.509 V3 does not require distinguished names.  You can use alternate
> names and leave the DN field blank.  It should be possible to put the
> PGP userid in as one of the alternate name forms, probably an email name.
> So the PGP->X509V3 direction seems simple enough as far as converting just
> the data in old certs.
> 
> Some issues remain:
> 
>  - Signature verification is the difficult one.  Even if we can structurally
>    reformat the information in PGP certs into an X.509 arrangement, the PGP
>    signatures are not going to validate once the data is reformatted.  For
>    importing 509 into PGP, we could specify a new signature type which meant
>    to use 509 formatting for the sig verification.  But going from PGP to
>    509 using legacy PGP certs looks impossible.

My thought is more to find places where X509 calls are made and fake an
X509 library that uses the PGP WoT model.  Integrating with everything
else in fully standard format woudl be difficult, but at the point where
there is a callback when there is a failure (when something says it
doesn't recognize the authority that signed the cert), install a second
mechanism.

>  - People may want to put more information into PGP certs than just email
>    address and common name.  For those, the kinds of extensions proposed
>    by Charles Breed seem useful.
> 
>  - People may want to convert 509 certs to PGP and keep the various extension
>    fields and DN tricks which have been used for policies and such.  Here is
>    a test 509 cert which one of our employees got from Entrust last year,
>    decoded:

I used the SSLeay certificate oneline as the "userid" string when going to
PGP, and do some parsing for the common name and email going the other
way.  Quick and dirty, but PGP seems good at extracting the data.

Date: Sat, 13 Sep 97 14:51 GMT+0200
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Subject: Re: Elgamal != DH
Organization: =?ISO-8859-1?B?SW5zdGl0dXQgPT9JU08tODg1OS0xP1E/Zj1GQ3JfdmVyc2Nodz1GNnJ1bmdzdGhlb3JldGlzY2hlPz0gSW5mb3JtYXRpaw==?=
Sender: [email-masked]

Hal Finney <[email-masked]>:

> In the past, Adam and I have discussed the question of how proper it is
> to refer to ElGamal as a variant of Diffie-Hellman.  This is an issue of
> terminology and people may differ in their preferred usage.

> In my opinion, DH strictly refers to a key exchange algorithm which
> requires messages to flow both ways,

In the scheme presented in the Diffie-Hellman journal paper, _all_ the
public parameters  y_user (= g^x_user MOD p)  are stored in a public
directory (and everybody uses the same prime and generator).  The
secret value  y_Alice ^ x_Bob = y_Bob ^ x_Alice  (mod p), which is
known only to Alice and Bob and can be used as a symmetric key, is
thus fixed, and no messages at all (not counting access to the public
directory) have to flow to compute it.

The patent (R.I.P.), which lists Diffie, Hellman and Merkle as
inventors, describes the exchange algorithm where all x's and y's are
ephemeral.  I think the text also mentions the variant where the
recipient's parameters are fixed and only the sender creates new
values (like in ElGamal-encryption), but this is described as a means
to obtain "authentication": The sender can be sure that only the
intended recipient, and no "man in the middle", can compute the
symmetric key y^x.  (This use of the word "authentication" may appear
a little strange today, but of course all the literature about public
key cryptography, digital signatures etc. did not yet exist then, so
Diffie et al. can't be blamed.)

ElGamal added the idea to use the symmetric key  k = y^x MOD p
directly for Vernam encryption.  (Vernam encryption can be done in any
finite group, not just in ({0,1}^n, XOR).  ElGamal's paper proposes
the groups ((Z/pZ)*, *) and (Z/pZ, +).)

Collecting all those names, ElGamal's encryption algorithm could be
called the Diffie-Hellman-Merkle-Vernam-ElGamal algorithm.
If that appears too long, "ElGamal encryption" is probably most
appropriate.  This naming, however, leads to a new risk: It might
suggest that ElGamal _encryption_ and the ElGamal _signature_ scheme
are basically the same thing (like RSA encryption and RSA signatures
are), while in fact they are two different algorithms.  E.g.,
PGP Inc.'s "Cryptography Reference Chart" (August 1997) claims that
the ElGamal scheme can be "used both for digital signatures and
encryption". But that's not true: ElGamal published _two_ schemes
(both of which use Diffie-Hellman parameters): one for encryption (the
"Diffie-Hellman-Merkle-Vernam-ElGamal" algorithm), and one for
signatures; the latter being the major contribution of his paper.

Bodo Moeller
<[email-masked]>

Date: Fri, 12 Sep 1997 15:09:50 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Elgamal != DH (was Re: The purpose of this mailing list)
Sender: [email-masked]

Adam Back writes:
> Could we call ElGamal ElGamal, please?
>
> It's not just a nit, what happens when someone wants to put real DH
> into the spec, are you going to call it "realDH" or "DH2"?

Actually the algorithm identifiers in the 5.0 source are:

PGP_PKALG_RSA
PGP_PKALG_ELGAMAL
PGP_PKALG_DSA

It has always been called ElGamal in the source.

In the past, Adam and I have discussed the question of how proper it is
to refer to ElGamal as a variant of Diffie-Hellman.  This is an issue of
terminology and people may differ in their preferred usage.

In my opinion, DH strictly refers to a key exchange algorithm which
requires messages to flow both ways, and cannot be used for email in
that form.  There are several ways in which DH can be adapted to the
requirement for one-way communication, which have various pros and cons
with respect to multiple recipients, shared primes, and other issues.
ElGamal is one such method.

It is possible in the future that we could support other forms of
encryption that fall into the DH "family", but I don't think it would
be proper to single any of these out and call it DH to the exclusion
of the others.  So I don't think we will ever have "Diffie-Hellman"
as a public key encryption algorithm.

Hal

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: The purpose of this mailing list
Reply-To: [email-masked]
Date: Sat, 13 Sep 1997 09:28:26 (NZST)
Sender: [email-masked]

Death rays from Mars made Hal Finney <[email-masked]> write:
>At 03:34 PM 9/12/97, Peter Gutmann wrote, quoting tzeruch:
>>>One of my other "stupid PGP tricks" is to convert X.509 to and from PGP
>>>(easier now that X509 has DSS, and maybe DH).  I can't really convert
>>>signatures, but I can move the moduli and other information around.
>> 
>>I've been working on this too.  X.509 -> PGP is doable, but going the other 
>>way is pretty challenging since the only thing in a PGP cert is what might be
>>a commonName, and usually an email address, but not a full DN.  What thoughts
>>do people have on handling the naming issues?
>X.509 V3 does not require distinguished names.  You can use alternate names 
>and leave the DN field blank.  
 
[For non-X.509 types, what you need to do is leave the DN empty and add an 
 altName attribute containing the email address, which is marked as critical 
 so that the program using the cert has to handle the altName]
 
This is a very risky move, because it makes the resulting cert unusable with 
X.500/LDAP directories (I have some comments on this usage in my X.509 style 
guide, http://www.cs.auckland.ac.nz/~pgut001/x509guide.txt).
 
>Here is a test 509 cert which one of our employees got from Entrust last 
>year, decoded:
>[...]
>Note the trick of putting liability statements into the issuer DN!
 
Which is very naughty, and another X.500/LDAP-breaking kludge.  
 
>Another alternative is to use the standard RFC1779 encoding of DN's in ASCII, 
>similar to what I used above, and to directly create userids of the form 
>C=Ca, L=Nepean, OU=No Liability Accepted,...  Then we might get by with just 
>one new userid type (or even use the existing packets and rely on a parser to 
>recognize when RFC1779 is being used).  We wouldn't need multiple new packet 
>types, we'd just use ASCII.
 
Given the rather broken DirectoryString string formats (again, see the 
'guide), you're going to see a lot of Unicode strings in non-English-speaking 
countries which will mean people have to resort to odd encodings like UTF 
variants for RFC 1779-compatibility (I'll have to check to see what 1779 says 
about non-ASCII character sets, but I assume you have to mangle things to get 
7-bit characters).
 
Peter.

Date: Fri, 12 Sep 1997 18:33:32 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Elgamal != DH (was Re: The purpose of this mailing list)
Sender: [email-masked]

Charles Breed <[email-masked]> writes:
> OIDs work fine here. PGP 5.x already has this, RSA, DH, DSA, and DES, 3DES,

Could we call ElGamal ElGamal, please?

It's not just a nit, what happens when someone wants to put real DH
into the spec, are you going to call it "realDH" or "DH2"?

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

Date: Fri, 12 Sep 1997 12:00:39 -0700
To: Ian Brown <[email-masked]>, Charles Breed <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: The purpose of this mailing list
Cc: [email-masked]
Sender: [email-masked]

At 11:57 AM 9/12/97 +0100, Ian Brown wrote:
   b) PGP, in effect, uses e-mail addresses as its DNs. Ultimately, as Carl
   Ellison's SPKI work says, a PGP certificate represents a cyberspace
   entity, not a physical one. The most we can logically certify on a key,
   in a large-scale PKI, is that the public key represents a user within a
   domain who receives e-mail at that address. For example, my public key
   ID is 'Ian Brown <[email-masked]>' - but unless I meet you
   personally and give you a copy of my fingerprint/full key, there is no
   way to make a connection between the virtual and physical me. And
   really, there is little need to. All that is needed - which DNSSEC could
   provide - is a guarantee by the cs.ucl.ac.uk domain that the public key
   you possess really does belong to the person who receives mail at
   [email-masked]. 
   
   However, it will not be nearly as easy if we use a SDSI solution where
   the public key IS the DN. If I receive a PGP-encrypted message and know
   only (say) the key ID, with a distributed system, where do I go to
   retrieve the key? I think if we are to go the SDSI/SPKI route, we need
   to embrace it wholeheartedly - so there just will not be a global
   namespace, and so little need for keyservers.
   
   Apologies if this if gibberish, but trying to reconcile DNSSEC, SDSI,
   SPKI, X.509 and PGP is making my head spin a bit!
   
This isn't gibberish at all. It's closely related to a number of issues
we've been dealing with.

I agree and disagree with your statement, "P, in effect, uses e-mail
addresses as its DNs." I agree in that an Internet Email Address *is* a DN.
There are a couple obvious issues that causes people to stress over
admitting this (for example, multiple people could use a single email
account), but these same issues are there for any other form of DN (let's
face it, even if you solve the DN problem, there are corresponding gray
areas like the DN for the tech support group of XYZcorp, or the fact that
the mail sent to a Famous Person is likely to be read by an aide, in many
households there is one partner whose task it is to do the bills and thus
will read mail addressed to someone else).

Email addresses are DNs, but email addresses are not the sole DN that PGP
uses. A PGP cert can have many email addresses attached to it. Yes, I am
aware of the apparent contradiction of a cert having many DNs. I'll point
you to some of Carl's work on naming, and frankly I don't see a problem
with a cert having multiple DNs, but that's me.

The way that PGP users identify keys is by key fingerprint. Yeah, it also
uses keyid, too, but this is the "real" way that we PGP users verify a key
-- we check fingerprint. So you can consider the fingerprint to be a DN. 

But wait, there's more. If you have two PGP certs that contain the same key
material, PGP will merge them. I think this needs to change sooner or
later, but that's the way things are presently. So from this aspect, the
truest DN is the key itself. The notion that the fingerprint or key itself
is the truest DN sounds pretty SPKI/SDSI-like to me. 

Carl likes to ding PGP for being name-centric, and I hiss at him everytime
he does, because I don't think it is. The last time we talked (last week at
the W3C meeting in Belgium), I pointed out that in his talk he said that
the *only* application of PKC where names are important is email. Well?
What is PGP used most for? What are we trying to grow it past? Email. So
what's the big deal? 

The biggest advantage of a PGP cert has is the way that it is "agile" as
I've heard some people call it. If you want to look at how you fit PGP into
a world that thinks names are important, you can use an email address as a
DN. If you want to use PGP in a name where keys are important, use the
fingerprint (or key proper) as a DN. No biggie. In fact, one of the central
points of the way the web of trust is organized relates directly to
resolving this apparent dichotomy. The PGP software, since its earliest
days, manages this apparent dichotomy. The beauty of PGP as a PKI is that
it can easily bridge an X.509-like, name-centric world to a SPKI-like,
key-centric world.

	Jon

-----
Jon Callas                                         [email-masked]
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065

Comments: Authenticated sender is <ieca2@[205.252.27.1]>
From: "Bonatti Chris" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
Date: Fri, 12 Sep 1997 12:48:03 -0500
Subject: Re: The purpose of this mailing list
Reply-to: [email-masked]
CC: [email-masked]
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

On 12 Sep 1997 02:03:56 -0000, [email-masked] wrote:
> To which I would add a desperate need: some mechanism in which
> to add new algorithms.  This is partly technical: the formats
> of some generic public key method are obviously going to be
> tricky, and the symmetric algorithms require a byte or int
> allocating type.

iang,

     I think you are correct that this is necessary, but we need
to be careful not to start any brush wars.  Are there no
registries of algorithms for other activities that we can
leverage?  If so, we should try to use values (OIDs maybe?)
already established.

     Otherwise, a good direction might be to set up a
framework for IANA to maintain a registry.  This is going to be
a common requirement that, I suspect, will span multiple IETF
activities.

Chris

 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti                 9010 Edgepark Road  |
 |  Vice-president                     Vienna, Virginia 22182  |
 |  [email-masked]   Tel: 301-212-9428   Fax: 703-506-8377  |
 |  PGP public key available from "http://www.ieca.com/"       |
 ---------------------------------------------------------------

Date: Fri, 12 Sep 1997 08:37:58 -0700 (PDT)
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: X.509 and PGP (was: The purpose of this mailing list)
Sender: [email-masked]

[This is a repost of a message from another account, where the email is
getting held or lost.  Apologies if you see it again later.]

At 03:34 PM 9/12/97, Peter Gutmann wrote, quoting tzeruch:
>>One of my other "stupid PGP tricks" is to convert X.509 to and from PGP
>>(easier now that X509 has DSS, and maybe DH).  I can't really convert
>>signatures, but I can move the moduli and other information around.
> 
>I've been working on this too.  X.509 -> PGP is doable, but going the other 
>way is pretty challenging since the only thing in a PGP cert is what might
be 
>a commonName, and usually an email address, but not a full DN.  What
thoughts 
>do people have on handling the naming issues?

X.509 V3 does not require distinguished names.  You can use alternate
names and leave the DN field blank.  It should be possible to put the
PGP userid in as one of the alternate name forms, probably an email name.
So the PGP->X509V3 direction seems simple enough as far as converting just
the data in old certs.

Some issues remain:

 - Signature verification is the difficult one.  Even if we can structurally
   reformat the information in PGP certs into an X.509 arrangement, the PGP
   signatures are not going to validate once the data is reformatted.  For
   importing 509 into PGP, we could specify a new signature type which meant
   to use 509 formatting for the sig verification.  But going from PGP to
   509 using legacy PGP certs looks impossible.

 - People may want to put more information into PGP certs than just email
   address and common name.  For those, the kinds of extensions proposed
   by Charles Breed seem useful.

 - People may want to convert 509 certs to PGP and keep the various extension
   fields and DN tricks which have been used for policies and such.  Here is
   a test 509 cert which one of our employees got from Entrust last year,
   decoded:

        Serial number:
                840717480
        Signature Algorithm:
                MD5 with RSA encryption (1.2.840.113549.1.1.4)
        Issuer name:
                C=Ca                            (country name)
                L=Nepean                        (locality name)
                OU=No Liability Accepted        (organizational unit name)
                O=For Demo Purposes Only        (organizational name)
                CN=Entrust Demo Web CA          (common name)
        Validity:
                Not before:     Thu Aug 22 13:38:00 1996 +0000
                Not after:      Fri Nov 22 12:38:00 1996 +0000
        Subject name:
                C=US                            (country name)
                ST=Michigan                     (state or province name)
                L=Kalamazoo                     (locality name)
                O=I/Net, Inc.                   (organization name)
                OU=Test PKCS 1024               (organizational unit name)
                CN=www.inetmi.com               (common name)

   Note the trick of putting liability statements into the issuer DN!
   509V3 has a different mechanism for this, but I don't know how widely
   used it is yet.  In order to import this kind of cert into PGP, we could
   again use the userid extension fields to capture all this cruft.

Another alternative is to use the standard RFC1779 encoding of DN's in
ASCII, similar to what I used above, and to directly create userids of
the form C=Ca, L=Nepean, OU=No Liability Accepted,...  Then we might get
by with just one new userid type (or even use the existing packets and
rely on a parser to recognize when RFC1779 is being used).  We wouldn't
need multiple new packet types, we'd just use ASCII.

Hal Finney
[email-masked]

Date: 	Fri, 12 Sep 1997 11:05:47 -0400
From: [email-masked]
To: Lindsay Mathieson <[email-masked]>
cc: [email-masked]
Subject: Re: While on the subject of standards
Sender: [email-masked]

On Sat, 13 Sep 1997, Lindsay Mathieson wrote:

> >but do not see any requirement for key escrow
> >or recovery
> 
> Nor should there be - that is a political issue, and nothing to do with IETF,
> PGP or non-us parties.
> 

I agree with you totally. There several other places where that discussion
should be held...let's not get distracted on the project at hand.

regards

robert

Date: Fri, 12 Sep 1997 07:33:22 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: The purpose of this mailing list
Sender: [email-masked]

At 03:34 PM 9/12/97, Peter Gutmann wrote, quoting tzeruch:
>>One of my other "stupid PGP tricks" is to convert X.509 to and from PGP
>>(easier now that X509 has DSS, and maybe DH).  I can't really convert
>>signatures, but I can move the moduli and other information around.
> 
>I've been working on this too.  X.509 -> PGP is doable, but going the other 
>way is pretty challenging since the only thing in a PGP cert is what might
be 
>a commonName, and usually an email address, but not a full DN.  What
thoughts 
>do people have on handling the naming issues?

X.509 V3 does not require distinguished names.  You can use alternate
names and leave the DN field blank.  It should be possible to put the
PGP userid in as one of the alternate name forms, probably an email name.
So the PGP->X509V3 direction seems simple enough as far as converting just
the data in old certs:

Some issues remain:

 - Signature verification is the difficult one.  Even if we can structurally
   reformat the information in PGP certs into an X.509 arrangement, the PGP
   signatures are not going to validate once the data is reformatted.  For
   importing 509 into PGP, we could specify a new signature type which meant
   to use 509 formatting for the sig verification.  But going from PGP to
   509 using legacy PGP certs looks impossible.

 - People may want to put more information into PGP certs than just email
   address and common name.  For those, the kinds of extensions proposed
   by Charles Breed seem useful.

 - People may want to convert 509 certs to PGP and keep the various extension
   fields and DN tricks which have been used for policies and such.  Here is
   a test 509 cert which one of our employees got from Entrust last year,
   decoded:

	Serial number:
		840717480
	Signature Algorithm:
		MD5 with RSA encryption (1.2.840.113549.1.1.4)
	Issuer name:
		C=Ca				(country name)
		L=Nepean			(locality name)
		OU=No Liability Accepted	(organizational unit name)
		O=For Demo Purposes Only	(organizational name)
		CN=Entrust Demo Web CA		(common name)
	Validity:
		Not before:	Thu Aug 22 13:38:00 1996 +0000
		Not after:	Fri Nov 22 12:38:00 1996 +0000
	Subject name:
		C=US				(country name)
		ST=Michigan			(state or province name)
		L=Kalamazoo			(locality name)
		O=I/Net, Inc.			(organization name)
		OU=Test PKCS 1024		(organizational unit name)
		CN=www.inetmi.com		(common name)

   Note the trick of putting liability statements into the issuer DN!
   509V3 has a different mechanism for this, but I don't know how widely
   used it is yet.  In order to import this kind of cert into PGP, we could
   again use the userid extension fields to capture all this cruft.

Another alternative is to use the standard RFC1779 encoding of DN's in
ASCII, similar to what I used above, and to directly create userids of
the form C=Ca, L=Nepean, OU=No Liability Accepted,...  Then we might get
by with just one new userid type (or even use the existing packets and
rely on a parser to recognize when RFC1779 is being used).  We wouldn't
need multiple new packet types, we'd just use ASCII.

Hal Finney
[email-masked]

CC: [email-masked]
Date: 13 Sep 1997 13:21:39 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: While on the subject of standards
To: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Sender: [email-masked]

--=====================806638704==_0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;charset=us-ascii

>but do not see any requirement for key escrow
>or recovery

Nor should there be - that is a political issue, and nothing to do with IETF,
PGP or non-us parties.

--
Lindsay Mathieson
Black Paw Communications
	http://www.blackpaw.com/

--=====================806638704==_0
Content-Transfer-Encoding: 7bit
Content-Type: text/x-vcard;charset=us-ascii

begin:	vcard
fn:	Lindsay Mathieson
n:	Lindsay Mathieson;;;
email;pref;internet:	Lindsay Mathieson <[email-masked]>
org:	Black Paw Communications
mailer:	Black Paw Communications's MailCat for Win32 Beta Release Vs 2.6
end:	vcard

--=====================806638704==_0--

Date: Fri, 12 Sep 1997 9:07:15 -0400 (EDT)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
To: [email-masked]
Subject: While on the subject of standards
Sender: [email-masked]

If PGP wishes to succeed in the commercial marketplace, there is another
standard that must be considered: FIPS-140. Increasingly I am seeing contracts
which have provisions for secure tranmittals which requires this. I would not
like to see PGP suceed in becoming an IETF standard but be abandoned for
failure to meet.

Have not read the whole thing yet but do not see any requirement for key escrow
or recovery, most onerous is DES/Triple-DES but that should be something already
in consideration as an add-in.

						Warmly,
							Padgett

Date: Fri, 12 Sep 1997 8:56:02 -0400 (EDT)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: The purpose of this mailing list
Sender: [email-masked]

Agree & would like to make a comment reguarding key/cert servers as a result
of some rumours I am hearing:

1) For the forseeable future, key/cert servers must be able to respond to both
   "traditional" (PGPv5) requests and x.509 requests
2) This means that the server will need to be able to recognize a x.509 request
2a)This could require a special "x.509 request"
2b)or assume anything that is not "traditional" is x.509 (not a great idea).

As a result, for near term I would expect a server to be able to create both
types of replies. Further would expect this to be a separate module or wrapper.

Since thusfar I have not seen any mention of a "request standard", would like
to add this subject.
						Warmly,
							Padgett

ps PGP so far has skated the issue of Viacrypt and Business Edition (4.0 &
   last year's 4.5). Am curious what the intention is particularly with respect
   to platforms *other* than MS W95/NT and Macintosh.

Date: Fri, 12 Sep 1997 11:59:35 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: Charles Breed <[email-masked]>
CC: [email-masked]
Subject: Re: The purpose of this mailing list
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Ye, spotted some gibberish already...

> If I receive a PGP-encrypted message and know
> only (say) the key ID, with a distributed system, where do I go to
> retrieve the key?

Of course, I meant if I receive a PGP-SIGNED message and want to check
the signature.

Ian.

Date: Fri, 12 Sep 1997 11:57:16 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: Charles Breed <[email-masked]>
CC: [email-masked]
Subject: Re: The purpose of this mailing list
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

> As the chief instigator of "Open-PGP", I intended this 'soon-to-be' 
> Working Group to specify the following...
> ...
> 2. PGP as a Public Key (Cert) Infrastruture

How is the DNSSEC group going on its work to allow public keys to be
supplied by the DNS? This would seem a good method of PGP keyserving,
as:

a) It is totally distributed - there is no way the current system of
replicated master keyservers will scale to the millions and millions of
users we are aiming for;

b) PGP, in effect, uses e-mail addresses as its DNs. Ultimately, as Carl
Ellison's SPKI work says, a PGP certificate represents a cyberspace
entity, not a physical one. The most we can logically certify on a key,
in a large-scale PKI, is that the public key represents a user within a
domain who receives e-mail at that address. For example, my public key
ID is 'Ian Brown <[email-masked]>' - but unless I meet you
personally and give you a copy of my fingerprint/full key, there is no
way to make a connection between the virtual and physical me. And
really, there is little need to. All that is needed - which DNSSEC could
provide - is a guarantee by the cs.ucl.ac.uk domain that the public key
you possess really does belong to the person who receives mail at
[email-masked]. 

However, it will not be nearly as easy if we use a SDSI solution where
the public key IS the DN. If I receive a PGP-encrypted message and know
only (say) the key ID, with a distributed system, where do I go to
retrieve the key? I think if we are to go the SDSI/SPKI route, we need
to embrace it wholeheartedly - so there just will not be a global
namespace, and so little need for keyservers.

Apologies if this if gibberish, but trying to reconcile DNSSEC, SDSI,
SPKI, X.509 and PGP is making my head spin a bit!

Ian.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: The purpose of this mailing list
Cc: [email-masked]
Reply-To: [email-masked]
Date: Fri, 12 Sep 1997 18:43:38 (NZST)
Sender: [email-masked]

>PS: I'd like to see at least one EC in the list of "MAY" asymmetric algos. 
 
You have to be *very* careful about this, because there are so many variables 
and parameters involved (field type, representation, field parameters, use of 
point compression, etc etc) that unless you decide on some useful constraints 
you'll end up with either specific, optimised implementations which don't 
interoperate because they use different parameters than everyone else, or 
incredibly complex and inefficient general-purpose solutions.  I think the 
best approach would be to take P1363 and define an interoperability profile 
for PGP (MUST use this field type, this curve, point compression, etc etc).  A 
good meet-in-the-middle approach is to take an existing, high-quality PD 
implementation which anyone can use, an example being George Barwood's pegwit 
code (there's a link to it somewhere on 
http://www.cs.auckland.ac.nz/~pgut001/links.html), and defining the parameters 
to match what the implementation does.  This sets a basic level of EC support 
which is required to interoperate, and simultaneously provides an 
implementation of the base level which anyone can use.
 
Peter.

Date: Thu, 11 Sep 1997 23:21:14 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: Re: The purpose of this mailing list
Cc: [email-masked]
Sender: [email-masked]

Good comments for the list, 

I suggest a "Capabilities Attribute" that's self-signed and dated to notify
the other party of changes (sound familiar?). I could not care less if
someone wants to use patented $$$ algorithms, as long as it's NOT a "MUST".
OIDs work fine here. PGP 5.x already has this, RSA, DH, DSA, and DES, 3DES,
IDEA, CAST, with MD5, SHA-1.... I think we should have DH with DSA, SHA-1
and either 3DES or CAST as a MUST, all else is fair game, but not required.
PGP Inc does not want to dictate this list of algorithms, that's what the
working group will decide. PS: I'd like to see at least one EC in the list
of "MAY" asymmetric algos.

CB

At 02:03 AM 9/12/97 -0000, [email-masked] wrote:
>Charles,
>
>Good list.
>
>To which I would add a desperate need: some mechanism in which to
>add new algorithms.  This is partly technical: the formats of some
>generic public key method are obviously going to be tricky, and the
>symmetric algorithms require a byte or int allocating type.
>
>It's partly managerial: somebody's got to do the work of holding the
>list of numbers, and allocating new ones.  A cryptographic Jon Postel
>as it where.
>
>And it's partly political: someone has got to avoid the various
>rent-seekers and other squeezers of this world, such that a purely
>socio-technical benefit is achieved.
>
>Maybe this isn't what you intended for the list, but it is something
>that has dogged the members of the Cryptix Development Team in the
>past:  no way to consistently add a new algorithm.  By the end of
>the year, we will have more than 10 algorithms that we want to put
>into a new version of PGP code.  How?  A mystery so far.
>
>Whilst on the subject, I'm not sure it is appropriate for PGP, Inc to
>perform this function.  We need someone outside the US.  Also PGP,
>Inc and the predecessor team have a record for secrecy that the NSA
>would kill for.  Not that this is entirely their fault, but history
>cannot be changed, and it's simply not helpful to the coder.
>
>-- 
>iang
>[email-masked]
>
>

Date: Thu, 11 Sep 1997 23:10:00 -0700
To: [email-masked], [email-masked]
From: Charles Breed <[email-masked]>
Subject: Re: The purpose of this mailing list
Cc: [email-masked]
Sender: [email-masked]

Well, let's look at the most recent S/MIME draft dated Sept 5th. Cert
handling, section 3.1, internet mail address MUST be used as DN, hmmm,
sounds like old PGP. I posted some extensions for the naming conventions a
while ago, and got some possitive response (besides the ASN.1 encoding
example). Open-PGP should use the Pub.Key as Distinguished Name or
Principle (as in SDSI), then you can put whatever in the identity /
authorization field for binding to the key by a signer.

CB

At 03:34 PM 9/12/97, Peter Gutmann wrote:
>>One of my other "stupid PGP tricks" is to convert X.509 to and from PGP
>>(easier now that X509 has DSS, and maybe DH).  I can't really convert
>>signatures, but I can move the moduli and other information around.
> 
>I've been working on this too.  X.509 -> PGP is doable, but going the other 
>way is pretty challenging since the only thing in a PGP cert is what might
be 
>a commonName, and usually an email address, but not a full DN.  What
thoughts 
>do people have on handling the naming issues?
> 
>BTW there's an X.509 profile for ElGamal as well as of a week or two ago, 
>check your local internet drafts repository for draft-gutmann-<something
with 
>'elgamal' in it>.
> 
>Peter.
>
>
>

Date: Thu, 11 Sep 1997 20:56:34 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Converting X.509 and PGP certs
Sender: [email-masked]

At 8:34 AM -0700 9/12/97, Peter Gutmann wrote:
>BTW there's an X.509 profile for ElGamal as well as of a week or two ago,
>check your local internet drafts repository for draft-gutmann-<something with
>'elgamal' in it>.

Not quite. It's "draft-rfced-info-pgutmann-00.txt", also available from IMC
as <http://www.imc.org/draft-rfced-info-pgutmann>.

Separately, I think any work on full interchange between PGP v3 and v4
certs and X.509 v3certs would be very helpful to the OpenPGP effort.

--Paul E. Hoffman, Director
--Internet Mail Consortium

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: The purpose of this mailing list
Cc: [email-masked]
Reply-To: [email-masked]
Date: Fri, 12 Sep 1997 15:34:47 (NZST)
Sender: [email-masked]

>One of my other "stupid PGP tricks" is to convert X.509 to and from PGP
>(easier now that X509 has DSS, and maybe DH).  I can't really convert
>signatures, but I can move the moduli and other information around.
 
I've been working on this too.  X.509 -> PGP is doable, but going the other 
way is pretty challenging since the only thing in a PGP cert is what might be 
a commonName, and usually an email address, but not a full DN.  What thoughts 
do people have on handling the naming issues?
 
BTW there's an X.509 profile for ElGamal as well as of a week or two ago, 
check your local internet drafts repository for draft-gutmann-<something with 
'elgamal' in it>.
 
Peter.

From: [email-masked]
Date: 12 Sep 1997 02:03:56 -0000
To: [email-masked]
Subject: Re: The purpose of this mailing list
Cc: [email-masked]
Sender: [email-masked]

Charles,

Good list.

To which I would add a desperate need: some mechanism in which to
add new algorithms.  This is partly technical: the formats of some
generic public key method are obviously going to be tricky, and the
symmetric algorithms require a byte or int allocating type.

It's partly managerial: somebody's got to do the work of holding the
list of numbers, and allocating new ones.  A cryptographic Jon Postel
as it where.

And it's partly political: someone has got to avoid the various
rent-seekers and other squeezers of this world, such that a purely
socio-technical benefit is achieved.

Maybe this isn't what you intended for the list, but it is something
that has dogged the members of the Cryptix Development Team in the
past:  no way to consistently add a new algorithm.  By the end of
the year, we will have more than 10 algorithms that we want to put
into a new version of PGP code.  How?  A mystery so far.

Whilst on the subject, I'm not sure it is appropriate for PGP, Inc to
perform this function.  We need someone outside the US.  Also PGP,
Inc and the predecessor team have a record for secrecy that the NSA
would kill for.  Not that this is entirely their fault, but history
cannot be changed, and it's simply not helpful to the coder.

-- 
iang
[email-masked]

Date: Thu, 11 Sep 1997 18:26:18 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: The purpose of this mailing list
Sender: [email-masked]

At 5:54 PM -0700 9/11/97, Charles Breed wrote:
>	2. PGP as a Public Key (Cert) Infrastruture
>(we have *lots* of real life experience at MIT, and other places worldwide)

Thanks for clarifying this. My comment earler about the key server lookup
protocol not being germain was from not seeing anything like it in the
charter. If you as the charter writer think that this was covered, and the
rest of the group agrees (as most of the folks have), then it should
certainly be part of the work. As folks who have worked in other IETF
Working Groups know, things that were "meant" to be in the charter but not
stated early in the process usually get forgotten.

>	4. handling MIME

Jon and I just talked, and we agreed that his earlier statement that this
group was not supposed to do the follow-on to PGP/MIME was a
misunderstanding. PGP/MIME is the description of handling PGP objects in
MIME, and is thus appropriate for the group to discuss. It's certainly one
part of what we're doing here.

>This might sound like way-too-much for the group to handle...

Well, at least you didn't put the PGP API in the list. :-)

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Thu, 11 Sep 1997 17:54:37 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: Re: The purpose of this mailing list
Sender: [email-masked]

   As the chief instigator of "Open-PGP", I intended this 'soon-to-be' 
   Working Group to specify the following...

	1. PGP Cert (a.k.a. Key) Structure (including X.509 support)
	2. PGP as a Public Key (Cert) Infrastruture
(we have *lots* of real life experience at MIT, and other places worldwide)
	2. MUST algorithms for interoperability
	3. correct use of the Trust Models
	4. handling MIME
	5. limited backwards compatibility with 2.6, 5.x
	6. and of course, basic functionality of encrypt, sign, decrypt, verify

This might sound like way-too-much for the group to handle, but if we keep
to the basics on each topic, and leverage the implementation work that is
already done, we can move forward quickly. PGP is already the world's
largest PKI, we need to document and make modest enhancements. By having
few dependencies on other incomplete specification, Open-PGP will have
great benefit by being self contained. (I know I'll be slammed for bring it
up, but S/MIME relies on PKCS#1-10, ANSI, CCITT/ITU X.509V3, PKIX, RSASDI
and more.) Once the Open-PGP spec is complete, implement to the spec, and
compete in an open and fair market.

Charles

Date: Thu, 11 Sep 1997 18:55:10 -0400
From: [email-masked]
To: Bonatti Chris <[email-masked]>
cc: [email-masked]
Subject: Re: The purpose of this mailing list
Sender: [email-masked]

On Thu, 11 Sep 1997, Bonatti Chris wrote:

> On Thu, 11 Sep 1997 10:56:06 +0100, Ian Brown wrote:
> >
> > Here's an ideal opportunity to tie both of these threads
> > together. A next generation keyserver could store multiple keys
> > for a user, but be able to specify their preferred one. This
> > would allow both selection of algorithm and preferred key for
> > receiving correspondence, while allowing other keys needed to
> > check signatures etc. to be retrieved if necessary.
> 
> This is the best idea yet.  It kills 2 bird with one stone.
> This approach would suggest a requirement for certificate
> structures.
> 
> BTW, I've seen some messages regarding X.509 certificates posted
> (both pro and con).  I guess my feeling is that whatever we
> develop should be flexible enough to work with a variety of
> public key management schemes.  Large organizations are probably

One of my other "stupid PGP tricks" is to convert X.509 to and from PGP
(easier now that X509 has DSS, and maybe DH).  I can't really convert
signatures, but I can move the moduli and other information around.

The keyserver protocol is important since I can then integrate the web of
trust into SSL, or do the converse, get an X509 certificate to act as a
PGP keyring including adding that to the WoT.  In some ways, with a few
tweaks of the Wot model, the CA hierarchy becomes a subset.  So I store a
root key or to (mainly for caching) and then calculate validity based on
what the keyservers say as to who signed who.

Comments: Authenticated sender is <ieca2@[205.252.27.1]>
From: "Bonatti Chris" <[email-masked]>
Organization: IECA, Inc.
To: Marla Pereira <[email-masked]>
Date: Thu, 11 Sep 1997 18:35:51 -0500
Subject: Re: The purpose of this mailing list
Reply-to: [email-masked]
CC: [email-masked]
Sender: [email-masked]

> From:          Marla Pereira <[email-masked]>
> Date:          Thu, 11 Sep 1997 15:13:02 -0700
> To:            [email-masked], [email-masked]
> Subject:       Re: The purpose of this mailing list
> Cc:            [email-masked], [email-masked], 
>                  [email-masked]
> 
> hi guys - how do you get off this mailing list??? I have sent
> three requests already to be removed from the list but there is
> no indication that there is anybody on the other end?!? Please
> send suggestions! -- [email-masked]

Marla,

     You should send a message to you can send mail to 
[email-masked] with the following command in the body of the 
message.

unsubscribe ietf-open-pgp [email-masked]

That should do the trick.

Chris

 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti                 9010 Edgepark Road  |
 |  Vice-president                     Vienna, Virginia 22182  |
 |  [email-masked]   Tel: 301-212-9428   Fax: 703-506-8377  |
 |  PGP public key available from "http://www.ieca.com/"       |
 ---------------------------------------------------------------

From: Marla Pereira <[email-masked]>
Date: Thu, 11 Sep 1997 15:13:02 -0700
To: [email-masked], [email-masked]
Subject: Re: The purpose of this mailing list
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

hi guys - how do you get off this mailing list??? I have sent
three requests already to be removed from the list but there is
no indication that there is anybody on the other end?!?
Please send suggestions!
-- [email-masked]

Comments: Authenticated sender is <ieca2@[205.252.27.1]>
From: "Bonatti Chris" <[email-masked]>
Organization: IECA, Inc.
To: Ian Brown <[email-masked]>
Date: Thu, 11 Sep 1997 17:31:25 -0500
Subject: Re: The purpose of this mailing list
Reply-to: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 11 Sep 1997 10:56:06 +0100, Ian Brown wrote:
>
> Here's an ideal opportunity to tie both of these threads
> together. A next generation keyserver could store multiple keys
> for a user, but be able to specify their preferred one. This
> would allow both selection of algorithm and preferred key for
> receiving correspondence, while allowing other keys needed to
> check signatures etc. to be retrieved if necessary.
>

This is the best idea yet.  It kills 2 bird with one stone.
This approach would suggest a requirement for certificate
structures.

BTW, I've seen some messages regarding X.509 certificates posted
(both pro and con).  I guess my feeling is that whatever we
develop should be flexible enough to work with a variety of
public key management schemes.  Large organizations are probably
going to benefit from hierarchical certificate management
offered by a X.509.  However, the level of infrastructure
required can be very hard to bootstrap.  I would not want either
side of this issue to become a barrier to Open-PGP acceptance.
Thus I think our trust model should be flexible enough to
embrace X.509 and web-of-trust.

Chris

 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti                 9010 Edgepark Road  |
 |  Vice-president                     Vienna, Virginia 22182  |
 |  [email-masked]   Tel: 301-212-9428   Fax: 703-506-8377  |
 |  PGP public key available from "http://www.ieca.com/"       |
 ---------------------------------------------------------------

Date: Thu, 11 Sep 1997 10:56:06 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: "William H. Geiger III" <[email-masked]>
CC: Rodney Thayer <[email-masked]>, [email-masked], [email-masked]
Subject: Re: The purpose of this mailing list
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

William H. Geiger wrote:

> Perhaps we need to create a draft RFC and working group on PGP keyserver
> protocols as it seems the only ones making an decisions on this is PGP
> Inc.

Robert Guerra wrote:

> With the advent of several different ways to encrypt & Sign pgp messages,
> i'd like to know if it might be a good idea to specify a preffered "method"
> which should be used in "answering" an encoded message.

Here's an ideal opportunity to tie both of these threads together. A
next generation keyserver could store multiple keys for a user, but be
able to specify their preferred one. This would allow both selection of
algorithm and preferred key for receiving correspondence, while allowing
other keys needed to check signatures etc. to be retrieved if necessary.

Ian :D

Date: Wed, 10 Sep 1997 14:25:56 -0700
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: The purpose of this mailing list
Sender: [email-masked]

At 07:45 PM 9/9/97 -0700, Paul Hoffman / IMC wrote:
   This mailing list is for discussion of the next-generation of PGP/MIME. We
   should be creating and discussing descriptions of that protocol.
   
   The discussions of the last few days (key server lookup protocol, API) are
   not really relevant to the OpenPGP spec. Disucssions about how a particular
   implementation of PGP work should be on the PGP developer's mailing list,
   not here. (I don't remember where that mailing list is, and it doesn't seem
   to be mentioned on the PGP, Inc. Web site, so if someone wants to pipe in
   with the address of that list, it would be very helpful.)
   
I disagree completely. This is *NOT* the mailing list for the
next-generation of PGP-MIME. This is the mailing list for OpenPGP. That's
why it's called the "ietf-open-pgp" mailing list.

I think that it's completely germane for the OpenPGP list to discuss the
OpenPGP spec, including key server protocols. What purpose do you think the
OpenPGP mailing list should be serving other than discussions of OpenPGP?

	Jon

-----
Jon Callas                                         [email-masked]
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 10 Sep 97 12:27:36 -0400
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: handling of different encryption methods..?
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

In <[email-masked]>,
on 09/10/97 
   at 11:53 AM, <[email-masked]> said:

>---------- Forwarded message ----------

>With the advent of several different ways to encrypt & Sign pgp messages,
>i'd like to know if it might be a good idea to specify a preffered
>"method" which should be used in "answering" an encoded message.

>An example (using pgp 5.0 & Eudora Plug-in):

>1.A encrypts & signs a message with RSA and sends it to B.
>2.B decodes the message, and writes a reply to A's message
>3.When message is processed by eudora/pgp a problem arises....A has two
>public keys..A RSA key and a DH/DSS key...which one should be used..?

>(one can decide to use both keys, and leave it up to A to
>decode...however A may "prefer" one method...)

>Thus, if it would be possible to encorporate a "preferred
>encrytion/signing method" then the selection of which key/encrytion
>method  might
> be able to be done automatically...

>I mentioned this a while ago to the folks at pgp, and would be interested
>in hearing what the mailing list thinks...

I have something like this with my current PGP implementation.
Unfortunately it's not very automatic. My users have the ability to set a
default key for an e-mail address. This was neccessary as quite often one
will find multiple keys with the same e-mail address in the Userid's.

Automatic determining of how to sign a message is tricky. 

- -- The simplest is just to use MD5/PGP2.6.x method of signing as everyone
regardless of version can verify these signatures. 

- -- Use PGP/MIME and sign the message in parallel in both formats. This
will cause problems with those unable to verify PGP/MIME signatures.

- -- Clear sign the message using standard PGP 2.6.x format then PGP/MIME
sign the message using the PGP 5.0 key. This would give the user the
greatest flexibility but I am sure there will be a few that will squawk
over this. :)

- -- Lookup the receivers key and check and see what type it is then use a
corresponding signature format. Much more work involved here as it would
require communication with the servers for each signature. It also does
not address the issue of a receiver having both types of keys nor the
issue of signed messages going to a group of people.

The current situation of PGP 2.6.x/RSA/MD5 & PGP 5.0/DSS/SHA1 is a real
PITA. It has added quite a bit of complication to PGP integration efforts.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: 	Wed, 10 Sep 1997 12:53:20 -0400
From: <[email-masked]>
To: [email-masked]
Subject:  handling of different encryption methods..?
Sender: [email-masked]

---------- Forwarded message ----------

With the advent of several different ways to encrypt & Sign pgp messages,
i'd like to know if it might be a good idea to specify a preffered "method"
which should be used in "answering" an encoded message.

An example (using pgp 5.0 & Eudora Plug-in):

1.A encrypts & signs a message with RSA and sends it to B.
2.B decodes the message, and writes a reply to A's message
3.When message is processed by eudora/pgp a problem arises....A has two
public keys..A RSA key and a DH/DSS key...which one should be used..?

(one can decide to use both keys, and leave it up to A to decode...however
A may "prefer" one method...)

Thus, if it would be possible to encorporate a "preferred
encrytion/signing method" then the selection of which key/encrytion method  might
 be able to be done automatically...

I mentioned this a while ago to the folks at pgp, and would be interested
in hearing what the mailing list thinks...

regards

robert

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 10 Sep 97 12:05:14 -0400
To: Rodney Thayer <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: The purpose of this mailing list
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

In <[email-masked]>, on 09/10/97 
   at 07:49 AM, Rodney Thayer <[email-masked]> said:

>Sorry you found my posting off-topic.  Since the charter process has  not
>been completed yet (I believe it's going through due process, I  am not
>worried) and since I was discussing a critical and  undocumented aspect
>of the current and future technology I thought it  was relevant.

>I think we have to allow some level of discussion of the state of the 
>art in this forum or else we won't have a baseline as to where the  next
>generation of PGP should go.

>The fact there is no public established developer list is exactly the 
>point -- there are clusters of informal communities, and what we want  to
>do is to get those pulled together in an IETF framework to move  forward.

>Also, you seem to have waited an AWFULLY long time before speaking  up.

I'll have to agree with Rodney here. :)

IMHO the Public Key Servers are more improtant to the contiuned
development and growth of PGP than any particular algortihm being used by
PGP. From the nuber of posts here on the topic it seems that it is of
great intrest to the members of the list.

Perhaps we need to create a draft RFC and working group on PGP keyserver
protocols as it seems the only ones making an decisions on this is PGP
Inc.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Wed, 10 Sep 97 15:18:36 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: Re: The purpose of this mailing list
Sender: [email-masked]

> From: Rodney Thayer <[email-masked]>
> I think we have to allow some level of discussion of the state of the
> art in this forum or else we won't have a baseline as to where the
> next generation of PGP should go.
>
I agree.  When will the _current_ PGP draft be done?

I have a partial draft for streamlining PGP in the SPKI mold, but I've
been awaiting the detailed and complete PGP 5 draft.  A lot of things
are not well specified.

Or are we starting from a clean slate?

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
[email-masked]
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Date: Wed, 10 Sep 1997 08:49:15 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: The purpose of this mailing list
Cc: [email-masked]
Sender: [email-masked]

Sorry you found my posting off-topic.  Since the charter process has 
not been completed yet (I believe it's going through due process, I 
am not worried) and since I was discussing a critical and 
undocumented aspect of the current and future technology I thought it 
was relevant.

I think we have to allow some level of discussion of the state of the 
art in this forum or else we won't have a baseline as to where the 
next generation of PGP should go.

The fact there is no public established developer list is exactly the 
point -- there are clusters of informal communities, and what we want 
to do is to get those pulled together in an IETF framework to move 
forward.

Also, you seem to have waited an AWFULLY long time before speaking 
up.

>Date: Tue, 9 Sep 1997 19:45:12 -0700
>To: [email-masked]
>From: Paul Hoffman / IMC <[email-masked]>
>Subject: The purpose of this mailing list
>Sender: [email-masked]
>
>This mailing list is for discussion of the next-generation of 
PGP/MIME. We
>should be creating and discussing descriptions of that protocol.
>
>The discussions of the last few days (key server lookup protocol, 
API) are
>not really relevant to the OpenPGP spec. Disucssions about how a 
particular
>implementation of PGP work should be on the PGP developer's mailing 
list,
>not here. (I don't remember where that mailing list is, and it 
doesn't seem
>to be mentioned on the PGP, Inc. Web site, so if someone wants to 
pipe in
>with the address of that list, it would be very helpful.)
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>
>
>
>

Date: Wed, 10 Sep 1997 08:35:03 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: The purpose of this mailing list
Cc: [email-masked]
Sender: [email-masked]

Sorry you found my posting off-topic.  Since the charter process has 
not been completed yet (I believe it's going through due process, I 
am not worried) and since I was discussing a critical and 
undocumented aspect of the current and future technology I thought it 
was relevant.

I think we have to allow some level of discussion of the state of the 
art in this forum or else we won't have a baseline as to where the 
next generation of PGP should go.

The fact there is no public established developer list is exactly the 
point -- there are clusters of informal communities, and what we want 
to do is to get those pulled together in an IETF framework to move 
forward.

Also, you seem to have waited an AWFULLY long time before speaking 
up.

>Date: Tue, 9 Sep 1997 19:45:12 -0700
>To: [email-masked]
>From: Paul Hoffman / IMC <[email-masked]>
>Subject: The purpose of this mailing list
>Sender: [email-masked]
>
>This mailing list is for discussion of the next-generation of 
PGP/MIME. We
>should be creating and discussing descriptions of that protocol.
>
>The discussions of the last few days (key server lookup protocol, 
API) are
>not really relevant to the OpenPGP spec. Disucssions about how a 
particular
>implementation of PGP work should be on the PGP developer's mailing 
list,
>not here. (I don't remember where that mailing list is, and it 
doesn't seem
>to be mentioned on the PGP, Inc. Web site, so if someone wants to 
pipe in
>with the address of that list, it would be very helpful.)
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>
>
>
>

From: Steven Tay Beng Kuan <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: The purpose of this mailing list
Date: Wed, 10 Sep 1997 15:57:52 +0800
Sender: [email-masked]

> ----- Original Message -----
> From:	Paul Hoffman / IMC [SMTP:[email-masked]]
> Sent:	Wednesday, September 10, 1997, 10:45:12
> To:	[email-masked]
> Subject:	The purpose of this mailing list
> 
> This mailing list is for discussion of the next-generation of PGP/MIME. We
> should be creating and discussing descriptions of that protocol.
> 
> The discussions of the last few days (key server lookup protocol, API) are
> not really relevant to the OpenPGP spec. Disucssions about how a particular
> implementation of PGP work should be on the PGP developer's mailing list,
> not here. (I don't remember where that mailing list is, and it doesn't seem
> to be mentioned on the PGP, Inc. Web site, so if someone wants to pipe in
> with the address of that list, it would be very helpful.)
> 
> --Paul E. Hoffman, Director
> --Internet Mail Consortium
> 
> 
> 
> 
> ----- End Of Original Message -----

Hi,

PGP User Mailing List
To subscribe to the digest, e-mail:
	[email-masked]

Likewise-

To unsubscribe to the digest, e-mail:
	[email-masked]

To post to the list, e-mail:
	[email-masked].

	Happy surfing. See u in the list.

Steven Tay Beng Kuan [ ICQ: 1423100 ]
SiteBuilder Member Level 2   [ Have you Sign my Guessbook ]
Url: http://www.post1.com/~bkuan       Email: [email-masked]
Send message to me with subject "send pgp" for PGP key
Public Key also at http://www.post1.com/~bkuan/pgpkey.html

Date: Tue, 9 Sep 1997 19:45:12 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: The purpose of this mailing list
Sender: [email-masked]

This mailing list is for discussion of the next-generation of PGP/MIME. We
should be creating and discussing descriptions of that protocol.

The discussions of the last few days (key server lookup protocol, API) are
not really relevant to the OpenPGP spec. Disucssions about how a particular
implementation of PGP work should be on the PGP developer's mailing list,
not here. (I don't remember where that mailing list is, and it doesn't seem
to be mentioned on the PGP, Inc. Web site, so if someone wants to pipe in
with the address of that list, it would be very helpful.)

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Tue, 09 Sep 1997 17:19:25 -0700
To: "C. Harald Koch" <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: key server lookup protocol? 
Sender: [email-masked]

At 01:41 PM 9/3/97 -0400, C. Harald Koch wrote:
   > Not too late ;-)
   > 
   > PGP 5.0 sends the following request:
   > "GET /pks/lookup?op=get&exact=on&search=<Email Address|Key ID> HTTP/1.0"
   
   Ah, good. I sit corrected. So now all we have to do is:
   
   a) get it back onto port 80 (both clients and keyservers)
   b) add HTTP proxy support 
   
   (Both of these are implementation details :-)
   
Indeed. There's no reason it can't be on any port whatsoever.

Now, with 5.5, we have an ldap server, which will make things a lot easier.
We support the old HTTP one, but the ldap one is the way to go.

	Jon

-----
Jon Callas                                         [email-masked]
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 08 Sep 97 09:32:05 -0400
To: Lindsay Mathieson <[email-masked]>
Cc: "Anthony E. Greene" <[email-masked]>, [email-masked]
Subject: Re: PGP API
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

In <[email-masked]>, on 09/08/97 
   at 09:01 AM, Lindsay Mathieson <[email-masked]> said:

>>>
>For commerical use you'll have to purchase the DLL from PGP Inc. I'm sure
> they will provide docs and support.
><<
>I'd like to, but their dosn't seem to be any info on the PGP web site re
>this, and being a non-us company I suspect they would be restricted in
>what they could sell me.

I beleive that there is a PGP Developers Kit for the Windows platform for
integrating PGP into application. <sigh> Unfortunatly if you are outside
of the US you are going to be SOL due to the ITAR/EAR restrictions.

You could always goto: http://www.pgpi.com get the 5.0i source code and
build your own dll's. I know that this is a PITA but this seems to be your
only alternative at this time.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

CC: [email-masked]
Date: 8 Sep 1997 9:1:18 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: PGP API
To: "Anthony E. Greene" <[email-masked]>
Sender: [email-masked]

>>
For commerical use you'll have to purchase the DLL from PGP Inc. I'm sure 
they will provide docs and support.
<<
I'd like to, but their dosn't seem to be any info on the PGP web site re
this, and being a non-us company I suspect they would be restricted in what
they could sell me.

--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Beta Release Vs 2.6, on September 8, 1997, in Win95
4.0
	http://www.blackpaw.com/

CC: [email-masked]
Date: 8 Sep 1997 3:13:32 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: PGP API
To: "Robert C. Cline" <[email-masked]>
Sender: [email-masked]

>>Docs?  What docs do you mean?
<<

Documentation on using the PGP DLL's from a program to encrypt/decrypt/sign
messages, as well as manage the key databases.

I wish to add PGP support to our email client.

Cheers - Linz
--
Lindsay Mathieson
Black Paw Communications
	http://www.blackpaw.com/

Date: 8 Sep 1997 13:22:10 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: PGP API
To: [email-masked]
Sender: [email-masked]

Hi All,

does anyone know of any docs for the Windows PGP 5.0 DLL's ?

Thanks - Linz
--
Lindsay Mathieson
Black Paw Communications
	http://www.blackpaw.com/

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: [Off-topic] Re: key server lookup protocol?
Reply-To: [email-masked]
Date: Fri, 5 Sep 1997 10:45:26 (NZST)
Sender: [email-masked]

[email-masked] writes:
 
>On Wed, 3 Sep 1997, Rodney Thayer wrote:
>>where is this documented?
 
>It isn't, but is obvious from a source or packet sniffer
 
This is like MITS Altair tech support when someone phoned asking for
documentation: "You've got the schematic, what's the problem?".
 
Peter.

Date: Thu, 04 Sep 1997 08:18:08 +0200
To: [email-masked]
From: "Anthony E. Greene" <[email-masked]>
Subject: Re: key server lookup protocol?
Sender: [email-masked]

At 14:20 03-09-1997 -0400, you wrote:
>where is this documented?
>
>where is that goofy port number they use in PGP 5 documented?
>

It's the default presented in the PGP 5.0 Preferences dialog.

*****************************************************************
* Anthony E. Greene <[email-masked]>                         *
* Use PGP -- Envelopes and Signatures for Email                 *
* What is PGP?: <http://www.pobox.com/~agreene/pgp/>            *
* My PGP Key: <http://www.pobox.com/~agreene/pgp/agreene.key>   *
* FREEWARE Win95 PGP 5.0: <http://web.mit.edu/network/pgp.html> *
*****************************************************************

Date: Thu, 04 Sep 1997 07:17:29 +0200
To: "Open-PGP List" <[email-masked]>
From: "Anthony E. Greene" <[email-masked]>
Subject: Re: key server lookup protocol?
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

At 17:38 03-09-1997 MDT, you wrote:
>> FWIW, it would have been *really* nice if this had been implemented as a
WWW
>> transaction, instead of as a separate protocol (on a separate port). Ah
>> well; too late now, I guess.
>
>Not too late ;-)
>
>PGP 5.0 sends the following request:
>"GET /pks/lookup?op=get&exact=on&search=<Email Address|Key ID> HTTP/1.0"

The new keyserver works on port 11371. Most Web servers should be 
configurable to listen on this port.

*****************************************************************
* Anthony E. Greene <[email-masked]>                         *
* Use PGP -- Envelopes and Signatures for Email                 *
* What is PGP?: <http://www.pobox.com/~agreene/pgp/>            *
* My PGP Key: <http://www.pobox.com/~agreene/pgp/agreene.key>   *
* FREEWARE Win95 PGP 5.0: <http://web.mit.edu/network/pgp.html> *
*****************************************************************

To: Rodney Thayer <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: key server lookup protocol?
From: Marc Horowitz <[email-masked]>
Date: 03 Sep 1997 18:43:48 -0400
Lines: 55
Sender: [email-masked]

Rodney Thayer <[email-masked]> writes:

>> where is this documented?

History lesson: the pgp keyserver started as a perl cgi hack, which
grew into a C hack, which grew into my undergraduate thesis, and then
things got really out of control :-)

If you want docs, look at <http://www.mit.edu/people/marc/pks/> and
follow the thesis link (or the source link).  The default port number
isn't in there, but if it will make it easier for people to get holes
in their firewalls, I can document it in the FAQ, or something.

I suppose the next step is taking the relevant section from the thesis
and formatting it as an i-d.

>> where is that goofy port number they use in PGP 5 documented?

It's the default in the installation.  Remember, this used to be hack.

>> Has anyone tried this with a proxy server?

I don't see why it wouldn't work, if the proxy server is configured
properly.

>> This doesn't work with some firewalls.

I'm completely unable to figure out how forbidding outbound TCP to
high numbered ports enhances the security of any firewall.

"A. Padgett Peterson P.E. Information Security" <[email-masked]> writes:

>> 11371 - was used by the original MIT server. Already suggested that PGP 
>> apply for a "assigned number" port under 1024.

Why under 1024?  This would require that unix systems run the daemon
as root, which is completely unnecessary.

"William H. Geiger III" <[email-masked]> writes:

>> Well there is nothing formal on what port is being used. While most are
>> using 11371 there are others using different ports including 80. This
>> depends on the software configuration and software being used (not all
>> servers are running the same software).
>> 
>> Myself prefer having a flexible approach to the port being used by the
>> server rather than having a set port. I can even see hi volumn servers
>> using multiple ports for access (similar to what irc servers do).

My server code, at least, has a configuration file which allows the
maintainer to specify the server port.  It only supports one at a
time, but there's already multiplexing code in there, so supporting
more than one would be pretty easy.

		Marc

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 03 Sep 97 16:07:20 -0400
To: Rodney Thayer <[email-masked]>
Cc: [email-masked]
Subject: Re: key server lookup protocol?
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

In <[email-masked]>, on 09/03/97 
   at 03:27 PM, Rodney Thayer <[email-masked]> said:

>The reason I want a document is so I can print it off and take it to the
>network manager of the offending firewall and swat him so he'll
>reconfigure it.  "11371, I heard it on the net" doesn't seem like a sound
>formal specification to reference when asking someone to open a new hole
>in their firewall.

Well there is nothing formal on what port is being used. While most are
using 11371 there are others using different ports including 80. This
depends on the software configuration and software being used (not all
servers are running the same software).

Myself prefer having a flexible approach to the port being used by the
server rather than having a set port. I can even see hi volumn servers
using multiple ports for access (similar to what irc servers do).

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Wed, 3 Sep 1997 14:11:53 -0700
From: Alan Batie <[email-masked]>
To: [email-masked]
Cc: Rodney Thayer <[email-masked]>, [email-masked]
Subject: Re: key server lookup protocol?
Sender: [email-masked]

--n2rw/3z4jIqBvZU5
Content-Type: text/plain; charset=us-ascii

On Wed, Sep 03, 1997 at 04:00:44PM -0400, [email-masked] wrote:
> > This doesn't work with some firewalls.
> It should be socksifiable, and the rest work as above.

I had our firewall guys set up a "transparent proxy" on port 11371 and
when I tried to use it, pgpkeys.exe (the freeware download) said
"receiving data", then after a long pause, died with an attempt to
dereference a null pointer.  I'm still analyzing the situation, but if
it could be made to work with the regular http proxy, that would be much
better.

-- 
Alan Batie                     ------        What goes up, must come down.
[email-masked]        \    /        Ask any system administrator.
+1 503-264-8844 (voice)         \  /         --unknown
D0 D2 39 0E 02 34 D6 B4          \/          5A 41 21 8F 23 5F 08 9D

--n2rw/3z4jIqBvZU5
Content-Type: application/pgp-signature

--n2rw/3z4jIqBvZU5--

Date: Wed, 03 Sep 1997 16:27:11 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Re: key server lookup protocol?
Sender: [email-masked]

The reason I want a document is so I can print it off and take it to the
network manager of the offending firewall and swat him so he'll reconfigure
it.  "11371, I heard it on the net" doesn't seem like a sound formal
specification to reference when asking someone to open a new hole in their
firewall.

>X-Sender: [email-masked]
>X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
>Date: Wed, 03 Sep 1997 14:31:17 -0500
>To: "A. Padgett Peterson P.E. Information Security"
<[email-masked]>,
>        [email-masked]
>From: "david d `zoo' zuhn" <[email-masked]>
>Subject: Re: key server lookup protocol?
>Cc: [email-masked]
>
>>>Has anyone tried this with a proxy server?
>>Not that I know of but not difficult - remote secure clients such as V-One's
>>SmartWall already use other "goofy" ports as do any number of databases 
>>such as Oracle.
>
>Any firewall worth its salt should be capable of opening a TCP port on 
>11371, so thereby enabling access to the key server.  No problems, but 
>not a very good answer.
>
>It's not unreasonable to expect PGP to be able to cope with an HTTP 
>proxy server, much as any Web browser does.  I've done some testing to 
>make sure that this works, and manual tests seem to work just fine.
>
>So the next step, and I'm going to see if I can do this in an afternoon 
>(my attention span for coding these days), is to add explicit proxy 
>support to the keyserver code in PGP itself.  
>
>Once this is done, then the world of PGP users behind firewalls can 
>utilize their already-working HTTP proxy server to access the various 
>key server databases.
>
>
>>>This doesn't work with some firewalls.
>>
>>SHTTP doesn't work with some firewalls.
>
>What's the relevance of SHTTP?  
>
>--
>-  david d `zoo' zuhn  -| Montana Rail Link/NP, circa 1995, in N scale
>--  [email-masked] --|  www.armadillo.com/zoo/layout/ for info
>
>

Date: Wed, 3 Sep 1997 16:00:44 -0400
From: [email-masked]
To: Rodney Thayer <[email-masked]>
cc: [email-masked]
Subject: Re: key server lookup protocol?
Sender: [email-masked]

On Wed, 3 Sep 1997, Rodney Thayer wrote:

> where is this documented?

It isn't, but is obvious from a source or packet sniffer

> where is that goofy port number they use in PGP 5 documented?

Most keyservers (e.g. mit) use that same port number, you don't notice it
unless you look at the URL, so it is a case of an informal convention
being change into a specification.

>From my autolookup script which long predated pgp5.0:

geturl http://swissnet.ai.mit.edu:11371/pks/lookup\?op=get\&search=0x$i

> Has anyone tried this with a proxy server?

Yes, but you have to tell the http proxy to work on the goofy port number,
or enable that port number to pass through.

> This doesn't work with some firewalls.

It should be socksifiable, and the rest work as above.

Date: Wed, 03 Sep 1997 14:31:17 -0500
To: "A. Padgett Peterson P.E. Information Security" <[email-masked]>, [email-masked]
From: "david d `zoo' zuhn" <[email-masked]>
Subject: Re: key server lookup protocol?
Cc: [email-masked]
Sender: [email-masked]

>>Has anyone tried this with a proxy server?
>Not that I know of but not difficult - remote secure clients such as V-One's
>SmartWall already use other "goofy" ports as do any number of databases 
>such as Oracle.

Any firewall worth its salt should be capable of opening a TCP port on 
11371, so thereby enabling access to the key server.  No problems, but 
not a very good answer.

It's not unreasonable to expect PGP to be able to cope with an HTTP 
proxy server, much as any Web browser does.  I've done some testing to 
make sure that this works, and manual tests seem to work just fine.

So the next step, and I'm going to see if I can do this in an afternoon 
(my attention span for coding these days), is to add explicit proxy 
support to the keyserver code in PGP itself.  

Once this is done, then the world of PGP users behind firewalls can 
utilize their already-working HTTP proxy server to access the various 
key server databases.

>>This doesn't work with some firewalls.
>
>SHTTP doesn't work with some firewalls.

What's the relevance of SHTTP?  

--
-  david d `zoo' zuhn  -| Montana Rail Link/NP, circa 1995, in N scale
--  [email-masked] --|  www.armadillo.com/zoo/layout/ for info

Date: Wed, 3 Sep 1997 15:11:40 -0400 (EDT)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: key server lookup protocol?
Sender: [email-masked]

>where is that goofy port number they use in PGP 5 documented?

11371 - was used by the original MIT server. Already suggested that PGP 
apply for a "assigned number" port under 1024.

>Has anyone tried this with a proxy server?
Not that I know of but not difficult - remote secure clients such as V-One's
SmartWall already use other "goofy" ports as do any number of databases 
such as Oracle.

>This doesn't work with some firewalls.

SHTTP doesn't work with some firewalls.
						Warmly,
							Padgett						

Date: Wed, 03 Sep 1997 14:20:34 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Re: key server lookup protocol?
Sender: [email-masked]

where is this documented?

where is that goofy port number they use in PGP 5 documented?

Has anyone tried this with a proxy server?

This doesn't work with some firewalls.

>Date: Wed, 3 Sep 97 17:38:16 MDT
>From: [email-masked] (Frank Brueckner)
>To: [email-masked]
>Subject: Re: key server lookup protocol?
>Sender: [email-masked]
>
>Rodney, Harald,
>
>
>> Is there a document anywhere describing the key lookup protocol used in
PGP 
>> 5? ...
>
>> FWIW, it would have been *really* nice if this had been implemented as a
WWW
>> transaction, instead of as a separate protocol (on a separate port). Ah
>> well; too late now, I guess.
>
>Not too late ;-)
>
>PGP 5.0 sends the following request:
>"GET /pks/lookup?op=get&exact=on&search=<Email Address|Key ID> HTTP/1.0"
>
>So you can run a CGI script acting as a Key Server (for retrieval), getting
>the key out from a data base (e.g. X.500) and sending back an application
>context like text/html or application/pgp-keys with the PGP Key in Ascii
Armor.
>
>
>Frank.
>
>
>

To: [email-masked]
Subject: Re: key server lookup protocol? 
From: "C. Harald Koch" <[email-masked]>
Date: Wed, 3 Sep 1997 13:41:12 -0400
Sender: [email-masked]

> Not too late ;-)
> 
> PGP 5.0 sends the following request:
> "GET /pks/lookup?op=get&exact=on&search=<Email Address|Key ID> HTTP/1.0"

Ah, good. I sit corrected. So now all we have to do is:

a) get it back onto port 80 (both clients and keyservers)
b) add HTTP proxy support 

(Both of these are implementation details :-)

-- 
Harald <[email-masked]>

Date: Wed, 03 Sep 1997 10:48:33 -0500
To: [email-masked] (Frank Brueckner), [email-masked]
From: "david d `zoo' zuhn" <[email-masked]>
Subject: Re: key server lookup protocol?
Sender: [email-masked]

>> FWIW, it would have been *really* nice if this had been implemented as a WWW
>> transaction, instead of as a separate protocol (on a separate port). Ah
>> well; too late now, I guess.

>PGP 5.0 sends the following request:
>"GET /pks/lookup?op=get&exact=on&search=<Email Address|Key ID> HTTP/1.0"

Great.  So it is HTTP.  Then maybe extend it a little bit so that HTTP 
proxy servers can be used (which is very often the case for people 
living behind corporate firewalls). 

--
-  david d `zoo' zuhn  -| Montana Rail Link/NP, circa 1995, in N scale
--  [email-masked] --|  www.armadillo.com/zoo/layout/ for info

Date: Wed, 3 Sep 97 17:38:16 MDT
From: [email-masked] (Frank Brueckner)
To: [email-masked]
Subject: Re: key server lookup protocol?
Sender: [email-masked]

Rodney, Harald,

> Is there a document anywhere describing the key lookup protocol used in PGP 
> 5? ...

> FWIW, it would have been *really* nice if this had been implemented as a WWW
> transaction, instead of as a separate protocol (on a separate port). Ah
> well; too late now, I guess.

Not too late ;-)

PGP 5.0 sends the following request:
"GET /pks/lookup?op=get&exact=on&search=<Email Address|Key ID> HTTP/1.0"

So you can run a CGI script acting as a Key Server (for retrieval), getting
the key out from a data base (e.g. X.500) and sending back an application
context like text/html or application/pgp-keys with the PGP Key in Ascii Armor.

Frank.

To: Rodney Thayer <[email-masked]>
cc: [email-masked]
Subject: Re: key server lookup protocol? 
From: "C. Harald Koch" <[email-masked]>
Organization: Secure Computing Canada Ltd.
Phone: +1 416 813 2054
Date: Wed, 3 Sep 1997 10:44:10 -0400
Sender: [email-masked]

In message <[email-masked]>, Rodney Thayer writes:
> Is there a document anywhere describing the key lookup protocol used in PGP
> 5?  I see one of the firewalls I sometimes have to pass doesn't think it's
> a valid protocol and I'd like to swat the network manager at that site with
> a document...

FWIW, it would have been *really* nice if this had been implemented as a WWW
transaction, instead of as a separate protocol (on a separate port). Ah
well; too late now, I guess.

-- 
Harald.

Date: Tue, 02 Sep 1997 21:13:04 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: key server lookup protocol?
Sender: [email-masked]

Is there a document anywhere describing the key lookup protocol used in PGP
5?  I see one of the firewalls I sometimes have to pass doesn't think it's
a valid protocol and I'd like to swat the network manager at that site with
a document...

[No, I am *not* trying to introduce Mission Creep into the Open PGP WG
charter.]

Date: Mon, 01 Sep 1997 09:10:26 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: William Allen Simpson <[email-masked]>
CC: [email-masked]
Subject: Re: UserID/Auth Field in Open-PGP certs
Sender: [email-masked]

The option to add in X.509 information would certainly make it easier
for open-pgp to gain acceptance in the corporate world...

Ian.