Subject: Re: Key Extraction odd behavior ???
From: "William H. Geiger III" <[email-masked]>
To: [email-masked], [email-masked]
Date: Thu, 01 Jan 98 00:10:27 -0600

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

Hi,

Well somthing screwy is going on.

I have now after doing several extracts of the same key from pubring.pkr
have two different keys?!?

I have the one of filesize 1504 that was attached to the previous message
and one of 1800 that seems to have the sig block properly formatted.

This is using the PGP 5.0i code (b8a).

odd very odd.

In playing with other DH keys I have found that sometimes 5.0 extracts the
key properly and other times it does not.

Is this a known bug in 5.0 or is this somthing new??

Any help would be appreciated as this is making it diffacult to analize my
code.

I have attached the second key which seems to have been properly extracted
so the two can be compaired.

Thanks,

- - -- 
- - ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
- - ---------------------------------------------------------------

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 31 Dec 97 21:33:02 -0600
To: EKR <[email-masked]>
Cc: Steve Schear <[email-masked]>, EKR <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

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

In <[email-masked]>, on 12/31/97 
   at 07:00 PM, EKR <[email-masked]> said:

>In message <v03102805b0d08d63c7cc@[208.129.55.202]>, Steve Schear writes:
>>At 2:25 PM -0800 12/31/97, EKR wrote:
>>>Will Price <[email-masked]> writes:
>>>> At 11:15 PM -0800 12/30/97, Eric Rescorla wrote:
>>
>>[big snip]
>>>Try to solve the following two examples:
>>>Netscape and Microsoft. Netscape has downloads off their web site.
>>>They want them to be easy. That means that the user can just
>>>point and click. That means the crypto must be exportable or none
>>>at all. Which do you suggest?
>>>Next consider Microsoft. They embed their browser in the OS (at
>>>least for now.). They want to ship that to foreigners. Again,
>>>the crypto has to be exportable or nonexistent. Which do you
>>>suggest?
>>>
>>>So, what do you suggest these companies do?
>>
>>How about funding programs such as Fortify, which patch browsers to enable 128
>>-bit SSL with all willing servers (whether or not they have supercerts)?

>That seems like a fine plan, but it doesn't really speak to what Netscape
>ships as a Netscape product, does it?

We still talking crypto code ??? Sorry couldn't resist <G>.

There is no reason why Netscape, MS, ... etc could not interface their
crypto code through a generic plugin interface. They the provide the
specific plug-in they wish to ship for their crypto code. If someone
wished to replace it they would be free to do so. If the plugin interface
can be used for other things than crypto this would bypass the "crypto
with a hole" concerns.

Just as an interesting side note one can not to this date DL a 128 SSL
version of the OS/2 Netscape browser. It takes next to an act of GOD to
aquire one (how much of this is due to NS and how much this is due to IBM
is anyone's guess).

A rather sad state of afairs when one must aquire a 128bit browser via
replay.com even when one is located in the US.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 31 Dec 97 18:59:15 -0600
To: [email-masked]
Cc: [email-masked]
Subject: Key Extraction odd behavior ???
Sender: [email-masked]

Hi,

I have been playing around with my OpenPGP packet analyzer code and I
found somthing odd.

For a signature packet that follows the userID packet for a key it should
have a CTB of 0010 (Type 2)  [0x89] but I have noticed that PGP 5.0 when
extracting a key converts this to 1110 (Type 14) [0xB9].

If I check in CTB for the signature in the pubring.pkr it does have a CTB
of 0010.

It only seems to do this with DSS signatures and not RSA signatures.

Now if I remove the key from the pubring.pkr and then readd it to the
keyring the CTB is kept at 1100 [0xB9].

Now this doesn't seem to make sense in the context of the following data:

B9 04 0D 04 34 A3 DF 8E ...

B9 is 10111001

10   = CTB old format
1110 = packet type 14
01   = length packet 2 octets

04 0D = 1037 octets = remaining length of the public key.

Now it after this I am getting lost. :(

04 = ?? subpacket length field ?? if so then what does the following 0x34
represent??

If we are to treat the 0xB9 as an error and assume that 0xB9 should really
be 0x89 then:

89 is 10001101

10   = CTB old format
0011 = packet type 2
01   = length packet 2 octets

04 0D = 1037 octets = remaining length of the public key.

04   = sig version number (4)

34   = ?? sig type ?? (sigtype of 0x34 is undefined)

If anyone understands what and why this conversion is being done and where
I am going wrong in reading the format please let me know. 

I have attached the extracted key. 

Thanks,

PS: Just as a side note to this section of the documentation. I find the
switching between hex, bin, and dec to make the reading of the
documentation much more complex. Also IMHO I think that any display of
values 8 bits or less should be done in binary (this was done in the
previous pgpformat documents including rfc1991).

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
---------------------------------------------------------------

To: Steve Schear <[email-masked]>
cc: EKR <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP 
Date: Wed, 31 Dec 1997 19:00:24 -0800
From: EKR <[email-masked]>
Sender: [email-masked]

In message <v03102805b0d08d63c7cc@[208.129.55.202]>, Steve Schear writes:
>At 2:25 PM -0800 12/31/97, EKR wrote:
>>Will Price <[email-masked]> writes:
>>> At 11:15 PM -0800 12/30/97, Eric Rescorla wrote:
>
>[big snip]
>>Try to solve the following two examples:
>>Netscape and Microsoft. Netscape has downloads off their web site.
>>They want them to be easy. That means that the user can just
>>point and click. That means the crypto must be exportable or none
>>at all. Which do you suggest?
>>Next consider Microsoft. They embed their browser in the OS (at
>>least for now.). They want to ship that to foreigners. Again,
>>the crypto has to be exportable or nonexistent. Which do you
>>suggest?
>>
>>So, what do you suggest these companies do?
>
>How about funding programs such as Fortify, which patch browsers to enable 128
>-bit SSL with all willing servers (whether or not they have supercerts)?
That seems like a fine plan, but it doesn't really speak to what
Netscape ships as a Netscape product, does it?

-Ekr

Date: Wed, 31 Dec 1997 16:28:19 -0800
To: EKR <[email-masked]>, <[email-masked]>
From: Steve Schear <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
Cc: [email-masked]
Sender: [email-masked]

At 2:25 PM -0800 12/31/97, EKR wrote:
>Will Price <[email-masked]> writes:
>> At 11:15 PM -0800 12/30/97, Eric Rescorla wrote:

[big snip]
>Try to solve the following two examples:
>Netscape and Microsoft. Netscape has downloads off their web site.
>They want them to be easy. That means that the user can just
>point and click. That means the crypto must be exportable or none
>at all. Which do you suggest?
>Next consider Microsoft. They embed their browser in the OS (at
>least for now.). They want to ship that to foreigners. Again,
>the crypto has to be exportable or nonexistent. Which do you
>suggest?
>
>So, what do you suggest these companies do?

How about funding programs such as Fortify, which patch browsers to enable 128-bit SSL with all willing servers (whether or not they have supercerts)?

--Steve  

Date: Thu, 01 Jan 1998 01:25:56 +0100
To: IETF Open-PGP List <[email-masked]>
From: "Anthony E. Greene" <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

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

At 14:25 31-12-97 -0800, EKR wrote:
>Try to solve the following two examples:
>Netscape and Microsoft. Netscape has downloads off their web site.
>They want them to be easy. That means that the user can just
>point and click. That means the crypto must be exportable or none
>at all. Which do you suggest?

A non-U.S. download site.

>Next consider Microsoft. They embed their browser in the OS (at
>least for now.).

That browser is downloadable separately, legal briefs notwithstanding. The 
128-bit version is available *now* from the U.S. site, separately from 
Win95. That means it can be downloaded separately from a non-U.S. site, 
separately from Win95, *if* Microsoft decides that it will do such a thing.

> They want to ship that to foreigners. Again,
>the crypto has to be exportable or nonexistent. Which do you
>suggest?

It is exportable, just not in electronic form.

>So, what do you suggest these companies do?
>
>-Ekr

Will made several suggestions. Your assertion that he did not offer any 
suggestions just ignores the fact that he did.

I use the Win95, point-and-click-download-and-install version of PGP, 
legally available outside of the U.S. Not vaporware, or legal briefs, or 
statements about feasibility, legality, or possibility, but honest to 
goodness software. A real-world example of what is possible. The reasons 
that other companies do not do this are not technical or legal, but are 
based on policy decisions made in those companies.

Is PGP Inc capable of things that Microsoft and Netscape are not? The very 
idea sounds ridiculous given the relative resources available.

It's not that they can't, it's that they won't.

There may be good reasons they won't, but let's not pretend that they 
*can't*, or that they don't have the resources to do it.

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

Date: Wed, 31 Dec 1997 15:53:20 -0800
To: EKR <[email-masked]>
From: Steve Schear <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
Cc: [email-masked]
Sender: [email-masked]

>> Some companies will undoubtedly never bring themselves to implementing one
>> of the above systems and will thus be relegated to snake oil security
>> internationally until the laws in the US change.
>I think it's unreasonable to say that 40 bit crypto is "snake oil".
>It's exactly as strong as advertised. There's no secret about the
>situation.

Yes, and quite useless.  Were one to map the security claims of 40-bit crypto to the drug industry, I would surprised if the product would merit anything more than a symptom reliever status.

>
>> Let's not infect our protocols with such politics.  TLS 1.0 is a done deal
>> as far as I'm concerned.  SSL3 had export algorithms, so TLS1 does too,
>> fine.  There are now many better solutions to the export problem,
>Perhaps, but you haven't suggested any.

Yes he has, your're just not accepting them.

--Steve

Date: Wed, 31 Dec 1997 15:46:20 -0800
To: [email-masked]
From: Steve Schear <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

>> At the very least one would think that the US vendors would put thier
>> crypto code in one DLL and document the API so someone overseas could
>> replace it with somthing worth using. <sigh> I guess even that is too
>> much to ask.
>
>If the US government would let us, you better believe we'd do it.  We have
>no vested interest in helping the NSA eavesdrop on people.  We make money
>by selling software that meet our customers' needs, and that includes being
>secure.
>
>The strategy you describe is called "crypto with a hole", and is explicitly
>forbidden by the export regs.

I don't think so.  If functional code is exported in machine-readable form=
 and contains no "hook" calls, and another document containing a diff is=
 separately exported as printed materials, and therefore protected (just=
 like PGP's code), then it is the receptient not the exporter that added the=
 crypto (which was in no way "required" by the machine-readable code).

As Ned notes: "...software which was specifically designed or modified to=
 allow it to be used with encryption software is itself regulated. And so=
 is, for that matter, software which in turn references such software."  But=
 if the machine-readable software contains no calls which are later replaced=
 by crypto and can function fine w/o the crypto, this should legally=
 circumvent the regs. =20

This is especially handy if the crypto routines are already available=
 offshore w/o EAR restraint (e.g., SSLeay), since the diff file can be quite=
 manageable in size, I hazard to guess even for programs the size of Navigat=
or.

--Steve

Date: Wed, 31 Dec 1997 22:50:25 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

As Will has now posted PGP's SMTP over TLS document now, I thought I
re-post this comment on authenticating TLS with keys from another
domain (PGP WoT domain).

This would neatly avoid the complexity of adding PGP certificates to
TLS because unauthenticated (and preferably forward secret) modes
could be used for TLS such as ADH (anonymous DH). (ADH-DES-CBC3-SHA
being the strongest of the unauthenticated cipher suites).

The point at which you would tie together the key material from the
PGP WoT based authentication with the TLS pre-master-secret I have not
considered in depth so far.

Adam

==============================8<==============================

Date: Sun, 26 Oct 1997 12:26:52 GMT
From: Adam Back <[email-masked]>
To: <another list>

One thing I'd like to see discussed is TLS (Transport Level Security)
for delivering pgp encrypted mails.

One objection to TLS is that it's difficult to authenticate without
key management.  This is true enough, though there is some value in
PFS (Perfect Forward Secrecy) TLS even without authentication -- this
value is that it forces an attacker to be active to even be able to
archive encrytped traffic.

The presumption is that a) active attacks are harder, and that b)
governments will find it harder to do lots of active attacks at once.

So PFS TLS is a good trend for protecting against future government
abuses... if lots of software is using PFS TLS, well government will
have some problems recalling all that software, and persuading people
to downgrade.

That's unauthenticated PFS TLS.

But I reckon this hack works: with PGP you've already got a WoT (Web
of Trust), so you don't need a separate key infrastructure to
authenicate TLS, and this is good because deploying automatic key
infrastructures (such as perhaps for DNSSEC) is complex.

The way to use PGP's WoT for TLS authentication is to have a
communication between MUA (Mail User Agent, eg a future pgp6.0) and
the MTA (Mail Transfer Agent, eg SMTP, or SMTP agent with SMTP
extensions).

It is even possible to have non-interactive, one sided communications
between sending MUA and MTA, and between receiving MTA and MUA which
is a good thing as it is after all store and forward and there may be
some local store and forward hops on the way to the TLS secured SMTP
delivery over the Internet, and some further local hops after receipt.

I figure all that is needed is this:

                           TLS secured link
MUA1 --> MTA1 --> TLS-MTA1 ================> TLS-MTA2 --> MTA2 --> MUA2

MTA1 and MTA2 represent local MTAs just distributing email inside an
organisation (inside the firewall), and just serve to show that any
communications better be one-sided, and not require replies.

TLS-MTA1 and TLS-MTA2 are the MTAs which actually send info out
through the firewall.

The topology of the communications suggests that MUA1 can send to
TLS-MTA1, but can't expect a reply.  And that TLS-MTA2 can send to
MUA2, but can't expect a reply.

You can authenticate the TLS link based on the PGP WoT using that
communications pattern.

MUA1 -> TLS-MTA1 communication would be a key k1 to use for
authentication.  The key would be sent as a mail-header:

X-auth-key: 0x1234132413241324

TLS-MTA1 would authenticate with this key.  (Perhaps computing a hash
of the negotiated DH (Diffie-Hellman) or transient EG (El Gamal) key
and the key.  Perhaps:

auth1 = hash( k1 || negotiated-dh-params )

The authentation information would be sent as a mail header, and the
key information would be removed, so X-auth-key line would be removed,
and this line added:

X-auth: 0x567856785678578578578

Then TLS-MTA2 (the recipient TLS) would just pass this info on
unchanged.

The receiving MUA would also need the information about the
negotiated-dh-parameters, that info would have to be sent to it by the
recieving MTA, presumably with another header:

X-auth-parameters: 0x123413241324, 0x3653563463654563653

or whatever.

Then the receiving MUA can check the X-auth line agains the key k1
included in the PGP encrypted message, by recomputing:

auth1 = hash( k1 || negotiated-dh-params )

The key k1 would be included inside the pgp message (or perhaps be
derived from something which is already there, perhaps k1 = hash(
session-key), the hash of the symmetric session key used to encrypt
the message).

The MUA would use the X-auth field to check the TLS authentication.
A MITM could be flagged by the recipients MUA.

Adam

Date: Wed, 31 Dec 1997 22:40:25 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: OpenPGP IETF meeting -- what happened? (Re: section 4.3)
Sender: [email-masked]

Hal Finney <[email-masked]> writes:
> [other stuff]
> 
> This is a good explanation.  Thanks for providing it.  There has been so
> much attention paid to the additional recipient feature that few people have
> had the energy to look at the other new features.

What happened to the ARR anyway?  Is it still there?  What happened at
IETF?

Would anyone who attended OpenPGP at IETF like to spend 5 mins giving
a run down of any significant decisions made etc?

(I imagine the Network Associates buyout has delayed things, but it
has been some time, and I'm sure we're all interested to hear what
happened).

Adam

Date: Wed, 31 Dec 1997 17:46:09 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

>At the very least one would think that the US vendors would put thier
>crypto code in one DLL and document the API so someone overseas could
>replace it with somthing worth using. <sigh> I guess even that is too much
>to ask.

Was the topic of a discussion a few years ago about ITAR. The conclusion
was that adding "hooks" like that was right out.

Have the text in my office, think it was under "auxilliary devices" or
some such.

Anyone know if it is in the EAR ?

						Warmly,
							Padgett

To: <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
From: EKR <[email-masked]>
Date: 31 Dec 1997 14:25:22 -0800
Lines: 120
Sender: [email-masked]

Will Price <[email-masked]> writes:
> At 11:15 PM -0800 12/30/97, Eric Rescorla wrote:
> >Will, I'm not particularly interested in debating protocol
> >level crypto policy here. However, the crypto export laws
> >are reality for most people here, and I find your attempt to
> >imply that they're easily worked around fairly disingenuous.
> 
> Easily?  If you got the impression from my message that it was easy, I
> suggest you read it again.  What you imply here is that you need an easy
> solution.  If you were willing to do something slightly less than easy, you
> might find another solution as other companies have.  This issue is at the
> very core of secure software.  If it isn't done right, nothing is.  Use of
> 40 bit scrambling is exactly the kind of issue on which companies making
> security products cannot use the easy solution.
No, what I imply here is that the solutions you propose are unworkable.
I don't really see any evidence to the contrary.

> >Will Price <[email-masked]> writes:
> >It's hard to believe that this is really going to work for many
> >real programs. Have you seen the size of Netscape lately. Have
> >you noticed how often Netscape ships new versions? (I'm not
> >trying to pick on Netscape here. IE has similar characteristics.
> >There are plenty of other big programs but web browsers hae
> >particularly fast release cycles.)
> 
> Have you seen the size of PGP 5.5.3 on 10 different platforms lately with
> all the GUI code?  It's not exactly small. 
I don't own a copy of PGP, however, your web site says that:
Note: The Unix Binary versions vary in size from 1.3MB to 1.5MB.
The latest version of Netscape on my machine is 8 megabytes.

These just aren't commensurate.

> >> insecure.  Such stories reduce user faith in everybody's security products.
> >> The only solution is public code review.
> >It's not obvious this makes much of a difference. Note that Sendmail
> >source code has been widely available since the beginning.
> 
> Nobody trusts sendmail.  Nobody needs to trust sendmail if they use secure
> mail.
You're getting bogged down in the comsec mentality. Sendmail is a
nightmare from a systems security perspective. 

>  Secure systems are built to be simple enough to comprehend fully so
> that reviewers can analyze it fully.  Sendmail clearly doesn't fall into
> this category.  Everyone knows sendmail is buggy, so nobody wastes their
> time trying to document every bug.
This statement is incorrect. There has actually been quite a concerted
effort to fix the security bugs in Sendmail. It's just been an utter
failure since there seem to be a nearly infinite number.

> >> Some companies will undoubtedly never bring themselves to implementing one
> >> of the above systems and will thus be relegated to snake oil security
> >> internationally until the laws in the US change.
> >I think it's unreasonable to say that 40 bit crypto is "snake oil".
> >It's exactly as strong as advertised. There's no secret about the
> >situation.
> 
> There is no "advertising" of it.  The users are simply unaware --
> effectively making it a secret.  When was the last time you saw a big
> company putting a very visible warning about 40 bit security inside its 40
> bit product?
Uh, let's see. When you pull down Document Info in Netscape, it says:
Security:
   This is a secure document that uses a medium-grade encryption key suited for
   U.S. export (RC4-40, 128 bit with 40 secret).

Hard to get more clear than that.

> I know I've never seen something like that.  Further, even
> the strong crypto products are infected by the weak crypto products in
> protocols like S/MIME and SSL which require both sides to use the same
> algorithms.  No warning is given in those cases either in any of the
> products I've examined.  It leads to a cascade effect wherein the vast
> majority of users end up having no security when they think they do have
> security.  The deceit here is that even when users learn about 40 bit
> security, they think it is still encryption.  Realistically, it just isn't.
This is a religious statement, not a technical one. Actually, the work
factor to break a 40 bit key is substantial. For example, Damien
Doligez's crack took the following resources:
	The 40-bit secret part of the key is 7e f0 96 1f a6.  I found
	it by a brute force search on a network of about 120 workstations
	and a few parallel computers at INRIA, Ecole Polytechnique, and
	Ecole Normale Superieure. The key was found after scanning a little
	more than half the key space in 8 days.

40 bit is next to worthless against a dedicated attacker. However,
there certainly are applications for which it is sufficient. Horses
for courses and all that.

>>Perhaps, but you haven't suggested any.  
> I
> suggested three each of which is completely workable and in use by
> real companies as big as Sun.  It isn't clear how you say that I
> have not suggested any when there are very clearly three
> alternatives suggested.  If these don't work for you, I suggest
> seeking legal advice.  There are many other roads that haven't yet
> been travelled.  Don't look for the easy solution, look for the
> right solution.
Hmmm... I'm not convinced that any of these is really workable.

Try to solve the following two examples:
Netscape and Microsoft. Netscape has downloads off their web site.
They want them to be easy. That means that the user can just
point and click. That means the crypto must be exportable or none
at all. Which do you suggest?
Next consider Microsoft. They embed their browser in the OS (at
least for now.). They want to ship that to foreigners. Again,
the crypto has to be exportable or nonexistent. Which do you
suggest?

So, what do you suggest these companies do?

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 31 Dec 97 12:45:01 -0600
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: section 4.3
Sender: [email-masked]

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

In <[email-masked]>, on 12/31/97 
   at 08:42 AM, Hal Finney <[email-masked]> said:

>We have not attempted to give detailed explanations of the intented uses
>or motivations of any of the features in the spec.  The spec simply
>defines the syntax and semantics.  There have been suggestions that we
>need a companion document to define rationale for the various features,
>which could be a follow-on project.  It seems to me though that almost
>every section of the spec deserves a page or more describing the
>motivations, the purpose, security considerations, things to watch for,
>etc.  So a rationale doc would probably considerably larger than the
>spec, and its creation will be a large project.

Well I have been working on a document for outlining the implementation of
the OpenPGP spec to messaging systems. I have around 35 pages written so
far and I am no where close to being done. Much of the info in the
document comes from my own experince of integrating PGP into messageing
systems over the past couple of years.

Below is an outline of the document:

Contents:
=========

I       Inbound Processing 
 a		Encrypted Messages 	
 b		Signed Messages 	
 c	 	Attached Keys 
 d		Message Stamping
II      Outbound Processing 
 a 		Auto Signing 
 b		Auto Encryption 
 c           WordWrap
III     User Interaction
 a		Key Lookups
 b		Signing
 c		Encrypting
 d		Attaching Keys
 e		Decrypting
 f		Verifying Signatures
 g		Removing Signatures
 h		Detaching Keys
IV      Key Generation
V       Key Management 
 a		KeyRing Indexing 
 b		Key Lookups 
 c		KeyServer Interaction 
 d		Multiple Keyring Support 
 e		Key Caching
VI      Remote Processing
 a		Signature Verification
 b		Message Encryption
 c		Policy Enforcement
VII     3rd Party Services
 a		Time Stamping Services
 b		Notary Services
 c		Certifying Authorities (CA's)
Appendix A	References
Appendix B	Glossary
Appendix C	Example Code
Index

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Wed, 31 Dec 1997 08:42:23 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: section 4.3
Sender: [email-masked]

William H. Geiger III, <[email-masked]>, writes:
> Hmmmmm I am going to present a senario below and see if this follows your
> logic here:
>
> User 1 generate a KeyPair.
>
> User 1 self-signs (Sig1) his Public Key (Pub1) with the private key
> (Sec1).
>
> In Sig1 he make's the sig non-revokable and the key revokable by User 2's
> key (Sec2).
>
> Now Sec1 is comprimised and User1 may not have a copy of Sec1 after the
> comprimise.
>
> User 1 notifies User 2 of the comprimise. [This presents an interesting
> senario in itself of how does one notify User2 if the key used for
> authentiaction is comprimised <g>].

[This would have to be done by out of band means, similar to how he would
identify himself to get his key signed by another party.]

> User 2 issues the revoke certificate (Revoke1) using Sec2.
>
> Revoke1 is accepted by Pub1 because of the 3rd party revoke flag in Sig1.
>
> The holder of the comprimised Sec1 can not prevent this as Sig1 is marked
> as non revokable.

This is a good explanation.  Thanks for providing it.  There has been so
much attention paid to the additional recipient feature that few people have
had the energy to look at the other new features.

> I think I understand the service you are trying to provide but to be
> honest it does not give me any warm fuzzies thinking about it.
>
> What does one do if Sec2 rather than Sec1 is comprimised?

In that case Sec1 could be revoked improperly, and the keyholder would
have to create a new key.  This is a denial of service attack rather
than a security breach.  No encrypted messages to Sec1 could be read.
So it is a less damaging attack.

> What does user1 do if he whishes to change the status of the preferences
> in his self signature? Say he no longer wishes for User2 to have revoke
> powers, or User2 needs to change his revoke key (Sec2)?

He would have to have two self signatures, one holding the third party
revocation grant, and one holding his preferences.

> Also how should the non-revoke flag interact with the experation flag?
> Which should take presedent? Should a non-revokable signature be treated
> as non-expirable?

The non-revoke flag says that there will be no revocations.  It does
not say anything about expirations, so there is no reason to think it
should be non-expirable.  Look at it this way: since they are in the
same signature, the same author must have created both the expiration
and the non-revocation.  The reasonable interpretation is that he wanted
the signature to expire at the specified time, but he wanted it to be
non-revocable prior to that time.

> I think that a detaled explination of this subtype is warrented along with
> it's inteded use and where it should never be used. Improperly implemented
> this feature could cause all kinds of havok. Things like the non-revoke
> flag being set on signatures other than self-signatures with the 3rd party
> revoke being set.

We have not attempted to give detailed explanations of the intented
uses or motivations of any of the features in the spec.  The spec
simply defines the syntax and semantics.  There have been suggestions
that we need a companion document to define rationale for the various
features, which could be a follow-on project.  It seems to me though
that almost every section of the spec deserves a page or more describing
the motivations, the purpose, security considerations, things to watch
for, etc.  So a rationale doc would probably considerably larger than
the spec, and its creation will be a large project.

Hal

Date: Wed, 31 Dec 1997 09:48:03 +0000
From: Jeff Williams <[email-masked]>
Organization: IEG. INC.
To: [email-masked]
CC: [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

Eric and all,

EKR wrote:
> 
> Will, I'm not particularly interested in debating protocol
> level crypto policy here. However, the crypto export laws
> are reality for most people here, and I find your attempt to
> imply that they're easily worked around fairly disingenuous.

  True enough.  I agree There are no easy work arounds.  But 
workarounds are really not the issue. US export and ITAR policy
is.  You are correct however this is not a good forum to discuss
policy in that context.
 
> Will Price <[email-masked]> writes:
> > At Pretty Good Privacy, we developed a reliable system which will be
> > continued by Network Associates.  The outline: write source code for
> > product, print source code in book, distribute book using normal means.
> > Now the process becomes somewhat foggier.  In any case, printed source code
> > for product gets exported -- note that this is of course legal.
> > Individuals outside the US scan source code.  A legally exported binary
> > version of the product then becomes available internationally.  Copyrights,
> > trademarks, and licenses protect the original vendor and revenue can be
> > made off the exported product.  This is only one highly functional system
> > for getting this done.
> It's hard to believe that this is really going to work for many
> real programs.

  No not many, correct but some.  And this is part of the problem to
which I believe Will's point is trying to make here.

> Have you seen the size of Netscape lately. Have
> you noticed how often Netscape ships new versions? (I'm not
> trying to pick on Netscape here. IE has similar characteristics.
> There are plenty of other big programs but web browsers hae
> particularly fast release cycles.)

  Exactly what I believe Will was trying to make here.
> 
> > insecure.  Such stories reduce user faith in everybody's security products.
> > The only solution is public code review.
> It's not obvious this makes much of a difference. Note that Sendmail
> source code has been widely available since the beginning.
> 
> > Some companies will undoubtedly never bring themselves to implementing one
> > of the above systems and will thus be relegated to snake oil security
> > internationally until the laws in the US change.

> I think it's unreasonable to say that 40 bit crypto is "snake oil".
> It's exactly as strong as advertised. There's no secret about the
> situation.

  No, not snake oil, but for most serious applications nearly worthless.
> 
> > Let's not infect our protocols with such politics.  TLS 1.0 is a done deal
> > as far as I'm concerned.  SSL3 had export algorithms, so TLS1 does too,
> > fine.  There are now many better solutions to the export problem,
> Perhaps, but you haven't suggested any.
> 
> -Ekr
> 
> --
> [Eric Rescorla                             Terisa Systems, Inc.]
>                 "Put it in the top slot."

Regards,
-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. IEG. INC. (Soon to be INEG. INC) Stay tunned! 
E-Mail [email-masked]

Wisdom:   "One who knows others is wise,
           one who knows himself is enlightened."
           Lao Tzu

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 31 Dec 97 08:34:34 -0600
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: section 4.3
Sender: [email-masked]

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

In <[email-masked]>, on 12/30/97 
   at 01:01 PM, Hal Finney <[email-masked]> said:

>> I also have some problems with some of the signature subpackets.
>>
>> - -- Revokable
>>
>> Is it really appropriate to have a signature that can not be revoked?

>This was intended to be used along with the third-party revocation
>mechanism.  This allows you to specify that some third party key has the
>power to revoked your key.  People are constantly forgetting their
>passphrases and are unable to revoke their own keys.  This will allow
>them to request a revocation from a designated third party.

>However if this third-party authorization self-signature were itself
>revocable, then someone who stole the secret key could revoke the
>third-party revocation authorization, making any attempt by the third
>party to revoke the key be ineffective.  So at least in this case it
>makes sense for the third party revocation authorization self signature
>to be irrevocable.  Given one use, more may be discovered, so I thought
>it should be a separate subpacket.

Hmmmmm I am going to present a senario below and see if this follows your
logic here:

User 1 generate a KeyPair.

User 1 self-signs (Sig1) his Public Key (Pub1) with the private key
(Sec1).

In Sig1 he make's the sig non-revokable and the key revokable by User 2's
key (Sec2).

Now Sec1 is comprimised and User1 may not have a copy of Sec1 after the
comprimise.

User 1 notifies User 2 of the comprimise. [This presents an interesting
senario in itself of how does one notify User2 if the key used for
authentiaction is comprimised <g>].

User 2 issues the revoke certificate (Revoke1) using Sec2.

Revoke1 is accepted by Pub1 because of the 3rd party revoke flag in Sig1.

The holder of the comprimised Sec1 can not prevent this as Sig1 is marked
as non revokable.

I think I understand the service you are trying to provide but to be
honest it does not give me any warm fuzzies thinking about it.

What does one do if Sec2 rather than Sec1 is comprimised?

What does user1 do if he whishes to change the status of the preferences
in his self signature? Say he no longer wishes for User2 to have revoke
powers, or User2 needs to change his revoke key (Sec2)?

Also how should the non-revoke flag interact with the experation flag?
Which should take presedent? Should a non-revokable signature be treated
as non-expirable?

I think that a detaled explination of this subtype is warrented along with
it's inteded use and where it should never be used. Improperly implemented
this feature could cause all kinds of havok. Things like the non-revoke
flag being set on signatures other than self-signatures with the 3rd party
revoke being set.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Wed, 31 Dec 1997 00:07:32 -0800
To: [email-masked]
From: Will Price <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
Cc: [email-masked]
Sender: [email-masked]

At 11:15 PM -0800 12/30/97, Eric Rescorla wrote:
>Will, I'm not particularly interested in debating protocol
>level crypto policy here. However, the crypto export laws
>are reality for most people here, and I find your attempt to
>imply that they're easily worked around fairly disingenuous.

Easily?  If you got the impression from my message that it was easy, I
suggest you read it again.  What you imply here is that you need an easy
solution.  If you were willing to do something slightly less than easy, you
might find another solution as other companies have.  This issue is at the
very core of secure software.  If it isn't done right, nothing is.  Use of
40 bit scrambling is exactly the kind of issue on which companies making
security products cannot use the easy solution.

>Will Price <[email-masked]> writes:
>> At Pretty Good Privacy, we developed a reliable system which will be
>> continued by Network Associates.  The outline: write source code for
>> product, print source code in book, distribute book using normal means.
>> Now the process becomes somewhat foggier.  In any case, printed source code
>> for product gets exported -- note that this is of course legal.
>> Individuals outside the US scan source code.  A legally exported binary
>> version of the product then becomes available internationally.  Copyrights,
>> trademarks, and licenses protect the original vendor and revenue can be
>> made off the exported product.  This is only one highly functional system
>> for getting this done.
>It's hard to believe that this is really going to work for many
>real programs. Have you seen the size of Netscape lately. Have
>you noticed how often Netscape ships new versions? (I'm not
>trying to pick on Netscape here. IE has similar characteristics.
>There are plenty of other big programs but web browsers hae
>particularly fast release cycles.)

Have you seen the size of PGP 5.5.3 on 10 different platforms lately with
all the GUI code?  It's not exactly small.  As for dot releases, use a diff
printed release.  Publish the diffs since the last source release.  We've
done it.  It works.  Big is not an issue.  Binaries, pictures, and all the
other things that go into a product are not an issue.  Very simple, solved
problems.

>> insecure.  Such stories reduce user faith in everybody's security products.
>> The only solution is public code review.
>It's not obvious this makes much of a difference. Note that Sendmail
>source code has been widely available since the beginning.

Nobody trusts sendmail.  Nobody needs to trust sendmail if they use secure
mail.  Secure systems are built to be simple enough to comprehend fully so
that reviewers can analyze it fully.  Sendmail clearly doesn't fall into
this category.  Everyone knows sendmail is buggy, so nobody wastes their
time trying to document every bug.

>> Some companies will undoubtedly never bring themselves to implementing one
>> of the above systems and will thus be relegated to snake oil security
>> internationally until the laws in the US change.
>I think it's unreasonable to say that 40 bit crypto is "snake oil".
>It's exactly as strong as advertised. There's no secret about the
>situation.

There is no "advertising" of it.  The users are simply unaware --
effectively making it a secret.  When was the last time you saw a big
company putting a very visible warning about 40 bit security inside its 40
bit product?  I know I've never seen something like that.  Further, even
the strong crypto products are infected by the weak crypto products in
protocols like S/MIME and SSL which require both sides to use the same
algorithms.  No warning is given in those cases either in any of the
products I've examined.  It leads to a cascade effect wherein the vast
majority of users end up having no security when they think they do have
security.  The deceit here is that even when users learn about 40 bit
security, they think it is still encryption.  Realistically, it just isn't.

>> Let's not infect our protocols with such politics.  TLS 1.0 is a done deal
>> as far as I'm concerned.  SSL3 had export algorithms, so TLS1 does too,
>> fine.  There are now many better solutions to the export problem,
>Perhaps, but you haven't suggested any.

I suggested three each of which is completely workable and in use by real
companies as big as Sun.  It isn't clear how you say that I have not
suggested any when there are very clearly three alternatives suggested.  If
these don't work for you, I suggest seeking legal advice.  There are many
other roads that haven't yet been travelled.  Don't look for the easy
solution, look for the right solution.

-Will

Will Price, Architect
Network Associates, Inc.
Direct  (650)596-1956
Main    (650)572-0430
Fax     (650)631-1033
Cell/VM (650)533-0399
<pgpfone://clotho.pgp.com>

PGPkey: <http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0xCF73EC4C>

To: <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
From: EKR <[email-masked]>
Date: 30 Dec 1997 23:15:24 -0800
Lines: 45
Sender: [email-masked]

Will, I'm not particularly interested in debating protocol
level crypto policy here. However, the crypto export laws
are reality for most people here, and I find your attempt to
imply that they're easily worked around fairly disingenuous.

Will Price <[email-masked]> writes:
> At Pretty Good Privacy, we developed a reliable system which will be
> continued by Network Associates.  The outline: write source code for
> product, print source code in book, distribute book using normal means.
> Now the process becomes somewhat foggier.  In any case, printed source code
> for product gets exported -- note that this is of course legal.
> Individuals outside the US scan source code.  A legally exported binary
> version of the product then becomes available internationally.  Copyrights,
> trademarks, and licenses protect the original vendor and revenue can be
> made off the exported product.  This is only one highly functional system
> for getting this done.
It's hard to believe that this is really going to work for many
real programs. Have you seen the size of Netscape lately. Have
you noticed how often Netscape ships new versions? (I'm not
trying to pick on Netscape here. IE has similar characteristics.
There are plenty of other big programs but web browsers hae
particularly fast release cycles.)

> insecure.  Such stories reduce user faith in everybody's security products.
> The only solution is public code review.
It's not obvious this makes much of a difference. Note that Sendmail
source code has been widely available since the beginning.

> Some companies will undoubtedly never bring themselves to implementing one
> of the above systems and will thus be relegated to snake oil security
> internationally until the laws in the US change.
I think it's unreasonable to say that 40 bit crypto is "snake oil".
It's exactly as strong as advertised. There's no secret about the
situation.

> Let's not infect our protocols with such politics.  TLS 1.0 is a done deal
> as far as I'm concerned.  SSL3 had export algorithms, so TLS1 does too,
> fine.  There are now many better solutions to the export problem,
Perhaps, but you haven't suggested any.

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Tue, 30 Dec 1997 20:01:03 -0800
To: [email-masked], [email-masked]
From: Will Price <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

Rather than quoting the messages on this topic, I'll just reference the
other messages on the topic of export algorithms and issues which
originated from my exclusion of export algorithms from the TLS/OpenPGP
Spec.  The debate over exactly what one can export legally usually proceeds
under seriously false assumptions in my opinion.  It generally starts with
what bit level algorithm can be exported, proceeds to discussions about
hooks whether general or crypto specific, usually has some mention of
MS-CAPI until people realize that the modules have to be signed, those with
legal knowledge try to jump in and help, and ends up with people being
somewhat confused and feeling fairly helpless leading to less crypto
software being written -- exactly the result the US government intended.

Not directed at anyone in particular, but let's get back to basics people.
There's no sense whatsoever in putting "export" algorithms into a product.
It isn't encryption.  The time is truly upon us when export algorithms are
crackable in near real time by normal people.  You might as well include a
decoder ring with your product, it will take just as long or longer to
decrypt for a casual attacker.

At Pretty Good Privacy, we developed a reliable system which will be
continued by Network Associates.  The outline: write source code for
product, print source code in book, distribute book using normal means.
Now the process becomes somewhat foggier.  In any case, printed source code
for product gets exported -- note that this is of course legal.
Individuals outside the US scan source code.  A legally exported binary
version of the product then becomes available internationally.  Copyrights,
trademarks, and licenses protect the original vendor and revenue can be
made off the exported product.  This is only one highly functional system
for getting this done.  One other alternative is to base all R&D outside
the US which is infeasible for most US companies -- but Sun did it with
SKIP.  Finally, the crypto hooks mechanism does work and Commerce does in
fact approve APIs that are intended for crypto but have been generalized
for other uses, Qualcomm's EMSAPI used in Eudora is a perfect example of
this.

I can hear the first cry that some people will have now: are you crazy, we
can't publish our source code!  My response: well then what are you doing
in the security business?  This sector isn't about proprietary algorithms
and code.  It is not feasible to achieve secure software without public
peer review by many cryptographers.  We have seen time and time again how
the smallest security bugs have turned into major international crises for
some of the larger companies doing this.  One can only imagine how many
more such issues are left to be found were a quality cryptographic public
peer review to take place on such products with access to source code.  The
majority of users reading the New York Times have no clue what a particular
security flaw is about.  They just know that the NYT says that product is
insecure.  Such stories reduce user faith in everybody's security products.
The only solution is public code review.

Now I can hear not only the cries about publishing source code, but the
feathers of some readers getting ruffled believing that I have implied
security flaws in their wonderful products.  Not at all.  I have the utmost
respect for any company that makes an attempt to write crypto software in
the US.  We're all under these silly laws together.  I use some of the
products which have had reported security flaws in the past, but those
products would be that much more valuable if one was able to trust their
security from 3rd party review and if their protocol infrastructures had
not been infected by 40 bit scrambling algorithms.

Some companies will undoubtedly never bring themselves to implementing one
of the above systems and will thus be relegated to snake oil security
internationally until the laws in the US change.  However, there *are* good
and reliable ways for even the largest companies to solve this problem
legally.  Inclusion of "export" algorithms is, IMHO, security suicide.
What has happened in many cases is that the installed base of, for
instance, S/MIME and SSL users has been so infected by 40 bit clients that
the vast majority really have no idea that the security they are using is
completely useless.  It forces those few with secure clients corresponding
with those using 40 bit clients to also use 40 bit and so on -- generally
without any warning to either user that their security has been eliminated.
Some companies like Wells Fargo have tried to take a stand and require 128
bit crypto SSL and they get major flack from users who don't understand
what is wrong with their 40 bit browser.

Caving in and using 40 bit algorithms is *not* a solution to anything.  We
all know this, but the speed of business can make that choice less clear.
The argument that "we have to sell it, so we have to include 40 bit" just
doesn't wash given that there are all sorts of creative legal alternatives.
The bigger the company, the more resources that company has to enable the
alternatives -- which is why it is so odd that the smaller companies often
produce the more secure software.  Mass producing a source code book of
>7000 pages for the PGP products isn't something a one person operation
would be doing, but is trivial for a normal company.

Let's not infect our protocols with such politics.  TLS 1.0 is a done deal
as far as I'm concerned.  SSL3 had export algorithms, so TLS1 does too,
fine.  There are now many better solutions to the export problem, let's not
fall into the trap of using the easiest way out in new specifications.

-Will

Will Price, Architect
Network Associates, Inc.
Direct  (650)596-1956
Main    (650)572-0430
Fax     (650)631-1033
Cell/VM (650)533-0399
<pgpfone://clotho.pgp.com>

PGPkey: <http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0xCF73EC4C>

Date: Tue, 30 Dec 1997 20:00:55 -0800
To: [email-masked]
From: Will Price <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
Cc: [email-masked]
Sender: [email-masked]

At 10:03 PM -0800 12/29/97, Tom Weinstein wrote:
>Will Price wrote:
>>
>> The alternative seems to be to include another subpacket in the Hello
>> packets negotiating certificate type just like compression is negotiated.
>> This would also be allowed by the spec as per 7.4.1.2.  If it was to be
>> done that way, I felt that this negotiation should have been included in
>> the TLS spec.  Since I assume the time for that has passed, I opted for
>> the ciphersuite overload.
>
>I don't think it can go into TLS 1.0, but it's definitely something we
>should work towards for a TLS 1.1 or 2.0.

Great.  When does work start on TLS 1.1/2.0?

Clearly, the TLS/OpenPGP document needs to move forward anyway based on TLS
1.0 and could later be revised for a future version of TLS.

>>> 3. Omitting the DistinguishedName field in the CertificateRequest
>>> field seems problematic. I understand PGP doesn't use DNs,
>>> but there should be a way to indicate who might be potential signers
>>> of a given key.
>>
>> OpenPGP keys generally have all the certs they need attached to them
>> whereas X509 certs are only a single cert unto themselves thus requiring
>> a chain if the specified cert is not directly certified by a root CA.
>> With OpenPGP, if a particular signer key is not found, the client or
>> server can use a certserver to look it up.
>
>Although TLS uses the X.509 cert formats, it doesn't require an X.500
>directory to operate.  I don't think it's a good idea to require an OpenPGP
>cert server, either.

I didn't mean to imply any such requirement for a certserver in my message
and the document makes no mention of such.  As stated in the document, this
issue is implementation dependent.  The equivalent of a DN in OpenPGP is
the 64 bit KeyID.  A reading of the OpenPGP spec will show that the "DN" or
KeyID is included in the certificate and can also replace the certificate.
I can see some implementations requiring users to get their OpenPGP key
certified by a particular CA, other implementations which simply accept any
key on first connection and require the authentication from that same key
on future connections like SSH, and other implementations which know the
keys for particular addresses and transmit only the KeyID rather than the
certificate.  A particularly complex implementation could get the key in
the Certificate message, lookup all the certifiers on a certserver and try
to establish validity dynamically that way, but I don't see that as likely
-- only a possible use.

-Will

Will Price, Architect
Network Associates, Inc.
Direct  (650)596-1956
Main    (650)572-0430
Fax     (650)631-1033
Cell/VM (650)533-0399
<pgpfone://clotho.pgp.com>

PGPkey: <http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0xCF73EC4C>

Date: Tue, 30 Dec 1997 12:52:17 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
To: Ben Laurie <[email-masked]>
Cc: [email-masked], "William H. Geiger III" <[email-masked]>, [email-masked]
Sender: [email-masked]

[This is fairly off-topic for the ietf-TLS list, but the issue is of such
importance to implementors regardless of IETF policy regarding such matters
that I think a little more discussion is permissible.]

> > > At the very least one would think that the US vendors would put thier
> > > crypto code in one DLL and document the API so someone overseas could
> > > replace it with somthing worth using. <sigh> I guess even that is too
> > > much to ask.

> > If the US government would let us, you better believe we'd do it.  We have
> > no vested interest in helping the NSA eavesdrop on people.  We make money
> > by selling software that meet our customers' needs, and that includes being
> > secure.

> > The strategy you describe is called "crypto with a hole", and is explicitly
> > forbidden by the export regs.

> Is this really true? I've heard it said a lot, but there's contradictory
> evidence...

> Way back when, NCSA were advised by the NSA that crypto hooks were
> illegal, and should be removed. NCSA did so, and passed this advice on
> to the Apache Group, who also did so. However, when later challenged, I
> seem to remember that this was denied (i.e. the USG claimed that they
> had never advised that hooks were illegal). This actually happened
> before I was involved in Apache, but I investigated it in some depth
> when I did Apache-SSL, in the hope that I could ease the load of
> tracking new versions. The results were inconlusive, but the Apache
> Group were unwilling to take the risk. So far, no-one has shown me
> definitive proof that hooks are illegal.

I'm no lawyer, but I think 15 CFR 774 supplement 1 section 5D002 does this,
more or less. For those not familiar with this terminology, this the Code of
Federal Regulations, Title 15 (Commerce and Foreign Trade), Volume 2 Chapter
VII, part 774 (The Commerce Control List). This is one small piece of the EAR,
or Export Administration Regulations, specifically its a subpart of the part
that says what's covered and what isn't. A copy of this can be found at
http://jya.com/774-ccl05.htm (I tried to find an officia GPO version of it at
www.access.gpo.gov but I cannot figure out how to retrieve supplements from
their server.)

Specifically, item a in section 5D002 says that "Software specially designed or
modified for the development, production or use of equipment or software
controlled by ... section 5D002" comes under export control. (A
self-referential rule... how cute.) And item c.1 in this same section specifies
encyption software explicitly.

In other words, there appears to me that software which was specifically
designed or modified to allow it to be used with encryption software is itself
regulated. And so is, for that matter, software which in turn references such
software.

> I'm also curious to know how Microsoft's CryptoAPI fits into this scheme
> of things?

My understanding is that CryptoAPI plugins are themselves signed, and unless
that signature is valid the plugin cannot be used. As such, it is possible to
regulate what plugs will actually work and what plugins will not work.

> Another interesting factor is that the evolution of the Apache API is
> gradually making it easier to add crypto without modification to the
> base code (you can't actually do it yet, but less hacking is required
> than at first). This has happened for reasons not directly connected
> with crypto. If Apache's API enables the addition of crypto as a pure
> module, does that make Apache's API unexportable, even if every aspect
> of it can be justified without resort to crypto hooks?

> Apache 2.0 (if it ever happens) is pretty likely to permit this, since
> it will allow layered I/O (which is the last major hurdle preventing
> it). Layered I/O is required to support all sorts of other advanced
> features (such as compressed transfer encodings, SSI over CGI, blah,
> blah).

This, I think, is a very interesting point. The text I just cited seems like it
may only apply to interfaces specifically designed for cryptographic plugins. A
more generic plugin interface with lots of other uses might fly. (Indeed, it is
hard to see how it could not, given that such interfaces exist in abundance in
literally hundreds of existing products.)

Of course it doesn't serve the government's interest to clarify this in any
way, which I think explains the NCSA debacle. It may well be that my reading of
the regulations is totally incorrect -- as I said, I'm no lawyer. It may be
that it is what it intended but not what the text actually ends up saying in a
legal sense. It may be that my interpretation is what is intended and what is
said but the rule is nevertheless flawed and unenforcable. It may be that the
rule is valid and enforceable but doesn't cover interfaces with more general
utility. Or it could cover the very general case, and everyone with a more
general interface that could conceivably be used to hook in encryption is in
technical violation of the law. However, a general chilling effect is obtained,
especially among those of us with a fiduciary responsibility to our companies
and stockholders, by leaving it unclear -- an effect that could never be
obtained by a clearer rule.

In any case, if you want to pursue this further offline I'd be happy to do so
as well.

				Ned

Date: Tue, 30 Dec 1997 20:44:11 +0100
To: IETF Open-PGP List <[email-masked]>
From: "Anthony E. Greene" <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

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

At 07:00 30-12-97 -0600, William H. Geiger III wrote:
>My understanding is that the MS Crypto API that is shiped overseas
>contains only weak crypto. The API is also signed so that no new/modified
>code can be added without the MS signature.
>
>I don't know for sure but I would imagine that the export product makes
>use of a different key then the domestic product so that the domestic code
>will not run on the export version.

The way I understand it, the API requires that the crypto module be signed 
with Microsoft's corporate key. I assume that Microsoft follows ITAR in 
deciding which modules get signed. The USG required such a mechanism before 
allowing export of Microsoft products that include the API. For the 
purposes of this working group, that makes it useless.

 --
 Anthony E. Greene <[email-masked]>
 PGP Key: <http://www.pobox.com/~agreene/pgp/agreene.key>

Date: Tue, 30 Dec 1997 10:01:52 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: section 4.3
Sender: [email-masked]

William H. Geiger III, <[email-masked]>, writes:
> I have a question regarding the Packet Tags (aka Cipher Type Byte) in
> section 4.3 [page 16].
>
> It has 14 as subkey packet, 15 reserved, and 16 as comment packet but
> accorinding to my notes the comment packet currently is 1110 (14 base 10).
> Also since 0-F is 0-15 (16 digits) it would seem that the Reserved status
> for type 15 needs to be removed and that the Subkey Packet type be
> assigned this number. This is assuming we are keeping current CTB's as is
> and reserving the 2 byte type codes for future use.

We changed packet type 14 from comment to subkey intentionally, to
facilitate backwards compatibility with PGP 2.6.2.  Packet 14 had never
actually been emitted by any version of PGP, but it would be ignored.
This way subkey packets don't break PGP 2.6.2.  The DSS/ElGamal keys
don't work with that version, of course, but at least 2.6.2 doesn't crash
if it sees one.  This was better than other solutions we tried.

> There are quite a few issues that AFAIK are still unresolved yet there
> seems to be little to no discussion of them:
>
> - -- UserID Revocation
> - -- Signing of Just the Key
> - -- Signing of Key and multiple userID's

These would be better left for V2 of OPGP.  I continue to believe that our
best approach is to avoid introducing more new features.

> I also have some problems with some of the signature subpackets.
>
> - -- Revokable
>
> Is it really appropriate to have a signature that can not be revoked?

This was intended to be used along with the third-party revocation
mechanism.  This allows you to specify that some third party key has
the power to revoked your key.  People are constantly forgetting their
passphrases and are unable to revoke their own keys.  This will allow
them to request a revocation from a designated third party.

However if this third-party authorization self-signature were itself
revocable, then someone who stole the secret key could revoke the
third-party revocation authorization, making any attempt by the third
party to revoke the key be ineffective.  So at least in this case it
makes sense for the third party revocation authorization self signature
to be irrevocable.  Given one use, more may be discovered, so I thought
it should be a separate subpacket.

> Also I didn't note any mechanism to inform an end user that various
> preferences in the subpacket had changed. Perhaps there could be an
> "update" signature subpacket. Basicly this is how it would work:

An interesting idea for a future version.  We need to think about
extending it to go beyond a binary flag, though, since multiple updates
may occur at different times.  Also, I suspect that we may eventually
have multiple self signature preference packets and you'd have to specify
which one(s) had been updated.

Hal

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 30 Dec 97 07:00:32 -0600
To: Ben Laurie <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

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

In <[email-masked]>, on 12/30/97 
   at 12:45 PM, Ben Laurie <[email-masked]> said:

>I'm also curious to know how Microsoft's CryptoAPI fits into this scheme
>of things?

My understanding is that the MS Crypto API that is shiped overseas
contains only weak crypto. The API is also signed so that no new/modified
code can be added without the MS signature.

I don't know for sure but I would imagine that the export product makes
use of a different key then the domestic product so that the domestic code
will not run on the export version.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 30 Dec 97 05:52:10 -0600
To: Tom Weinstein <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

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

In <[email-masked]>, on 12/30/97 
   at 03:11 AM, Tom Weinstein <[email-masked]> said:

>William H. Geiger III wrote:
>> In <[email-masked]>, on 12/30/97
>>    at 01:03 AM, Tom Weinstein <[email-masked]> said:
>> 
>>> While I support the ideal of building standards that use strong crypto,
>>> it does nobody any good to create a standard which won't get
>>> implemented.  The export ciphers exist because in order for US software
>>> manufacturers to use TLS, they have to be able to export the software
>>> that includes it.  It is certainly true that there are many software
>>> developers who live in the free world, but those of us stuck in the US
>>> still need to sell software.
>> 
>> But who in their right minds are going to buy it??

>Products compete along more than one axis.  It's a sad fact that much of
>the most usable software is also some of the least secure.  It would be
>great if the most popular product could always be the most secure, but it
>doesn't always work out that way.  Do I really have to explain this to
>anyone?

It all depends on who you are marketing your product to and for what use.
If you are adding crypto so joe sixpack can have warm fuzzies when he uses
his credit card on the internet then you could use ROT-13 for all the
difference it would make. On the other hand if you are trying to sell to
john doe for securing his banking transaction security consideration far
outweigh "usability". No matter how pretty you make your interface, if he
has any smarts at all he woun't settle for rc2/40 or some other weak
crypto. Look at the stink going on in Sweeden right now as the government
is just finding out the their Lotus Notes system is insecure.

>> I for one would *never* recomend to my overseas clients to use crippled
>> US export crypto products. There are just too many people writting
>> non-crippled software to justify it.
>> 
>> At the very least one would think that the US vendors would put thier
>> crypto code in one DLL and document the API so someone overseas could
>> replace it with somthing worth using. <sigh> I guess even that is too
>> much to ask.

>If the US government would let us, you better believe we'd do it.  We
>have no vested interest in helping the NSA eavesdrop on people.  We make
>money by selling software that meet our customers' needs, and that
>includes being secure.

>The strategy you describe is called "crypto with a hole", and is
>explicitly forbidden by the export regs.

I'll leave that one for the layers. :)

An interesting thought: What liability does a software/hardware vendor
have if they knowingly sell an insecure product and because of that the
customers security is breached and losses are sustained? Are they open to
charges of fraud if they market and sell a product as "Secure" while they
know it is not?

While US vendors make some sales in the short term unless things change
they are going to find themselves to be a big fish in an ever shrinking
pond. Once offshore security vendors become established meeting the
unsatisfied demand for secure products overseas, US vendors will be
fighting them for US market share (unless Freeh gets his way and restricts
imports of strong crypto and domestic use of strong crypto).

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Tue, 30 Dec 1997 12:45:51 +0000
From: Ben Laurie <[email-masked]>
Organization: A.L. Digital Ltd.
To: [email-masked]
CC: "William H. Geiger III" <[email-masked]>, [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

Tom Weinstein wrote:
> > At the very least one would think that the US vendors would put thier
> > crypto code in one DLL and document the API so someone overseas could
> > replace it with somthing worth using. <sigh> I guess even that is too
> > much to ask.
> 
> If the US government would let us, you better believe we'd do it.  We have
> no vested interest in helping the NSA eavesdrop on people.  We make money
> by selling software that meet our customers' needs, and that includes being
> secure.
> 
> The strategy you describe is called "crypto with a hole", and is explicitly
> forbidden by the export regs.

Is this really true? I've heard it said a lot, but there's contradictory
evidence...

Way back when, NCSA were advised by the NSA that crypto hooks were
illegal, and should be removed. NCSA did so, and passed this advice on
to the Apache Group, who also did so. However, when later challenged, I
seem to remember that this was denied (i.e. the USG claimed that they
had never advised that hooks were illegal). This actually happened
before I was involved in Apache, but I investigated it in some depth
when I did Apache-SSL, in the hope that I could ease the load of
tracking new versions. The results were inconlusive, but the Apache
Group were unwilling to take the risk. So far, no-one has shown me
definitive proof that hooks are illegal. 

I'm also curious to know how Microsoft's CryptoAPI fits into this scheme
of things?

Another interesting factor is that the evolution of the Apache API is
gradually making it easier to add crypto without modification to the
base code (you can't actually do it yet, but less hacking is required
than at first). This has happened for reasons not directly connected
with crypto. If Apache's API enables the addition of crypto as a pure
module, does that make Apache's API unexportable, even if every aspect
of it can be justified without resort to crypto hooks?

Apache 2.0 (if it ever happens) is pretty likely to permit this, since
it will allow layered I/O (which is the last major hurdle preventing
it). Layered I/O is required to support all sorts of other advanced
features (such as compressed transfer encodings, SSI over CGI, blah,
blah).

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: [email-masked] |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 30 Dec 97 04:51:24 -0600
To: [email-masked]
Subject: section 4.3
Sender: [email-masked]

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

Hi,

I have a question regarding the Packet Tags (aka Cipher Type Byte) in
section 4.3 [page 16].

It has 14 as subkey packet, 15 reserved, and 16 as comment packet but
accorinding to my notes the comment packet currently is 1110 (14 base 10).
Also since 0-F is 0-15 (16 digits) it would seem that the Reserved status
for type 15 needs to be removed and that the Subkey Packet type be
assigned this number. This is assuming we are keeping current CTB's as is
and reserving the 2 byte type codes for future use.

After the holidays would it be possiable to get some type of status report
to the list as far as where we are with the drafts?

There are quite a few issues that AFAIK are still unresolved yet there
seems to be little to no discussion of them:

- -- UserID Revocation
- -- Signing of Just the Key
- -- Signing of Key and multiple userID's

I also have some problems with some of the signature subpackets.

- -- Revokable

Is it really appropriate to have a signature that can not be revoked?

Also I didn't note any mechanism to inform an end user that various
preferences in the subpacket had changed. Perhaps there could be an
"update" signature subpacket. Basicly this is how it would work:

Adam self-signs his public key with all his preferences and then posts the
key to his prefered public keyserver.

Mary DL's the key and her OP software follows all of Adams preferences.

6mo latter Adam has updated his software and has new preferences.

On all messages that Adam signs there is an "update" subpacket that tells
Mary's OP software that Adam has changed his preferences and to get an
updated key.

At this time Mary need not know what changes have been made only that
there has been changes and a updated key needs to be obtained.

All that should be needed in the update subpacket is a timestamp which can
be compared to the timestamp on the self signature on the public key. 

I wouldn't mind hearing where others are in implementing the OpenPGP draft
(others are writting code arn't they <g>).

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Tue, 30 Dec 1997 03:11:45 -0800
From: Tom Weinstein <[email-masked]>
Organization: Netscape Communications, Inc.
To: "William H. Geiger III" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

William H. Geiger III wrote:
> In <[email-masked]>, on 12/30/97
>    at 01:03 AM, Tom Weinstein <[email-masked]> said:
> 
>> While I support the ideal of building standards that use strong crypto,
>> it does nobody any good to create a standard which won't get
>> implemented.  The export ciphers exist because in order for US software
>> manufacturers to use TLS, they have to be able to export the software
>> that includes it.  It is certainly true that there are many software
>> developers who live in the free world, but those of us stuck in the US
>> still need to sell software.
> 
> But who in their right minds are going to buy it??

Products compete along more than one axis.  It's a sad fact that much of
the most usable software is also some of the least secure.  It would be
great if the most popular product could always be the most secure, but it
doesn't always work out that way.  Do I really have to explain this to
anyone?

> I for one would *never* recomend to my overseas clients to use crippled
> US export crypto products. There are just too many people writting
> non-crippled software to justify it.
> 
> At the very least one would think that the US vendors would put thier
> crypto code in one DLL and document the API so someone overseas could
> replace it with somthing worth using. <sigh> I guess even that is too
> much to ask.

If the US government would let us, you better believe we'd do it.  We have
no vested interest in helping the NSA eavesdrop on people.  We make money
by selling software that meet our customers' needs, and that includes being
secure.

The strategy you describe is called "crypto with a hole", and is explicitly
forbidden by the export regs.

-- 
What is appropriate for the master is not appropriate| Tom Weinstein
for the novice.  You must understand Tao before      | [email-masked]
transcending structure.  -- The Tao of Programming   |

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 30 Dec 97 03:47:52 -0600
To: Tom Weinstein <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

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

In <[email-masked]>, on 12/30/97 
   at 01:03 AM, Tom Weinstein <[email-masked]> said:

>While I support the ideal of building standards that use strong crypto,
>it does nobody any good to create a standard which won't get implemented. 
>The export ciphers exist because in order for US software manufacturers
>to use TLS, they have to be able to export the software that includes it. 
>It is certainly true that there are many software developers who live in
>the free world, but those of us stuck in the US still need to sell
>software.

But who in their right minds are going to buy it??

I for one would *never* recomend to my overseas clients to use crippled US
export crypto products. There are just too many people writting
non-crippled software to justify it.

At the very least one would think that the US vendors would put thier
crypto code in one DLL and document the API so someone overseas could
replace it with somthing worth using. <sigh> I guess even that is too much
to ask.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Tue, 30 Dec 1997 00:11:17 +0000
From: Jeff Williams <[email-masked]>
Organization: IEG. INC.
To: [email-masked]
CC: [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

Tom and all,

Tom Weinstein wrote:
> 
> EKR wrote:
> >
> > I see several problems here:
> > 1. While overloading the cipherSuites mechanism is convenient and
> > backwards compatible, it strikes me as ill-advised. In the limit,
> > we end up with a large number of cipherSuites that differ only
> > in the types of certificational material they provide. This
> > fragments effort. Here you call out an RSA/3DES/RIPEMD mode.
> > If that's a good idea, wouldn't it be a good idea with X.509
> > certificates as well?
> >
> > Algorithm choice is largely orthogonal to certificate format and
> > should be represented as such. That does seem to be a missing
> > capability in TLS. We should add it rather than hacking around
> > it.
> 
> Agreed.  Rather than overloading cipherSuites with information about cert
> formats, I think it would be better to extend TLS to provide for cert
> format negotiation.

  I totaly agree.  Hence on of the reasons we went ahead and developed
our
"Interface Facility (MLPI)" which incorporates this capability for any
set of ciphersuites for most cert formats.  I came to this conclusion
over a year ago.
> 
> --
> What is appropriate for the master is not appropriate| Tom Weinstein
> for the novice.  You must understand Tao before      | [email-masked]
> transcending structure.  -- The Tao of Programming   |

Regards,
-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. IEG. INC. (Soon to be INEG. INC) Stay tunned! 
Phone :913-294-2375 (v-office)
E-Mail [email-masked]

Wisdom:   "One who knows others is wise,
           one who knows himself is enlightened."
           Lao Tzu

Date: Mon, 29 Dec 1997 22:03:47 -0800
From: Tom Weinstein <[email-masked]>
Organization: Netscape Communications, Inc.
To: [email-masked]
CC: [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

Will Price wrote:
> 
> The alternative seems to be to include another subpacket in the Hello
> packets negotiating certificate type just like compression is negotiated.
> This would also be allowed by the spec as per 7.4.1.2.  If it was to be
> done that way, I felt that this negotiation should have been included in
> the TLS spec.  Since I assume the time for that has passed, I opted for
> the ciphersuite overload.

I don't think it can go into TLS 1.0, but it's definitely something we
should work towards for a TLS 1.1 or 2.0.

>> Here you call out an RSA/3DES/RIPEMD mode.  If that's a good idea,
>> wouldn't it be a good idea with X.509 certificates as well?
> 
> Yes, it would.  Unfortunately once again, I assume the time to add such
> things has passed.  I felt it was important to have more than one hash
> algorithm associated with the OpenPGP certificates, but didn't want to
> use a potentially weak algorithm like MD5 (except where the TLS protocol
> requires MD5).  Were the TLS spec to ignore compatibility, I'm sure MD5
> would be eliminated, so I didn't want to add it to any new ciphersuites.
> RIPEMD-160 seemed an ideal replacement that was already part of OpenPGP.

HMAC-MD5 still appears to be strong.  While it would be nice to eliminate
MD5 from TLS at some point, there don't seem to be a lot of good
alternatives.  In my opinion, RIPEMD-160 hasn't seen enough analysis to
feel comfortable about it.  I'd prefer to give it another few years, at
least.

>> 3. Omitting the DistinguishedName field in the CertificateRequest
>> field seems problematic. I understand PGP doesn't use DNs,
>> but there should be a way to indicate who might be potential signers
>> of a given key.
> 
> OpenPGP keys generally have all the certs they need attached to them
> whereas X509 certs are only a single cert unto themselves thus requiring
> a chain if the specified cert is not directly certified by a root CA. 
> With OpenPGP, if a particular signer key is not found, the client or
> server can use a certserver to look it up.

Although TLS uses the X.509 cert formats, it doesn't require an X.500
directory to operate.  I don't think it's a good idea to require an OpenPGP
cert server, either.

>> 4. In addition, I don't see what the point of prohibiting
>> "Export" ciphers with PGP keys is. Obviously, if you're explicitly
>> calling out cipherSuites, you can simply omit all the export cipher
>> suites from that list, but frankly, stating that  "Export" algorithms
>> also may not be used with OpenPGP keys" seems silly. It's not our
>> place as protocol designers to tell people what they may use.
> 
> The export sections of TLS seem to me to be a holdover from the SSL
> legacy days and are there mostly for compatability.  OpenPGP pays no
> attention to this issue as it isn't appropriate to have such limits in an
> international standard.  Clearly, an implementation could choose to
> implement their own ciphersuites for export algorithms with OpenPGP keys,
> but there doesn't seem to be any reason to specify those as none of the
> export quality algorithms are supported by OpenPGP.  Simply removing the
> statement does seem appropriate however making them implicitly excluded
> rather than explicitly.

While I support the ideal of building standards that use strong crypto, it
does nobody any good to create a standard which won't get implemented.  The
export ciphers exist because in order for US software manufacturers to use
TLS, they have to be able to export the software that includes it.  It is
certainly true that there are many software developers who live in the
free world, but those of us stuck in the US still need to sell software.

-- 
What is appropriate for the master is not appropriate| Tom Weinstein
for the novice.  You must understand Tao before      | [email-masked]
transcending structure.  -- The Tao of Programming   |

Date: Mon, 29 Dec 1997 21:43:21 -0800
From: Tom Weinstein <[email-masked]>
Organization: Netscape Communications, Inc.
To: [email-masked]
CC: [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

EKR wrote:
> 
> I see several problems here:
> 1. While overloading the cipherSuites mechanism is convenient and
> backwards compatible, it strikes me as ill-advised. In the limit,
> we end up with a large number of cipherSuites that differ only
> in the types of certificational material they provide. This
> fragments effort. Here you call out an RSA/3DES/RIPEMD mode.
> If that's a good idea, wouldn't it be a good idea with X.509
> certificates as well?
> 
> Algorithm choice is largely orthogonal to certificate format and
> should be represented as such. That does seem to be a missing
> capability in TLS. We should add it rather than hacking around
> it.

Agreed.  Rather than overloading cipherSuites with information about cert
formats, I think it would be better to extend TLS to provide for cert
format negotiation.

-- 
What is appropriate for the master is not appropriate| Tom Weinstein
for the novice.  You must understand Tao before      | [email-masked]
transcending structure.  -- The Tao of Programming   |

To: <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
From: EKR <[email-masked]>
Date: 28 Dec 1997 22:11:51 -0800
Lines: 160
Sender: [email-masked]

Will Price <[email-masked]> writes:

> At 11:36 AM -0800 12/28/97, Eric Rescorla wrote:
> >1. While overloading the cipherSuites mechanism is convenient and
> >backwards compatible, it strikes me as ill-advised. In the limit,
> >we end up with a large number of cipherSuites that differ only
> >in the types of certificational material they provide. This
> >fragments effort.
> 
> I agree, certificate type negotiation is an unfortunate missing piece from
> TLS.  However, according to Section 7.4.2 of the TLS spec and previous
> discussion on the TLS list, overloading ciphersuites appears to be the
> recommended way to introduce a new certificate type.
Hmm.. What it says is:

   All certificate profiles, key and cryptographic formats are defined
   by the IETF PKIX working group [PKIX]. When a key usage extension is
   present, the digitalSignature bit must be set for the key to be
   eligible for signing, as described above, and the keyEncipherment
   bit must be present to allow encryption, as described above. The
   keyAgreement bit must be set on Diffie-Hellman certificates.

   As CipherSuites which specify new key exchange methods are specified
   for the TLS Protocol, they will imply certificate format and the
   required encoded keying information.

So, reading this literally, since OpenPGP isn't a PKIX work item,
what you suggest is impermissible. (I don't really suggest reading
this literally. I'm merely trying to make the point that TLS doesn't
appear to have any provision whatsoever for new certificate
formats, except what is required for new algorithms.)

> Fortunately, the
> ciphersuite field is 16 bits, so it doesn't seem that any valuable space is
> being wasted.
Space isn't the issue, really. It's protocol maintainance and
reuse that's at issue. Nevertheless, I'd be wary of assuming that
we have an infinitude of cipherSuite space. We only do if we
don't waste it.

> The alternative seems to be to include another subpacket in the Hello
> packets negotiating certificate type just like compression is negotiated.
> This would also be allowed by the spec as per 7.4.1.2.  If it was to be
> done that way, I felt that this negotiation should have been included in
> the TLS spec.  Since I assume the time for that has passed, I opted for the
> ciphersuite overload.
I'd suggest this as a TLS 2.0 wor k item, myself.

> >Here you call out an RSA/3DES/RIPEMD mode.  If that's a good idea,
> >wouldn't it be
> >a good idea with X.509 certificates as well?
> 
> Yes, it would.  Unfortunately once again, I assume the time to add such
> things has passed.  I felt it was important to have more than one hash
> algorithm associated with the OpenPGP certificates, but didn't want to use
> a potentially weak algorithm like MD5 (except where the TLS protocol
> requires MD5).  Were the TLS spec to ignore compatibility, I'm sure MD5
> would be eliminated, so I didn't want to add it to any new ciphersuites.
> RIPEMD-160 seemed an ideal replacement that was already part of OpenPGP.
HMAC-MD5 is not known to be weak. And remarkably little is known
about RIPEMD-160. I'm not really that confident it's better than
MD5.

> >2. The Certificate payload design doesn't seem to allow for
> >a chain of certificates to be carried. This seems like a bug.
> >
> >3. Omitting the DistinguishedName field in the CertificateRequest
> >field seems problematic. I understand PGP doesn't use DNs,
> >but there should be a way to indicate who might be potential signers
> >of a given key.
> 
> These are both issues of certification of the received key.  The OpenPGP
> trust model works differently than the win or lose X.509 model where it is
> essentially assumed that all clients have all root CA certificates and
> those certificates are implicitly trusted.  In the OpenPGP model, there is
> generally no chain and if there is it could be multiple chains.  In
> practice, I suspect most implementations will in fact possess OpenPGP CA
> keys and it will work much the same way.  In this model however, a
> certificate chain isn't used.  OpenPGP keys generally have all the certs
> they need attached to them whereas X509 certs are only a single cert unto
> themselves thus requiring a chain if the specified cert is not directly
> certified by a root CA.  With OpenPGP, if a particular signer key is not
> found, the client or server can use a certserver to look it up.  One
> motivation in the document is also to reduce the overhead of the key
> exchange.  A key need not even be sent by sending the key ID instead.  On
> the first connection, this may incur some overhead if the the key is not
> found because the certserver may need to be accessed.  On future
> connections (even when the sessions are not cached), this will be a
> substantial benefit.
> 
> This method also introduces to TLS some of the flexibility afforded by SSH
> where first connections could be assumed valid and future connections must
> use the same keys.  Again, this is an implementation dependent issue.
Let's take these two separately:
2. I'm pretty familiar with the OpenPGP certification model. What
I'm not that famaliar with is the OpenPGP certificate format. 
The purpose of the exercise here is for the public keyholder
to provice enough certificates to enable the public key user to 
verify his certificate. If PGP keys can have enough certificates
attached to them to provide this, then we don't have a problem.
A quick glance at the OpenPGP spec didn't make this clear, however.
In any case, this isn't an implementation issue if we don't provide
the facilities to make it possible. 

As for cert servers, TLS with X.509 works perfectly well without
The Directory. (good thing too, since The Directory doesn't exist).
TLS with OpenPGP certificates should work equally well.

3. You haven't addressed the DN in certificate request issue. I
don't see that the OpenPGP cert structure has much relevance
here. Am I missing something.

> >4. In addition, I don't see what the point of prohibiting
> >"Export" ciphers with PGP keys is. Obviously, if you're explicitly
> >calling out cipherSuites, you can simply omit all the export cipher
> >suites from that list, but frankly, stating that  "Export" algorithms
> >also may not be used with OpenPGP keys" seems silly. It's not our
> >place as protocol designers to tell people what they may use.
> 
> The export sections of TLS seem to me to be a holdover from the SSL legacy
> days and are there mostly for compatability.
I completely disagree. The fact of the matter is that people who
ship TLS products often have to export them. In order to do so,
they need to use exportable ciphers. That's why SSL had them and
it's why TLS has them.

>  OpenPGP pays no attention to
> this issue as it isn't appropriate to have such limits in an international
> standard. 
They aren't limits. They're options. 

> Clearly, an implementation could choose to implement their own
> ciphersuites for export algorithms with OpenPGP keys, but there doesn't
> seem to be any reason to specify those as none of the export quality
> algorithms are supported by OpenPGP.
You're failing to distinguish here between OpenPGP the messaging
format and OpenPGP the certification system. What you're trying to
do here is use OpenPGP certification with TLS protocol. What
crypto algorithms OpenPGP messaging supports really doesn't have
any relevance to this.

>  Simply removing the statement does
> seem appropriate however making them implicitly excluded rather than
> explicitly.
Right. The correct behavior is to specify them.

> >5. Also, you've failed to call out support for the integrity only
> >cipherSuites. Is this intentional?
> 
> Not intentional.  That is an oversight.
I'd observe that this is the precise problem with having the certification
structure bound up in the cipherSuite. Keeping X.509 cipherSuites matched
with OpenPGP cipherSuites is going to be quite difficult.

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Sun, 28 Dec 1997 15:20:14 -0800
To: <[email-masked]>
From: Will Price <[email-masked]>
Subject: Re: Proposed Extensions to TLS for OpenPGP
Cc: [email-masked]
Sender: [email-masked]

At 11:36 AM -0800 12/28/97, Eric Rescorla wrote:
>1. While overloading the cipherSuites mechanism is convenient and
>backwards compatible, it strikes me as ill-advised. In the limit,
>we end up with a large number of cipherSuites that differ only
>in the types of certificational material they provide. This
>fragments effort.

I agree, certificate type negotiation is an unfortunate missing piece from
TLS.  However, according to Section 7.4.2 of the TLS spec and previous
discussion on the TLS list, overloading ciphersuites appears to be the
recommended way to introduce a new certificate type.  Fortunately, the
ciphersuite field is 16 bits, so it doesn't seem that any valuable space is
being wasted.

The alternative seems to be to include another subpacket in the Hello
packets negotiating certificate type just like compression is negotiated.
This would also be allowed by the spec as per 7.4.1.2.  If it was to be
done that way, I felt that this negotiation should have been included in
the TLS spec.  Since I assume the time for that has passed, I opted for the
ciphersuite overload.

>Here you call out an RSA/3DES/RIPEMD mode.  If that's a good idea,
>wouldn't it be
>a good idea with X.509 certificates as well?

Yes, it would.  Unfortunately once again, I assume the time to add such
things has passed.  I felt it was important to have more than one hash
algorithm associated with the OpenPGP certificates, but didn't want to use
a potentially weak algorithm like MD5 (except where the TLS protocol
requires MD5).  Were the TLS spec to ignore compatibility, I'm sure MD5
would be eliminated, so I didn't want to add it to any new ciphersuites.
RIPEMD-160 seemed an ideal replacement that was already part of OpenPGP.

>Algorithm choice is largely orthogonal to certificate format and
>should be represented as such. That does seem to be a missing
>capability in TLS. We should add it rather than hacking around
>it.

Bravo.

>2. The Certificate payload design doesn't seem to allow for
>a chain of certificates to be carried. This seems like a bug.
>
>3. Omitting the DistinguishedName field in the CertificateRequest
>field seems problematic. I understand PGP doesn't use DNs,
>but there should be a way to indicate who might be potential signers
>of a given key.

These are both issues of certification of the received key.  The OpenPGP
trust model works differently than the win or lose X.509 model where it is
essentially assumed that all clients have all root CA certificates and
those certificates are implicitly trusted.  In the OpenPGP model, there is
generally no chain and if there is it could be multiple chains.  In
practice, I suspect most implementations will in fact possess OpenPGP CA
keys and it will work much the same way.  In this model however, a
certificate chain isn't used.  OpenPGP keys generally have all the certs
they need attached to them whereas X509 certs are only a single cert unto
themselves thus requiring a chain if the specified cert is not directly
certified by a root CA.  With OpenPGP, if a particular signer key is not
found, the client or server can use a certserver to look it up.  One
motivation in the document is also to reduce the overhead of the key
exchange.  A key need not even be sent by sending the key ID instead.  On
the first connection, this may incur some overhead if the the key is not
found because the certserver may need to be accessed.  On future
connections (even when the sessions are not cached), this will be a
substantial benefit.

This method also introduces to TLS some of the flexibility afforded by SSH
where first connections could be assumed valid and future connections must
use the same keys.  Again, this is an implementation dependent issue.

>4. In addition, I don't see what the point of prohibiting
>"Export" ciphers with PGP keys is. Obviously, if you're explicitly
>calling out cipherSuites, you can simply omit all the export cipher
>suites from that list, but frankly, stating that  "Export" algorithms
>also may not be used with OpenPGP keys" seems silly. It's not our
>place as protocol designers to tell people what they may use.

The export sections of TLS seem to me to be a holdover from the SSL legacy
days and are there mostly for compatability.  OpenPGP pays no attention to
this issue as it isn't appropriate to have such limits in an international
standard.  Clearly, an implementation could choose to implement their own
ciphersuites for export algorithms with OpenPGP keys, but there doesn't
seem to be any reason to specify those as none of the export quality
algorithms are supported by OpenPGP.  Simply removing the statement does
seem appropriate however making them implicitly excluded rather than
explicitly.

>5. Also, you've failed to call out support for the integrity only
>cipherSuites. Is this intentional?

Not intentional.  That is an oversight.

Thanks.
-Will

Will Price, Architect
Network Associates, Inc.
Direct  (650)596-1956
Main    (650)572-0430
Fax     (650)631-1033
Cell/VM (650)533-0399
<pgpfone://clotho.pgp.com>

PGPkey: <http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0xCF73EC4C>

To: <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposed Extensions to TLS for OpenPGP
From: EKR <[email-masked]>
Date: 28 Dec 1997 11:36:26 -0800
Lines: 38
Sender: [email-masked]

I see several problems here:
1. While overloading the cipherSuites mechanism is convenient and
backwards compatible, it strikes me as ill-advised. In the limit,
we end up with a large number of cipherSuites that differ only
in the types of certificational material they provide. This
fragments effort. Here you call out an RSA/3DES/RIPEMD mode.
If that's a good idea, wouldn't it be a good idea with X.509
certificates as well?

Algorithm choice is largely orthogonal to certificate format and
should be represented as such. That does seem to be a missing
capability in TLS. We should add it rather than hacking around
it.

2. The Certificate payload design doesn't seem to allow for 
a chain of certificates to be carried. This seems like a bug.

3. Omitting the DistinguishedName field in the CertificateRequest
field seems problematic. I understand PGP doesn't use DNs,
but there should be a way to indicate who might be potential signers
of a given key.

4. In addition, I don't see what the point of prohibiting 
"Export" ciphers with PGP keys is. Obviously, if you're explicitly
calling out cipherSuites, you can simply omit all the export cipher
suites from that list, but frankly, stating that  "Export" algorithms
also may not be used with OpenPGP keys" seems silly. It's not our
place as protocol designers to tell people what they may use.

5. Also, you've failed to call out support for the integrity only
cipherSuites. Is this intentional? 

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Sun, 28 Dec 1997 03:00:26 -0800
To: [email-masked], [email-masked]
From: Will Price <[email-masked]>
Subject: Proposed Extensions to TLS for OpenPGP
Sender: [email-masked]

This is an early draft of a document I'm working on.  Since it applies to
both ietf-openpgp and ietf-tls, I'm sending it to both.  My intent is to
make this a separate document not integrated into either of the main
documents from the two groups.  Comments welcome.

--------------------

Draft Proposed Extensions to TLS for OpenPGP keys

Will Price
Network Associates, Inc.
December 28, 1997

Abstract

This document builds upon the TLS Protocol Specification, currently an IETF
Internet Draft.  The extensions described herein are intended to apply to
the latest draft of the IETF TLS 1.0 protocol dated November 12, 1997.

The purpose of this document is to update the TLS protocol with extensions
to support the certificates, public key algorithms, symmetric ciphers, hash
algorithms, and trust model used by OpenPGP.

This document uses the same notation used in the TLS Protocol draft.

Certificate

The X.509.v3 [X509] certificates recommended for use with TLS will not be
used in conjunction with OpenPGP keys.  An implementation should be able to
support both TLS with X509 and TLS with OpenPGP keys.  It is not required
that an implementation support both.  The "peer certificate" in the session
state of TLS can refer to either X509 or OpenPGP.

The contents of the Certificate (11) message sent from server to client and
vice versa are determined by the Cipher Suite.  Many new Cipher Suites are
defined in the Cipher Suites section of this document for use with OpenPGP
keys.  All OpenPGP Cipher Suites require a OpenPGP key in the Certificate
messages.  A OpenPGP key appearing in the Certificate message will be sent
in binary OpenPGP format.  The Certificate message includes a OpenPGP key
where the X509 certificate would normally appear.  The option is also
available to send a 64 bit OpenPGP Key ID instead of sending the entire
key.  The client will respond with a fatal alert no_certificate if the Key
ID cannot be found.  If the key is not valid, expired, revoked, or corrupt,
the appropriate fatal alert message is sent from section A.3 of the TLS
specification.  If a key is valid and neither expired nor revoked, it is
accepted by the protocol.  A particular OpenPGP compatible TLS
implementation may wish to allow users to designate certain keys
specifically as Trusted Server Keys.  This is a local matter outside the
scope of this document.

enum {
	keyid (0), key (1), (255)
} PGPKeyDescriptorType;

opaque PGPKeyID<8>
opaque PGPKey<1..2^24-1>
struct {
	PGPKeyDescriptorType descriptorType;
	select (descriptorType) {
		case keyid: PGPKeyID;
		case key: PGPKey;
	}
} Certificate;

Certificate Request

The server is allowed to request a client certificate from the client.  The
meaning of this message is essentially unchanged to allow OpenPGP keys.

The rsa_sign and dss_sign certificate types may be requested in conjunction
with OpenPGP keys.  The ClientCertificateType field is used identically to
the TLS specification.  The subsequent DistinguishedName field is not
included when using Cipher Suites based on OpenPGP keys.

The Client Certificate message is sent using the same formatting as the
server Certificate message in response to the Certificate Request message.
If no OpenPGP key is available from the client, the no_certificate alert is
returned.  The server may then respond with a fatal alert if appropriate.
This transaction follows the TLS specification.

Server Key Exchange

When using ephemeral Diffie-Hellman, the Server Key Exchange message is
sent to pass the Diffie-Hellman public value to the client.  The client and
server then use this value to establish the shared secret.  This is
identical to the operation of standard TLS.

Certificate Verify

The Certificate Verify message for OpenPGP key types is identical to the
specification.  The signature is made using either DSS or RSA depending on
the Cipher Suite.

Finished

The Finished message for OpenPGP key types is identical to the description
in the specification.

Cipher Suites

Since TLS does not have a certificate type field, the Cipher Suites field
is used to perform the same function.  A number of additional Cipher Suites
are defined for use with OpenPGP keys.

CipherSuite TLS_PGP_DHE_DSS_WITH_CAST_CBC_SHA		= { 0x01, 0x01 };
CipherSuite TLS_PGP_DHE_DSS_WITH_IDEA_CBC_SHA		= { 0x01, 0x02 };
CipherSuite TLS_PGP_DHE_DSS_WITH_3DES_EDE_CBC_SHA	= { 0x01, 0x03 };
CipherSuite TLS_PGP_DHE_DSS_WITH_CAST_CBC_RMD		= { 0x01, 0x04 };
CipherSuite TLS_PGP_DHE_DSS_WITH_IDEA_CBC_RMD		= { 0x01, 0x05 };
CipherSuite TLS_PGP_DHE_DSS_WITH_3DES_EDE_CBC_RMD	= { 0x01, 0x06 };
CipherSuite TLS_PGP_RSA_WITH_CAST_CBC_SHA		= { 0x01, 0x20 };
CipherSuite TLS_PGP_RSA_WITH_IDEA_CBC_SHA		= { 0x01, 0x21 };
CipherSuite TLS_PGP_RSA_WITH_3DES_EDE_CBC_SHA		= { 0x01, 0x22 };
CipherSuite TLS_PGP_RSA_WITH_CAST_CBC_RMD		= { 0x01, 0x23 };
CipherSuite TLS_PGP_RSA_WITH_IDEA_CBC_RMD		= { 0x01, 0x24 };
CipherSuite TLS_PGP_RSA_WITH_3DES_EDE_CBC_RMD		= { 0x01, 0x25 };

Note:	The above numeric definitions for Cipher Suites have not yet been
registered.

All of the above Cipher Suites use either the CAST, IDEA, or TripleDES
block ciphers in CBC mode.  The choice of hash is either SHA-1 or
RIPEMD-160.  Use of any of these Cipher Suites requires an OpenPGP key in
any Certificate and Client Certificate messages.  MD5 may not be used with
OpenPGP keys.  "Export" algorithms also may not be used with OpenPGP keys.

To be considered complaint with support for OpenPGP in TLS, an
implementation must support TLS_PGP_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

Will Price, Architect
Network Associates, Inc.
Direct  (650)596-1956
Main    (650)572-0430
Fax     (650)631-1033
Cell/VM (650)533-0399
<pgpfone://clotho.pgp.com>

PGPkey: <http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0xCF73EC4C>

Date: Sat, 20 Dec 1997 09:40:34 -0500
To: [email-masked], [email-masked]
From: Robert Guerra <[email-masked]>
Subject: G10: The Free PGP Replacement
Cc: Macintosh Cryptography Mailing List  <[email-masked]>, [email-masked]
Sender: [email-masked]

Content-Transfer-Encoding: quoted-printable

I haven't seen this announced here before, and thought it might interest peo=
ple

(if someone ports it to the Macintosh, please let me know :)     )

http://www.d.shuttle.de/isil/g10.html
G10

The Free PGP Replacement
                                        Overview

I recently started a project to replace PGP by a free utility. PGP is not
free software in the sense of freedom as
defined by the GPL; so I decided to write a replacement.

                                          Goals

       GPLed
       Full replacement of PGP
       Does not use any patented algorithms.
       Using ElGamal, Blowfish and RIPE-MD-160 as algorithms.
       Hooks to add a RSA module, so that non U.S. users are able to reuse
there signed keys. RSA will be
       completely back on Sep 20th, 2000.
       Better functionality, including some security enhancements.
       Can be used as a filter.
       Support for Unix, GNU, OS/2, MSDOS, Windoze, NT.
       Uses the PGP packet format as described in RFC1991 with some
enhancements.
       New algorithms are easy to implement.

                                       More infos

The primary FTP site for G10 is ftp.guug.de. But note, that there is no
code available yet; I will put up a first
ALPHA version before christmas.

You can subscribe to the mailing list [email-masked] by sending a mail
with the word "subscribe" in the body
to [email-masked]. An archive of the list is also available here.

A related project is psst..., a free ssh/sshd replacement.

                                          Status

Done:

       create signatures and detached signatures.
       checking signatures (data and keys).
       encrypt and decrypt (public key and conventional).
       List and check keyrings
       Print fingerprints
       Self signatures are added to generated keys.
       RSA and ElGamal Key generation.
       Ripe-MD-160 used for hashing.
       Works inside a pipe w/o any temporary files.
       autoconf/configure works.
       using armor files works.
       compressing stuff implemented.
       Some enhancements to make it somewhat compatible with the OpenPGP
draft.
       Added SHA-1.
       Added configuration stuff (options file)

Not yet done:

       Trust packets.
       Keyring management (partly done)
       Old style signatures
       Documentation.
       DSA, subkeys etc.
       and, and, and ....

Updated: 18.12.97

	Merry christmas, and Happy New Year.
	Joyeux No=EBl et Bonne Anne.
	Feliz navidad y prospero a=F1o nuevo.

Robert Guerra - PGP public key available on PGP key servers
Email-> mailto:[email-masked]
Home Page-> http://www.geocities.com/CapitolHill/3378

From: "Rich Ankney" <[email-masked]>
To: "Myron Lewis" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Dan Lewis Randall" <[email-masked]>
Subject: Re: Improving resistance against attacks
Date: Thu, 18 Dec 1997 13:13:22 -0500
Sender: [email-masked]

> Nice thinking, Patrick, but why go to all that trouble when there is a
key
> generator that continually generates unpredictable keys of any size as
often
> as you want  and synchronizes them across a link without transmitting any
> info about them.  It's called the ASK ToolKit(tm).  See www.keygen.com
>

Well, perhaps we're going to all this trouble because (a) ASK doesn't do
digital
signatures, (b) it doesn't accommodate an Email environment where there is
no
connection between sender and recipient, and (c) it requires maintaining
pairwise
keys and state between each sender/recipient pair, rather than just
exchanging
public keys.  (The above comments based on checking out your web page a few
weeks ago.)

Regards,
Rich

From: "Myron Lewis" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Dan Lewis Randall" <[email-masked]>
Subject: Re: Improving resistance against attacks
Date: Thu, 18 Dec 1997 11:06:42 -0500
Sender: [email-masked]

Nice thinking, Patrick, but why go to all that trouble when there is a key
generator that continually generates unpredictable keys of any size as often
as you want  and synchronizes them across a link without transmitting any
info about them.  It's called the ASK ToolKit(tm).  See www.keygen.com

Regards,

Myron Lewis,
President,
KeyGen Corporation.
781-860-0108
-----Original Message-----
From: Robert Hettinga <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, December 17, 1997 9:14 AM
Subject: Improving resistance against attacks

>---------------------------------------------------------------------
>This mail is brought to you by the e$pam mailing list
>---------------------------------------------------------------------
>
>From: Patrick Feisthammel <[email-masked]>
>Reply-To: Patrick Feisthammel <[email-masked]>
>To: [email-masked]
>cc: Patrick Feisthammel <[email-masked]>
>Subject: Improving resistance against attacks
>MIME-Version: 1.0
>Sender: [email-masked]
>Precedence: bulk
>
>-----BEGIN PGP SIGNED MESSAGE-----
>
> Hi!
>
> After the thread about weak RSA keys in sci.crypt, I tought about
> improving the security against attacks on the public keys.
>
> My propoal in short: Use multiple keys at the same time.
>
>
> Why using multiple keys at the same time
> ========================================
> If a key is generated, there is a probability p, that there is a 'fast'
> algorithm to factorize this key. For two keys, the probability, that
> both are 'easy' to break is p^2. And therefore much smaler.
>
>
> How it works
> ============
> To encrypt some data d with two keys K1 and K2:
>   1. Create a one time pad o (random data) of the same length as d.
>   2. Encrypt the data d with o: c1= E(d, o)
>   3. Encrypt the result from step 2 with the key K1: c2= E(c1, K1)
>   4. Encrypt the one time pad with key K2: c3= E(o, K2)
>   5. The encrypted data is the concatenation of c2 and c3.
>
> To decrypt:
>   1. Decrypt c3 with K2: o= D(c3, K2)
>   2. Decrypt c2 with K1: c1= D(c2, K1)
>   3. Decrypt the data: d= D(c1, o)
>
> If key K1 is broken, only c2 can be decrypted. Because without the one
> time pad o, the knowledge about the data is still zerol
> If key K2 is broken, the one time pad is known, but this also does not
> give any information about the data d.
>
> Some thougths have to be done for multiple recipients, that two broken
> keys of different recipients don't reveal the cleartext.
>
>
> Communication with PGP 2.6.x and PGP 5.x
> ========================================
> The usage of two keys can easaly be added to the today version with
> one key:
>   - Add the information about the key id of the second key in the
>     public key, as non critical information.
>   - pgp-2keys checks if the receipient has a one-key public key. If he
>     has, the old encryption/signing is used. If not, the new system is
>     used.
> Users of pgp-1key will always encrypt/sign with only one key, which is the
> today used scheme. pgp-2key users can communicate with the schema
> proposed in this mail.
> This way it is fully compatible with todys versions. (Or at least as
> compatible as today versions)
>
>
> 2 keys or m keys
> ================
> Of course, this system can easaly be extended to the more general case
> of m keys. The keys could even be from other key algorithms.
>
>
> What do you think? Would this be a suitable way to reduce the risk
> given by the usage of one signle key?
> Could this be an idea for later versions of OpenPGP?
>
>
> Cheers, Patrick
>
>
>
>
>
>
> - --
>  PGP-KeyID: DD934139 ([email-masked])    encrypt mail with PGP if possible
>  more about PGP on http://www.rubin.ch/pgp/ (in german only at the moment)
>
>
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
>
> iQESAwUBNJeAe5VgYabdk0E5AQFLvgfkCKj+9dmpQMAYBxyKRKUnNpMIVvbIqOIB
> Cn/ja5vUy+Z9NPX8dBKkiqlTS2vbJV88awtnjGE761M0983kLiX8gzdzMUQoC8bM
> CJobaGHK9J1UjOzzJdCtxGbBYkqjVAU8UQec8d1d787u1MRcpjZg/AwOvcGLFLYs
> wXhWA89/wur9487Jc/wxx2gtf+rphgdQcLrSTxmx25LISwJG4jLPvINbWbk+YC7W
> jqB2vwHx0ZmEyyPOHsMpIqQ+Y9s1B2Mm9ckft9jcRbmG/w0MJezr58A8SWnbJHxl
> A3yAXCYivlwinfk6LyNBulh5YiV7N/rVPtj+mwRNgp5FsgPrZg==
> =8pFP
> -----END PGP SIGNATURE-----
>
>
>----------------------------------------------------------------------
>Where people, networks and money come together:        Consult Hyperion
>http://www.hyperion.co.uk/                          [email-masked]
>----------------------------------------------------------------------
>Full-Strength Cryptographic Solutions for Worldwide Electronic Commerce
>http://www.c2.net/                                    [email-masked]
>----------------------------------------------------------------------
>Like e$? Help pay for it!
>For e$/e$pam contributions or sponsorship:  <mailto:[email-masked]>
>----------------------------------------------------------------------

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Where is the symmetric algorithm defined?
Date: 18 Dec 1997 07:52:29 GMT
Organization: IKS GmbH Jena
Lines: 5
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Hal Finney wrote:
>Do you mean, in a public key encrypted message, where is it specified what
>conventional (symmetric) algorithm is used to encrypt the message itself?

Thnx I really stupid.

Date: Wed, 17 Dec 1997 11:21:42 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Where is the symmetric algorithm defined?
Sender: [email-masked]

Lutz Donnerhacke, [email-masked], writes:
>   Where is the symmetric algorithm of an encrypted messages defined in the
>   OpenPGP message format?

Do you mean, in a public key encrypted message, where is it specified what
conventional (symmetric) algorithm is used to encrypt the message itself?

This is in section 5.1:

> The encrypted value "m" in the above formulas is derived from the
> session key as follows.  First the session key is prepended with a
> one-octet algorithm identifier that specifies the conventional
> encryption algorithm used to encrypt the following Symmetrically
> Encrypted Data Packet.

This one-octet algorithm identifier is what tells the symmetric algorithm
that is used to encrypt the body of the message.  It is only visible once
the ESK packet has been decrypted.  Third parties can't tell what algorithm
was used to encrypt the message.

Hal

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Where is the symmetric algorithm defined?
Date: 17 Dec 1997 16:14:33 GMT
Organization: IKS GmbH Jena
Lines: 3
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

I'm stupid...
  Where is the symmetric algorithm of an encrypted messages defined in the
  OpenPGP message format?

Date: Wed, 17 Dec 1997 08:34:15 +0100 (CET)
From: Patrick Feisthammel <[email-masked]>
Reply-To: Patrick Feisthammel <[email-masked]>
To: [email-masked]
cc: Patrick Feisthammel <[email-masked]>
Subject: Improving resistance against attacks
Sender: [email-masked]

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

Hi!

After the thread about weak RSA keys in sci.crypt, I tought about
improving the security against attacks on the public keys.

My propoal in short: Use multiple keys at the same time.

Why using multiple keys at the same time
========================================
If a key is generated, there is a probability p, that there is a 'fast'
algorithm to factorize this key. For two keys, the probability, that
both are 'easy' to break is p^2. And therefore much smaler.

How it works
============
To encrypt some data d with two keys K1 and K2:
  1. Create a one time pad o (random data) of the same length as d.
  2. Encrypt the data d with o: c1= E(d, o)
  3. Encrypt the result from step 2 with the key K1: c2= E(c1, K1)
  4. Encrypt the one time pad with key K2: c3= E(o, K2)
  5. The encrypted data is the concatenation of c2 and c3.

To decrypt:
  1. Decrypt c3 with K2: o= D(c3, K2)
  2. Decrypt c2 with K1: c1= D(c2, K1)
  3. Decrypt the data: d= D(c1, o)

If key K1 is broken, only c2 can be decrypted. Because without the one
time pad o, the knowledge about the data is still zerol
If key K2 is broken, the one time pad is known, but this also does not
give any information about the data d.

Some thougths have to be done for multiple recipients, that two broken
keys of different recipients don't reveal the cleartext.

Communication with PGP 2.6.x and PGP 5.x
========================================
The usage of two keys can easaly be added to the today version with
one key:
  - Add the information about the key id of the second key in the
    public key, as non critical information. 
  - pgp-2keys checks if the receipient has a one-key public key. If he
    has, the old encryption/signing is used. If not, the new system is
    used.
Users of pgp-1key will always encrypt/sign with only one key, which is the
today used scheme. pgp-2key users can communicate with the schema
proposed in this mail.
This way it is fully compatible with todys versions. (Or at least as
compatible as today versions)

2 keys or m keys
================
Of course, this system can easaly be extended to the more general case
of m keys. The keys could even be from other key algorithms.

What do you think? Would this be a suitable way to reduce the risk
given by the usage of one signle key?
Could this be an idea for later versions of OpenPGP?

Cheers, Patrick

 
- --
 PGP-KeyID: DD934139 ([email-masked])    encrypt mail with PGP if possible
 more about PGP on http://www.rubin.ch/pgp/ (in german only at the moment)

Date: Sun, 14 Dec 1997 15:26:58 -0800
To: [email-masked], [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: Possible attack on remailer keys?
Sender: [email-masked]

At 02:07 PM 12/09/1997 MDT, Anonymous Remailer wrote,
to the remailer-operators list:
>I just discovered a disturbing fact. I'm not sure how it works with other
>remailers, but Juno remailers (and I think Winsock too) shell to PGP,
>supplying the key passphrase to decrypt messages. This in itself is fine
>(ugly, but it works), but it happens to be that a person can guess the
>key passphrase by sending the remailer a CONVENTIONALLY encrypted message
>(with the probable passphrase). 
>
>PGP doesn't seem to care if the key phrase applies to a secret key, or to
>the message password if conventionally encrypted. The message will pass
>as normal, thus proving the passphrase is correct.

While this is using PGP 2.6.x, it's still a problem for future versions
(though perhaps this belongs in pgp-bugs rather than ietf-open-pgp.)
The obvious workaround is to use a good passphrase (:-),
but there really is a need to tell PGP what key a given passphrase is for.

The PGPPASS was always a somewhat risky feature (passing sensitive
information to a program you don't control is inherently risky,
and at least in Unix, the environment variables are often
visible as well), but it's something you need to be able to use
to build non-interactive environments.
				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

From: "William H. Geiger III" <[email-masked]>
Date: Sun, 14 Dec 97 12:29:08 -0600
To: Rodney Thayer <[email-masked]>
Cc: [email-masked]
Subject: Re: PGP 5 (i, source) question...
Sender: [email-masked]

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

In <[email-masked]>, on 12/12/97 
   at 09:05 AM, Rodney Thayer <[email-masked]> said:

>Could someone suggest an appropriate forum in which to ask questions
>about the PGP 5 code that was scanned in 'offshore'?

>I assume it's not appropriate to ask someone from N.A. about this...

Hi Rodney,

You may wish to as over in the [email-masked] mailing list.

Has been a little slow but there are a group of people there who have
worked with the 5.0i code.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Comments: Authenticated sender is <[email-masked]>
From: "Maksim Otstavnov" <[email-masked]>
Organization: home office
To: [email-masked], [email-masked]
Date: Fri, 12 Dec 1997 22:09:41 +0400
Subject: Re: Handling 8-bit cleartext signatures - a proposal (Was: Re: O
Reply-to: [email-masked]
Sender: [email-masked]

--back onlist

On Fri, 12 Dec 1997 Lutz Donnerhacke wrote:

> > > >PGP/MIME in its current incarnation (RFC2015) _does not_ deal with 
> > > >clearsigs.
> > > 
> > > I thought, that PGP/MIME does provide a multipart/signed type.
> > 
> > 1. Well, multipart/signed might be called a clearsigning 
> > but it's a kind of "detached clearsign", that is, one cannot just 
> > save the whole msg in a file and verify in file mode as a last 
> > resort.
> 
> I can save it. I save the whole message.
... and then manually insert armor, eh?

> > 2. 2015 explicitly _forbids_ producing 8-bit first part in 
> > multipart/signed.
> 
> RfC 2015 is somewhat badly designed, yes. I talked to Mark and he will fix
> those points in the next version. Virtually all mailers handle other types
> correctly.
Great.

> > I believe the general problem is not in that (3a) it is hard to
> > maintain certain language environment PGP performance, and even not 
> > in that (3b) 8-bit texts require codepage info for
> > rendering/interpretation, but in that (3c) we deal with ways of
> > PGPing "objects" but have kinds of "objects" still undefined. My
> > understanding is that implicitly we slill have the two flavors of
> > object: "binary streams" and "texts". Texts require some
> > environment-specific info. One example currently defined is the way
> > EOL is represented on a certain platform. An example currently
> > undefined is charset info.
> 
> Correct. But the problem can be solved easily applying the OSI layers
> strictly. Armor is Layer 6 as MIME. It has nothing to do with the message
> format. It has nothing to do with hash calculation ...
Right, armor is OSI Layer 6 issue. It should go to other document, 
but in such case we would have no armor definition in interim period 
(after Formats start its standard track and before 2015 successor 
starts its own).

Anyway, direct referencing to OSI Layers definitions (which RFCs?) 
and indicating the layer(s) involved would enhance the draft.

> > 4. Certainly, I would like "charset" to come back.
> That means reimplementing MIME functionality in PGP seperatly.
Maybe you're right. But still... I'd like to have it as should, for 
backword compatibility with 2.6i
 
--
-- Maksim Otstavnov <[email-masked]> http://www.geocities.com/SoHo/Studios/1059/
--   -maintainer of The Russian PGP HomePage
--     (http://www.geocities.com/SoHo/Studios/1059/pgp-ru.html)

Date: Fri, 12 Dec 1997 09:44:54 -0500 (EST)
From: Tony Mione <[email-masked]>
To: Rodney Thayer <[email-masked]>
cc: [email-masked]
Subject: Re: PGP 5 (i, source) question...
Sender: [email-masked]

There has been some discussion about 5.0i on [email-masked].

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 *****

On Fri, 12 Dec 1997, Rodney Thayer wrote:

> Could someone suggest an appropriate forum in which to ask questions about
> the PGP 5 code that was scanned in 'offshore'?

> I assume it's not appropriate to ask someone from N.A. about this...

Date: Fri, 12 Dec 1997 09:05:10 -0500
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: PGP 5 (i, source) question...
Sender: [email-masked]

Could someone suggest an appropriate forum in which to ask questions about
the PGP 5 code that was scanned in 'offshore'?

I assume it's not appropriate to ask someone from N.A. about this...

Comments: Authenticated sender is <[email-masked]>
From: "Maksim Otstavnov" <[email-masked]>
Organization: home office
To: [email-masked], [email-masked] (Lutz Donnerhacke)
Date: Thu, 11 Dec 1997 00:02:56 +0400
Subject: Re: Handling 8-bit cleartext signatures - a proposal (Was: Re: O
Reply-to: [email-masked]
Sender: [email-masked]

Lutz Donnerhacke wrote:
> * Maksim Otstavnov wrote:
> >An OP application SHOULD mark an outgoing message produced in 
> >a way defined hereabove with either the following headers:
> >
> >%  MIME-Version: <x.x>
> >%  Content-Type: text/plain; charset=<y>
> >%  Content-Transfer-Encoding: <z>bit
> 
> Your proposal deals with MIME, but PGP/MIME still solved the problem.

PGP/MIME in its current incarnation (RFC2015) _does not_ deal with 
clearsigs.

If MIME is considered for any reason a four-letter word in this 
draft, the text starting with the words Lutz quoted and up to the end 
of 2.7.1 section should be excluded from my proposal.
--
-- Maksim Otstavnov <[email-masked]> http://www.geocities.com/SoHo/Studios/1059/
--   -maintainer of The Russian PGP HomePage
--     (http://www.geocities.com/SoHo/Studios/1059/pgp-ru.html)

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Handling 8-bit cleartext signatures - a proposal (Was: Re: OP an
Date: 10 Dec 1997 15:30:04 GMT
Organization: IKS GmbH Jena
Lines: 9
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Maksim Otstavnov wrote:
>An OP application SHOULD mark an outgoing message produced in 
>a way defined hereabove with either the following headers:
>
>%  MIME-Version: <x.x>
>%  Content-Type: text/plain; charset=<y>
>%  Content-Transfer-Encoding: <z>bit

Your proposal deals with MIME, but PGP/MIME still solved the problem.

Date: Wed, 10 Dec 1997 09:42:26 +0100
From: Werner Koch <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: DSA and patents
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> The current draft of OpenPGP allows for Elgamal signatures. It *is* true
> that PGP 5.x does not implement them, but the standard allows them. If
> there's anything in the draft that forbids them, let me know and I'll
> correct it, as I consider that a bug in the spec.

It´s okay, we would only have a problem with the MUST DSA requirement
if we can´t use DSA due to patent issues - according to Peter Gutmann´s
message this will not be the case.

By the way: The bit fiddling stuff with the length headers is somewhat
annoying:  If there is need for partial length headers, the document will
anyway be quite large and spending some extra bytes does matter.  I hope
that can be fixed with next OpenPGP version.

Werner

-- 
Werner Koch, Duesseldorf  -   [email-masked]   -  PGP keyID: 0C9857A5

Date: Tue, 9 Dec 1997 18:30:50 -0800
To: Werner Koch <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: DSA and patents
Cc: [email-masked]
Sender: [email-masked]

At 11:23 AM -0800 12/9/97, Werner Koch said:

   Another issue with the OpenPGP draft is, that it requires DSA signatures
   and has no provisions for plain ElGamal signatures.  If it=B4s true, that
   DSA may infringe on some patents, can ElGamal signatures be made an optio=
n
   for OpenPGP and DSA be a SHOULD and not a MUST?

The current draft of OpenPGP allows for Elgamal signatures. It *is* true
that PGP 5.x does not implement them, but the standard allows them. If
there's anything in the draft that forbids them, let me know and I'll
correct it, as I consider that a bug in the spec.

	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: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re:  DSA and patents
Cc: [email-masked]
Reply-To: [email-masked]
Date: Wed, 10 Dec 1997 09:22:29 (NZDT)
Sender: [email-masked]

>2. The Schnorr patent (4,995,082):  In a letter to the NIST Schnorr
>   claimed that the DSA infringes his patent.  FIPS 186 (about DSS)
>   states that "The Department of Commerce is not aware of any patents
>   that would  be infringed by this standard".  I also heard, that the
>   government will help if someone is sued on patent infringement while
>   working on a project implementing DSS for governmental purposes.
 
The Schnorr patent is a so-called "scarecrow patent" which only applies to a 
very restricted set of smart-card based applications.  A number of lawyers 
from companies big enough to care about possible lawsuits have examined it and 
decided that any claims against typical software implementations are baseless.
 
>Another issue with the OpenPGP draft is, that it requires DSA signatures
>and has no provisions for plain ElGamal signatures.  If itM-4s true, that
>DSA may infringe on some patents, can ElGamal signatures be made an option 
>for OpenPGP and DSA be a SHOULD and not a MUST?
 
There are various issues with Elgamal signatures, the main one is that the 
keys PGP 5 currently generates with g=2 makes the signatures forgeable using 
an attack which Daniel Bleichenbacher described at EuroCrypt'96.  You'd need 
to modify the PGP keygen to avoid this.  There's a draft RFC 
draft-rfced-info-gutmann-elgamal-00.txt which covers this and other issues.  
>From the draft:
 
>3. Security considerations
>
>Although the use of the Elgamal algorithm for digital signature
>generation is not directly addressed in this document, it should be
>pointed out that some care needs to be taken with both the choice of
>keys and the use of the algorithm.  Details on the safe use of Elgamal
>are given in [4].  A weakness of Elgamal when used for digital
>signatures, and workarounds to avoid the weakness, are given in [5].
>
>Ongoing research into the security of Elgamal may reveal other factors
>which need to be taken into account to provide adequate security for
>signature and encryption applications, for example it is desirable that
>g generate a large subgroup of Zp*; it is recommended that implementors
>keep abreast of current research on the choice of parameters and use of
>the algorithm in order to avoid potential security weaknesses.
 
Peter.

Date: Tue, 9 Dec 1997 20:23:43 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: DSA and patents
Sender: [email-masked]

Richard Stallman asked me to clarify the status of possible patent
conflicts on DSA.  I know of these two points: 

  1. There is a a patent of Kravitz (5,231,668) assigned to "The United
     States of America as ...".  The NIST said, that they will make
     this patent world-wide available on a royalty-free basis.

  2. The Schnorr patent (4,995,082):  In a letter to the NIST Schnorr
     claimed that the DSA infringes his patent.  FIPS 186 (about DSS)
     states that "The Department of Commerce is not aware of any patents
     that would  be infringed by this standard".  I also heard, that the
     government will help if someone is sued on patent infringement while
     working on a project implementing DSS for governmental purposes.

If anyone here has more information, can [s]he be so kind and comment
on this?

Another issue with the OpenPGP draft is, that it requires DSA signatures
and has no provisions for plain ElGamal signatures.  If it´s true, that
DSA may infringe on some patents, can ElGamal signatures be made an option 
for OpenPGP and DSA be a SHOULD and not a MUST?

-- 
Werner Koch, Duesseldorf  -   [email-masked]   -  PGP keyID: 0C9857A5

Date: 9 Dec 1997 0:38:43 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: co-chair resigns
To: Charles Breed <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

We'll miss your chairing Charles - its been good. I hope we continue to see
you on the list ?

Cheers - Linz
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Beta Vs 2.6.1.2, on December 9, 1997, in Win95 4.0
	http://www.blackpaw.com/

Date: Mon, 08 Dec 1997 14:38:46 -0800
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: co-chair resigns
Sender: [email-masked]

To all OpenPGP list members,

I'm resigning as co-chair of the IETF OpenPGP working group, John
Noerenberg <[email-masked]> at Qualcomm will be the one and only
chairperson.

My employment has been terminated as part of the Network Associates
buy-out, and it's critical that the OpenPGP specification gets done
and adopted by many without having to pay ANYTHING to Network
Associates. Open, Free, Unencumbered, no royalties will make the spec
successful with lots of independent implementations.

I'll be working for Interlink / NetLock on IPsec starting Jan. '98

Cheers,
Charles Breed

Date: Mon, 8 Dec 1997 13:31:00 -0500
From: [email-masked]
To: [email-masked]
Subject: Re: Discrete log signature key sizes
Sender: [email-masked]

On Thu, 4 Dec 1997, Hal Finney wrote:

> Anybody have a good way to synthesize a 320 bit hash out of a 160 bit one?
> I found a paper which suggested doing a "butterfly" using 8 instances of
> the smaller hash which looked pretty good (Eurocrypt 96, Aiello).
> 
> Hal

What about concatenating SHA1 and RIPEMD160 hashes?  Or are they too
related so that it would be significantly less than the square of the cost
of finding either?  What about the second hash being over the message and
the first hash?

Also, if a 320 bit hash was available, how would you modify DSS to allow
for that, simply change Q to a 320 bit number?

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

Date: Sun, 07 Dec 1997 16:45:34 -0500
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: r.e. code fragments in the documents
Sender: [email-masked]

>Has the BXA ruled on itef drafts?  Snuffle is smaller than many code
>fragments, but (barring a further ruling) still cannot be posted on the
>internet.  I have lots of concise working examples of how PGP does things,
>from my implementations, but will we run into the "crypto is a munition"
>problem if the draft contains the wrong type of example?

In IETF land it is ok to put code fragments in drafts.  It is strongly
recommended they fall across page boundries so that it's clearly a
technical paper.  See the RC5 RFC by Rivest for an example, it's basically
code with a light topping of page footers.

This is a technical/academic paper in a public forum, I believe, so that's
why it's ok.

Date: Sun, 7 Dec 1997 21:46:49 -0500
To: [email-masked]
From: "John  W. Noerenberg" <[email-masked]>
Subject: Agenda for Monday's WG meeting
Sender: [email-masked]

So you all have some idea how I plan to order the meeting tomorrow, here's
how I'll break it down:

1 Outline meeting John N (5 min)
2 WG goals John N (10 min)
  restate the charter
3 Phil Zimmerman -- Design philosophy of PGP (10 min)
4 2015 status -- Dave Del Torto (20 min)
5 format draft status -- Jon Callas (45 min)
6 revise charter to add Trust Model doc (15 min)
7 any other new business (15 min)

The Trust Model is something we talked about in the early days of
organizing the WG, and I've lately been thinking it would be worthwhile
bringing it back into our scope.  Mike Elkins was unable to attend the
meeting, so Dave Del Torto has graciously stepped in to conduct the
discussion on 2015.

The heart of the meeting is the format draft discussion.  There has been a
lot of discussion over the last 2 weeks.  I expect the meeting will help us
bring closure to some of these discussions.  The results of the live(ly)
discussion will be posted as soon as possible.

I'll be looking for a volunteer to keep notes during the discussion for the
benefit of those who won't be at the meeting.

john  w noerenberg, ii
[email-masked]
pager: [email-masked]
  ----------------- --------------------------- ----------------------
  "The great man is he who in the midst of the crowd keeps
   with perfect sweetness the independence of solitude."
  -- Ralph Waldo Emerson, "Self Reliance", 1841
  ----------------- --------------------------- ----------------------

From: [email-masked]
DATE: 07 Dec 97 4:02:02 AM
TO: [email-masked]
SUBJECT: We bulk Email for You
Sender: [email-masked]

                LET US DO YOUR BULK MAILINGS!!!

             ...$350 PER MILLION ADDRESSES SENT
           ...$250 PER 1/2 MILLION ADDRESSES SENT

      THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS!

Our company will do bulk emailing for your product/service.

DON'T BE LEFT IN THE DUST OF YOUR COMPETORS, ADVERTISE TODAY!!!

Addresses are extracted daily by 6 of our computers, which run 24 
hours a day 7 days a week, scanning the net for new addresses.  
Estimated 60-80,000 addresses extracted daily.  They are fresh!  
Over 40 million addresses on file.   More computers with cable 
modems are being added due to increasing responses.

All ads can not be more than 2 pages (50 lines) and 68 characters 
wide.  More than 50 lines, there will be an additional charge of $50
per page or 25 lines or less.  
 
No porn, no foul language or sex relative material will be
sent.  

    ->->->->->->->-> TARGETED MAILINGS <-<-<-<-<-<-<-<-

->-> $150 per 50,000 addresses extracted or less
->-> This price includes mailing of material
->-> Allow 3-7 days for extracting of addresses
->-> Mailings to US only (general addresses) $500 per 500,000
->-> Many targeted list on file
->-> Purchased target list $150 per 50,000 or less

If you have your own list, we will email your list for $200
per 500,000 or less.  All list must be in text format and
each address must be on individual lines.

***Mailings are done all at once, not broken down into 
multiple mailings.***

Addrsses are processed against our remove list of those
individuals who have asked to be elimated from any of our
mailings.  All mailings are de-duped for duplicates.  No
.mil, .gov or .edu included. 

There are no lower prices on the net.  Your mailing 
can be done in a matter of hours.  Turn around time for
mailings range from 3 to 5 days.  This time varies according 
to the demand of mailings.

For the fastest service, cheapest prices and cleanest
mailings call our processing and new accounts office
at 904-282-0945, Monday - Friday 9 - 5 EST (English only).  
If the line is busy or no repsonse, please keep trying, 
as bulk mailing is growing fast and we are busy responding 
to those who are interested in advertsing on the internet.  
We DO want to work with you to advertise your product/service.  
No collect calls.

Our computers are working 24 hours a day to better serve YOU!

To have your name removed, call our processing office.
Any negative responses will be dealt with accordingly.

Date: Sun, 07 Dec 1997 18:16:13 -0800
To: Ian Grigg <[email-masked]>
From: Bill Stewart <[email-masked]>
Subject: Re: Speculative Mode for KeyIDs of all zeroes
Cc: [email-masked]
Sender: [email-masked]

At 09:53 AM 12/06/1997 +0000, Ian Grigg wrote:
>Hmmm.  True, a very good point, a test would be needed.  Maybe it should
>only be supported in text mode ('t' flag on?), or maybe there should be
>a magic number within.  If it was only in test mode, then binaries could
>be done by armouring (or whatever) inside.

Binary's fine, if the Symmetrically Encrypted  Data Packets contains
a Compressed Data Packet or Literal Data Packet or Signature Packet
or OnePass Signature Packet or other recognizable PGP form.

>> Another option is to only check the "default" key,
>> though default key really an artifact of the user interface
>> rather than something OPGP needs to know about.
>Another problem is that most PGP implementations will treat the keys on
>the rings in  a simple fashion, so the first implementations of the
>Zeroes feature are likely to ask the user for *all* the keys in
>succession ... <blech>.

Boring, eh?  But most people don't have too many secret keys,
so it isn't really that much slower, and you can skip any keys
that aren't the right length to match the encrypted session key.
(E.g. if the ESK is 1024 bits long, you can skip that 2047-bit
signature-only key and your 512-bit regular-use key.
It's probably a good idea for people who are this paranoid to
use standard length keys, probably 1024, since that
1984-bit key is somewhat of a giveaway.)

>I wouldn't even make it SHOULD as it will be quite difficult to get
>right, from the comments above.  MAY is fine by me.

Agreed, especially since you can do it with wrappers and not need
to trouble the OPGP implementation directly.
MAY accept KeyID 0, and MAY generate KeyID 0 instead of a real key,
and if you send a KeyID 0 to somebody who you don't know has it,
you should expect to lose.  I suppose Notation Subpackets
aren't a bad place to indicate that you support KeyID 0.

>As a side-effect, would we add "An implementation SHOULD treat KeyID of
>all zeroes  as a reserved and/or bad key?"  What is the source and
>semantics of a KeyID of zero?  Presumably it must happen as keyservers
>are worried about clashes, so should a key that generates with this be
>considered a bad key?

The probability of a generating a key with KeyID of 0 is 2**-64.
It could happen by accident, though it probably won't, and worst case is
the lucky user of such a key will just have to check all messages 
sent to him that have KeyID 0 against all his keys.
Annoying, but no loss of functionality.
				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: PGP Inc. cleans off the KRAP
Reply-To: [email-masked]
Date: Mon, 8 Dec 1997 12:52:24 (NZDT)
Sender: [email-masked]

Just appeared on PGP Inc's home page: "Network Associates Withdraw from Key 
Recovery Alliance".  Cool.
 
Peter.

From: [email-masked]
DATE: 05 Dec 97 5:25:06 PM
TO: [email-masked]
SUBJECT: Lasers/Optics/Optical Tables - Save!
Sender: [email-masked]

MWK INDUSTRIES SALE! 

JUST A QUICK LETTER TO SHOW YOU  SOME LASERS- OPTICS AND OPTICAL TABLES 
SURPLUS
THAT WE JUST RECEIVED.

ITEM TRIMMU12   14 WATT ARGON LASER MADE FOR HEART SURGERY, TRIMEDYNE 
MODEL 900
TEMOO, POLORIZED,220VAC INPUT , WATER COOLED , FIBER LAUNCH, ALL ON 
ROLLAROUND CART
EXCELENT FOR LAB USE, THE POWER WAS MEASURED AT 13 TO 14 WATTS. PRICE 
$9500
12 MONTH WARRANTEE.  

ITEM: COHERENT ARTICULATING ARM FROM A  MODEL 451 CO2 MEDICAL LASER.
ECCELLENT COND. $200

ITEM CO220A:  CO2 LASER MADE BY PFIZER ,1990, FOR SURGERY, TATTOO 
REMOVAL ECT.
20 WATT OUTPUT , TESTED AND IN EXC. COND. 110 VAC INPUT, COST $40,000 
NEW OUR PRICE 4,900.
MODEL 20-C

ITEM:PDA-1U1  SPECTRA PHYSICS QUANTRA RAY PULSED DYE LASER , GOOD FOR 
SPARE PARTS
MODEL PDA-1 $500

ITEM NEWU1  NEWPORT OPTICAL TABLE 16" BY 36" 4" THICK, 1 " HOLE SPACING, 
COMES WITH A
RUBBER ISOLATED TABLE STAND, NOT AIR SUPPORTED,   $750

ITEM: HEPSN1  HELIUM  NEON POWER SUPPLY KIT OPERATES UP TO A 15 mW  
LASER, INCLUDES
ALL COMPONENTS AND PRINTED CIRCUIT BOARD, ALL YOU HAVE TO DO IS STUFF 
AND
SOLDER THE CIRCUIT  BOARD . 4" BY 3" BY 3", PRICE $75

ITEM  HENEU12   1 TO 1.5 MW HE-NE LASER 632.8 nM INCLUDES 12VDC INPUT 
POWER SUPPLY
ALL  IN A PLASTIC HOUSING 6.25 IN. BY 1.375IN BY 2.25 IN. TEMOO,RANDOM 
POL. ,1.7 MR DIVERGENCE.
12 MONTH WARRANTEE , PRICE $45

ITEM MELU12   1 TO 2 mW  HE-NE LASER 632.8 NM , PULLS FROM MEDICAL 
EQUIPMENT .EACH
UNIT INCLUDES HE-NE HEAD AND POWER SUPPLY[110VAC INPUT]. ALL YOU NEED TO 
PROVIDE IS A POWER CORD AND A FUSE TO MAKE THE UNIT OPERATIONAL. THE 
BEAM IS TEM00, POLORIZED
WE WILL COVER EACH UNIT WITH A 12 MONTH UNLIMITED HOUR WARRANTEE, 
EXCELLENT
FOR FOR LAB OR HOME USE. NEW THESE COST APPROX. $350 OUR PRICE $85. 
DIMENSIONS  9.75 BY 1.25 INCHES, P.S. 4.25 BY 3.25BY 1.25 INCHES.

ITEM  RAMCNS1:  RAMAN CELL OPTICS 308 nm AR/AR 4600 A 0=0 DEGREES
1000 MM FL. 2" DIA. NEW. ORIGINAL PRICE $520 OUR PRICE $175

ITEM TFPOLNS1:   POLARIZERS , THIN FILM FOR 532 nm , NEW, ORIGINAL COST 
$590 EACH
OUR PRICE $200 EACH  10 MM DIA.

ITEM CO2OCNS1:  CO2 HIGH REFECTOR AND OUTPUT COUPLER 10.5 MM DIA, OC 
=79%R
NEW. $200 A SET.

ITEM 25MNS1: DIELECTRIC BROADBAND MIRRORS 450 TO 700NM , NEW WITH 
PLASTIC 
PROTECTIVE COATINGS , 2 SIZES 25 MM SQ. AND 50 MM SQ. RECOMENDED FOR 
HIGHER
POWER LASERS. 

25MM SIZE  ITEM  25MNS1 $20
50MM SIZE  ITEM 50MNS1  $25

ITEM # BSDNS1:   50/50 DIELECTRIC COATED PLATE BEAM SPLITTER 630 TO 660 
NM
COMES IN A TRIANGLE SHAPE EACH SIDE APPROX. 1"   PRICE $20

ITEM # 45NS1  45 DEGREE RED REFLECTOR , PASSES 488 TO 532NM , CAN BE 
USED TO COMBINE
RED AND GREEN/BLUE LASERS TO CREATE A WHITE LIGHT LASER. 1" SQ.   PRICE 
$15

ITEM# PCINS1  PLANO/CONVEX LENS COATED FOR YAG 1064NM  , AR COATED, 10MM 
DIA.
NEW, ORIG. COST $250 OUR PRICE $100

ITEM# INFILTER   : INTERFERENCE FILTERS USED FOR PASSING A PARTICULAR 
SPECTRAL
LINE , 11.8 MM DIA. CAREFULLY REMOVED FROM MEDICAL EQUIPMENT AND WRAPPED
IN LENSE PAPER.  THE FOLLOWING WAVE LENGTHS ARE AVAILABLE.
523.5, 547.4 , 572.1,  512.9,   550.6,  488,  505.7 nm   price $20 each.

FOR A COMPLETE LINE OF NEW AND USED LASERS - OPTICS -ELECTRO OPTICS- 
LASER SHOWS
ORDER A COMPLETE CATALOG AT MWKINDUSTRIES.COM

TO: ORDER GO TO OUR WEB SITE    MWKINDUSTRIES.COM   {SECURE ORDERING 
SITE}

QUESTIONS OR REMOVAL FROM MAILING LIST EMAIL:  [email-masked]

MWK INDUSTRIES
1269 POMONA RD
CORONA CA 91720
PHONE 909-278-0563
FAX 909-278-4887

Comments: Authenticated sender is <[email-masked]>
From: "Maksim Otstavnov" <[email-masked]>
Organization: home office
To: Jon Callas <[email-masked]>
Date: Sat, 6 Dec 1997 23:12:39 +0400
Subject: Handling 8-bit cleartext signatures - a proposal (Was: Re: OP an
Reply-to: [email-masked]
CC: IETF OpenPGP <[email-masked]>
Sender: [email-masked]

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

On Thu, 04 Dec 1997 10:57:28 -0800 Jon Callas <[email-masked]> wrote:

> At 09:22 PM 12/4/97 +0400, Maksim Otstavnov wrote:
> 
>>Besides, it has nothing to do with PGP/MIME. PGP/MIME is a separate
>>question currentely not discussed by this WG according to its
>>agenda. (right?).
> 
> No, PGP/MIME (a.k.a. OP-MIME, or RFC 2015) is covered by this
working group.
>    
>>The OP is to obsolete rfc1991, not 2015, right? Ascii-armor is
>>currently defined in 1991, not 2015. So I just wish OP rfc to 
contain 
>>both a concept of "8-bit text" and definition of actions order for
>>plugins/glues producing _non-PGP/MIME_ messages. Just so little ;)
> 
> This working group has two things under its charter (presently) --
the
> OP-FORMAT document and RFC 2015. So each are relevant, we just have
two
> documents.

...But a new PGP(OP?)/MIME is not scheduled yet... Handling clearsigs
_does_ belong to OP draft domain currently and all ambiguities imho
should be fixed before it starts on its standard track.

I apologize if a subject of my previous postings was ambiguos. The
exact problem I face is that pgp 5.0i users in Russian environment
suffer a set of complications derived (I believe) from the fact that
8-bit text clearsigning is performed differently in different cases.

For example, I apply a procedure (recommended by PGP 5.0 manual) for
clearsingning msg to be sent with an _unsupported_ MUA (eg MS Internet
Mail). The MUA operates in a Windows native codepage (so called
"Windows-cp1251") and PGP produces a clearsign of this codepage
rendering of the plaintext. Then I send a message. Before sending, the
message (mime, 8-bit, plaintext) is usually converted to
cross-platform standard, KOI8-R (RFC 1489, officially registered with
RFC 1700, also registered by the POSIX WG15 character set collection,
the latest Registered Charsets List from IANA and by IBM  as CP878)
either as 8-bit or printed-quotable. 

If a receiving MUA isn't Win-based, the message normally never 
returns to the native Win cp, so signature can't be verified.

Furthermore, a _supported_ plugin developer currently not bound 
(nor even advised) by any document to a particular _order_ of 
performing both conversion and PGP-clearsigning a single message. So,
it may happen that a message clearsigned with one plugin won't be
verified by an other one, even on _the same_ platform.

(I don't know for sure how current 5.0 MUA plugins (I am aware of the
four - Eudora, MS Exchange/Outlook, Mail'97, and QDPGP 1.60 for
Pegasus for 32-bit Windows) handle the two operations of a single
message).

In recent days I've been trying to figure how OP would fix the 
problem. The following proposals are the result (I browsed through the
entire archive of the OP list and found no proposals which would
contradict these; pls advise me if I'm wrong). I am not overall happy
with them, for clipboard clearsigning remains a problem, but it would
at least make all OP-compliant applications ("supported MUAs")
intercompatible over 8-bit clearsigned texts.

Suggestions? Comments?

- -----cut here-----
>2.6 Cleartext signature framework
>
>Sometimes it is necessary to sign a textual octet stream 
Proposal:
, consisting either of 7-bit or 8-bit textual octets, 
>without ASCII
>armoring the stream itself, so the signed text is still readable
>without special software.  In order to bind a signature to such a
>cleartext, this framework is used. (Note that RFC 2015 defines
>another way to clear sign messages for environments that support
>MIME.)

Proposal:

2.7 Handling 8-bit cleartext signatures

Sometimes it is desirable to perform cleartext signature over a 8-bit
textual octet stream. In certain environments performing of other, not
defined in this document, conversion ("Non-OP conversion") of a 8-bit
textual octet stream is also required (e.g. for handling non-English
messages in a cross-platform environment).

If an OP application allows handling 8-bit textual octet stream it
MUST apply cleartext signature and perform a non-OP conversion of a
single 8-bit textual octet stream in the following way.

2.7.1 Producing 8-bit cleartext signature

- - perform non-OP conversion of the original textual octet stream 
  (producing either 8-bit or 7-bit output) required by a specific
  environment; then

- - apply cleartext signature framework (defined in 2.6 of this
document) 
  over the product of such conversion.

The product of the two consequential procedures described 
hereabove is either 8-bit or 7-bit textual octet stream,
depending on specific environment requirements.

An OP application SHOULD mark an outgoing message produced in 
a way defined hereabove with either the following headers:

%  MIME-Version: <x.x>
%  Content-Type: text/plain; charset=<y>
%  Content-Transfer-Encoding: <z>bit

or the following headers:

%  MIME-Version: <x.x>
%  Content-Type: text/printed-quotable; charset=<y>
%  Content-Transfer-Encoding: 7bit

where 
- - <x.x> is a version of MIME supported by the OP application;
- - <y> is a registered charset corresponding with the semantics of
the 
  output of the non-OP conversion applied; 
- - <z> is either "8" or "7" depending on the octet width of non-OP 
  conversion.

2.7.2 Verifying 8-bit cleartext signature

- - verify cleartext signature; then

- - perform non-OP conversion of the message in accordance with
  its "MIME-Version", "Content-Type", and "Content-Transfer-Encoding"
  headers values.
- -----cat there-----

--
-- Maksim Otstavnov <[email-masked]> http://www.geocities.com/SoHo/Studios/1059/
--   -maintainer of The Russian PGP HomePage
--     (http://www.geocities.com/SoHo/Studios/1059/pgp-ru.html)
--   -moderator of "Security&Privacy" (Russian language) Web-forum
--     (http://www.rocit.ru/forum)

Date: Sat, 06 Dec 1997 09:53:16 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
CC: [email-masked]
Subject: Re: Speculative Mode for KeyIDs of all zeroes
Sender: [email-masked]

[email-masked] wrote:

(stego stuff cut, this is too much for V1 IMHO)

> On the other hand, if OPGP does support the 0s mode,
> it'll have to successively try each secret key it has
> until it either finds one that works or finds that
> none of them work; an alternative is to have an external
> preprocessor program that drives it, by trying each KeyID in succession.
> This requires that the driver know what KeyIDs are available
> (either reading directly from the keyring or
> just from a list), and that the OPGP implementation
> have some easily-parsed response that lets the driver
> decide whether or not the decryption worked.

Hmmm.  True, a very good point, a test would be needed.  Maybe it should
only be supported in text mode ('t' flag on?), or maybe there should be
a magic number within.  If it was only in test mode, then binaries could
be done by armouring (or whatever) inside.

> Another option is to only check the "default" key,
> though default key really an artifact of the user interface
> rather than something OPGP needs to know about.

Another problem is that most PGP implementations will treat the keys on
the rings in  a simple fashion, so the first implementations of the
Zeroes feature are likely to ask the user for *all* the keys in
succession ... <blech>.

> Internal support is more efficient, but non-critical,
> so I'd recommend against making it a MUST, but it'd be
> nice to have it as a SHOULD.

I doubt it could be a MUST as it is not used anywhere yet, and it is too
adventurous of us to mandate anything that is not yet in use.

I wouldn't even make it SHOULD as it will be quite difficult to get
right, from the comments above.  MAY is fine by me.

As a side-effect, would we add "An implementation SHOULD treat KeyID of
all zeroes  as a reserved and/or bad key?"  What is the source and
semantics of a KeyID of zero?  Presumably it must happen as keyservers
are worried about clashes, so should a key that generates with this be
considered a bad key?

-- 
iang                                      systemics.com

FP: 1189 4417 F202 5DBD  5DF3 4FCD 3685 FDDE on pgp.com

Date: Fri, 5 Dec 1997 10:44:14 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft - Long.
Sender: [email-masked]

Peter Gutmann, [email-masked], writes:
> To get around this, you could use Elgamal for signatures (although the current 
> PGP doesn't support this, the code is commented out).

One word of caution for those who may be tempted to un-comment the ElGamal
signature code in the 5.0 source: there is a security flaw as written.

The problem is not in the signatures per se but in the key generation.
ElGamal signatures require some care in the choice of the generator.
We use a generator of 2 for ElGamal encryption, which is safe for that
purpose, but is not safe for ElGamal signatures.

So before enabling ElGamal signatures, they must change the keygen code.

(I don't know of any reason to use ElGamal signatures in place of DSS
signatures though.)

Hal

Date: Fri, 05 Dec 1997 18:04:49 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
Subject: US participation in International Standards (was: Re: Complexity...)
Sender: [email-masked]

[email-masked] wrote:

> Has the BXA ruled on itef drafts?

I believe that there is an exemption on Americans being permitted to
participate on standards committees of an international nature.  If
anybody knows the precise wording of the exemption, I'd be interested to
see.

-- 
iang                                      systemics.com

FP: 1189 4417 F202 5DBD  5DF3 4FCD 3685 FDDE on pgp.com

Date: Fri, 5 Dec 1997 12:16:47 -0500
From: [email-masked]
To: Ian Grigg <[email-masked]>
cc: Hal Finney <[email-masked]>, [email-masked]
Subject: Re: Complexity not a dominant strategy for independant deployment
Sender: [email-masked]

On Tue, 25 Nov 1997, Ian Grigg wrote:

> Hal Finney wrote:
> 
> > Maybe a more constructive approach is to ask whether the description
> > in the new draft is clear and useful.  The draft is lengthy, yes,
> > but not very much of it is occupied discussing packet length headers,
> > and perhaps that portion could be made more concise.  We could include
> > some code samples if this is an area where people are afraid of the
> > implementation difficulty.
> 
> Adding code fragments is a good idea.  Code does not lie where text can
> not help but spread mistruths.
> 
> Psuedo code or C or even Java would be very useful.  We may even be able
> to make this easier by adopting the convention that comments on the
> draft, within this mailgroup, include code fragments to explain their
> points, as Adam did earlier.  Then, the editors can simply cut and past.

Has the BXA ruled on itef drafts?  Snuffle is smaller than many code
fragments, but (barring a further ruling) still cannot be posted on the
internet.  I have lots of concise working examples of how PGP does things,
from my implementations, but will we run into the "crypto is a munition"
problem if the draft contains the wrong type of example?

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

Date: Fri, 5 Dec 1997 12:11:15 -0500
From: [email-masked]
To: [email-masked]
Subject: Re: Complexity not a dominant strategy for independant deployment
Sender: [email-masked]

On Tue, 25 Nov 1997, Hal Finney wrote:

> Ian Grigg, <[email-masked]>, writes:
> > It never occurred to me until right now - probably because I have
> > cauterised that part of my brain - but it would be a big win for future
> > generations if we can add an alternate CFB method that is straight down
> > the line, and start deprecating the existing method.
> 
> We will need to make some alterations when it is time to support ciphers
> with block sizes larger than 64 bits.  There is language in the draft
> which would allow us to fix it at that time.  The current wording is:
...
> Notice "resynchronized if the cipher block size is 8 octets or less".
> This means the resync will go away for larger block ciphers.  However now
> I realize that the 8+2 header will not be right for such ciphers, either.
> Probably we should replace the "8" with the block size of the cipher.
> Any other suggestions on how to revise this?
> 
> (Note that the purpose of the two redundant bytes is to tell if you have
> the right key for decryption.)

Either way, however lock in either a fixed 8, or fixed "Cipher Block Size"
early.  Right now I have 8 hardcoded, but all three existing algorithms
use 8 byte blocks.  Also quickly define a >8 byte block size cipher with
number and implement something so interoperability can be easily checked.

...
> I considered another way of documenting the resynchronization of the
> CFB mode.  It can be described pretty cleanly as follows:  Encrypt the
> first 8 bytes in CFB-64 mode, the next two bytes in CFB-16 mode, and
> the remainder of the message in CFB-64.

I managed to get totally confused by the CFB stuff, but managed to hack
something that worked for 2.6.x starting with idea_cfb64_encrypt(buf1,
buf2, 10...)  (from SSLeay - yes, 10 bytes), and after verifying the last
two byte pairs are identical, I reset the iv counter and load the ivec
with the original first 8 bytes, and then just use idea_cfb64_encrypt
normally. 

It is much easier to just do than to explain.  I had to create my own
generic cfb, which was fairly simple, and cfbreset routines for PGP 5.0
since it applied the cfb function over multiple algorithms.  Cfbreset
should be just: 

void cfbreset()
{
  memmove(&cfbivec[8 - ivleft], cfbivec, ivleft);
  memcpy(cfbivec, &lastiv[ivleft], 8 - ivleft);
	/* lastiv is the iv previous to the current image */
  ivleft = 0;
}

Replace 8 with cipherblocksize if/when that is changed.  Also note that if
the only reset occurs at the beginning, and the initial iv is all zeros,
simply copying the original cipherblocksize bytes into the iv is
sufficient.  This is currently true of how cfbreset is used in the
existing PGP implementations.

The worst problem I have is that various libraries have different data
types (sizes), so the iv data must be converted from/to the 8 byte cfb
vector to/from the 32bit words or whatever in a portable way.  So although
there is not an "endian" assumption per se, when DES and IDEA use 32 bit
entities, I have to insure that the char[4] aligns properly.  This isn't a
problem if there is an internal X_cfb64_encrypt call in the lib for all
conventional algorithms I want to implement.

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

Date: Fri, 05 Dec 1997 13:51:17 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Jon Callas <[email-masked]>
CC: Hironobu Suzuki <[email-masked]>, [email-masked]
Subject: Re: new algorithm identifier of the symmetric cryptosystem.
Sender: [email-masked]

Jon Callas wrote:

>    Few years later, someone will hack AES (Advanced Encryption Standard)
>    into PGP. I think several people will hack it at the same time. Who
>    does allocate/control id number of AES?
> 
> You're correct, it makes sense to reserve a constant for the AES now. Thank
> you for the suggestion.

Actually, the AES will be chosen from a group of 5 submitted
algorithms.   As all of those algorithms are likely to be independantly
hacked in before the winner is chosen, they will all need numbers, and
it is likely that we can simply use the winning number as a continuation
if it has been deployed.

However, in the event that NIST asks for any changes in the algorithm,
it would be a wise precaustion to reserve the extra number for the
eventual AES as well.  Numbers are cheap, reservations are not.
-- 
iang                                      systemics.com

FP: 1189 4417 F202 5DBD  5DF3 4FCD 3685 FDDE on pgp.com

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: More draft comments
Date: 5 Dec 1997 08:19:48 GMT
Organization: IKS GmbH Jena
Lines: 52
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Tony Mione wrote:
[Signatures]
>	Why is the keyID needed? It should be present in the actual
>signature packet at the end of the message (in an Issuer ID subpacket
>within the actual signature packet). Isn't this a waste of space? Also,

No. The additional package nac provide more bits of the fingerprint (aka key
ID) that the fixed size field. But this is truly optional.

>what if you are setting up one pass signing for multiple keys? Do you need
>multiple one pass signature packets if all of the other information is the
>same (pk algorithm, sig type, hash alg, etc)?

No, only for the hashes.

[Secret key]
>	Why are p and q saved? My understanding was that these are not
>needed should be thrown away after the keypair is generated. If the secret
>key exponent is saved in addition to the public exponent, then there is no
>need for these pieces of data. Or am I totally missing something?

There are several shortcuts in modular arithmetics which requires p, q, and
some modular inverses.

>	How about a new packet type for all certificates. Internally, it
>can included a certificate type (PGP Classic = 1, OpenPGP = 2, X.509 = 3,
>SPKI = 4, etc.) followed by certificate-specific contents (ASN.1 crud
>for X.509, s-expression for SPKI, etc).

You like to introduce an other layer. But OpenPGP defines only the PGP layer
not a framework on top of such layers.

>	In each case, exactly what material is the key signing? The
>signature packet says which subpackets are included in the signed material,
>however, what parts of the preceding packets are hashed and signed:
>
>	- The entire public key packet followed by the entire user-id packet?
>	- The MPIs from the pk packet + user-id data?
>	- only the actual key material from the pk packet + the user-id data?

Quote from my proposal:
   13 - Key certification, positive ID. Heavy-duty identification efforts,
        photo ID, direct contact with personal friend, etc. Material
	signed is public key pkt and User ID pkt.
	MUST be supported.

>	Ok, now I'm confused. How does this relate to the public key
>packet? If this is not a packet, but rather a stored structure, then why is
>it in a document on Message Formats?

Im confused, too. My major problem is, that the current draft status is
unavailable. I do not know what's edited and what's not.

Date: Fri, 5 Dec 1997 01:12:53 -0500 (EST)
From: Tony Mione <[email-masked]>
To: [email-masked]
cc: Tony Mione <[email-masked]>
Subject: More draft comments
Sender: [email-masked]

Some more comments....hope they are helpful.

Secition 5.4:

...
	- A one-octet number describing the public key algorithm used.
	- An eight-octet number holding the key ID of the signing key.
	- A one-octet number holding a flag showing whether the signature...
...

	Why is the keyID needed? It should be present in the actual
signature packet at the end of the message (in an Issuer ID subpacket
within the actual signature packet). Isn't this a waste of space? Also,
what if you are setting up one pass signing for multiple keys? Do you need
multiple one pass signature packets if all of the other information is the
same (pk algorithm, sig type, hash alg, etc)?

Section 5.5.3:

	Why are p and q saved? My understanding was that these are not
needed should be thrown away after the keypair is generated. If the secret
key exponent is saved in addition to the public exponent, then there is no
need for these pieces of data. Or am I totally missing something?

Section 5.12, second editor's note:

...
{{Editor's note: should we put in an X.509 encapsulation packet type?}}
...

	How about a new packet type for all certificates. Internally, it
can included a certificate type (PGP Classic = 1, OpenPGP = 2, X.509 = 3,
SPKI = 4, etc.) followed by certificate-specific contents (ASN.1 crud
for X.509, s-expression for SPKI, etc).

Section 7.1:

	In each case, exactly what material is the key signing? The
signature packet says which subpackets are included in the signed material,
however, what parts of the preceding packets are hashed and signed:

	- The entire public key packet followed by the entire user-id packet?
	- The MPIs from the pk packet + user-id data?
	- only the actual key material from the pk packet + the user-id data?

Section 8:

	Ok, now I'm confused. How does this relate to the public key
packet? If this is not a packet, but rather a stored structure, then why is
it in a document on Message Formats?

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 *****

Date: Thu, 04 Dec 1997 19:35:58 -0800
To: [email-masked], <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: new algorithm identifier of the symmetric cryptosystem. 
Cc: [email-masked]
Sender: [email-masked]

At 09:47 PM 12/4/97 -0500, Robert Guerra wrote:
   
   is there a spec. for an eliptic curve encryption algorithym?
   
I've added one in for Elliptic Curve encryption and for ECDSA.

	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)

Date: 	Thu, 4 Dec 1997 21:47:52 -0500
From: Robert Guerra <[email-masked]>
Reply-To: [email-masked]
To: <[email-masked]>
Subject: Re: new algorithm identifier of the symmetric cryptosystem. 
cc: [email-masked]
Sender: [email-masked]

On Thu, 4 Dec 1997 17:04:56 -0500 [email-masked] (Jon Callas) wrote:

>
>Presently, the OP-FORMAT spec defines 4 for Blowfish. I'll reserve one for
>GOST.
>

is there a spec. for an eliptic curve encryption algorithym?

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: new algorithm identifier of the symmetric cryptosystem.
Reply-To: [email-masked]
Date: Fri, 5 Dec 1997 14:47:01 (NZDT)
Sender: [email-masked]

>One problem we have (which was discussed a while back on this list) is that
>our algorithm identifiers have no provision for variants.  With IDEA this was
>not a problem as there was only one IDEA.  3DES is pretty well standardized
>on the version we use (EDE).  CAST is technically a design procedure rather
>than a cipher, and what we call CAST is properly known as CAST5-128, with
>several other variations possible.
 
Why not just use the ISO AlgorithmIdentifiers, which (where they exist) are
well-know and standardised, and handle parameters and variants?  The only
problem is that they're variable-length, but that shouldn't be a major problem,
especially since the current format doesn't handle algorithm parameters and
will need some sort of major change to support this anyway.
 
Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: DSS lengths
Reply-To: [email-masked]
Date: Fri, 5 Dec 1997 14:46:37 (NZDT)
Sender: [email-masked]

>[DSA 1Kbit limit]
>I've tried in OP-FORMAT not to talk about this -- I don't want to limit an
>implementation to 1024 bits, nor to mandate how to get a larger hash value.
>Is there something I need to change in the spec?
 
It would be a good idea to at least warn people about this, because without it
people will (a) use keys > 1K bits thinking they're getting extra security, or
(b) try to cobble together their own hash functions to get > 160 bits output.
It's probably worth a note in the "Security Considerations" section to say that
people shouldn't do this.
 
Peter.

Date: Thu, 4 Dec 1997 15:23:11 -0800 (PST)
From: Hal <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: new algorithm identifier of the symmetric cryptosystem.
Cc: [email-masked]
Sender: [email-masked]

One problem we have (which was discussed a while back on this list) is
that our algorithm identifiers have no provision for variants.  With IDEA
this was not a problem as there was only one IDEA.  3DES is pretty well
standardized on the version we use (EDE).  CAST is technically a design
procedure rather than a cipher, and what we call CAST is properly known
as CAST5-128, with several other variations possible.

The newer ciphers we are reserving alg identifiers for also have this
problem.  In the case of Blowfish, it can support any key size up to
some maximum.  I think 128 bit keys may be a common implementation.
GOST does not specify the S-boxes so there will be variations on that,
similar to CAST.

AES is planned to support a few different key and block sizes so there will
be at least two or three variations on that one.

I'm not sure it makes sense to reserve single algorithm identifiers for
these ciphers.  Maybe we should just do it as they are implemented.
When someone implements Blowfish with a 128 bit key they get an algorithm
ID for that.  If someone else wants to implement a 256 bit key they get a
new identifier.  There is probably not a need for a huge spectrum of
variations on any of these functions.

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

Date: Thu, 04 Dec 1997 13:54:24 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: DSS lengths
Cc: [email-masked]
Sender: [email-masked]

As Peter said, to make a DSA implementation greater than 1024 bits, you
need a hash that is bigger that 160 bits. Also as Peter noted, we've been
investigating how to do this. We plan on getting larger hashes and thus
longer DSA keys.

I've tried in OP-FORMAT not to talk about this -- I don't want to limit an
implementation to 1024 bits, nor to mandate how to get a larger hash value.
Is there something I need to change in the spec?

	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: [email-masked]
Date: Thu, 04 Dec 1997 13:35:00 -0800
To: "William H. Geiger III" <[email-masked]>
Original-From: Bill Stewart <[email-masked]>
Subject: Re: Speculative Mode for KeyIDs of all zeroes
Cc: [email-masked]
Sender: [email-masked]

At 04:22 AM 12/04/1997 -0600, William H. Geiger III wrote:
>I believe that there is a program PGP Stealth that works well for striping
>this information from PGP messages before Stego is applied.
>
>We had a rather lengthy discussion on Stego techniques on #pgp the other
>day. I have primarily playing with the bit hiding and haven't looked too
>much at the PGP header striping. I imagine that if a PGP implementation
>could not handle a "striped" PGP message that the Stego preprocessor could
>"fix" the encrypted message before passing it to PGP.

This isn't a spelling flame, but you're ambiguous here - do you mean
- "Stripping" - taking out unnecessary stuff, or
- "Striping" - spreading information out in thin stripes, similarly
	to striped file systems spread across disk drives
?

But yes, using an all-zero KeyID as a speculative mode would
fit in very well with a stealth preprocessor, which can
use whatever values it wants in the field when stealthed,
and then replace with 0s when destealthing if it doesn't
have a better alternative.

On the other hand, if OPGP does support the 0s mode,
it'll have to successively try each secret key it has
until it either finds one that works or finds that
none of them work; an alternative is to have an external
preprocessor program that drives it, by trying each KeyID in succession.
This requires that the driver know what KeyIDs are available
(either reading directly from the keyring or 
just from a list), and that the OPGP implementation
have some easily-parsed response that lets the driver
decide whether or not the decryption worked.

Another option is to only check the "default" key,
though default key really an artifact of the user interface
rather than something OPGP needs to know about.

Internal support is more efficient, but non-critical,
so I'd recommend against making it a MUST, but it'd be
nice to have it as a SHOULD.  
				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Thu, 04 Dec 1997 14:04:56 -0800
To: Hironobu Suzuki <[email-masked]>, Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: new algorithm identifier of the symmetric cryptosystem. 
Cc: [email-masked]
Sender: [email-masked]

At 03:20 PM 12/4/97 +0900, Hironobu Suzuki wrote:
   
    I wrote the GOST/BLOWFISH with PGP as prototype and testing version,
   not to open it to the public. But I need to distribute to someone who
   criticize my idea or my source codes. Sometime, both things contradict
   each other. If ID #4 and #5 are already assinged for other algorithms,
   it makes a trouble and a confusion for PGP community. I hope to avoid
   this situation.

Your previous message said that your implementation of GOST and Blowfish
was a kind of a joke, so I didn't know if you were requesting a constant or
not.

Presently, the OP-FORMAT spec defines 4 for Blowfish. I'll reserve one for
GOST.
   
   Few years later, someone will hack AES (Advanced Encryption Standard)
   into PGP. I think several people will hack it at the same time. Who
   does allocate/control id number of AES?
   
You're correct, it makes sense to reserve a constant for the AES now. Thank
you for the suggestion.

	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: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Comments on draft - Long.
Cc: [email-masked]
Reply-To: [email-masked]
Date: Fri, 5 Dec 1997 08:56:41 (NZDT)
Sender: [email-masked]

"William H. Geiger III" <[email-masked]> writes:
>In <[email-masked]>, on 12/04/97 
>   at 10:50 AM, [email-masked] (Peter Gutmann) said:
>>>DSS/DSA is only specified for key lengths between 512 and 1024, but OpenPGP 
>>>should be free to do longer keys, even though the standard doesn't actually 
>>>support them.
>>There's no point in moving to p > 1K bits if q is only 160 bits because
>>it'll  be vulnerable to a small-exponent attack.  Since q is governed by
>>the hash  function associated with DSA, you then need to define a new
>>hash function with  a larger output block size, and suddenly things get
>>very messy.  At the moment  I don't think it's sensible to use keys > 1K
>>bits, all it'll do is lead to  confusion about the amount of security
>>offered.
>I am not that well versed on DSA but what is involved in increasing p if a 
>corresponding q can be supplied? 
>
>Will a p of 2048 work with a corresponding q of 320?
 
Here's a table of p vs q (generated by Colin Plumb).
 
/* Once the DSA p goes above 1024 bits, we need to increase q correspondingly
   to provide equivalent security from small-exponent attacks.  The following
   information for doing this was provided by Colin Plumb.
 
   This is based on a paper by Michael Wiener on    | The function defined
   the difficulty of the two attacks, which has     | below (not part of the
   the following table:                             | original paper)
                                                    | produces the following
     Table 1: Subgroup Sizes to Match Field Sizes   | results:
    
    Size of p       Cost of each attack          Size of q       
     (bits)         (instructions or              (bits)          
                     modular multiplies)                            

       512              9 x 10^17                   119                     
       768              6 x 10^21                   145                     
      1024              7 x 10^24                   165                     
      1280              3 x 10^27                   183                     
      1536              7 x 10^29                   198                     
      1792              9 x 10^31                   212                     
      2048              8 x 10^33                   225                     
      2304              5 x 10^35                   237                     
      2560              3 x 10^37                   249                     
      2816              1 x 10^39                   259                     
      3072              3 x 10^40                   269                     
      3328              8 x 10^41                   279                     
      3584              2 x 10^43                   288                     
      3840              4 x 10^44                   296                     
      4096              7 x 10^45                   305                     
      4352              1 x 10^47                   313                     
      4608              2 x 10^48                   320                     
      4864              2 x 10^49                   328                     
      5120              3 x 10^50                   335 */ 
 
As you can see, you'd need a hash of >300 bits for keys of up to 4096 bits, so 
in theory you could use some double-width variant of SHA for keys > 1K bits.  
I remember someone from PGP Inc asking about wide hashes about a year ago on 
some mailing list, so it looks like PGP Inc have already considered (and 
rejected) something like this in the past.
 
Peter.

Date: Thu, 04 Dec 1997 10:57:28 -0800
To: [email-masked], Ian Brown <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: OP and pgp5.0i: some problems
Cc: IETF OpenPGP <[email-masked]>
Sender: [email-masked]

At 09:22 PM 12/4/97 +0400, Maksim Otstavnov wrote:

   Besides, it has nothing to do with PGP/MIME. PGP/MIME is a separate 
   question currentely not discussed by this WG according to its agenda. 
   (right?).

No, PGP/MIME (a.k.a. OP-MIME, or RFC 2015) is covered by this working group.
   
   The OP is to obsolete rfc1991, not 2015, right? Ascii-armor is 
   currently defined in 1991, not 2015. So I just wish OP rfc to contain 
   both a concept of "8-bit text" and definition of actions order for 
   plugins/glues producing _non-PGP/MIME_ messages. Just so little ;)

This working group has two things under its charter (presently) -- the
OP-FORMAT document and RFC 2015. So each are relevant, we just have two
documents.

	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)

Comments: Authenticated sender is <[email-masked]>
From: "Maksim Otstavnov" <[email-masked]>
Organization: home office
To: Ian Brown <[email-masked]>
Date: Thu, 4 Dec 1997 21:22:10 +0400
Subject: Re: OP and pgp5.0i: some problems
Reply-to: [email-masked]
CC: IETF OpenPGP <[email-masked]>
Sender: [email-masked]

on Thu, 04 Dec 1997 15:35:38 +0000 Ian Brown quoted Maksim Otstavnov 
and wrote:
> > Currently, PGP/MIME (RFC2015) allows only 7-bit content.
> 
> You said you wanted:
> >Content-Type: text/plain; charset=KOI8-R
> >Content-Transfer-Encoding: 8bit
> 
> Content-Transfer-Encoding could be base64 just as easily. PGP/MIME would
> then sign that encoded data.

Yes it works in most 2.6-compatible mailers. I'd like to have 
abovequouted format as an option, though, for the advantage of 
legibility.

Besides, it has nothing to do with PGP/MIME. PGP/MIME is a separate 
question currentely not discussed by this WG according to its agenda. 
(right?).

The OP is to obsolete rfc1991, not 2015, right? Ascii-armor is 
currently defined in 1991, not 2015. So I just wish OP rfc to contain 
both a concept of "8-bit text" and definition of actions order for 
plugins/glues producing _non-PGP/MIME_ messages. Just so little ;)

> > There are 2 questions:
> > 1) do plugins in existence support the operation?
> > 2) Should it be documented in OP or in a separate document?
> 
> MIME-compatible mailers will do the encoding.

Which encoding: base64 or 8-bit or both?

thanks,
--
-- Maksim Otstavnov <[email-masked]> http://www.geocities.com/SoHo/Studios/1059/
--   -maintainer of The Russian PGP HomePage
--     (http://www.geocities.com/SoHo/Studios/1059/pgp-ru.html)
--   -moderator of "Security&Privacy" (Russian language) Web-forum
--     (http://www.rocit.ru/forum)

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Comments on draft - Long.
Date: 4 Dec 1997 16:19:56 GMT
Organization: IKS GmbH Jena
Lines: 6
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Hal Finney wrote:
>No, the length is meant to be one byte.  However counted strings are no
>longer used in the document proper, and so they could probably go away.

Pathnames are stored in that way. (at least)

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: OP and pgp5.0i: some problems
Date: 4 Dec 1997 16:11:30 GMT
Organization: IKS GmbH Jena
Lines: 18
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Hal Finney wrote:
>I don't know much about the charset stuff.  Does it just affect how
>the signature is calculated, or does it actually affect how the data
>is decoded out of a literal packet?

Yes. In cleartext signed messages the conversation is done before hashing.

>> (2) "charset" setting is somewhat misleading. For instance, when I
>> sign a 8-bit text content of Windows clipboard, it is usually
>> meaningful in Windows native coding (the so called Windows-cpXXXX, is

It is a subset of Unicode not a special charset.

>I hope not.  Can't we just leave the messages alone?  Trying to translate
>an 8-bit Cyrillic document into 7-bit printable US-ASCII sounds like a
>nightmare.

Exactly that's what RfC 2015 is for.

Date: Thu, 04 Dec 1997 15:35:38 +0000
From: Ian Brown <[email-masked]>
To: [email-masked]
CC: IETF OpenPGP <[email-masked]>
Subject: Re: OP and pgp5.0i: some problems
Sender: [email-masked]

> Currently, PGP/MIME (RFC2015) allows only 7-bit content.

You said you wanted:

>Content-Type: text/plain; charset=KOI8-R
>Content-Transfer-Encoding: 8bit

Content-Transfer-Encoding could be base64 just as easily. PGP/MIME would
then sign that encoded data.

> There are 2 questions:
> 1) do plugins in existence support the operation?
> 2) Should it be documented in OP or in a separate document?

MIME-compatible mailers will do the encoding.

Ian.

Date: Thu, 4 Dec 1997 05:44:31 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Discrete log signature key sizes
Sender: [email-masked]

Peter Gutmann, [email-masked], writes:
> >Bill Stewart <[email-masked]> writes:
> >At 10:50 AM 12/04/1997, Peter Gutmann wrote:
> >>>DSS/DSA is only specified for key lengths between 512 and 1024, but OpenPGP 
> >>>should be free to do longer keys, even though the standard doesn't actually 
> >>>support them.
> >>There's no point in moving to p > 1K bits if q is only 160 bits because it'll
> >>be vulnerable to a small-exponent attack.  Since q is governed by the hash 
> >>function associated with DSA, you then need to define a new hash function wit
> >>a larger output block size, and suddenly things get very messy.  At the momen
> >>I don't think it's sensible to use keys > 1K bits, all it'll do is lead to 
> >>confusion about the amount of security offered.
> >Also, as I look at PGP key generation again, it does limit the DSA keys to 
> >1024 bits, even when you're doing longer ElGamal. Doesn't necessarily have to 
> >do that, but I didn't find a way to input different behaviour.
>  
> To get around this, you could use Elgamal for signatures (although the current 
> PGP doesn't support this, the code is commented out).  I published an Elgamal 
> profile for X.509 a few months ago (available from RFC draft repositories) 
> which specifies how to do this and covers various security issues.

It's still questionable to go to longer key sizes even with ElGamal.
A birthday attack against the hash function has the same work factor as
breaking a 1024 discrete log, approximately (which is why DSS used the
160 bit / 1024 bit structure).  Now for some apps a birthday attack is not
good enough, you need to duplicate the hash, which takes the square of
the effort, and for them using a longer key could work.  But for general
use there is no point in increasing key size until you have a larger hash.

Anybody have a good way to synthesize a 320 bit hash out of a 160 bit one?
I found a paper which suggested doing a "butterfly" using 8 instances of
the smaller hash which looked pretty good (Eurocrypt 96, Aiello).

Hal

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 04 Dec 97 07:17:33 -0600
To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked]
Subject: Re: Comments on draft - Long.
Sender: [email-masked]

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

In <[email-masked]>, on 12/04/97 
   at 10:50 AM, [email-masked] (Peter Gutmann) said:

>>DSS/DSA is only specified for key lengths between 512 and 1024, but OpenPGP 
>>should be free to do longer keys, even though the standard doesn't actually 
>>support them.
> 
>There's no point in moving to p > 1K bits if q is only 160 bits because
>it'll  be vulnerable to a small-exponent attack.  Since q is governed by
>the hash  function associated with DSA, you then need to define a new
>hash function with  a larger output block size, and suddenly things get
>very messy.  At the moment  I don't think it's sensible to use keys > 1K
>bits, all it'll do is lead to  confusion about the amount of security
>offered.
> 

I am not that well versed on DSA but what is involved in increasing p if a
corresponding q can be supplied? 

Will a p of 2048 work with a corresponding q of 320?

Does q need to be the entire Hash or can it be only part of it? Say you
have a p of 512 and a 160 hash does one use only 80 bits of the 160 hash
and discard the rest?

The lines I am thinking along are as follows:

You desire a key of size p which requires a certain q. You have a hash
which is a fraction of q. Rather than generating 1 hash of the message you
evenly divide the message into parts and create a hash for each part then
concatenate the hashes to provide the required q for the size p key you
wish to work with.

If there is a gaping flaw in the logic here please be gentle with the
flames as I have been up all night working. :)

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Comments: Authenticated sender is <[email-masked]>
From: "Maksim Otstavnov" <[email-masked]>
Organization: home office
To: Ian Brown <[email-masked]>
Date: Thu, 4 Dec 1997 16:09:05 +0400
Subject: Re: OP and pgp5.0i: some problems
Reply-to: [email-masked]
CC: IETF OpenPGP <[email-masked]>
Sender: [email-masked]

From:                 Self <maksim>
To:               Ian Brown <[email-masked]>
Subject:          Re: OP and pgp5.0i: some problems
Copies to:        IETF OpenPGP <[email-masked]>
Send reply to:    [email-masked]
Date sent:        Thu, 4 Dec 1997 15:50:34 +0400

on Thu, 04 Dec 1997 10:22:43  Ian Brown quoted Maksim Otstavnov and
wrote: > > It would be nice but Windows or Mac native Cyrillic
codepages will > > look gibberish to each other. (Of course there are
tools to read > > cp1251 on Mac or Unix, but we aim at Mr Common
User). Normalization to > > KOI8 is currently the only safe way to
achive cross-platform legibility > > (even MS mailers learned to
understand koi8 nowadays). >  > PGP/MIME would be perfect for this. A
MIME encoding of your message > would be signed rather than the
message itself.

Currently, PGP/MIME (RFC2015) allows only 7-bit content. The perfect 
solution would be to have an option of 8-bit MIME

(eg
>Content-Type: text/plain; charset=KOI8-R
>Content-Transfer-Encoding: 8bit
for Russian)

containing clearsigned message.

There are 2 questions:

1) do plugins in existence support the operation?
(of course I would just test it, but it requires installing rather
huge MS Outlook and _warez_ Eudora plugin, the latter not included in
5.0i kit).

2) Should it be documented in OP or in a separate document?

I'd welcome comments from plugins developers.
--
-- Maksim Otstavnov <[email-masked]> http://www.geocities.com/SoHo/Studios/1059/
--   -maintainer of The Russian PGP HomePage
--     (http://www.geocities.com/SoHo/Studios/1059/pgp-ru.html)
--   -moderator of "Security&Privacy" (Russian language) Web-forum
--     (http://www.rocit.ru/forum)

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Comments on draft - Long.
Cc: [email-masked]
Reply-To: [email-masked]
Date: Thu, 4 Dec 1997 23:59:14 (NZDT)
Sender: [email-masked]

>Bill Stewart <[email-masked]> writes:
>At 10:50 AM 12/04/1997, Peter Gutmann wrote:
>>>DSS/DSA is only specified for key lengths between 512 and 1024, but OpenPGP 
>>>should be free to do longer keys, even though the standard doesn't actually 
>>>support them.
>>There's no point in moving to p > 1K bits if q is only 160 bits because it'll
>>be vulnerable to a small-exponent attack.  Since q is governed by the hash 
>>function associated with DSA, you then need to define a new hash function wit
>>a larger output block size, and suddenly things get very messy.  At the momen
>>I don't think it's sensible to use keys > 1K bits, all it'll do is lead to 
>>confusion about the amount of security offered.
>Also, as I look at PGP key generation again, it does limit the DSA keys to 
>1024 bits, even when you're doing longer ElGamal. Doesn't necessarily have to 
>do that, but I didn't find a way to input different behaviour.
 
To get around this, you could use Elgamal for signatures (although the current 
PGP doesn't support this, the code is commented out).  I published an Elgamal 
profile for X.509 a few months ago (available from RFC draft repositories) 
which specifies how to do this and covers various security issues.
 
Peter.

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 04 Dec 97 04:22:03 -0600
To: Black Unicorn <[email-masked]>
Cc: Jonathan Wienke <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Speculative Mode for KeyIDs of all zeroes
Sender: [email-masked]

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

In <[email-masked]>, on 12/04/97 
   at 03:12 AM, Black Unicorn <[email-masked]> said:

>At 11:20 PM 12/3/97 -0800, you wrote:

>>If
>>you are worried about being tortured, the best defense is for Big Brother
>>to be unable to verify the existence of a PGP message at all.  Some stego
>>programs already kludge this by removing various message headers, but I
>>don't have references to the techniques handy.  I would like to see some
>>kind of "stealth message" format defined, where the first N bits of the
>>message (N corresponding to the length of the asymmetric key you are using
>>to speculatively decrypt) contain the session key, signature keyid, message
>>length, symmetric algorithm ID, hash algorithm ID, random padding, and
>>other such details so that if you stego a .WAV file, the only way to tell
>>is to collect the first 2048 sample LSBits and try decrypting them with
>>your private key(s) to see if a message header shows up.  Otherwise, all
>>you see is random-looking data that may or may not be a PGP message.

>Even more substantial kudos.

I believe that there is a program PGP Stealth that works well for striping
this information from PGP messages before Stego is applied.

We had a rather lengthy discussion on Stego techniques on #pgp the other
day. I have primarily playing with the bit hiding and haven't looked too
much at the PGP header striping. I imagine that if a PGP implementation
could not handle a "striped" PGP message that the Stego preprocessor could
"fix" the encrypted message before passing it to PGP.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Thu, 4 Dec 1997 11:08:36 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Fingerprints once again...
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--ZPt4rx8FFjLCG7dd
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

The draft's description of V4 fingerprints contains some
traps for implementors, e.g., it is _not_ clear that the
Packet Tag for subkeys has to be changed to a Public Key
Packet Tag.  Thus, I'd like to propose the attached
change to the draft.

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
   1280/593238E1 · AE 24 38 88 1B 45 E4 C6  03 F5 15 6E 9C CA FD DB

--ZPt4rx8FFjLCG7dd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=draft-diff

--- draft-ietf-openpgp-formats-00.txt.orig	Thu Dec  4 10:55:35 1997
+++ draft-ietf-openpgp-formats-00.txt	Thu Dec  4 11:06:14 1997
@@ -2145,11 +2145,15 @@
 
 8.2 V4 Key IDs and Fingerprints
 
-A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet Tag,
-followed by the two-octet packet length, followed by the entire Public
-Key packet starting with the version field.  The key ID is either the
-low order 32 bits or 64 bits of the fingerprint.  Here are the fields
-of the hash material, with the example of a DSA key:
+A V4 fingerprint is the 160-bit SHA-1 hash of a valid old-style public
+key packet containing the public key in question.  This packet consists
+of the public key packet tag, followed by a two-octet packet length
+field, followed by the entire Public Key material starting with the
+version field.  Note that the packet used for fingerprint generation will
+always be denoted as a Public Key Packet (content tag 6), but never as a
+Subkey Packet (content tag 14). The key ID is either the low order 32
+bits or 64 bits of the fingerprint. Here are the fields of the hash
+material, with the example of a DSA key:
 
     a.1) 0x99 (1 byte)
     a.2) high order length byte of (b)-(f) (1 byte)

--ZPt4rx8FFjLCG7dd--

Date: Thu, 04 Dec 1997 10:22:43 +0000
From: Ian Brown <[email-masked]>
To: [email-masked]
CC: IETF OpenPGP <[email-masked]>
Subject: Re: OP and pgp5.0i: some problems
Sender: [email-masked]

> It would be nice but Windows or Mac native Cyrillic codepages will
> look gibberish to each other. (Of course there are tools to read
> cp1251 on Mac or Unix, but we aim at Mr Common User). Normalization to
> KOI8 is currently the only safe way to achive cross-platform
> legibility (even MS mailers learned to understand koi8 nowadays).
 
PGP/MIME would be perfect for this. A MIME encoding of your message
would be signed rather than the message itself.

Ian :D

Date: Thu, 04 Dec 1997 01:55:23 -0800
To: [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: Comments on draft - Long.
Cc: [email-masked]
Sender: [email-masked]

At 10:50 AM 12/04/1997, Peter Gutmann wrote:
>>DSS/DSA is only specified for key lengths between 512 and 1024, but OpenPGP 
>>should be free to do longer keys, even though the standard doesn't actually 
>>support them.
> 
>There's no point in moving to p > 1K bits if q is only 160 bits because it'll 
>be vulnerable to a small-exponent attack.  Since q is governed by the hash 
>function associated with DSA, you then need to define a new hash function with 
>a larger output block size, and suddenly things get very messy.  At the moment 
>I don't think it's sensible to use keys > 1K bits, all it'll do is lead to 
>confusion about the amount of security offered.

Also, as I look at PGP key generation again, it does limit the
DSA keys to 1024 bits, even when you're doing longer ElGamal.
Doesn't necessarily have to do that, but I didn't find a way to
input different behaviour.
				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Thu, 04 Dec 1997 02:12:39 -0600
To: Jonathan Wienke <[email-masked]>
From: Black Unicorn <[email-masked]>
Subject: Re: Speculative Mode for KeyIDs of all zeroes
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 11:20 PM 12/3/97 -0800, you wrote:

>If
>you are worried about being tortured, the best defense is for Big Brother
>to be unable to verify the existence of a PGP message at all.  Some stego
>programs already kludge this by removing various message headers, but I
>don't have references to the techniques handy.  I would like to see some
>kind of "stealth message" format defined, where the first N bits of the
>message (N corresponding to the length of the asymmetric key you are using
>to speculatively decrypt) contain the session key, signature keyid, message
>length, symmetric algorithm ID, hash algorithm ID, random padding, and
>other such details so that if you stego a .WAV file, the only way to tell
>is to collect the first 2048 sample LSBits and try decrypting them with
>your private key(s) to see if a message header shows up.  Otherwise, all
>you see is random-looking data that may or may not be a PGP message.

Even more substantial kudos.

Date: Wed, 03 Dec 1997 23:20:05 -0800
To: Ian Grigg <[email-masked]>, Hal Finney <[email-masked]>
From: Jonathan Wienke <[email-masked]>
Subject: Re: Speculative Mode for KeyIDs of all zeroes
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 08:29 PM 12/3/97 +0000, Ian Grigg wrote:

>"An implementation MAY interpret a KeyID of all zeroes to mean that all
>keys available should be used to decrypt the message speculatively." 
>or  some such.
>
>I don't think adding any extra features will work for the intended
>audience.  For reasons that I won't go into now, I don't think any users
>who really need the speculative mode will be using anything but pgp2.6
>(the C version, not any compatibility suite like Cryptix).  The rest of
>us might like to implement it for fun.

For "deniable steganography" applications, such as hiding a PGP message in
the background noise in TIFF images or .WAV files, the KeyID field should
be able to go away entirely, causing the speculative decryption mode.  If
you are worried about being tortured, the best defense is for Big Brother
to be unable to verify the existence of a PGP message at all.  Some stego
programs already kludge this by removing various message headers, but I
don't have references to the techniques handy.  I would like to see some
kind of "stealth message" format defined, where the first N bits of the
message (N corresponding to the length of the asymmetric key you are using
to speculatively decrypt) contain the session key, signature keyid, message
length, symmetric algorithm ID, hash algorithm ID, random padding, and
other such details so that if you stego a .WAV file, the only way to tell
is to collect the first 2048 sample LSBits and try decrypting them with
your private key(s) to see if a message header shows up.  Otherwise, all
you see is random-looking data that may or may not be a PGP message.

Most people have a fairly small number of private keys, so doing
speculative decryption in this manner shouldn't be too computationally
expensive, especially if the user can specify the order in which the keys
are tried.

To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: new algorithm identifier of the symmetric cryptosystem. 
Date: Thu, 04 Dec 1997 15:20:33 +0900
From: Hironobu Suzuki <[email-masked]>
Sender: [email-masked]

I don't know this topic is a good for IETF mailing list.  If someone
knows a good ML(s) for this topic, please let me know about it.

Jon Callas <[email-masked]> said:
> Does mean you want me to put in an algorithim identifier for GOST,
> or not?

 I wrote the GOST/BLOWFISH with PGP as prototype and testing version,
not to open it to the public. But I need to distribute to someone who
criticize my idea or my source codes. Sometime, both things contradict
each other. If ID #4 and #5 are already assinged for other algorithms,
it makes a trouble and a confusion for PGP community. I hope to avoid
this situation.

I hope to use id numbers which nobody complains me :-).  Even if id
number should be #11 or #101 or #1001, it's OK.

Ian Grigg <[email-masked]> said: 

> Until the full paramaters are known (S Boxes, etc, as mentioned by
> Bill), perhaps a provisional number could be allocated pending an
> RFC for GOST/PGP, that includes the relevant detail.

This suggestion is better than what I thought. Thanks Mr. Grigg.

Provisional number:

	GOST/PGP -- #4
	BLOWFISH/PGP -- #5

It's sounds good :-)

Few years later, someone will hack AES (Advanced Encryption Standard)
into PGP. I think several people will hack it at the same time. Who
does allocate/control id number of AES?

HAPPY HACKING!

-- 
Hironobu SUZUKI        Independent Software Consultant
E-Mail: [email-masked]
URL://www.pp.iij4u.or.jp/~h2np

Date: Wed, 03 Dec 1997 23:10:06 -0600
To: Ian Grigg <[email-masked]>, Hal Finney <[email-masked]>
From: Black Unicorn <[email-masked]>
Subject: Re: Speculative Mode for KeyIDs of all zeroes
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 08:29 PM 12/3/97 +0000, Ian Grigg wrote:

>I agree with this.  This would be a MAY, would it not?
>
>"An implementation MAY interpret a KeyID of all zeroes to mean that all
>keys available should be used to decrypt the message speculatively." 
>or  some such.
>
>I don't think adding any extra features will work for the intended
>audience.  For reasons that I won't go into now, I don't think any users
>who really need the speculative mode will be using anything but pgp2.6
>(the C version, not any compatibility suite like Cryptix).  The rest of
>us might like to implement it for fun.

Outstanding.

Kudos.

Date: Wed, 3 Dec 1997 21:43:37 -0500 (EST)
From: Ryan Anderson <[email-masked]>
To: [email-masked]
Subject: Re: expedience, consensus and editing
Sender: [email-masked]

On 27 Nov 1997, Lutz Donnerhacke wrote:

> >2) MIME as MAY/SHOULD/MUST?
> 
> Has nothing to do with OpenPGP. OpenPGP deals with the application layer not
> with the presentation layer MIME is for. Same goes for Ascii Armor.

The WG charter specifically mentions MIME, and I thought we were working
on an e-mail spec.  From that point of view, future impementations are
going to need to interoperate with MIME.  

So I'd definitely say MUST for MIME (for e-mail applications) and SHOULD
for Armor (to be reduced to MAY in v2).

> >3) 32 bit int clean up shelved for OpenPGPv2, or discussed now
> 
> 32bit is an unnecessary restriction. (640k are enough for everybody!)

It's an increase from the current hacked bit format, from what's been
posted here.  Shelved for v2 is my vote.

> >4) CMR/ARR and alternatives worked through now or shelved for OpenPGPv2,
> 
> Drop it completely but mark the subsignature ID as in use.

It must be mentioned for proper handling of the critical bit.  Mark it as
used for a proprietary (PGP Inc.) signature addition that can be ignored
if not supported.

Ryan Anderson - Alpha Geek
PGP fp: 7E 8E C6 54 96 AC D9 57  E4 F8 AE 9C 10 7E 78 C9
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: Thu, 04 Dec 1997 00:18:16 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Jon Callas <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: new algorithm identifier of the symmetric cryptosystem.
Sender: [email-masked]

> At 01:37 PM 12/3/97 +0900, Hironobu Suzuki wrote:
> 
>    I'd like to know who is control the algorithm identifier of the
>    symmetric cryptosystem.

Jon Callas wrote:
> Does mean you want me to put in an algorithim identifier for GOST, or not?

Until the full paramaters are known (S Boxes, etc, as mentioned by
Bill), perhaps a provisional number could be allocated pending an RFC
for GOST/PGP, that includes the relevant detail.
-- 
iang                                      systemics.com

FP: 1189 4417 F202 5DBD  5DF3 4FCD 3685 FDDE on pgp.com

Date: Thu, 04 Dec 1997 00:37:10 +0000
To: [email-masked]
From: Graham Klyne <[email-masked]>
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Cc: Gunther Schadow <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 15:54 30/11/97 -0800, David Sternlight wrote:

>[...] For instance it is
>mutually exclusive to allow anyone to be a signer and to allow only those
>meeting certain standards to be signers.

Leaving aside, for the moment, any reference to any particular system:  is
this necessarily true?

I can imagine a system in which the signature itself may carry an
authority.  So those signers meeting certain standards may supply a
credential (as part of the signature) which is verifiable using a public
key of the body which set those standards.

But as a non-expert in this field, I may be missing something.

GK.
---

------------
Graham Klyne

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Comments on draft - Long.
Cc: [email-masked]
Reply-To: [email-masked]
Date: Thu, 4 Dec 1997 10:50:28 (NZDT)
Sender: [email-masked]

>DSS/DSA is only specified for key lengths between 512 and 1024, but OpenPGP 
>should be free to do longer keys, even though the standard doesn't actually 
>support them.
 
There's no point in moving to p > 1K bits if q is only 160 bits because it'll 
be vulnerable to a small-exponent attack.  Since q is governed by the hash 
function associated with DSA, you then need to define a new hash function with 
a larger output block size, and suddenly things get very messy.  At the moment 
I don't think it's sensible to use keys > 1K bits, all it'll do is lead to 
confusion about the amount of security offered.
 
Peter.

Comments: Authenticated sender is <[email-masked]>
From: "Maksim Otstavnov" <[email-masked]>
Organization: home office
To: Hal Finney <[email-masked]>, [email-masked]
Date: Wed, 3 Dec 1997 23:49:08 +0400
Subject: Re: OP and pgp5.0i: some problems
Reply-to: [email-masked]
Sender: [email-masked]

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

on   Wed, 3 Dec 1997 10:33:45 -0800  Hal Finney quoted Maksim 
Otstavnov and wrote:

> > "Charset" header needs defining. Values defined in 2.6.xi need
> > enlisting. A mechanism for charsets registration, or embracing
> > charsets otherwise registered needs defining.
> 
> I don't know much about the charset stuff.  Does it just affect how
> the signature is calculated, or does it actually affect how the data
> is decoded out of a literal packet?

since it is undefined, nobody knows :( 
Probably the question should be sent to Colin Plumb?

> There are really two questions the signature software needs to know.
> Is the input to be clearsigned vs binary signed, and should the
output
> be in text form.  In 5.0 these were combined into one checkbox, but
> logically there is another possibility, a binary signed file which
is
> ascii armored for output.

Yes.

> 
> > 2.2 Problems with clearsigning
> >
> > There are still problems however.
> >
> > (1) 8-bit clearsigning is not described anywhere (I presume). I
> > strongly believe it needs defining at least as "SHOULD" in OP.
> 
> How does this differ from the clearsigning description in the draft?

The draft reads: ..."textual octet stream"... [2.6] West of 
Koenigsberg the phrase will most probably be read as "plain vanilla
7-bit ascii". Am I wrong?

> > (3) If sending MUA is to perform any other (not cryptographic)
> > 8-bit-to-8-bit or 8-bit-to-7-bit transmutation of a msg, the MUA
must
> > first do this transmutation, then sign the message, and a
receiving
> > MUA must first check signature, then perform any other
transmutations.
> > Right? 
> 
> I hope not.  Can't we just leave the messages alone?  

It would be nice but Windows or Mac native Cyrillic codepages will
look gibberish to each other. (Of course there are tools to read
cp1251 on Mac or Unix, but we aim at Mr Common User). Normalization to
KOI8 is currently the only safe way to achive cross-platform
legibility (even MS mailers learned to understand koi8 nowadays).

>Trying to translate
> an 8-bit Cyrillic document into 7-bit printable US-ASCII sounds like
a
> nightmare.

Yes. Unfortunately some older SMTP server truncate or bounce 8-bit
msgs (is it obsoleted by any document?), so sometimes 7-bitization is
needed.

> Sorry can't be more help, this is not an area I know much about.

Thank you anyway Hal. I hope MUA plugins developers will keep up the
thread.

--
-- Maksim Otstavnov <[email-masked]> http://www.geocities.com/SoHo/Studios/1059/
--   -maintainer of The Russian PGP HomePage
--     (http://www.geocities.com/SoHo/Studios/1059/pgp-ru.html)
--   -moderator of "Security&Privacy" (Russian language) Web-forum
--     (http://www.rocit.ru/forum)

Date: Wed, 03 Dec 1997 20:29:36 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Hal Finney <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Speculative Mode for KeyIDs of all zeroes
Sender: [email-masked]

Hal Finney wrote:
> 
> Thanks to Bill Stewart for some very helpful comments....

> > 5.1 Encrypted Session Key Packet - Traffic Analysis Risk -
> > The KeyID field, as defined, leads to a major traffic analysis risk,
> > but the format doesn't depend critically on the value in the field.
> > At a previous Bay Area Cypherpunks meeting, somebody from PGP
> > mentioned a request from some freedom fighter users that KeyIDs
> > be shorter, because the current tyrannical government was
> > using them to identify who to torture into decrypting messages -
> > having PGP was incriminating enough, but with short KeyIDs,
> > e.g. 0-3 or 0-16, it's possible to reduce decryption workload
> > without indentifying the user of the message.
> 
> I raised this possibility on the list a few weeks ago, but the only
> response was negative (I think because it would break the way the
> keyids were being used as indexes).

If you have that sort of risk, then *any* clues can be used to
incriminate you.  2 bits is  enough for torture purposes, in my
admittedly limited experience of the art.

> > Some obvious alternative implementations are to keep the field
> > for compatibility, while specifying that the
> > - - the receiver of a message MAY attempt decryption regardless
> >       of the value in the field, regardless of whether
> >       it's intended for him or not.
> > - - the sender must output a value in the field that
> > - -- SHOULD be the KeyID, but
> > - -- MAY be all-0, for which the receiver SHOULD/MAY decrypt
...
> Interesting possibilities.  Jon Callas also suggested (internally) the
> idea of putting all zeros into the keyid field to mean that the receiver
> should try all his keys.

This is a good idea.  All zeroes, and when confined to small groups who
all know what is going on, and have the software that understands this,
would work well.

> > Since this just requires permission in the spec, rather than
> > needing specific implementation, and since the main negative impact
> > on non-implementing users is attempting to decrypt
> > an occasional message that wasn't intended for them that they
> > happened to receive, I'd like to ask that it be included.

I agree with this.  This would be a MAY, would it not?

"An implementation MAY interpret a KeyID of all zeroes to mean that all
keys available should be used to decrypt the message speculatively." 
or  some such.

I don't think adding any extra features will work for the intended
audience.  For reasons that I won't go into now, I don't think any users
who really need the speculative mode will be using anything but pgp2.6
(the C version, not any compatibility suite like Cryptix).  The rest of
us might like to implement it for fun.

-- 
iang                                      systemics.com

FP: 1189 4417 F202 5DBD  5DF3 4FCD 3685 FDDE on pgp.com

Date: Wed, 03 Dec 1997 12:20:56 -0800
To: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: new algorithm identifier of the symmetric cryptosystem.
Sender: [email-masked]

At 01:37 PM 12/3/97 +0900, Hironobu Suzuki wrote:
   
   I'd like to know who is control the algorithm identifier of the
   symmetric cryptosystem.
   
   I hacked GOST and BLOWFISH into PGP but still buggy. The algorithm
   identifier of GOST as FOUR(#4) and BLOWFISH as FIVE(#5) were assigned
   for my hacked PGP. You may get patch file for pgp50i-b8 from
   
   	URL://www.pp.iij4u.or.jp/~h2np/pgp
   
   	Note: 
   	THIS IS NOT FOR ANY OFFICIAL OR UNOFFICAL VERSION OF PGP.
   	IT'S A KIND OF JOKE. DON'T BE A SERIOUS.
   
Does mean you want me to put in an algorithim identifier for GOST, or not? 

	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)

Date: Wed, 03 Dec 1997 12:13:39 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: Tony Mione <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: What is going on?!?
Sender: [email-masked]

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

Tony Mione wrote:
> 
> > Who the $#@#$@!!! let David "FUD" Sternlight in here?!? Bad enough his
> > rants fill up the pgp newsgroups do we really need him here?
> >
> 
>         If we want him to go away, we need to consistently ignore him
> regardless of how inflamatory his remarks are. People like this want some
> cause to fight for (really, they just want to get other people ticked). If
>no one is playing the game, it is no fun. He will just pick up his ball and
> go home (please, please, please).

An unbiased review of my posts to the ietf open pgp list will show that
I have made no personal remarks about any interlocutor on this list, nor
posted any "rants". To the contrary I have bent over backwards to be
fair-minded, presenting (for example) advantages of web of trust as well
as rigid heirarchical in the context both of this group and the
instructions this group and the S/MIME 3 group are under to work
together in areas of commonality. I have raised some issues in the
context of trust models and the robustness of signature structures. In
return, several have mounted vicious personal attacks against me.

Readers who aren't trying to obfuscate those issues will realize that
personal attacks come from those who feel threatened by a discussion of
such issues because they conflict with some hidden agenda. The attackers
are attempting to pseudo-speciate my posts in order to avoid those
issues. Such behavior speaks for itself, and I assume fair-minded
readers see it for what it is.

Those who wish to use this group to pursue a partisan political or
commercial agenda will have to live with the self-exposure their
behavior has now produced.

This will be my only post on this topic, since the purpose of this list
is to discuss open PGP and not me or attackers on me. I leave it to the
good sense of readers to deal with the latter issue as they see fit, in
the privacy of their kill files.

David Sternlight, Ph.D.
Los Angeles

From: [email-masked]
Date: Wed, 03 Dec 1997 09:50:24 -0800
To: IETF OpenPGP <[email-masked]>, [email-masked]
Original-From: Bill Stewart <[email-masked]>
Subject: Re: Comments on draft - Long.
Sender: [email-masked]

Forgot to add one comment:
DSS/DSA is only specified for key lengths between 512 and 1024, 
but OpenPGP should be free to do longer keys, even though the
standard doesn't actually support them.
				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

From: [email-masked]
Date: Wed, 03 Dec 1997 11:14:51 -0800
To: [email-masked], [email-masked]
Original-From: Bill Stewart <[email-masked]>
Subject: Re: new algorithm identifier of the symmetric cryptosystem.
Sender: [email-masked]

At 01:37 PM 12/03/1997 +0900, Hironobu Suzuki wrote:
>I'd like to know who is control the algorithm identifier of the
>symmetric cryptosystem.
>
>I hacked GOST and BLOWFISH into PGP but still buggy. The algorithm
>identifier of GOST as FOUR(#4) and BLOWFISH as FIVE(#5) were assigned
>for my hacked PGP. You may get patch file for pgp50i-b8 from

Note that GOST is not a single algorithm - it's a family of algorithms,
and the security depends on the set of S-Boxes you use.
The USSR Military used one set, USSR non-military government another,
but we don't know what those sets were, and the set you have
may be just as strong, or much weaker.

>	URL://www.pp.iij4u.or.jp/~h2np/pgp
>	Note: 
>	THIS IS NOT FOR ANY OFFICIAL OR UNOFFICAL VERSION OF PGP.
>	IT'S A KIND OF JOKE.  DON'T BE A SERIOUS.

My company's firewall censorware didn't like the page,
and gave me a blocking banner.  Must have been a politically incorrect joke....
				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Wed, 3 Dec 1997 10:33:45 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: OP and pgp5.0i: some problems
Sender: [email-masked]

On Wed, 3 Dec 1997, Maksim Otstavnov, <[email-masked]>, wrote:
> 1.1
>
> "Charset" header needs defining. Values defined in 2.6.xi need 
> enlisting. A mechanism for charsets registration, or embracing 
> charsets otherwise registered needs defining.

I don't know much about the charset stuff.  Does it just affect how
the signature is calculated, or does it actually affect how the data
is decoded out of a literal packet?

> 5.0(i) for Windows works with  the three exact types 
> of object: (1) files, (2) clipboard text, and (3) data provided 
> by an MUA plugin through API. Right?
>
> I cannot test mode (3) now, but the first two (files, with "Text
> output" on and "Sign clipboard text" from PGPtray) both produce
> a clearsigned 8-bit text which is  in some sence "correct"

There are really two questions the signature software needs to know.
Is the input to be clearsigned vs binary signed, and should the output
be in text form.  In 5.0 these were combined into one checkbox, but
logically there is another possibility, a binary signed file which is
ascii armored for output.

> 2.2 Problems with clearsigning
>
> There are still problems however.
>
> (1) 8-bit clearsigning is not described anywhere (I presume). I 
> strongly believe it needs defining at least as "SHOULD" in 
> OP.

How does this differ from the clearsigning description in the draft?

> (2) "charset" setting is somewhat misleading. For instance, when I
> sign a 8-bit text content of Windows clipboard, it is usually
> meaningful in Windows native coding (the so called Windows-cpXXXX, is
> it described anywhere?), "windows-cp1251" for Russian. But I have
> "charset" header in sig armor set in "noconv". PGP 2.6.3i (on all
> platforms) and most other programs interprete "noconv" as equivalent
> to a native codepage of the receiving system. (In particular, "KOI8-R"
> extended charset as Russian standard for open systems).

I don't understand charsets so I can't comment on this.

> (3) If sending MUA is to perform any other (not cryptographic)
> 8-bit-to-8-bit or 8-bit-to-7-bit transmutation of a msg, the MUA must
> first do this transmutation, then sign the message, and a receiving
> MUA must first check signature, then perform any other transmutations.
> Right? 

I hope not.  Can't we just leave the messages alone?  Trying to translate
an 8-bit Cyrillic document into 7-bit printable US-ASCII sounds like a
nightmare.

Sorry can't be more help, this is not an area I know much about.

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

Date: Wed, 3 Dec 1997 10:21:13 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Comments on current draft
Sender: [email-masked]

On Wed, 3 Dec 1997, Tony Mione, <[email-masked]>, wrote:
> 1) There are a few places where the wording suggests and order in which
> message processing must take place. It would be better to word things such
> that the implementor can decide order of operations as long as the elements
> are processed in the correct manner (i.e. hashes are applied to the correct
> octet string, etc). One example is on page 4, section 2.1:
>
> ...
> Both digital signature and confidentiality services may be applied to
> the same message.  First, a signature is generated for the message and
> attached to the message.  Then, the message plus signature is encrypted
> using a conventional session key.  Finally, the session key is
> encrypted using public-key encryption and prepended to the encrypted
> block.
> ...

This is just introductory and expository and is intended to give a broad
overview of the process, not constrain an implementation.

> 2) Section 2.2:
>
> ...
>   1. The sender creates a message.
>   2. The sending software generates a hash code of the message
>   3. The sending software generates a signature from the hash code using
>      the sender's private key.
>   4. The binary signature is attached to the message.
>   5. The receiving software keeps a copy of the message signature.
> 			    ^^^^^huh?
> 	Better:
>
> 	5. The receiving software decrypts the signature with the sender's
> 	public key and saves that hash code.
>
>   6. The receiving software generates a new hash code for the received
>      message and verifies it using the message's signature. If the 
> 					^^^^^^^^^^^^^^^^^^
>      verification is successful, the message is accepted as authentic.
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^	
> 	Better:
>
> 	6. The receiving software generates a new hash code for the received
>         message. If the new hash code matches the hash code derived from the
> 	signature, the message is accepted as authentic.

It's not a matter of matching hash codes, it is a matter of running it
through the signature verification algorithm.  I agree that the "keeps a
copy" wording is unclear.

> 3) Section 2.6, last paragraph:
>
> ...
> Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of
> any line is ignored when the cleartext signature is calculated.
> ...
>
> 	Is this text historical? It seems counter intuitive to me to modify
> the text of a message in any way before signing it.

This is not historical, it is how it works.  Some gateways munge messages
by altering trailing whitespace, and this allows such messages to verify
correctly.

> 4) Section 3.3:
>
> ...
> A counted string consists of a length and then N octets of string data.
> ...
>
> 	How long is the length (1 octet, 2 octets, same length encoding as
> the packet length calculations in section 4.2)?

1 octet, but counted strings are not used.

> 5) Section 3.5.3.3:
>
> ...
> 	count of octets to be hashed = (16 + CMANT) << (CEXP + 6)
> ...
>
> 	Just curious? Why the constants 16 and 6?

The 16 is the implicit first bit, as is standard for floating point
formats.  The 6 is a normalization so that a more useful range of values
can be expressed.

> 6) Section 5.2.2.2: 
> 	It would be good to specify which subpackets are required and which
> are optional (or under which conditions they are required/optional). There
> are hints in the text, but it would be good to be explicit (perhaps a small
> table would make this clear).

Yes, Bill Stewart suggested something similar.  Personally I would
prefer not to make any of them mandatory but perhaps it is necessary as
a temporary measure so that current software can work efficiently.

>
> 	Also:
>
> ...
> {{Editor's note:  The above preference (hash algs) is controversial.  I
> included it in for symmetry, because if someone wants to build a
> ...
>
> 	Why is this controversial?

Hash algs would normally be chosen by the signer.  They are closely
related to the choice of signing key.  For example, DSS requires SHA.
It doesn't work well for the message recipient(s) to try to say how it
should be hashed for signing, since normally we sign before encrypting
(possibly long before).

> 7) Further down in the same section:
>
> ...
>     Regular expression (null-terminated regular expression) (Hashed)
> ...
>
> 	Which implementation of regular expressions? (See O'Reilly's
> 'Mastering Regular Expressions')

Good point.  We need to document the regexps.

> 	That's all for now. Have fun.

Thanks for your comments!

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

Date: Wed, 3 Dec 1997 10:23:19 -0800
To: "William H. Geiger III" <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: What is going on?!? (FROM The CHAIR)
Cc: [email-masked]
Sender: [email-masked]

At 10:57 PM -0600 12/2/97, you wrote:

>
>I am rather disapointed to see the amount of bickering going on over
>non-issues. The whole ascii issue has been blown way out of proportion.
>It's only a couple of lines of code people spend an afternoon write the
>code and be done with it. Shesh!!

That's my fault.  I've been sick with pneumonia the last couple of weeks
and haven't been able to wade in to bring this to a close.

There are some subtleties here.  I'm just now trying to catch up myself.
I'm unhappy with MIME and armor both as SHOULDs and no MUST to express the
objects. .  This is no way to guarantee interoperability.  Of course the
resolution may simply be that objects MUST be encapsulated in pgp binary
packets and rendition of the packets in some ascii printable form can be
safely relegated to SHOULDs.  There is another thread where this is under
discussion (see "expedience, consensus and editing")

>
>Who the $#@#$@!!! let David "FUD" Sternlight in here?!? Bad enough his
>rants fill up the pgp newsgroups do we really need him here?

IETF mailing lists are open to all who wish to make a contribution.
However (and this is not directed at you Bill, but to all)...

Discussion of these and other off-topic issues should simply be ignored. We
waste more time writing messages about how we should not be talking about
these things than simply not indulging ourselves.  Everyone, please show
some restraint!

THIS IS A TECHNICAL FORUM FOR DISCUSSION OF PGP FORMAT.
THIS IS A TECHNICAL FORUM FOR DISCUSSION OF PGP FORMAT.
THIS IS A TECHNICAL FORUM FOR DISCUSSION OF PGP FORMAT.

Other discussions has no place here.

Is that sufficiently clear?

>
>Well the IETF meeting is next week. I hope that we can get some productive
>work done afterwards.
>

Yes, let's hope.

john  w noerenberg, ii
[email-masked]
pager: [email-masked]
  ----------------- --------------------------- ----------------------
  "The great man is he who in the midst of the crowd keeps
   with perfect sweetness the independence of solitude."
  -- Ralph Waldo Emerson, "Self Reliance", 1841
  ----------------- --------------------------- ----------------------

Date: Wed, 3 Dec 1997 10:09:54 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft - Long.
Sender: [email-masked]

Thanks to Bill Stewart for some very helpful comments.  There are too
many valid issues raised for me to try to address them in one message.
Maybe we should collect comments, sort them by section, and then work
through them to achieve a decision on each one.

I will only respond to a few areas that I can address right now:

On Wed, 03 Dec 1997, Bill Stewart, <[email-masked]>, writes:
> 3.3 Counted Strings - 
> 	"A counted string consists of a length and 
> 	then N octets of string data"
> How long is the length field?  What's its format?
> I'm guessing it's one of the various variable-length-packed-number
> formats used in PGP, but you need to specify which one. 

No, the length is meant to be one byte.  However counted strings are no
longer used in the document proper, and so they could probably go away.

> 3.4 Time Fields - Y2038 problem - Also 5.2.2.2, 5.5.2. 5.9

It is only a problem in 2038 if your software assumes dates are signed
or otherwise limits them to 31 bits.  With 32 bits it is good until
2106.  By then we'll either have destroyed our civilization or transcended
into immortal beings of pure energy, right?

> 3.5.1.3 / 3.5.3.3 Iterated-Salted
> What a blazingly ugly design!  Is it really necessary to use
> a byte-count in a special one-octet-floating-point format,
> rather than using an iteration count?  Probably saves one
> multiplication when preparing the argument for a hash,
> at the cost of a couple masks and shifts and adds a hunk of code.
> Especially with the "Conventionally Encrypted Session Key" 
> available, the extra complexity seems unnecessary.

The actual format of these stringtokey specifiers was established before
I got involved, so I don't know the history.  But let me say a few words
in defense of this one, which several other people have objected to.

First, this option is by far the most important of the stringtokey
specifiers.  In fact, it is the only one which should ever be used.
The "simple" works like old PGP, but that version never used stringtokey
specifiers so it is not even needed for backwards compatibility.
"Salted" is a subset of "iterated/salted".

Only "iterated/salted" provides the maximum security against dictionary
based passphrase attacks.  The salt prevents precalculation, and the
iteration increases the cost to the attacker manyfold.  Lutz suggested
that the iteration didn't help because it applies the same cost to
the legitimate user as to the attacker, but in most contexts the user
can tolerate a small delay while for the attacker it makes his attack
hugely harder.  He can generate a hash very quickly to test a passphrase.
Making him iterate his hash function thousands or millions of times
means he can test only one passphrase in the time he could have tried
thousands or millions.

As for the one-byte hash length count, granted that may be a bit
over-optimized.  But it only takes one line of code to turn it into a
length count, so it is hardly a major implementation cost.  Sure, it
could have used a 24 or 32 bit field, but that is not really necessary
for the purpose.  You want to set the passphrase testing cost in almost
order-of-magnitude terms.  You don't need to differentiate between one
million bytes of hashing versus one million and one versus one million
and two.  You just need to specify it roughly as say 1,000 bytes or
1,000,000.  The format provides four bits of precision, which is more
than enough for this purpose.

> If anybody's really using this option, it probably should be kept,
> but as a MAY read, DEPRECATED generate.  Otherwise reserve the
> S2K-type indicator 0x03 and drop it.

We could make another one which used a 32 bit length but was otherwise
the same, and deprecate this one.  I'm not sure it's worthwhile, though.

The thing which I object to about the stringtokey specifiers is that
they have no internal length field.  If you don't recognize the type of
stringtokey object, you don't know where it ends.  Apparently that is OK
as they are used now, because if you can't interpret them there is no
data following them which is of any use to you.  But it will constrain
any future uses of them.

> 4.2 Packet Headers - Packet Length.
> Meanwhile, it appears that the Partial Body Length can
> support indefinite-length material, which is critical,
> since it allows PGP to be used with streaming input such as
> speech that goes on for a long time, (though the particular
> encoding is inefficient if the data comes in natural chunk sizes
> that aren't powers of 2 (or at least 3*2**n), or compresses
> to irregular sizes.)  It's worth noting this kind of application
> in the draft, to encourage OpenPGP implementations to be designed
> in ways that aren't limited by temp files with maximum lengths.

This is a good application for this packet.  Many people seem to have
trouble understanding the significance of the one-pass model.  It could
be that some motivation would help here.

> 5.1 Encrypted Session Key Packet - Traffic Analysis Risk -
> The KeyID field, as defined, leads to a major traffic analysis risk,
> but the format doesn't depend critically on the value in the field.
> At a previous Bay Area Cypherpunks meeting, somebody from PGP 
> mentioned a request from some freedom fighter users that KeyIDs
> be shorter, because the current tyrannical government was
> using them to identify who to torture into decrypting messages -
> having PGP was incriminating enough, but with short KeyIDs, 
> e.g. 0-3 or 0-16, it's possible to reduce decryption workload
> without indentifying the user of the message.

I raised this possibility on the list a few weeks ago, but the only
response was negative (I think because it would break the way the
keyids were being used as indexes).

> Some obvious alternative implementations are to keep the field
> for compatibility, while specifying that the 
> - - the receiver of a message MAY attempt decryption regardless
> 	of the value in the field, regardless of whether
> 	it's intended for him or not.
> - - the sender must output a value in the field that 
> - -- SHOULD be the KeyID, but 
> - -- MAY be all-0, for which the receiver SHOULD/MAY decrypt
> - -- MAY be Z=1-63 bits of leading 0 followed by the low-order
> 	64-Z bits of the intended recipient's KeyID, which the 
> 	receiver SHOULD/MAY decrypt if it matches his KeyID's low bits.
> - -- MAY be some other prearranged value, e.g. a multicast code,
> 	which the receiver MAY decide to attempt to decrypt.

Interesting possibilities.  Jon Callas also suggested (internally) the
idea of putting all zeros into the keyid field to mean that the receiver
should try all his keys.

I would prefer to see a new version of the ESK packet (or PKESK if we
want to call it that).  One problem we have is that messages encrypted to
DH subkeys have only the keyid of the subkey in them, not the keyid of the
DSS key.  The current PGP client software tries to simplify things for
users by not exposing the complexity of the dual-key model, so users only
see the keyid of the top level DSS key.  Then if they don't have the key
for a message recipient, displaying the keyid of the missing key won't
match the keyid they see.

One solution we've been discussing would be to add some subpacket
information to the ESK packet similar to what we have in the signatures.
There could be "hint" subpackets to help find the decryption key, like
one which tells the keyid of the DSS key.  Maybe other hints could be
useful too, as we have proposed for the signatures (key server URLs,
etc.).  This would be for V2.

> Since this just requires permission in the spec, rather than
> needing specific implementation, and since the main negative impact
> on non-implementing users is attempting to decrypt
> an occasional message that wasn't intended for them that they
> happened to receive, I'd like to ask that it be included.

Definately worth considering, at least the all zeros one.  The subset
one has the obvious problem that there is no specification of the matching
length.  You may want to send the low order 4 bits of the keyid to use
for decryption, but if they happen to be all zeros then you can't do it.

> 5.2.2 Version 4 Signature Packet Format
>
> The format does not contain a KeyID field, and does not
> document how to find the KeyID from the various Public Key types --
> there needs to be at least a reference to the section
> currently numbered 8.2.

There is a keyID field, subpacket type 16, but it got left out of this
section by mistake.  That should be corrected.

> The subpacket stuff is confusing (no surprise, it's new.)
> The descriptions of the Hashed and Unhashed subpacket data should be
> - - one or more hashed subpackets

Actually zero or more

> - - zero or more unhashed subpackets
> or else these two lines and their preceding lines should be replaced by
> - - hashed_subpacket block
> - - unhashed_subpacket block
> and the definitions of the subpacket blocks (here or in 5.2.2.1) should be
> - - Two-octet octet count for following subpacket data.
> - - zero or more (un)hashed subpackets

Maybe some rewording will help here.  We just refer to "subpacket data"
where you mention a "subpacket block".

> 5.2.2.1 - Signature Subpacket Specification
> I'm assuming the "Two-octet octet count" in this section is the
> same field as in 5.2.2?  (Should be anyway.)  Only should appear once.

No, it's not.  This is the count of the size of one subpacket, while the
5.2.2 count is the size of all the subpackets.

> The description up front needs to say something like
> - -------------
> Some subpacket types are mandatory, others are optional.
> Some subpacket types only apply to self-signatures.
> Some subpacket types can appear multiple times, others just once.
> Some subpacket types are always hashed, some are always unhashed.
> 	(Are any of them optionally hashed?)
> A hashed subpacket MUST be in the hashed_subpacket block, and 
> an unhashed subpacket MUST/MAY appear in the unhashed_subpacket block.
> - -------------

I like the idea of showing this kind of information in tabular form.

One quibble is that I'm not sure the optional/mandatory makes sense.
I think there could be contexts in which all of them are optional.
A signature does not necessarily need a creation date.  We don't force
them to have expiration dates so symmetry might suggest there are some
contexts where a creation date is not appropriate.  Also, maybe there
is no time source handy for the signer.  Signer KeyID could be optional
if there was some other subpacket created to help identify the signer
(say signer key fingerprint).  Or maybe the signer identity is implicit.

> It would be nice to reserve some of this space for
> user-defined functions, though it's a tossup whether the best mechanism
> is to define additional numbers (e.g. reserve 64-127 or 96-127)
> or to use the notation data with user-specified values (better?).

This was the intention of the notation data subpacket.

I've run out of time and steam to do more now.  There are many more very
good points raised by Bill which we should consider.

Hal Finney
[email-masked]

Comments: Authenticated sender is <[email-masked]>
From: "Maksim Otstavnov" <[email-masked]>
Organization: home office
To: [email-masked]
Date: Wed, 3 Dec 1997 19:33:52 +0400
Subject: OP and pgp5.0i: some problems
Reply-to: [email-masked]
Sender: [email-masked]

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

A set of problems have arisen during the initial testing of 5.0i for
Windows in a non-English environment. I believe it is desirable to
treat (or at least identify) them in OP, for the benefits of OP
worldwide promulgation.

1. "charset" header.

[2.4.1 in the November OP Draft]

1.1

"Charset" header needs defining. Values defined in 2.6.xi need 
enlisting. A mechanism for charsets registration, or embracing 
charsets otherwise registered needs defining.

1.2 Discussion

PGP 5.0 is unable to process correctly armors with 
"charset" headers other than "noconv" and equivalents. (However, 5.0
doesn't claim 2.6i compatibility, but 2.6).

1.3 Note

It would be neat to advise developers (SHOULD?) to set 
"charset" to "noconv" if related material is pure 7-bit ASCII, 
regardles of the settings of native 8-bit interpretation in the 
environment.

2. Clearsigning 8-bit

[2.6 in the November OP Draft]

2.1 Discussion

5.0(i) for Windows works with  the three exact types 
of object: (1) files, (2) clipboard text, and (3) data provided 
by an MUA plugin through API. Right?

I cannot test mode (3) now, but the first two (files, with "Text
output" on and "Sign clipboard text" from PGPtray) both produce
a clearsigned 8-bit text which is  in some sence "correct"

"Correct" means that resulting file passes signcheck with 2.6.3,
("charset=noconv"), and v.v., clearsigned text produced with 2.6.3
("charset=noconv") passes signcheck by 5.0(i) (when the known
"123-213" bug in 5.0 is fixed).

2.2 Problems with clearsigning

There are still problems however.

(1) 8-bit clearsigning is not described anywhere (I presume). I 
strongly believe it needs defining at least as "SHOULD" in 
OP.

(2) "charset" setting is somewhat misleading. For instance, when I
sign a 8-bit text content of Windows clipboard, it is usually
meaningful in Windows native coding (the so called Windows-cpXXXX, is
it described anywhere?), "windows-cp1251" for Russian. But I have
"charset" header in sig armor set in "noconv". PGP 2.6.3i (on all
platforms) and most other programs interprete "noconv" as equivalent
to a native codepage of the receiving system. (In particular, "KOI8-R"
extended charset as Russian standard for open systems).

(3) If sending MUA is to perform any other (not cryptographic)
8-bit-to-8-bit or 8-bit-to-7-bit transmutation of a msg, the MUA must
first do this transmutation, then sign the message, and a receiving
MUA must first check signature, then perform any other transmutations.
Right? 

I believe it _is not_ defined anywhere presently. (RFC2015 defines
8-bit-to-7-bit only "normalization").

--
-- Maksim Otstavnov <[email-masked]> http://www.geocities.com/SoHo/Studios/1059/
--   -maintainer of The Russian PGP HomePage
--     (http://www.geocities.com/SoHo/Studios/1059/pgp-ru.html)
--   -moderator of "Security&Privacy" (Russian language) Web-forum
--     (http://www.rocit.ru/forum)

Date: Wed, 3 Dec 1997 09:17:30 -0500 (EST)
From: Tony Mione <[email-masked]>
To: [email-masked]
cc: Tony Mione <[email-masked]>
Subject: Comments on current draft
Sender: [email-masked]

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

Here are some comments on the first half of
draft-ietf-openpgp-formats-00.txt. Some are nits. Take them for what they
are worth.

0) Before I start, I will quote from the page header:

...
Callas, et. al.                Expires May 1998                [Page 1]
^L
Internet Draft              OpenPGP Message Format              Nov 1998
...
                                                                ^^^^^^^^OOPS!
	(I remember....doing the TIME WARP!)

1) There are a few places where the wording suggests and order in which
message processing must take place. It would be better to word things such
that the implementor can decide order of operations as long as the elements
are processed in the correct manner (i.e. hashes are applied to the correct
octet string, etc). One example is on page 4, section 2.1:

...
Both digital signature and confidentiality services may be applied to
the same message.  First, a signature is generated for the message and
attached to the message.  Then, the message plus signature is encrypted
using a conventional session key.  Finally, the session key is
encrypted using public-key encryption and prepended to the encrypted
block.
...

2) Section 2.2:

...
  1. The sender creates a message.
  2. The sending software generates a hash code of the message
  3. The sending software generates a signature from the hash code using
     the sender's private key.
  4. The binary signature is attached to the message.
  5. The receiving software keeps a copy of the message signature.
			    ^^^^^huh?
	Better:

	5. The receiving software decrypts the signature with the sender's
	public key and saves that hash code.

  6. The receiving software generates a new hash code for the received
     message and verifies it using the message's signature. If the 
					^^^^^^^^^^^^^^^^^^
     verification is successful, the message is accepted as authentic.
     ^^^^^^^^^^^^^^^^^^^^^^^^^^	
	Better:

	6. The receiving software generates a new hash code for the received
        message. If the new hash code matches the hash code derived from the
	signature, the message is accepted as authentic.

...

3) Section 2.6, last paragraph:

...
Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of
any line is ignored when the cleartext signature is calculated.
...

	Is this text historical? It seems counter intuitive to me to modify
the text of a message in any way before signing it.

4) Section 3.3:

...
A counted string consists of a length and then N octets of string data.
...

	How long is the length (1 octet, 2 octets, same length encoding as
the packet length calculations in section 4.2)?

5) Section 3.5.3.3:

...
	count of octets to be hashed = (16 + CMANT) << (CEXP + 6)
...

	Just curious? Why the constants 16 and 6?

6) Section 5.2.2.2: 
	It would be good to specify which subpackets are required and which
are optional (or under which conditions they are required/optional). There
are hints in the text, but it would be good to be explicit (perhaps a small
table would make this clear).

	Also:

...
{{Editor's note:  The above preference (hash algs) is controversial.  I
included it in for symmetry, because if someone wants to build a
...

	Why is this controversial?

7) Further down in the same section:

...
    Regular expression (null-terminated regular expression) (Hashed)
...

	Which implementation of regular expressions? (See O'Reilly's
'Mastering Regular Expressions')

	That's all for now. Have fun.

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 *****

Date: Wed, 3 Dec 1997 07:28:36 -0500 (EST)
From: Tony Mione <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
cc: Tony Mione <[email-masked]>
Subject: PGP Implementor's survey : First results snapshot available
Sender: [email-masked]

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

	I have compiled the surveys returned to me so far. You can find the
results from my web page (look for 'IETF involvment') or go directly to the
survey page:

http://www-ns.rutgers.edu/~mione/openpgp/

	I will be updating the page regularly (I am hoping to do this on at
least a weekly basis).

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 *****

Date: Wed, 3 Dec 1997 06:44:18 -0500 (EST)
From: Tony Mione <[email-masked]>
To: [email-masked]
cc: [email-masked], Tony Mione <[email-masked]>
Subject: Re: What is going on?!?
Sender: [email-masked]

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

> 
> Hello,
> 
> Well between a switch in ISP's and a rather hetic couple of weeks I fail
> to notice that I had not changed my address for the mail list. I am now in
> the process of catching up on +90 messages.
> 
> I am rather disapointed to see the amount of bickering going on over
> non-issues. The whole ascii issue has been blown way out of proportion.
> It's only a couple of lines of code people spend an afternoon write the
> code and be done with it. Shesh!!
> 

	I whole-heartedly agree with this! Just make ARMOR a SHOULD and
leave it as a 'quality-of-implementation' issue. The code is trivial and
the market will drive most implementations to include it before very long.

> Who the $#@#$@!!! let David "FUD" Sternlight in here?!? Bad enough his
> rants fill up the pgp newsgroups do we really need him here?
> 

	If we want him to go away, we need to consistently ignore him
regardless of how inflamatory his remarks are. People like this want some
cause to fight for (really, they just want to get other people ticked). If
no one is playing the game, it is no fun. He will just pick up his ball and
go home (please, please, please).

> I saw that someone sugested droping all support of current implemntations
> and starting from scratch. I hope this was just a bad joke.
> 
> Well the IETF meeting is next week. I hope that we can get some productive
> work done afterwards.
> 
> - -- 
> - ---------------------------------------------------------------
> William H. Geiger III  http://users.invweb.net/~whgiii
> Geiger Consulting    Cooking With Warp 4.0
> 

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 *****

Date: Wed, 03 Dec 1997 02:53:20 -0800
To: IETF OpenPGP <[email-masked]>, [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Comments on draft - Long.
Sender: [email-masked]

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

OpenPGP Comments - Bill Stewart, [email-masked], 12/2/97
Based on 11/97 draft-ietf-openpgp-formats-00.txt ,
plus some mailing list discussion.
===================================================
Structural comment - the draft is a bottom-up document,
rather than a top-down document.  That generally makes the
syntax clearer, in that you never use a FooObject as a component
of a BarObject until you've seen the syntax for the FooObject,
but it's difficult to use for recursive structures,
and it's extremely difficult to do a good job of explaining the
semantics, at least when the context and meaning are as
closely intertwined as they are here.  I say this partly as
a call for careful, clear writing, and partly as an apology for
stuff I get wrong because I don't quite follow it :-)
====================================================

Major missing capability - support for Stealth formats.
I suppose that, since I haven't written up a proposal by now,
I can't complain (:-), but it'd be nice to leave this open
for OpenPGPv2 or something.

=============
Various packed number formats - it's probably cleaner to
describe these up front, or at least before they're used.
=============

3.3 Counted Strings - 
	"A counted string consists of a length and 
	then N octets of string data"
How long is the length field?  What's its format?
I'm guessing it's one of the various variable-length-packed-number
formats used in PGP, but you need to specify which one. 

3.4 Time Fields - Y2038 problem - Also 5.2.2.2, 5.5.2. 5.9
Using Unix-style "seconds since 1970" dates as the only format is 
not a bright thing to do in 1997....   A couple of alternatives:
a) Define a new format, like "yyyymmdd,milliseconds of day" or
	"microseconds since 1AD/01/01/00:00:00" (easy fit in 64bits) or
	"yyyymmddhhmmss.nanosec", that'll be good for all
	reasonable applications (are microseconds enough??)
b) Time values below 10,000,000 are days since 1AD/01/01
	(assumes 1 day granularity is enough, and no PGP in first
	115 days of 1970 :-)  Or hours since 1AD/01/01/00:00:00.
	(Another packed number format - sigh :-)
c) At very minimum, make the times modulo-2**32, with values 
	assumed to be later than ~1990, and validity intervals
	adjusted appropriately.  That still limits you to
	68-year usage, or 34 for safety, which is unfortunately
	a real problem for long-term e-commerce.
d) Use the notation field in signatures if you really care...

There's also the problem that times can't be trusted,
so you shouldn't depend on them too strongly.

3.5.1.3 / 3.5.3.3 Iterated-Salted
What a blazingly ugly design!  Is it really necessary to use
a byte-count in a special one-octet-floating-point format,
rather than using an iteration count?  Probably saves one
multiplication when preparing the argument for a hash,
at the cost of a couple masks and shifts and adds a hunk of code.
Especially with the "Conventionally Encrypted Session Key" 
available, the extra complexity seems unnecessary.

If anybody's really using this option, it probably should be kept,
but as a MAY read, DEPRECATED generate.  Otherwise reserve the
S2K-type indicator 0x03 and drop it.

4.2 Packet Headers - Packet Length.
I'd rather have seen a cleaner format for the length,
but that's a job for OpenPGPv2 to clean up.
(In particular, I'd like to see a format that allows for
padding to multiples of 4 or 8 octets.)

Meanwhile, it appears that the Partial Body Length can
support indefinite-length material, which is critical,
since it allows PGP to be used with streaming input such as
speech that goes on for a long time, (though the particular
encoding is inefficient if the data comes in natural chunk sizes
that aren't powers of 2 (or at least 3*2**n), or compresses
to irregular sizes.)  It's worth noting this kind of application
in the draft, to encourage OpenPGP implementations to be designed
in ways that aren't limited by temp files with maximum lengths.

4.3 Packet Tags / 5.1 Encrypted Session Key Packet - (nitpick)
should "Encrypted Session Key Packet" be renamed 
"Public Key Encrypted Session Key Packet" now that 
there's also a "Conventionally Encrypted Session Key Packet"?

Also, the "Name Packet" (Tag 13) is yet another packet that's
later called a "UserID Packet".  My personal preference is to
call it a "User Data Packet" - see 5.11 for discussion.

5.1 Encrypted Session Key Packet - Traffic Analysis Risk -
The KeyID field, as defined, leads to a major traffic analysis risk,
but the format doesn't depend critically on the value in the field.
At a previous Bay Area Cypherpunks meeting, somebody from PGP 
mentioned a request from some freedom fighter users that KeyIDs
be shorter, because the current tyrannical government was
using them to identify who to torture into decrypting messages -
having PGP was incriminating enough, but with short KeyIDs, 
e.g. 0-3 or 0-16, it's possible to reduce decryption workload
without indentifying the user of the message.

Some obvious alternative implementations are to keep the field
for compatibility, while specifying that the 
- - the receiver of a message MAY attempt decryption regardless
	of the value in the field, regardless of whether
	it's intended for him or not.
- - the sender must output a value in the field that 
- -- SHOULD be the KeyID, but 
- -- MAY be all-0, for which the receiver SHOULD/MAY decrypt
- -- MAY be Z=1-63 bits of leading 0 followed by the low-order
	64-Z bits of the intended recipient's KeyID, which the 
	receiver SHOULD/MAY decrypt if it matches his KeyID's low bits.
- -- MAY be some other prearranged value, e.g. a multicast code,
	which the receiver MAY decide to attempt to decrypt.

Since this just requires permission in the spec, rather than
needing specific implementation, and since the main negative impact
on non-implementing users is attempting to decrypt
an occasional message that wasn't intended for them that they
happened to receive, I'd like to ask that it be included.

5.2 Signature Packet
===== documentation comments
This section deals with some of the most complex parts of PGP.
It needs to address where the signature packets fall in the
grand scheme of things, e.g. needs enough BNF here or elsewhere to say

    Signed_Thing::= 	Signed_Key | Signed_Doc | One_Pass_Signed_Doc
    Signed_Key  ::= 	one Public Key Packet (Tag 6) FOLLOWED BY
			one or more Signature_Packet(Tag 2)
    Signed_Doc	::=	one Signature_Packet(Tag 2) FOLLOWED BY
			one Data_Packet
    Data_Packet	::=	Compressed_Data_Packet(Tag 8) |
			Literal Data Packet
    One_Pass_Signed_Doc::= one One_Pass_Signature_Packet(Tag4) FOLLOWED BY
			one Data_Packet FOLLOWED BY
			one Signature Packet

(Correcting this as needed.)

It also would be nice to put some of the semantic issues in the
front section here - at very least, the definition of
"self-signature".

Also, while PGP 2.6.2 uses Version 3 Signature Packets,
either section 5.2 or 5.2.1 should indicate that it only supports
RSA and not also the DSA signatures.

=== proposed semantic issues for 5.2:
Implementations SHOULD support generation of V3 signatures,
and PROBABLY (??) SHOULD generate them when encrypting to RSA keys,
or at least RSA keys received from a Public Key Packet Version 3.
Implementations SHOULD NOT generate V3 signatures for non-RSA keys?

5.2.2 Version 4 Signature Packet Format

The format does not contain a KeyID field, and does not
document how to find the KeyID from the various Public Key types --
there needs to be at least a reference to the section
currently numbered 8.2.

The subpacket stuff is confusing (no surprise, it's new.)
The descriptions of the Hashed and Unhashed subpacket data should be
- - one or more hashed subpackets
- - zero or more unhashed subpackets
or else these two lines and their preceding lines should be replaced by
- - hashed_subpacket block
- - unhashed_subpacket block
and the definitions of the subpacket blocks (here or in 5.2.2.1) should be
- - Two-octet octet count for following subpacket data.
- - zero or more (un)hashed subpackets

5.2.2.1 - Signature Subpacket Specification
I'm assuming the "Two-octet octet count" in this section is the
same field as in 5.2.2?  (Should be anyway.)  Only should appear once.

The description up front needs to say something like
- -------------
Some subpacket types are mandatory, others are optional.
Some subpacket types only apply to self-signatures.
Some subpacket types can appear multiple times, others just once.
Some subpacket types are always hashed, some are always unhashed.
	(Are any of them optionally hashed?)
A hashed subpacket MUST be in the hashed_subpacket block, and 
an unhashed subpacket MUST/MAY appear in the unhashed_subpacket block.
- -------------

The header format description is clumsy, and should be restructured.
Replace the 
	- subpacket type (1 octet):
	  If bit 7 is set, subpacket understanding is critical,
with
	- subpacket_type_and_criticality_flag (1 octet)
	bit 7    - Criticality Flag
	bits 6-0 - subpacket type.

I'd recommend that the table of subpacket types indicate
which of these attributes apply to it, e.g.:
- --------------
	 2 = signature creation time, 	(hashed,mandatory,once)
	 3 = signature expiration time,	(hashed,optional,once)
	 4 = exportable,		(hashed,optional,once)
	 5 = trust signature,		(hashed,????,????)
	 6 = regular expression,	(hashed,optional,once)
	 7 = revocable,			(hashed,optional,once)
	 9 = key expiration time,	(hashed,optional,once,self)
	10 = reserved for PGP use	(hashed,optional,multiple,self)
	11 = preferred symmetric algorithms,	(hashed,optional,once)
	12 = revocation key,		(hashed,optional,????,self)
	16 = issuer key ID,		(unhashed,mandatory,once)
	20 = notation data,		(unhashed,optional,multiple)
	21 = preferred hash algorithms,	(hashed,optional,once)
	22 = preferred compression algorithms,	(hashed,optional,once)
	23 = key server preferences,	(hashed,optional,once,self)
	24 = preferred key server 	hashed,optional,once,self)
- ------------

Semantics Question - is support for optional subpacket types MUST?
	or only SHOULD or MAY?  
	Is support for types not defined here MAY or MUST NOT?

It would be nice to reserve some of this space for
user-defined functions, though it's a tossup whether the best mechanism
is to define additional numbers (e.g. reserve 64-127 or 96-127)
or to use the notation data with user-specified values (better?).

The Criticality Flag stuff is confusing.  I think I understand it better
now than I did before, so here's what I think it means (and if
I'm wrong, I hope somebody will rewrite it so it sinks in next time:-)
	The Criticality Flag is a request from the signer to the
	recipient's OpenPGP implementation for strict semantic support
	for optional and undefined subpacket types.  
	If the recipient's implementation does not recognize or 
	recognizes but does not implement a subpacket type
	for which the signer has set the Criticality Flag
	- For a Signed_Doc or One_Pass_Signed_Doc, the implementation
		? SHOULD ignore the Criticality Flag
		? SHOULD use the implementation-defined bad-signature
			handling response.
	- For a Signed_Public_Key, 
		Define a Valid Self-Signature as
		The packet contains an Issuer KeyID subpacket, 
		The implementation must calculate the Key's KeyID
		The Issuer KeyID matches the Key's KeyID
		The implementation must calculate the signature
			for the public key packet, using the public key,
			as described in Section #.##
		The calculated signature matches.

		Depending on whether the signature is a self-signature,
		- If the Signature Packet is not a Self-Signature,
		  --- the implementation SHOULD discard the Signature Packet
		  --- the implementation SHOULD invoke error-handling
		- If the Signature Packet is a Valid Self-Signature,
		  --- the implementation MUST? discard the Signature Packet
		  --- the implementation SHOULD? invalidate the 
			entire key that the Signature signs,
			at least if it's a brand-new key
		  --- the implementation SHOULD NOT? continue to use
			the key, at least if it's new.
		  --- the implementation SHOULD invoke error-handling
		- If the Signature Packet is an INVALID Self-Signature,
			the implementation MUST discard the signature
			but PROBABLY SHOULD NOT? invalidate the key,
			unless it's a brand-new key. 

5.2.2.2 Signature Subpacket Types
(it'd be nice to number these, especially since you've got numbers :-)
I've already discussed Y2038 problems above, so assume they apply
here as well.

- - Signature Creation Time - MANDATORY?  
	Or MAY this be optional, at least for environments like
	smartcards that may really not know what time it is.

- - Preferred {sym,hash,comp} - array of one-octet values
	The syntax for an array needs to be specified!
	Is it "Some counter field and COUNT octets"?
	Or "Null-terminated bunch of octets"?

- - Exportability - needs a definition of export/import.

- - Trust Signature - this invokes a bunch of complex semantics,
	which aren't explained very deeply in the one paragraph.
	If they're defined stably enough to really belong in this
	document, they should either be described here,
	or (better) in an appendix, or There should be a pointer 
	to some document elsewhere that explains what all this
	"meta-introducer" stuff is about and why it's different
	from simply being one signature higher up the food chain.

- - Additional Recipient Request - the community seems to have
	stabilized on the view that this should be
	Reserved For <Somebody's> Use.

- - Notation Data - I'm unclear on the flag syntax.  Is it
	-	First Octet - ALWAYS 0x80 or RESERVED
		2nd-4th Octets - 0x00, Reserved, MUST ignore
	- or -	First Octet - 0x00 or 0x80 or implementation-defined
		2nd-4th Octets - implementation-defined
	I'd prefer the latter.  Also, since this is an obvious
	extension mechanism for software, we ought to define
	some way to specify that the Notation is intended for
	implementation-defined software use.  Perhaps
		0x00 - Something special
		0x80 - Human-readable, non-software
		0x01-0x7f - Reserved for future OpenPGP use
		0x81-0xff - user-defined

- - Preferred Key Server - Currently self-signature only -
	I suggest we also permit this for non-self-signatures,
	so signers can indicate where they serve their keys
	and maybe even where they store revocation certificates.

- - Key Server Preferences - I'm guessing a more functional definition
	would be something like
	- No-Modify - Key Server SHOULD NOT change any data
		in the key server records for a key that
		sets this field.

- - [Unclear context:] Implementations SHOULD implement a "preference"
	and MAY implement a "request."
	? It's not clear to me what this statement is referring to.
	The "preferences" indicated above were the hash/symmetric/public
	algorithms and the key servers; the only "request" I saw
	was the "Additional Recipient Request".
	It's also not clear what it means - does it mean that
	implementations SHOULD implement the ability to accept input 
	packets containing preferences (perhaps obeying them),
	and MAY implement the ability to generate output packets
	containing the preferences?

- - JDCC Note - specifying negative preferences - Is specifying
	only Triple-DES good enough?  Or should we do something hokey
	like making algorithm numbers 128-255 (or -1 - -128)
	indicate that you really don't want alg&0x80 (or -alg)?
	I lean towards the former, especially since there are
	MUST defaults available, though it would be nice to say
	CAST5,IDEA,-3DES so that the sender whose preferences are
	3DES,Blowfish,DSASubliminal,CAST5 will know to pick CAST5
	even though she likes 3DES better.  That's too subtle, though.
	Perhaps the negotiation rule should be
		Sender SHOULD pick the algorithm supported by both
			sender and receiver that the receiver prefers,
		but MAY selfishly pick any algorithm supported by
			both sender and receiver.

- - JDCC Note - revoking user name / user data - there isn't enough context
	at this point in the document to indicate that - we've only
	had hints and allegations that there really are user data packets
	that are signed :-)  So it needs to be later in the document.

- - JDCC Note - PGP3 other subpacket types - did it go as far as
	specifying the subpacket numbers or subpacket names?
	Should we reserve those numbers now?
	e.g. 42 - answer subpacket - reserved for later

- - 5.2.3 Signature Types -
- - JDCC Note - What should we do about defined-but-not-implemented types?
	These types 0x11-0x13 follow the "UserID Identifies A Body" model,
	rather than the more general "Key Asserts Some Attribute" model
	that folks like Carl Ellison have advocated (which I prefer.)
	(See comments on 5.11 suggesting calling it "User Data".)
	I'd recommend that we do one of two things:
	1) Junk them now, stick to generic certifications,
	and use either notations subpackets or other as-yet undefined
	subpacket types to indicate special attributes of signatures.
	We've got enough syntactical hooks already.
	2) Define more syntactical hooks :-)  
	Keep them, and also reserve 0x14-0x1f for signature types:
	implementations SHOULD/MAY accept Signature types 0x10-0x1f
	as signatures on keys, MAY handle them specially, and
	MAY output them (if there's a good reason.)
	Alternatively (now that I've ranted against the critical bit :-),
	SHOULD accept 0x10-0x17, SHOULD reject unrecognized 0x18-0x1f,
	or maybe keep 0x10-0x1f for signatures you SHOULD accept and 
	0x80-0xff for user-defined signature types which should
	be rejected if unrecognized.

- - JDCC Note - Timestamp Signatures? - Reserve for future use?
	I'm not sure how a timestamp signature is different from any
	other document signature, since there's already a timestamp
	in the signature field.  Sounds like a better job for a notation?
	But somebody may make a good argument to the contrary.
	Also, it's a bit odd that compressed data fields don't have
	timestamps in them but literal data fields do.

- - JDCC Note - Key-only signature that doesn't cover user name -
	I'm not sure what the semantics of this are,
	except perhaps they're useful for self-signatures
	or binding notation-based attributes to the key.
	You could just as well sign a key with the user name
	and ignore the user name when using the key?
	On the other hand, if you want the feature,
	it probably needs to be a separate signature type
	so you know not to include the hash of the user name.

- - 5.3 Conventionally Encrypted Session Key (Tag 3)
	It's a bit disappointing that this uses an all-zero IV,
	but it's presumably already implemented.
	The problem is that it gives an octet of relatively-well-known
	plaintext in the encrypted session key - the algorithm ID.
	It's not much use for a Bad Guy, but it's there.

- - 5.5 Key Material Packet
	Some good BNF descriptions would really help here.

- - 5.5.2 - Public Key Packet Formats
	Implementations SHOULD accept V3 public key packets and
	MUST accept V4 public key packets?

	Another minor weakness with V3 keys is that the validity period
	is limited to 64k days (assuming unsigned short?),
	and some applications may find 200 years a bit limiting :-)
	More importantly, it doesn't allow defining keys with
	very short expiration times, e.g. 1 hour or 30 seconds.

	V4 keys 
	- The Y2038 problem is here too...
	- Is this a good place to specify that implementations
	MUST support DSA and El-Gamal, and SHOULD support RSA?

- - 5.5.3 - Secret Key Packet Formats 
	- Does this belong in the standard?  Is the Secret Key Packet 
	ever transmitted outside the implementation?
	Or is it really an implementation detail that doesn't need 
	to be part of a standard?  I agree that it's convenient to 
	read your PGP Version N secret keyring with PGP Version N+1,
	but to me that only rates a SHOULD and not a MUST.  
	In particular, there may be environments in which the 
	applications don't store their secret keys in files, 
	and don't transmit them to anyone, especially for 
	transient communications applications,
	and there are applications that want more security than the 
	standard PGP implementation uses for storing its secret keys
	(e.g. the UserName is visible in the secret key ring.)
	Also, there may be applications that only need to 
	verify signatures, or only need to public-key encrypt data, 
	or maybe even only need to symmetric-key encrypt data, 
	but don't need to public-key decrypt or sign data, 
	and it would be nice for them to say they're OpenPGP compliant.

	- Does "CFB" refer to standard CFB, or PGP-hacked CFB-variant?

- - 5.6 - Compressed Data Packet (Tag 8)
	According to section 7.2, a Compressed Data Packet
	should be decompressible into a valid OpenPGP message,
	while this section only specifies that it contain
	an RFC1951 DEFLATE block containing "some set of packets".
	The spec should state at this point that the contents
	of the DEFLATE block must be a valid OpenPGP message,
	or more precisely, that 
	an OpenPGP program writing a Compressed Data Packet 
	MUST use a valid OpenPGP message as the contents, and that 
	an OpenPGP program reading a Compressed Data Packet 
	SHOULD assume that the decompressed contents are valid
	and attempt to interpret them.

- - 5.7 - Symmetrically Encrypted Data Packet (Tag 9)
	Will this packet _always_ contain either a literal or compressed?
	Or will it at least always contain some PGP packets?
	(For instance, you might use it to encrypt secret keys....)
	Should OP be _required_ to always interpret any PGP packets in it?

- - 5.8 - Should this now say "NA" or "OP" or "McAfee" :-)

- - 5.9 - Literal Data Packet (Tag 11)
	- Is it "__CONSOLE" or "_CONSOLE" (I assume one _, but it's
	easy for underscores to get kerned together.)
	- Perhaps the example should mention displaying on a CRT
	as well as not saving it on a disk?
	- Y2038 time problems again.
	- The semantics are arbitrary and the syntax doesn't
	indicate which choice was the sender made here - if anyone cares.
	- Implements SHOULD NOT believe what they read :-)

- - 5.10 - Trust Packet (Tag 12)
	Since these packets aren't exported and shouldn't be imported,
	it's not clear this belongs in the standard.
	The trust packet and the trust signature subpacket in 5.2.2.2
	both have complex semantics that aren't very well documented.
	At least these are internal-use only, though, so who cares?
	I agree that they should be implementation-dependent.
	
	I also agree that the trust packet should be signed by the user -
	but the standards document has not yet told us where the
	trust packet is syntactically - is it attached to one key,
	in which case there's a key to self-sign with?
	Is it free-floating in the public key file (more likely)?
	(In which case there's no "self" to self-sign them...).
	It's even worse than it appears - other people's public keys
	are used in a context where you're either encrypting to them,
	or checking the validity of their signatures, so there's
	no need to use anybody's private keys to be able to check against,
	and the instance of PGP may not even have any private key at all.
	An implementation might require a private key to unlock a 
	secret key ring without too much annoyance, but doing so to
	unlock the pubkey file seems a bit paranoid.

- - 5.11 - UserID / UserName / User Data
	I'd suggest the term "User Data".  Unlike "User ID" or "User Name",
	it doesn't imply the "True Name" or "One Key, One Body" model
	of how public keys are used - but it does imply that the data is 
	picked by the user, which is not only a less authoritarian model,
	but more reflective of reality than some of the other terms.
	It also makes it potentially less clear what the certifier
	is certifying, but that also reflects reality.

	Requiring UTF-8 is probably not bad - we need to be sure the field
	always gets protected if it's being transmitted across
	non-8-bit-safe media, which gets back to the armor-vs-mime wars.
	We should at least require that a conforming implementation
	MUST NOT munge the string except in automatically reversible ways
	(such as MIME-Quoted-Printable or armoring the whole thing),
	and should do any key-related transactions in full-8-bit.

	There is one security-related problem of permitting
	arbitrary characters - users can put newlines in their key strings,
	or backspaces, or ANSI terminal-control escape sequences,
	or other things that can encourage the user interface to lie
	to the unsuspecting recipient.  Banning those might be good.

- - 6.1 - Public-Key Algorithm Constants
	Elliptic Curve - Yeah, they probably deserve some numbers.
	Perhaps reserve 20-29 for future Elliptic Curve.
	Leaving ElGamal signatures unmentioned is probably good,
	but if you want to use them, anybody seeing the "16" for
	ElGamal in a signature context ought to get the idea.
	ElGamal signatures and DSA signatures both have subliminal
	channel problems; perhaps we should allocate some symmetric-key
	algorithm identifiers for those :-)

- - 6.2 - Symmetric-Key Algorithm Identifiers
	By the way, how DOES PGP generate 3-key 3DES keys, since
	168 bits of key is just bigger than a 160-bit hash?
	Or does it use 2-key only?  S2K is limited to the hash length.

- - 7 - Packet Composition 
	My preference is to have this section up front.

- - 7.1 - Transferable Public Keys 
	The BNF needs to be beefed up.  In particular,
	if each Subkey can be followed by one or more revocation sigs
	as well as one or more normal signatures.
	Also, are the signatures on the Subkeys required?
	Are they required to be self-signed by the preceding public key?
	
	Again, my recommendation of the term "User Data" for "UserID".

	JDCC's note near the end of section 5.2.2.2 on 
	revocable User Data is in scope at this point.
	The syntax looks very clearly like a revocation signature
	immediately following the user data would apply to that data,
	rather than to the whole key, and it calls for zero or more packets
	so there's clearly room.  The catch is making sure the
	implementation doesn't choke when seeing a revocation instead
	of either a signature or a subkey.  I would definitely recommend
	that if a implementation sees a revocation sig immediately following
	a User Data field, that it MAY/SHOULD revoke that User Data,
	though the meaning of "revoke" may not be precisely defined. :-)
	On the other hand, it's probably too early to generate such
	(certainly needs testing with popular implementations first.)

	On the other hand, there's the operational queston of what
	revoking a User Data means.  It probably means that 
	PGP should notify the user before trying to use that key
	with that name.  But signatures are signed by keys,
	not by names, so rejecting signatures by that key when
	there are other User Data fields active is a mistake.
	And PGP 5.0 doesn't always tell you who signed some key anyway.
	If a Key/UserData pair is signed by a certifier's key,
	and you receive a revocation for that UserData signed by 
	the certifier's key, you SHOULD discard or ignore the certification.

- - 7.2 - BNF should go a layer or two deeper.

- - 8 Key Formats -
	This appears to overlap substantially with 7.1.  Why both?
	Also, 7.1 permits zero or more subkeys, while 8 V4 requires one.
	Can the number be zero?  Or more than one?

- - 8.2 KeyIDs and Fingerprints
	Probably should also repeat the V3 fingerprint format here.
	It's also worth noting that the KeyID and fingerprint 
	are both calculated rather than stored in the data;
	implementations may choose to cache this information for
	internal use, though there's no mechanism for export/import,
	and keyservers would definitely want to.

- - 9 - Security Considerations
	Traffic analysis should be mentioned here, since PGP does
	little to stop it and doesn't have stealth built in.

	Talking about the fingerprint hacks may be useful here.

===============================================================================
=

				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 03 Dec 97 00:06:06 -0600
To: Ian Grigg <[email-masked]>
Cc: [email-masked]
Subject: Re: why MIME in the standard?
Sender: [email-masked]

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

In <[email-masked]>, on 11/23/97 
   at 12:58 PM, Ian Grigg <[email-masked]> said:

>Adam Back wrote:

>> Doesn't seem like a big deal implementation-wise -- the complexity
>> saving of removing the checksum probably more than compensates for
>> having to output and parse a fixed Content-Type: string.

>I don't think it is a big deal implementation-wise either.  It is
>deployment that is my concern.  Changing all those servers over, changing
>all the scripts over, upgrading all pgp script copies to handle mime
>because they can no longer get the AA keys from where ever they got them
>from before.

>All those interoperability issues can be solved in one of two ways: by
>having one software source (as in pgp2.6 up to nowish) and by having a
>standard that insists on interoperable feature sets.

>We write standards to solve the problem of interoperability in the
>absence of common source.  We do not write standards to make it easier to
>implement, except as a secondary opportunity.

>As interoperability is the issue, IMNSHO, and everything that is out
>there with the label PGP attached to it uses Armour, then Armour it is.

>Add MIME to the standard if we believe this is the "way to go" by all
>means.  But that's in the opportunity basket, not the interoperability
>basket.  People like Dave Crocker are going to be possible proven "right"
>by events here  But this is small change compared to the cost of 
>breaking the current user base, no matter how "wrong" it might be.

I think that there is another issue regarding Ascii-Armor that is beeing
missed. That of compatability between OpenPGP implementations.

While most of the debate has centered around providing backward
compatablity with the current user base I have some concers regarding
future implementations.

What is going to happen when OpenPGP from vendor A sends a rfc822
clearsigned message to OpenPGP from vendor B who has not implemented the
Ascii-Armor code??

You could add a large set of preferance codes to the public key outlining
the capabilities of the various implementations but this restricts
portability of keys between implementations. Also it only is vaible in a
one->one communications. In a one->many environment (which PGP is quite
frequently used) you need a core set of functions that ALL implementations
support.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 03 Dec 97 00:40:07 -0600
To: Ian Grigg <[email-masked]>
Cc: [email-masked]
Subject: Re: PGP evolving, improving
Sender: [email-masked]

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

In <[email-masked]>, on 11/24/97 
   at 03:59 AM, Ian Grigg <[email-masked]> said:

>As I recall, the flaws are:

>  * create an arbitrary ID, and therefore spoof a key server
>  * create a key with the same fingerprint as another, under
>    some conditions, and thus spoof the server/key.

>For more detail, check out Gary's HIP-paper on
>http://www.hotlava.com/doc/fag-pgp/  I should note that PGP Inc have
>stated that all but one of the issues was known and fixed.

>So there are problems with the old PGP system.  But, and it's an
>important but, these (key) problems only effect keyservers in general. 
>As most people don't use key servers, this is not a tremendous problem,
>and certainly not justification for dropping the old formats.  It is of
>course more important to PGP Inc as their products use key servers
>automatically.

It is also possable to create a key that spoofs *both* keyID &
keyFingerprint. With the old formats the only sure way for verifying a key
was to take the size, keyID, & keyFingerprint.

There was another spoof that I came across (last year I think) dealing
with the display of key information by PGP. The reason I bring this up as
it is somthing to look out for when displaying key data to the user. I
have attached a copy of the key to this message.

OK I found my post to the coderpunks list:
=========================================================================

Hi,

While doing some analysis on the BAL server keyrings I cam across this PGP
key that may be of intrest:

- -- 

Type Bits/KeyID    Date       User ID
pub   512/37CD5C41 1994/08/16 Big, Important Person
sig       38D011C8             Trusted Introducer
            Key fingerprint = C4 8A BB 58 B1 A6 53 6F  21 AD 45 84 50 1D AA 6C

What is intresting about the key is it has not been signed even though a
signature is shown from a pgp -kvvc output!

How was this done??

The clever creator of this key formated his userid in such a way that when
displayed it would look like there was a valid signature for the key. The
entire "sig" line is really part of the userid for the key.

I have attached a copy of the key if anyone is intrested at looking at how
it was created.

For some of my scripts I had been parsing the output of PGP to build
information on the keys in the keyring. Since then I have switched to
extracting the data directly from the keyring. It was while I was testing
this new code that I came across this key. Glad I switched methods :))

=========================================================================

>As to the MD5 weakness, yes, you are correct there: theoretical
>weaknesses do not mean an unseemly dumping of the existing user base is
>warranted.

I have a patched version of PGP 2.6.x on my web site that allows it to use the SHA1 hash. I also fixed a "feature" in 2.6.x where if a message was encrypted with RSA but signed with an unknown algorithm it would fail not only the signature verification but the decryption too! The patched version will now decrypt the messages and warn of a verification failure.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 02 Dec 97 22:57:36 -0600
To: [email-masked]
Subject: What is going on?!?
Sender: [email-masked]

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

Hello,

Well between a switch in ISP's and a rather hetic couple of weeks I fail
to notice that I had not changed my address for the mail list. I am now in
the process of catching up on +90 messages.

I am rather disapointed to see the amount of bickering going on over
non-issues. The whole ascii issue has been blown way out of proportion.
It's only a couple of lines of code people spend an afternoon write the
code and be done with it. Shesh!!

Who the $#@#$@!!! let David "FUD" Sternlight in here?!? Bad enough his
rants fill up the pgp newsgroups do we really need him here?

I saw that someone sugested droping all support of current implemntations
and starting from scratch. I hope this was just a bad joke.

Well the IETF meeting is next week. I hope that we can get some productive
work done afterwards.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

To: [email-masked]
Reply-To: [email-masked]
Subject: new algorithm identifier of the symmetric cryptosystem.
Date: Wed, 03 Dec 1997 13:37:01 +0900
From: Hironobu Suzuki <[email-masked]>
Sender: [email-masked]

I'd like to know who is control the algorithm identifier of the
symmetric cryptosystem.

I hacked GOST and BLOWFISH into PGP but still buggy. The algorithm
identifier of GOST as FOUR(#4) and BLOWFISH as FIVE(#5) were assigned
for my hacked PGP. You may get patch file for pgp50i-b8 from

	URL://www.pp.iij4u.or.jp/~h2np/pgp

	Note: 
	THIS IS NOT FOR ANY OFFICIAL OR UNOFFICAL VERSION OF PGP.
	IT'S A KIND OF JOKE. DON'T BE A SERIOUS.

If the algorithm identifiers which I assigned make a trouble, I remove
my patch file.

HAPPY HACKING!

=========
PGP Message Exchange Formats
<draft-ietf-pgp-formats01.txt>

5.1.3 Secret key packet
.....
The algorithm identifier of the symmetric cryptosystem is zero for
unencrypted (should only occur in not pagable memory), one for IDEA, two
for 3DES-EDE, or three for CAST5.
.....
=========

-- 
Hironobu SUZUKI        Independent Software Consultant
E-Mail: [email-masked]
URL://www.pp.iij4u.or.jp/~h2np

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 02 Dec 97 22:08:03 -0600
To: David Sternlight <[email-masked]>, Dave Del Torto <[email-masked]>, Adam Back <[email-masked]>, Ian Grigg <[email-masked]>, Uri Blumenthal <[email-masked]>, [email-masked]
Subject: Re: [LISTBIZ] A Point of Order
Sender: [email-masked]

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

David, David, Daivd, I hope Jim is paying you well for your years of
service.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~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://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

Date: Tue, 02 Dec 1997 12:39:38 -0500
To: [email-masked]
From: James Howard <[email-masked]>
Subject: rhetoric
Sender: [email-masked]

>Let me cut through all the rhetoric with two simple analogies.

 typical. "Let me finish this pointless discussion by bringing up 
two more pointless discussions."

 DAVID, GO AWAY.  To paraphrase Stuart Smalley, you're not
good enough, you're not smart enough, and people really don't
like you.

Date: Tue, 02 Dec 1997 09:24:42 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Sender: [email-masked]

Antonio Mana Gomez wrote:

> 
>    You mean that we should be glad that the company that produced the
> browser has saved us the effort of finding who to trust, registering,
> configuring and all those tedious procedures? 

<much more of the same excised>

Let me cut through all the rhetoric with two simple analogies. They are
intended to be heuristic, not syllogistic. Hopefully they will close this
sub-discussion. 

1. Web of trust is like trusting a friend, without which personal relations
would be difficult. People aren't going to get a Visa logo on their foreheads
for this. Open PGP developers should, I assert, focus on maximizing their
model's efficiency and ease of use for this model and not try to move further
to a mixed model.

2. Rigid hierarchical is like the major credit card certifiers, without which
effective transaction systems at scale would be difficult. People aren't going
to roll their own credit cards for this. S/MIME 3 developers should, I assert,
focus on maximizing their model's efficiency and ease of use for this model
and not try to move further to a mixed model.

Each has its place. Corrupting either leads to its losing some of its unique
advantages. For instructive details consult any good text on the evolution of
national banking systems, or the appropriate chapters in introductory
economics texts.

David

Reply-To: James M Galvin <[email-masked]>
To: Colin Robbins <[email-masked]>
cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "'Steve Crocker'" <[email-masked]>
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? 
Date: Tue, 02 Dec 1997 10:59:05 -0500
From: James M Galvin <[email-masked]>
Sender: [email-masked]

On Tue, 02 Dec 1997 10:30:29 GMT, Colin Robbins said (and I quote):

    This suggests the choice between S/MIME and MOSS is being made on
    the basis of what is easy to implement.  This is never a good
    argument to use, as it loses sight of one major consideration - the
    users.

    Any choice ought to be focusing on what the users - at the end of
    the day our customers - will find integrates into the desktop
    environment in the simplest and cleanest way.  My understanding is
    this debate suggests this is a MOSS based approach.

Funny you should say this.  I agree with the conclusion but not how you
got there.

In the debate over X.400, PEM, PGP, MOSS, MSP, or S/MIME, one
observation I like to make is that the user doesn't care what you
choose.  Frankly, all these protocols provide the security services of
the greatest interest to users.  Further, all these protocols could be
made to support the trust model of your choice and the algorithms of
your choice.  (Some may have made policy choices in these areas but
those choices could be changed!)  It just doesn't matter.

What the user cares about is interoperability, i.e., when I send you a
secure email message you can process it.  This is problematic given so
many choices.  That is the problem!

The differences in these protocols are in the implementation.  Only
developers care about the differences in these protocols (setting aside
politics).  Each of these protocols requires a different amount of
effort to be integrated with various email clients and applications, as
well as other applications, e.g., the web.  Each of these protocols made
different design choices based on different assumptions and
requirements.  It is these things we should be evaluating in our quest
to make a choice.

On the issue of deployment, it's nice that S/MIME is integrated with
Netscape/Microsoft.  I suspect it will get a certain market share
because of this.  But let us not forget there are a lot more email user
agents out there than just Microsoft/Netscape.  And many of them are far
better than Microsoft/Netscape (although probably not for long).  S/MIME
is not going to just slip in to that market.

Jim
--
James M. Galvin                       Executive Director, Trust and Security
CommerceNet Consortium                +1 410.203.2707
3209A Corporate Court                 +1 410.203.2709 FAX
Ellicott City, MD  21042              http://www.commerce.net

Date: Tue, 02 Dec 1997 12:14:34 +0100
From: Antonio Mana Gomez <[email-masked]>
Reply-To: [email-masked]
Organization: Universidad de Málaga (SPAIN)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Sender: [email-masked]

--------------E5A56DE0BBF27BFD865EEDB2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

___________________________________________________________________
Mon, 01 Dec 1997 10:07:02 -0800
David Sternlight wrote:

> Phillip M Hallam-Baker wrote:
> > ...
> >
> > The only sense in which the built in client certs are in any
> > way special is that the browser company (Microsoft/Netscape)
> > has reviewed their Certification Practices Statement and
> > their operations and determined that their certificates
> > may generally be considered trustworthy. If you disagree
> > with this assement then uncheck the box next to VeriSign,
> > MCI, Thawte etc and you are entirely OK.
>
> This is the point, though I may have expressed it imprecisely. For
> S/MIME-X509-Verisign et al (what can we call that as shorthand?) there are
> "Certification Practices Statements" and sets of hardware and software
> standards for CAs. Second of all they are reviewed and only those considered
> trustworthy in general are pre-installed in general-user browsers (as distinct
> from some possible intranet practice). This is a distinct advantage of the
> model, as implemented, for arms-length interaction between strangers.

   You mean that we should be glad that the company that produced the
browser has saved us the effort of finding who to trust, registering,
configuring and all those tedious procedures? Just like Microsoft did,
saving us the effort to select, get and install a WEB browser by
including Explorer in the Windows package?. Of course, you can always
choose not to use those pre-installed features, but you know that the
average user will use them without questioning whether there are
alternatives and then the others will have to follow in order to
mantain compatibility and interoperatibility. Only those users who have
knowledge about computer security and do not like the kind of trust
model proposed will uncheck those boxes. But those are just commercial
practices (Not very ethical, by the way). Trust CAN NOT be started that
way. By definition. Period. Trust MUST be originated in the real 3D
world and then expressed by the tools that the technology provide. If
the actual tools are not satisfactory (not easy to use, not natural, not
efficient or not elegant...) then what we have to do is to develop new
tools not to try to adapt the world to the tools we have.
   By the way, Gunther, the solution to this problem has not been here
for more than ten years. We're just starting to develop it. Please do not
think that the theory of information security is just a few encipherment
algorithms. There are new questions and problems arising every day that
need a solution. Examples? Legal communication interception that does not
destroy the citizens rights, Electronic Commerce and many others.
   We have seen lately that the kind of marketing described above has led
to the success of products that are not the best ones, based on letting
everybody use them for free until the product has swep the competitors
and then, without alternatives, imposing the company's rules. I wont
mention any of them, but I suppose everybody has in mind at least a kind
of computer and one Operating System (both of them used by me to send
this message). The importance of the issue we are speaking of in this
group forces us to consider different alternatives and being very
careful when we choose one. The main point is that people can use the
Internet for their private communications, business or whatever without
loosing not even one of their rights. That's not guaranteed with the
actual trust models and certification schemes.

> In contrast, the web of trust model, as practiced, doesn't require such
> practice statements, nor central checking, nor any particular CA
> standard-sets. Instead each user creates his own trust heirarchy and rules.
> This is a distinct advantage of that model, for small workgroups where
> participants know each other and have an opportunity to verify fingerprints or keys
> to identities directly.

The advantage of this model is that trust comes from the real world but it
fails when:
-we have to communicate with people that are not linked by a trust
 (certificate) chain to us.
-we have to revocate trust on somebody.
-we have lost our certificates.
-we have to check a certificate with a long trus chain.
-etc.,
Some of those problems are common to the S/MIME model.

> Clearly the first approach is useful in some environments, and the second in
> others. It would be a mistake for users in arms-length interaction to trust
> unverified signatures just as it would be a mistake to force small
> self-contained work groups to adopt the overhead of CAs, trust statements,
> etc. And unless the canonical models are distinct, a degree of user education
> well beyond pragmatic practice is required, and the possibility is opened for
> much mischief.

  I really believe that the simultaneous use of the two models is not a good
idea, it just seems to me a proposal to close this discussion. There are too
many problems involved in any of those models alone to combine them in one
model with two options.

> ...
> To avoid misunderstanding I repeat my basic mantra--each trust model in its
> pure form has its place and to combine one with the other in the base design
> is a bad idea,

I agree as I have just said above, in the second part, but I don't think
that the coexistence of both models is an advance, maybe you just want to
put them out there and let the market do its job selecting one of them.

> thought providing a fail-safe multi-step escape hatch giving
> users some flexibility (as you've illustrated for S/MIME in Explorer) may be
> useful. Nevertheless I suggest the canonical forms are distinct, and should
> remain so: In S/MIME-X509 as practiced, users are provided with high-level CA
> keys which meet CPS tests; in web of trust as practiced, users must build
> their own CA structure on a case by case basis but aren't limited by anyone
> else's idea of CPS tests (pace Thawte).
>
> Frankly speaking, I have the impression this is really not a useful discussion
> to continue in the PGP and S/MIME 3 IETF lists since I think de facto we've
> got two standards evolving and the commonality is likely mostly to be in the
> area of envelopes. But it is not for me to try to shut off discussion on this
> interesting topic, if others find it useful.

I agree. It's time to close the debate of PGP vs. S/MIME but it's also time to DEVELOP
some new alternatives. Please, if conforming to an old standard like
X.500 or any other makes it difficult to develop those new alternatives we
should try to develop those alternatives without the old standards. I want
to note that we are witnessing the difficulties of the development of a
standard, and the different points of view that arise in every question,
so we should be aware that a standard (specially those never used before)
is likely to have imperfections (small or big). That means that NOTHING
should be taken as the indisputable basis of our design.
   I really think that the point of view of all the people that
participated in this discussion has enrichted this group.
   Antonio.
                          ~~~~~
                         ( o o )
  +----------------o000-----U------000o--------------------+
  !           _   ,                                        !
  ! Antonio Mana-Gomez               eMail: [email-masked] !
  !                                                        !
  ! http://www.lcc.uma.es/personal/mana/mana.html          !
  !                                                        !
  ! Departamento de Lenguajes y Ciencias de la Computacion !
  !        E.T.S.I.Informatica.    Desp. 1.2.B.19          !
  !                Campus de Teatinos.                     !
  !               29071 MALAGA (SPAIN)                     !
  !                                                        !
  ! Phone: (+34) 5 213 27 54        Fax: (+34) 5 213 13 97 !
  +--------------------------------------------------------+

--------------E5A56DE0BBF27BFD865EEDB2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#990000" ALINK="#CC33CC">
<TT>___________________________________________________________________</TT>
<BR><TT>Mon, 01 Dec 1997 10:07:02 -0800</TT>
<BR><TT>David Sternlight wrote:</TT>
<BLOCKQUOTE TYPE=CITE><TT>Phillip M Hallam-Baker wrote:</TT>
<BR><TT>> ...</TT>
<BR><TT>></TT>
<BR><TT>> The only sense in which the built in client certs are in any</TT>
<BR><TT>> way special is that the browser company (Microsoft/Netscape)</TT>
<BR><TT>> has reviewed their Certification Practices Statement and</TT>
<BR><TT>> their operations and determined that their certificates</TT>
<BR><TT>> may generally be considered trustworthy. If you disagree</TT>
<BR><TT>> with this assement then uncheck the box next to VeriSign,</TT>
<BR><TT>> MCI, Thawte etc and you are entirely OK.</TT>

<P><TT>This is the point, though I may have expressed it imprecisely. For</TT>
<BR><TT>S/MIME-X509-Verisign et al (what can we call that as shorthand?)
there are</TT>
<BR><TT>"Certification Practices Statements" and sets of hardware and software</TT>
<BR><TT>standards for CAs. Second of all they are reviewed and only those
considered</TT>
<BR><TT>trustworthy in general are pre-installed in general-user browsers
(as distinct</TT>
<BR><TT>from some possible intranet practice). This is a distinct advantage
of the</TT>
<BR><TT>model, as implemented, for arms-length interaction between strangers.</TT></BLOCKQUOTE>
<TT>&nbsp;&nbsp; You mean that we should be glad that the company that
produced the</TT>
<BR><TT>browser has saved us the effort of finding who to trust, registering,</TT>
<BR><TT>configuring and all those tedious procedures? Just like Microsoft
did,</TT>
<BR><TT>saving us the effort to select, get and install a WEB browser by</TT>
<BR><TT>including Explorer in the Windows package?. Of course, you can
always</TT>
<BR><TT>choose not to use those pre-installed features, but you know that
the</TT>
<BR><TT>average user will use them without questioning whether there are</TT>
<BR><TT>alternatives and then the others will have to follow in order to</TT>
<BR><TT>mantain compatibility and interoperatibility. Only those users
who have</TT>
<BR><TT>knowledge about computer security and do not like the kind of trust</TT>
<BR><TT>model proposed will uncheck those boxes. But those are just commercial</TT>
<BR><TT>practices (Not very ethical, by the way). Trust CAN NOT be started
that</TT>
<BR><TT>way. By definition. Period. Trust MUST be originated in the real
3D</TT>
<BR><TT>world and then expressed by the tools that the technology provide.
If</TT>
<BR><TT>the actual tools are not satisfactory (not easy to use, not natural,
not</TT>
<BR><TT>efficient or not elegant...) then what we have to do is to develop
new</TT>
<BR><TT>tools not to try to adapt the world to the tools we have.</TT>
<BR><TT>&nbsp;&nbsp; By the way, Gunther, the solution to this problem
has not been here</TT>
<BR><TT>for more than ten years. We're just starting to develop it. Please
do not</TT>
<BR><TT>think that the theory of information security is just a few encipherment</TT>
<BR><TT>algorithms. There are new questions and problems arising every
day that</TT>
<BR><TT>need a solution. Examples? Legal communication interception that
does not</TT>
<BR><TT>destroy the citizens rights, Electronic Commerce and many others.</TT>
<BR><TT>&nbsp;&nbsp; We have seen lately that the kind of marketing described
above has led</TT>
<BR><TT>to the success of products that are not the best ones, based on
letting</TT>
<BR><TT>everybody use them for free until the product has swep the competitors</TT>
<BR><TT>and then, without alternatives, imposing the company's rules. I
wont</TT>
<BR><TT>mention any of them, but I suppose everybody has in mind at least
a kind</TT>
<BR><TT>of computer and one Operating System (both of them used by me to
send</TT>
<BR><TT>this message). The importance of the issue we are speaking of in
this</TT>
<BR><TT>group forces us to consider different alternatives and being very</TT>
<BR><TT>careful when we choose one. The main point is that people can use
the</TT>
<BR><TT>Internet for their private communications, business or whatever
without</TT>
<BR><TT>loosing not even one of their rights. That's not guaranteed with
the</TT>
<BR><TT>actual trust models and certification schemes.</TT>
<BR><TT>&nbsp;</TT>
<BLOCKQUOTE TYPE=CITE><TT>In contrast, the web of trust model, as practiced,
doesn't require such</TT>
<BR><TT>practice statements, nor central checking, nor any particular CA</TT>
<BR><TT>standard-sets. Instead each user creates his own trust heirarchy
and rules.</TT>
<BR><TT>This is a distinct advantage of that model, for small workgroups
where</TT>
<BR><TT>participants know each other and have an opportunity to verify
fingerprints or keys to identities directly.</TT></BLOCKQUOTE>
<TT>The advantage of this model is that trust comes from the real world
but it</TT>
<BR><TT>fails when:</TT>
<BR><TT>-we have to communicate with people that are not linked by a trust</TT>
<BR><TT>&nbsp;(certificate) chain to us.</TT>
<BR><TT>-we have to revocate trust on somebody.</TT>
<BR><TT>-we have lost our certificates.</TT>
<BR><TT>-we have to check a certificate with a long trus chain.</TT>
<BR><TT>-etc.,</TT>
<BR><TT>Some of those problems are common to the S/MIME model.</TT>
<BLOCKQUOTE TYPE=CITE><TT>Clearly the first approach is useful in some
environments, and the second in</TT>
<BR><TT>others. It would be a mistake for users in arms-length interaction
to trust</TT>
<BR><TT>unverified signatures just as it would be a mistake to force small</TT>
<BR><TT>self-contained work groups to adopt the overhead of CAs, trust
statements,</TT>
<BR><TT>etc. And unless the canonical models are distinct, a degree of
user education</TT>
<BR><TT>well beyond pragmatic practice is required, and the possibility
is opened for</TT>
<BR><TT>much mischief.</TT></BLOCKQUOTE>
<TT>&nbsp; I really believe that the simultaneous use of the two models
is not a good</TT>
<BR><TT>idea, it just seems to me a proposal to close this discussion.
There are too</TT>
<BR><TT>many problems involved in any of those models alone to combine
them in one</TT>
<BR><TT>model with two options.</TT>
<BLOCKQUOTE TYPE=CITE><TT>...</TT>
<BR><TT>To avoid misunderstanding I repeat my basic mantra--each trust
model in its</TT>
<BR><TT>pure form has its place and to combine one with the other in the
base design</TT>
<BR><TT>is a bad idea,</TT></BLOCKQUOTE>
<TT>I agree as I have just said above, in the second part, but I don't
think</TT>
<BR><TT>that the coexistence of both models is an advance, maybe you just
want to</TT>
<BR><TT>put them out there and let the market do its job selecting one
of them.</TT>
<BLOCKQUOTE TYPE=CITE><TT>thought providing a fail-safe multi-step escape
hatch giving</TT>
<BR><TT>users some flexibility (as you've illustrated for S/MIME in Explorer)
may be</TT>
<BR><TT>useful. Nevertheless I suggest the canonical forms are distinct,
and should</TT>
<BR><TT>remain so: In S/MIME-X509 as practiced, users are provided with
high-level CA</TT>
<BR><TT>keys which meet CPS tests; in web of trust as practiced, users
must build</TT>
<BR><TT>their own CA structure on a case by case basis but aren't limited
by anyone</TT>
<BR><TT>else's idea of CPS tests (pace Thawte).</TT>

<P><TT>Frankly speaking, I have the impression this is really not a useful
discussion</TT>
<BR><TT>to continue in the PGP and S/MIME 3 IETF lists since I think de
facto we've</TT>
<BR><TT>got two standards evolving and the commonality is likely mostly
to be in the</TT>
<BR><TT>area of envelopes. But it is not for me to try to shut off discussion
on this</TT>
<BR><TT>interesting topic, if others find it useful.</TT></BLOCKQUOTE>
<TT>I agree. It's time to close the debate of PGP vs. S/MIME but it's also
time to DEVELOP some new alternatives. Please, if conforming to an old
standard like</TT>
<BR><TT>X.500 or any other makes it difficult to develop those new alternatives
we</TT>
<BR><TT>should try to develop those alternatives without the old standards.
I want</TT>
<BR><TT>to note that we are witnessing the difficulties of the development
of a</TT>
<BR><TT>standard, and the different points of view that arise in every
question,</TT>
<BR><TT>so we should be aware that a standard (specially those never used
before)</TT>
<BR><TT>is likely to have imperfections (small or big). That means that
NOTHING</TT>
<BR><TT>should be taken as the indisputable basis of our design.</TT>
<BR><TT>&nbsp;&nbsp; I really think that the point of view of all the people
that</TT>
<BR><TT>participated in this discussion has enrichted this group.</TT>
<BR><TT>&nbsp;&nbsp; Antonio.</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
~~~~~</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
( o o )</TT>
<BR><TT>&nbsp; +----------------o000-----U------000o--------------------+</TT>
<BR><TT>&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
_&nbsp;&nbsp; ,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</TT>
<BR><TT>&nbsp; ! Antonio Mana-Gomez&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
eMail: [email-masked] !</TT>
<BR><TT>&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</TT>
<BR><TT>&nbsp; ! <A HREF="http://www.lcc.uma.es/personal/mana/mana.html">http://www.lcc.uma.es/personal/mana/mana.html</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</TT>
<BR><TT>&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</TT>
<BR><TT>&nbsp; ! Departamento de Lenguajes y Ciencias de la Computacion
!</TT>
<BR><TT>&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; E.T.S.I.Informatica.&nbsp;&nbsp;&nbsp;
Desp. 1.2.B.19&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</TT>
<BR><TT>&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Campus de Teatinos.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</TT>
<BR><TT>&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
29071 MALAGA (SPAIN)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</TT>
<BR><TT>&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</TT>
<BR><TT>&nbsp; ! Phone: (+34) 5 213 27 54&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax: (+34) 5 213 13 97 !</TT>
<BR><TT>&nbsp; +--------------------------------------------------------+</TT>
<BR><TT>&nbsp;</TT>
</BODY>
</HTML>

--------------E5A56DE0BBF27BFD865EEDB2--

From: Colin Robbins <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "'Steve Crocker'" <[email-masked]>
Subject: RE: Why do people fight about S/MIME vs. PGP rather than use   MOSS?
Date: Tue, 2 Dec 1997 10:30:29 -0000
Sender: [email-masked]

On 30 November 1997 14:11, Steve Crocker[SMTP:[email-masked]] =
wrote:

> Meanwhile, S/MIME adherents usually take the position that MOSS cannot =
be
> implemented easily unless one has a complete MIME implementation =
already.

This suggests the choice between S/MIME and MOSS is being made on the =
basis of what is easy to implement.  This is never a good argument to =
use, as it loses sight of one major consideration - the users.

Any choice ought to be focusing on what the users - at the end of the =
day our customers - will find integrates into the desktop environment in =
the simplest and cleanest way.  My understanding is this debate suggests =
this is a MOSS based approach.

Colin

Date: 1 Dec 1997 23:32:34 -0000
From: Secret Squirrel <[email-masked]>
Comments: Please report problems with this automated remailing service to <[email-masked]>. The message sender's identity is unknown, unlogged, and not replyable.
Subject: Sternlight
To: [email-masked]
Sender: [email-masked]

David Sternlight wrote

Frankly speaking, I have the impression this is really not a useful discussion
to continue in the PGP and S/MIME 3 IETF lists since I think de facto we've
got two standards evolving and the commonality is likely mostly to be in the
area of envelopes. But it is not for me to try to shut off discussion on this
interesting topic, if others find it useful.

David

-------

David, please depart this group. Your input and focus should be more
relevant there, and your absence from the open pgp list will help us
get work done rather than casting us into the polemics of insult and
Zimmerman-hate that you take everywhere you post.

Date: Mon, 01 Dec 1997 15:15:59 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: Dave Del Torto <[email-masked]>
CC: Adam Back <[email-masked]>, Ian Grigg <[email-masked]>, Uri Blumenthal <[email-masked]>, [email-masked]
Subject: Re: [LISTBIZ] A Point of Order
Sender: [email-masked]

Dave Del Torto wrote:
> 
> 
> At 3:15 pm -0800 11/24/97, David Sternlight wrote:
>  [material removed]
> >>Of course, Security Area folks don't have the depth of knowledge tat
> >>David has been exhibiting on the Net for quite a while (:-).
> >
> >Your gratuitous slam comes with ill grace from someone who apparently
> >doesn't understand the meaning of "for all the new standards". We were
> >talking about PGP's pulling RSA key generation from free PGP 5.0, and
> >pulling RSA entirely from free PGP 5.5.2, neither of which is a new IETF
> >standard or even a standard in work.. What is more, they didn't pull it
> >from pay PGP 5.0 at the same time, so your argument fails doubly.
> > [snip]
> 
> Gentlemen,
> 
> Regardless of whether I agree with anything any of you has posted on this
> topic, or with the manner, lack of manners, or even the *imagined* lack of
> manners (as the case may be) with which it has been said, the fact remains
> that this particular thread (playing haruspex over PGP Inc's business plans
> and development decisions), does not belong on the IETF's OpenPGP list.
> 
> Please pause to re-familiarize yourselves with the Charter (see:
> <http://www.ietf.org/html.charters/openpgp-charter.html>). This list is
> dedicated to the definition, under IETF guidelines, of an *open* PGP
> messaging standard, neither designed nor controlled by PGP Inc -- which
> company is absent from mention in the Charter (which also, in a fit of
> neutrality, lacks any mention of RSADSI or its products). Thus, whether you
> like them or abhor them, use them or prefer to ignore them posting your
> opinions about PGP Inc's products and/or practices on this particular
> working list is conspicuously inappropriate. It may also be counter-
> productive to this standards effort (readers: draw your own conclusions).
> 
> I believe I can safely assume that the four of you are intelligent enough to
> at least agree on one thing: that the Internet badly needs a real-world,
> workable standard for interoperable messaging with strong encryption. I also
> assume that, as interested/concerned technical participants, it is not your
> intention to impede the work of this (or any other) Working Group. If so,
> please do us the courtesy of moving this thread to another forum where you
> can pursue it at your convenience.

I agree completely with the sentiments of the writer.

> 
> Since it was Mr. Sternlight who first saw fit to insert his opinions here
> (without regard for netiquette, or first familiarizing himself with the WG's
> Charter), perhaps it would be appropriate to move this thread to
> <news:alt.fan.david-sternlight>. Those who are so inclined may spelunk
> deeply into his opinions there without further involving the members of this
> Working Group (some of whom I suspect might still wish to move the OpenPGP
> standard forward, unencumbered by irrelevancies such as debates over why PGP
> Inc's freeware doesn't contain this cipher or that hash).

It is regrettable that Del Torto spoiled a statement of high principle with an
archly personal slam. Those comments are at least subject to
misinterpretation. I had not been a subscriber to the list, and one such
subscriber e-mailed me several previous posts to the list which I thought in
fairness needed a response, which I made. That response triggered off personal
attacks from certain others with which I have tried not to engage since I,
too, felt them inappropriate.

On reflection I think the e-mailed copies were a provocation and It may be
that the attempt to drag me into the discussion should have been ignored. Be
that as it may, I support Del Torto's sentiments and do not plan further to
pursue any matter which he refers to as "irrelevancies" on this list. I hope
those holding different views from mine on such matters will behave in a
similar fashion.

As for Del Torto's redirect pointer, I do not participate directly in that
group despite its name. In any case a more useful place for further exercise
of righteous indignation at, or ringing defense of the actions of PGP Inc.
might be the bit bucket. For those consumed by this issue whose mailers don't
provide such a redirect option, news:comp.security.pgp.discuss might be a
viable alternative.

David

Date: Mon, 1 Dec 1997 17:51:05 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Sender: [email-masked]

[ massive cross-post stripped down to just ietf-open-pgp ]

> From: Gunther Schadow <[email-masked]>
> 
> I   have a strong  personal distaste  with S/MIME,   as the PKCS specs
> require ASN.1, X500 and other OSI stuff that  does not merge very well
> with  the rest of  the Internet infrastructure.

No one can argue with personal taste.  But my personal experience is
contrary to those who believe that "ASN.1, X.500, and other OSI stuff"
is difficult to use, difficult to program, and inevitably results in
slow, bloated code.

Is your distaste the result of having actually written an S/MIME user agent
or X.509 certificate library, or is it just a fear of the unknown?  In
an effort to teach myself X.509, I wrote a certificate parser from scratch,
rather than reuse code available from my employer, or the excellent
software from Eric Young, Consensus, SECUDE, and elsewhere.
Going in to that exercise, I regarded ASN.1 as a regrettable but necessary
evil.  Coming out, I have a new-found respect for ASN.1 as a protocol
documentation language and for BER as a universal, application-independent
serialization/marshalling mechanism.

Precisely what do you mean by "the rest of the Internet infrastructure"?
* The bits-in-boxes diagrams that document the TCP/IP stack?  Those are
  easy to understand, but not quite flexible enough for use in describing
  application-layer protocols.
* Various BNF/EBNF notations?
* Protocol-specific notations such as the one defined by a whole chapter
  in the TLS specification?
* XDR (as used by ONC-RPC)?
* S-expressions, or hybrid ASCII-binary encodings (as used by SPKI)?
* SGML/HTML/XML?
* other private/domain-specific notations I know nothing about or am
  not even aware of (DCE-RPC, CORBA, ...)?

All of these arguably have their place, but the sheer number of them
suggests that there is no "Internet infrastructure" to which all of them
belong but from which ASN.1 is, for some reason, excluded.
To the contrary, I believe that there is significant benefit in using
a common protocol description language across multiple protocols - it
enables the community's investment in knowledge, tools, code samples, and
most importantly, lessons learned, to be amortized over diverse application
domains.  To cite just one example, the ASN.1 OBJECT IDENTIFIER is a powerful
mechanism for achieving global registration of almost anything (data
structures, algorithms, protocols, policies, etc.) that requires agreement
between implementors, guaranteed uniqueness, and support for both
standardized and local object definitions.  How many different defined
constants or GUIDs does the world need to refer to the MD5 hash algorithm?

And to be more practical and less philosophical, I believe that ASN.1
can more than hold it's own from a code size, memory usage, and runtime
perspective against the alternatives.  It would be interesting to see
(no, Jon, I'm not volunteering to write them! :-) benchmarks of the
kilobytes and microseconds required to parse PGP, SPKI, and X.509 certs,
or of ASN.1 vs. "native" representations for both PGP and SPKI certs.

Date: Mon, 01 Dec 1997 14:48:54 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: James Howard <[email-masked]>
CC: [email-masked]
Subject: Re: David, are you listening?
Sender: [email-masked]

This brief note for the record is to indicate that there is little reason to
take the list's time up with a make-wrong contest, as Howard seems determined
repeatedly to do. 

David

James Howard wrote:
<omitted>

Date: Mon, 1 Dec 1997 13:58:25 -0800
To: David Sternlight <[email-masked]>
From: Dave Del Torto <[email-masked]>
Subject: [LISTBIZ] A Point of Order
Cc: Adam Back <[email-masked]>, Ian Grigg <[email-masked]>, Uri Blumenthal <[email-masked]>, [email-masked]
Sender: [email-masked]

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

At 3:15 pm -0800 11/24/97, David Sternlight wrote:
 [material removed]
>>Of course, Security Area folks don't have the depth of knowledge tat
>>David has been exhibiting on the Net for quite a while (:-).
>
>Your gratuitous slam comes with ill grace from someone who apparently
>doesn't understand the meaning of "for all the new standards". We were
>talking about PGP's pulling RSA key generation from free PGP 5.0, and
>pulling RSA entirely from free PGP 5.5.2, neither of which is a new IETF
>standard or even a standard in work.. What is more, they didn't pull it
>from pay PGP 5.0 at the same time, so your argument fails doubly.
> [snip]

Gentlemen,

Regardless of whether I agree with anything any of you has posted on this
topic, or with the manner, lack of manners, or even the *imagined* lack of
manners (as the case may be) with which it has been said, the fact remains
that this particular thread (playing haruspex over PGP Inc's business plans
and development decisions), does not belong on the IETF's OpenPGP list.

Please pause to re-familiarize yourselves with the Charter (see:
<http://www.ietf.org/html.charters/openpgp-charter.html>). This list is
dedicated to the definition, under IETF guidelines, of an *open* PGP
messaging standard, neither designed nor controlled by PGP Inc -- which
company is absent from mention in the Charter (which also, in a fit of
neutrality, lacks any mention of RSADSI or its products). Thus, whether you
like them or abhor them, use them or prefer to ignore them posting your
opinions about PGP Inc's products and/or practices on this particular
working list is conspicuously inappropriate. It may also be counter-
productive to this standards effort (readers: draw your own conclusions).

I believe I can safely assume that the four of you are intelligent enough to
at least agree on one thing: that the Internet badly needs a real-world,
workable standard for interoperable messaging with strong encryption. I also
assume that, as interested/concerned technical participants, it is not your
intention to impede the work of this (or any other) Working Group. If so,
please do us the courtesy of moving this thread to another forum where you
can pursue it at your convenience.

Since it was Mr. Sternlight who first saw fit to insert his opinions here
(without regard for netiquette, or first familiarizing himself with the WG's
Charter), perhaps it would be appropriate to move this thread to
<news:alt.fan.david-sternlight>. Those who are so inclined may spelunk
deeply into his opinions there without further involving the members of this
Working Group (some of whom I suspect might still wish to move the OpenPGP
standard forward, unencumbered by irrelevancies such as debates over why PGP
Inc's freeware doesn't contain this cipher or that hash).

I thank you sincerely for your consideration in this regard,

   dave

____________________________________________________________________________
Quotations by Famous People Who Never Used PGP   [#112]

 "Secrecy is the first essential in the affairs of the State."
  --Cardinal Armand Jean du Plessis, Duc de Richelieu (1585-1642).
  As Chief Minister to Louis XIII, Cardinal Richelieu was notorious as a
  French Monarchist, spymaster, sexual deviant, professional eavesdropper
  and torturer. He was also among the first in history to never use PGP.

Date: Mon, 1 Dec 1997 16:30:15 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

>As far as I remember, MOSS is a MIMEisation of PEM.
>PEM is based on X.509 and X.500. PEM imposed a centric view of the securi=
>ty
>world (1 IPCA)
>
>So MOSS imply X.509 and then ASN.1 as S/MIME does.

Wrong.

MOSS supports lots of different ways of identifying the participants,
X.509, user/mail name, key,...  with different trust models.

You might want to read the specs - see rfc1848, section 4.

--Sandy Murphy

Date: Mon, 01 Dec 1997 15:49:34 -0500
To: [email-masked]
From: James Howard <[email-masked]>
Subject: David, are you listening?
Sender: [email-masked]

FUDlight wrote:
>It would also mean, under a
>single-standard view and the reality of the mountains, that the IETF PGP
group
>is largely wasting its time. Note that I do not hold that view.

 Close, but not quite. _You_ are wasting _our_ time.

 It seems like the last half dozen of your rambling posts to this list have
been finished with "I know this is off topic, but I dont want to stifle 
conversation, so I'll continue in a few minutes with another 10 page 
treatise"    You've repeated the argument about 1000 times that you
think Open-PGP and S/MIME should both exist, and that you think 
S/MIME should be used for all commercial activity and Open-PGP 
should be used only for hobbyists.  Everyone actively working in
this group disagrees with you.  You will not convince a single 
person, no matter how loud you raise your voice or how many times
you send massively crossposted messages through anonymous
remailers to defeat our sternlight filters.

 David, take it to email, or just go away.  You contribute absolutely 
nothing to this group except wasted energy in deleting your messages.
How direct do we have to be to get this through your skull?   

 -james

From: "Alain Zahm" <[email-masked]>
To: "Gunther Schadow" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Date: Mon, 1 Dec 1997 20:59:07 +0100
Sender: [email-masked]

As far as I remember, MOSS is a MIMEisation of PEM.
PEM is based on X.509 and X.500. PEM imposed a centric view of the security
world (1 IPCA)

So MOSS imply X.509 and then ASN.1 as S/MIME does.

----------
> De : Gunther Schadow <[email-masked]>
> A : [email-masked]; [email-masked]; [email-masked];
[email-masked]
> Cc : [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
> Objet : Why do people fight about S/MIME vs. PGP rather than use MOSS?
> Date : dimanche 30 novembre 1997 14:39
> 
> TWO EVERYONE INTERESTED IN INTERNET MAIL SECURITY.
> 
> I am  a member of a  EDI standards organization currently  preparing a
> recommendation  for   their   members on  applying    Internet  E-Mail
> standards.  Of course, security is a major issue here. Our observation
> is that the  field is everything else than  clear while PGP and S/MIME
> camps  are fighting each   other.  Unfortunately, marketing  interests
> seem to play the major role  in that fight. As  much as I am confident
> in the IETF  to stick to its  former  policy propagating open,  freely
> available, simple and effective standards, I am nevertheless concerned
> that industry is  on the edge to do  a lot of harm in  that field.  It
> seems already that the  "Internet Mail Consortium"  will have a strong
> impact in  IETF   standardization, and  as  the   IMC is   an industry
> consortium, is not committed to the IETF policy.
> 
> I   have a strong  personal distaste  with S/MIME,   as the PKCS specs
> require ASN.1, X500 and other OSI stuff that  does not merge very well
> with  the rest of  the Internet infrastructure.  Of  course the use of
> patent encumbered algorithms is  a deleterious "feature" of S/MIME  --
> this also shows whose only real interest  it is to  have S/MIME. It is
> not common sense, it is the profit  of one company: RSA Data Security,
> Inc.  The other  industry that present  itself as deciples of RSA D.S.
> Inc.  is  there to serve as distributors  of patent license royalties.
> This is a very similar marketing strategy as  we all know far too much
> from Bill Gates. Do  you really want  such attitudes to  influence the
> Internet?
> 
> On the other hand PGP  is doing  a  definite cut  in its tradition  in
> order to move  away from  patent  encumbered algorithms. However,  PGP
> uses an ad-hoc binary format as  well. Even though  it is simpler than
> ASN.1/DER,   it is still unnecessarily  obscure,  when  applied in the
> world of MIME. 
> 
> Unfortunately, the MOSS  specification   RFC1848 seems to   have  been
> forgotten. MOSS beats both S/MIME  and PGP in terms  of being open and
> straight forward. It fits  very well into the MIME  world and does not
> require any other technology than MIME. And  most important, it is not
> engaged  in any way  to a  certain set of    algorithms.  MOSS can  be
> translated from and  to S/MIME as well as  traditional or Open PGP. It
> transcends the specifics of any of these technology.
> 
> I really   much like to  see MOSS  having   a future in   the Internet
> community. I would myself write a concise implementation of a flexible
> multi-algorithm   MOSS that would be   freely available.  And I think,
> others would do so as well. 
> 
> Anyway, what I refuse to accept is that the two camps (PGP and S/MIME)
> do not try to collaborate.  Why don't they sit together, listing their
> features in an abstract manner, independent from any format like ASN.1
> or PGP's  or any technology  like X509?  These feature-lists  could be
> merged, in order to  come up with  an abstract security  specification
> that includes both approaches.  This abstract specification could then
> be mapped to concrete technologies, whether  MIME (=> MOSS), ASN.1 (=>
> PKCS) or the PGP-style.  Conversion software could be used as gateways
> between these protocols.
> 
> If this where done,  the IMC or any other  involved party  could show,
> whether their work  in the IETF is  for the sake  of the community  or
> just  for their own  market share. Get back  to common sense, now! Get
> the Internet back into people's hands!
> 
> regards
> -Gunther
> 
> Gunther Schadow-----------Windsteiner Weg 54a, Berlin 14165, FR. Germany
> Dept. of Anaesthesia, Benjamin Franklin Univerity Hospital, Berlin.
> [email-masked]               http://userpage.fu-berlin.de/~gusw
> ----------------------------------#include <usual/disclaimer>-----------

Date: Mon, 01 Dec 1997 10:07:02 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: Phillip M Hallam-Baker <[email-masked]>
CC: Gunther Schadow <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Sender: [email-masked]

Phillip M Hallam-Baker wrote:
> 
> >> 3. Either has "unique" advantages
> >>
> >> see above. If they had, why not listing them and join all advantages
> >> into one standard?
> >
> >Perhaps I should have said "unique and mutually exclusive" to drive the
> point
> >home, though I thought I had done that with my examples. For instance it is
> >mutually exclusive to allow anyone to be a signer and to allow only those
> >meeting certain standards to be signers.
> 
> With respect David this is simply not true.

It is logically true. There are ways around it, as you show with respect to S/MIME.

 <way round it via user intervention omitted>

> 
> The only sense in which the built in client certs are in any
> way special is that the browser company (Microsoft/Netscape)
> has reviewed their Certification Practices Statement and
> their operations and determined that their certificates
> may generally be considered trustworthy. If you disagree
> with this assement then uncheck the box next to VeriSign,
> MCI, Thawte etc and you are entirely OK.

This is the point, though I may have expressed it imprecisely. For
S/MIME-X509-Verisign et al (what can we call that as shorthand?) there are
"Certification Practices Statements" and sets of hardware and software
standards for CAs. Second of all they are reviewed and only those considered
trustworthy in general are pre-installed in general-user browsers (as distinct
from some possible intranet practice). This is a distinct advantage of the
model, as implemented, for arms-length interaction between strangers.

In contrast, the web of trust model, as practiced, doesn't require such
practice statements, nor central checking, nor any particular CA
standard-sets. Instead each user creates his own trust heirarchy and rules.
This is a distinct advantage of that model, for small workgroups where
participants know each other and have an opportunity to verify fingerprints or
keys to identities directly.

Clearly the first approach is useful in some environments, and the second in
others. It would be a mistake for users in arms-length interaction to trust
unverified signatures just as it would be a mistake to force small
self-contained work groups to adopt the overhead of CAs, trust statements,
etc. And unless the canonical models are distinct, a degree of user education
well beyond pragmatic practice is required, and the possibility is opened for
much mischief.

In your own prior message you speak about the mountains having decided how
it's going to be. This is another such example. One may argue (and such
arguments may be interesting and even useful during design of some new
standard if the mountains will go along) that in theory it could be different.
But the proof of the pudding is in the eating and the current menu on offer
involves Certification Practices Statements on the one hand, and roll your own
on the other.

Thus I continue to disagree that there ought to be a single standard in its
base form, but rather two. PGP fans who believe your earlier sketch about
Phil's unmoving view vs. the "mountains" ought to take delight in that
position. The alternative--under your sketch--is for PGP to go away except as
a niche application and S/MIME to continue to be the de facto standard and
eventually become the de jure standard. It would also mean, under a
single-standard view and the reality of the mountains, that the IETF PGP group
is largely wasting its time. Note that I do not hold that view.

To avoid misunderstanding I repeat my basic mantra--each trust model in its
pure form has its place and to combine one with the other in the base design
is a bad idea, thought providing a fail-safe multi-step escape hatch giving
users some flexibility (as you've illustrated for S/MIME in Explorer) may be
useful. Nevertheless I suggest the canonical forms are distinct, and should
remain so: In S/MIME-X509 as practiced, users are provided with high-level CA
keys which meet CPS tests; in web of trust as practiced, users must build
their own CA structure on a case by case basis but aren't limited by anyone
else's idea of CPS tests (pace Thawte).

Frankly speaking, I have the impression this is really not a useful discussion
to continue in the PGP and S/MIME 3 IETF lists since I think de facto we've
got two standards evolving and the commonality is likely mostly to be in the
area of envelopes. But it is not for me to try to shut off discussion on this
interesting topic, if others find it useful.

David

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>, "Gunther Schadow" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Date: Mon, 1 Dec 1997 12:02:54 -0500
Sender: [email-masked]

>> 3. Either has "unique" advantages
>>
>> see above. If they had, why not listing them and join all advantages
>> into one standard?
>
>Perhaps I should have said "unique and mutually exclusive" to drive the
point
>home, though I thought I had done that with my examples. For instance it is
>mutually exclusive to allow anyone to be a signer and to allow only those
>meeting certain standards to be signers.

With respect David this is simply not true. An S/MIME client can be
used in precisely the PGP web of trust mode. I will take Outlook
Express as an example but the same holds for other S/MIME
clients such as Navigator only the process is slightly different.

If someone sends me a certificate that is either self signed
or signed by a root not trusted by the browser I simply click
a few buttons to add the sender to my address book then go
to 'properties->digital ids' I select the untrusted cert and
select 'explicitly trust this certificate'. If I want to trust the
key as a signing key I click 'inherit trust from this cert.'.

The only sense in which the built in client certs are in any
way special is that the browser company (Microsoft/Netscape)
has reviewed their Certification Practices Statement and
their operations and determined that their certificates
may generally be considered trustworthy. If you disagree
with this assement then uncheck the box next to VeriSign,
MCI, Thawte etc and you are entirely OK.

This is precisely what many people using VeriSign
private label (aka OnSite) certificates do. There is no
reason to force them to recognize the public certs
on an Intranet.

There is a rather nice poster put out by PGP which shows
all the various options for arranging certificate issue. As
the poster shows PGP can be used in hierarchical fashion
if desired. Unfortunately it overlooks the fact that X.509v3
certificates are equally flexible.

Please don't start the tiresome flames about personal interest.
Its not as if PGP Inc.had no vested interest. I happen to believe
that the more ways certificates can be used the larger the
market for them will become. It is certainly not in our interest
to be dogmatic.

Let us all stop being dogmatic about all this then. If there was
indeed a problem with the certificate structure of S/MIME that
would not make its transport formats invalid. There would be
no need to obsolete 25 million clients simply to introduce
a different trust model. Evolve the certificate spec to a new
level, either in ISO or if need be in the IETF.

This is starting to look like one of those programming language/
editor/ Operating System wars*. Ho hum...

                Phill

* BTW the answers are occam, LSE and VMS or Java, does not
matter, NT.

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Gunther Schadow" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Date: Mon, 1 Dec 1997 11:13:46 -0500
Sender: [email-masked]

>But back to the internet. Tell me, who invented it? Industry
>was in fact not really interested in it before some Physicists at CERN
>(again a governmentally founded research organization) invented the
>WWW. The industry discovered the WWW as a perfect marketing tool, and
>helped spread the HTTP/TCP/IP as the most important informational
>revolution since the Television. But did they add any technological
>benefit to these protocols? Tell me? 

As one of the longtime membersof that CERN team I can
assure you that Marc Andressen, the founder of Netscape
had more than a minor role in helping develop the technology.
Just because a Netscape PR flack may occasionally give
the impression that he invented everything all by himself
does not mean his contribution should be ignored. I am
also thinking of people such as Ari Luotenen (inventor of
the Web proxy), Rob Mcool (co invented CGI with Ari
along with much else) and Eric Binna (whose contibutions to 
HTML are extensive). Throughout the entire time that 
Dave Raggett has worked on HTML he has been paid 
by HP.

The other reason the 'government funded the Web' meme
is simply inaccurate is that CERN never authorized the 
project. To my knowledge the limit of CERN's support
was to provide two student interns for a year (Henrick
and Ari), thats not to say they were not incredible interns
but from the reports one would imagine that there was a
team of twenty people. Everyone else who worked on the
Web did so by diverting resources from some other 
project. I was meant to be working on C++, instead I 
became the security 'team'. There is absolutely no way
that the resources that CERN provided could have allowed
the Web to come a tenth of the way it has. Support from
industry was absolutely essential. Without it there would 
not have been the money to fund the Web consortium 
after our CERN contracts expired and folk asked about
the stuff we had been 'supposed' to do.

Industry has always had a major role in setting IETF standards.
Anyone who thinks that an IPV6 protocol that was not supported
by CISCO, 3COM et al could survive does not understand the
process. 

>First of all it was not RSADSI. It was Rivest, Shamir and Adleman, who
>worked at MIT founded by governmental grants (a fact that -- in your
>voice -- should discredit the innovative nature of the RSA
>algorithm). As much as five (5!) years later, the patent was
>claimed. 

This is not true. It was issued five years later but the application
date was six months after it was published. RSADSI was formed
by the patentees to exploit their invention. Ron Rivest was 
Chairman until the SDI buyout and still plays an active role.

>This is rubbish, and you know it. There is not much to be
>theoretically developed in security today, all knowledge is there for
>more than ten years. 

That is simply not true Micali's certificate revocation technique
and the Pedderson phone tick modulus appeared in the past
three years. You may be unaware of developments but that
does not mean that they are not happening. Bruce's book
only contains developments that happened before it went to 
press, funny that.

>1. The "userbase"
>
>The userbase that you cite comes easily by having Netscape and
>Microsoft select S/MIME. But don't ask how many S/MIME installations
>do exist, but how many of them are actually *used*. I'd be interested
>in a good statistics that compares actual *users* not posessors of
>S/MIME vs. PGP software.

That is not the appropriate measure. What does it take for a
user to abandon a built in facility to use another one?

If I wish to sign an email I know that almost every recipient will
have S/MIME and only a very small number will have gone
to the trouble of downloading PGP. If I wish to allow people
to send me encrypted mail the same argument means that
an X.509 cert wins over a PGP key.

The IETF has been talking about encrypted and signed mail
for the past ten years. The main reason it has not taken off is
that security enhanced mail clients have only ever reached
a fraction of the userbase. As a direct result of SSL every
browser already has a complete RSA suite and X.509v3
certificate suite. It is no accident that they are interested in
a solution that is compatible with that base.

Look at the penetration of plug in applications for browsers.
Shockwave, Vivo, RealAudio etc appear on only a small
fraction of sites despite the ready avaliability of plug ins
and the growing trend for them to be made available at
the same time the browser is.

I can't debug other companies business plans. Hey maybe
Phil Z. is right and he can win this battle. Just don't imagine
that because it is logical to have a common standard and 
Phil Z. is determined not to budge that the mountains are
going to move to him. The mountains seem to have figured
out their idea of what the common standard is and be quite
happy where they are. 

                Phill

Date: Mon, 01 Dec 1997 10:40:50 +0000
From: Ian Brown <[email-masked]>
To: Hal Finney <[email-masked]>
CC: [email-masked]
Subject: Re: expedience, consensus and editing
Sender: [email-masked]

Hal Finney wrote:

> I wonder if it wouldn't make more sense though to define a general
> MIME type for a base64 encoded PGP object.  This would ***NOT*** be
> an alternative or replacement for PGP/MIME.  That protocol is used to
> protect MIME body parts, and would still be the protocol of choice for
> email and similar appliations.
> 
> This proposal would simply be a transport layer for a binary PGP message.
> It would be an alternative/replacement for PGP's existing ascii armor.
> We'd add a couple of parameters to encode the small amount of data we
> currently have in the ascii armor headers and header line.

This is an *excellent* idea. It seems similar to S/MIME's 'envelope'.
Let's do it!

> (Including "PUBLIC KEY BLOCK" would mean that this would subsume the
> application/pgp-keys content type from RFC2015.)

Just one reservation. If you had separate apps for crypto and key
management (like PGPtray and PGPkeys) you would then have to have at
least a stub application which looked at the parameter and launched the
appropriate application. If we kept application/pgp-keys, that type
could be explicitly associated with a key management program, and
application/pgp kept for the crypto itself.

Ian :D