Subject: Re: 25 Million S/MIME Users
From: David Sternlight <[email-masked]>
To: Lindsay Mathieson <[email-masked]>
Cc: IETF OpenPGP <[email-masked]>
Date: Sun, 30 Nov 1997 20:06:58 -0800

Lindsay Mathieson wrote:
> 
> >about its business, and has by far the most massively installed base
> >on the
> >Internet,
> >in terms of both Netscape and Microsoft, as well as by far the
> >broadest
> >capital
> 
> Ok, I'll react to this, so as to resolve one myth:
> 
> 1.      The 25 million+ installed user base of Netscape/MS counts as a user base
> for S/MIME
> 
> Bollocks - how many of those people know, care or use the S/MIME integration
> in Microsoft/Netscapes Mailers. I have IE & Communicator & Netscape 3.0
> installed, but I don't use the S/MIME features in any of them. Given the
> weak state of US export encryption this side of the pacific (Australia) I
> doubt many people use S/MIME at all.
> 

The point to which I was responding was "installed base". My response was
accurate. If you're going to discount installed base for usage, PGP's figures
must be similarly discounted. So gross or net, apples and apples, please.

I suggest that pursuing this topic further is likely off-purpose for this list.

David

Date: Mon, 01 Dec 1997 01:47:54 +0000
To: [email-masked], James Howard <[email-masked]>
From: Chris Liljenstolpe <[email-masked]>
Subject: Let it die (was: Re: David, get stuffed.)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Folks -

	This is not going anywhere in getting the work done on this spec.  This
kind of discussion is political, and, by now, is way out of the charter of
these lists.  There is a job to do here, and a job to do on the s/mime
working group.  Let's deal with the technical stuff and debate the politics
later.  Maybe we need a list for these discussions, say:
mail-crypto-sniveling

	Chris

At 1997-11-30 22:06 , David Sternlight wrote:
>
>
>James Howard wrote:
>
>> Please take your borderline paranoia and correspondence-school
>> legalese back to the alt groups where it belongs.  Your continued
>> posts to this list under forged headers is simply the icing on the cake.
>
>I do not post under forged headers and any charge I do so is a lie.
>
>David
> 
mailto: [email-masked]  <http://www.io.com/%7Ecds>http://www.io.com/~cds
"If ye love wealth greater than liberty, the tranquility of servitude
greater than the animating contest for freedom, go home from us in peace.
We seek not your counsel, nor your arms. Crouch down and lick the hand that
feeds you. May your chains set lightly upon you; and may posterity forget
that ye were our countrymen."
-- Samuel Adams

Date: Sun, 30 Nov 1997 20:48:59 -0500
From: Anonymous <[email-masked]>
Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at <[email-masked]>.
To: [email-masked], [email-masked]
Sender: [email-masked]

Stupid lying forger David Sternlight wrote:
>James Howard wrote:
>
>> Please take your borderline paranoia and correspondence-school
>> legalese back to the alt groups where it belongs.  Your continued
>> posts to this list under forged headers is simply the icing on the cake.
>
>I do not post under forged headers and any charge I do so is a lie.

Stupid lying forger David Sternlight is lying again, as usual.

Date: Sun, 30 Nov 1997 13:32:14 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: expedience, consensus and editing
Sender: [email-masked]

Ned Freed, <[email-masked]>, writes:
> Existing facilities can be used to do detached MIME signaturues. Specifically,
> one constructs a message/external-body MIME object that contains a
> content-md5 field describing the external data. One then signs this
> part. The result is a detached signature that also contains a pointer
> to the actual data which has been signed.

Yes, this is similar to a PGP detached signature.  For some applications,
it is superior since it includes a direct reference to the data being
signed.  However although it is functionally similar it is not a MIME
encoding of a PGP detached signature.  As I wrote earlier, PGP/MIME can
be thought of as an alternative protocol to PGP, with similar functionality
but different ways of achieving it.

> If you don't want the pointer then the right answer is to define a
> MIME type for a existing PGP detached signature object.

Yes, and likewise we could define MIME types for other PGP objects,
like binary signed objects.

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.

Something like:

   Content-Type: application/pgp; pgp-data-type="SIGNATURE";
    pgp-version="PGP for Personal Privacy 5.0"
   Content-Transfer-Encoding: base64
   
   iQA/AwUBNIHX9cDh8jnv1nHwEQKPigCfe+AIn3e7ij8BG6UYFhCHXaIJZZ4An3Ad
   bZC17Lo0/Yt/GH02/lVgDTYD

The pgp-data-type represents the data from the normal "-----BEGIN
PGP" line.  It could be "SIGNATURE", "MESSAGE", "PUBLIC KEY BLOCK",
or whatever others get defined.  The pgp-version has the version
info from the PGP ascii armor.  We could have a pgp-comment as well.
(Including "PUBLIC KEY BLOCK" would mean that this would subsume the
application/pgp-keys content type from RFC2015.)

Then we have the base64 encoded PGP data, just like in a regular ascii
armor block, except that we don't have a checksum.

Application/pgp had been considered and rejected for PGP/MIME, because
they wanted to exploit the MIME security multiparts from RFC1847.  I think
that is a good decision for that purpose.  Having solved that (modulo
improvements) there still may be a role for a simple transfer encoding
to allow transport of general PGP objects.  It would even be possible
to translate between the ascii armor format and this encoding, except
for the checksum.  (We could think about making the checksum be an
additional optional parameter.)

This would allow MIME compliant mail readers to automatically launch
PGP on messages containing PGP objects.

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

Date: Sun, 30 Nov 1997 15:54:53 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: 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?
Sender: [email-masked]

Gunther Schadow wrote:
> 
> Sorry for the massive cross-post, I just didn't know which e-mail list
> David's reply came about...

It was posted to all the groups your original post went to. I simply did a
"reply" in my mailer. ;-)

> First I'll summarize your points:

(more like labelling, but let's assume readers are following this thread.)

> 
> 1. The "userbase"
> 
> 2. Trust "algorithms"
> 
> 3. Either has "unique" advantages
> 
> 4. Intellectual "property"
> 
> 5. The "gift model" no longer holds today
> 
> > Similarly, we've seen the sight of PGP Inc. disenfranchinsing a huge
> > RSA-key PGP user base in free version 5.53, along with the web of
> > signatures built up over several years. Again--never mind; the Open PGP
> > working group must simply insure that that cannot happen again with Open
> > PGP.
> 
> 6. David, you are obviously from the S/MIME camp, and you keep
> fighting against PGP, even though I did not raise my voice for PGP
> vs. S/MIME. There is a misunderstanding to my open letter.

I am a user of both. I was one of the first users of PGP until I found it
infringed. I then mounted a campaign behind the scenes (I wasn't looking for
credit, and I wasn't the only one) with Bidzos to license RSA for PGP. In the
event, Phil's intransigence (see Garfinkel's book) got in the way for a very
long time, but this wasn't because of any lack of my efforts, Eric Hughes'
efforts, or the goodwill of Jim Bidzos (see Garfinkel). When MIT PGP came out
as street-legal I was one of the first users, and both Jeff Schiller and Derek
Atkins signed my key. I have also helped beta test various versions, including
two US/Canada ones and FileCrypt. I find each of PGP and
S/MIME-X509-Netscape/Explorer have their unique and non-substituable uses,
mainly revolving around distinctions between their trust models.

As for your claim that you weren't raising your voice for PGP, if you reread
your post perhaps you will see why I thought in places you were. Never
mind--it's not worth sidetracking a discussion of principles and objectives
for that.

> 
> 7. Either standards are not a reduction of choice and optionality, or
> you are against the standardization.

There are two distinct trust models and systems involved. Each has a
non-substitutable and important place. Thus two standards are appropriate and
a reductionist argument isn't. Such cases are common in standards work.
Eventually the marketplace may choose one over the other, or each may be
viable for its purpose. We're not writing the Decalogue here.

> 
> If yor S/MIME has the "user base" and is self sufficient in that, why
> are you seeking for the blessings of being called an Internet
> standard? It sounds to me as if you're arguing  It is probably an abuse > of the term "standard" not being an end in itself but a marketing tool.

Do you have a question about substance here rather than an accusation?

> 
> > > 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.
> >
> > Like the bumblebee, S/MIME is out there in millions (well over 25 million)
> > of installed base copies of Netscape and Explorer. Perhaps if there is a
> > problem with the "internet infrastructure" it is that which needs
> > adjustment.
> 
> What I meant by "infrastructure" is design and technology. The IETF
> has early enough opened itself up to OSI concepts and ASN.1. However,
> these keep to not really fit into the rest of the internet
> infrastructure. One good example is that X500 needed LDAP to be
> deployed within the Internet infrastructure.

Sounds like you're arguing for some combination of the status quo and the easy
way out.

> 
> > Thus far I've not heard of the Internet crashing down because
> > of the particular crypto protocols in, say, Netscape. There are far more
> 
> I am not talking about crashes -- these happened to me back in the
> times when I used "userbase" and "marketplace" software :-). I am
> talking about interoperability on an open an equal basis. I speak your
> language, you speak mine.

Esperanto has not caught on in the marketplace, and for good reason.

> most innovations have been achieved by governamntal funding and *not*
> on industry on a competitional basis.

That isn't accurate. "Some" would be more apt. But you weren't arguing for
that in any case, since government funding for the Internet is mostly over.
You were arguing for the free "gift" model rather than the intellectual
property model.

<more stuff on the big government R&D model omitted>

> 
>  There is not much to be
> theoretically developed in security today, all knowledge is there for
> more than ten years.

I leave that statement for readers to contemplate, with my jaw hanging down in amazement.

>The problem is deployment. Companies seem to be
> too involved with patent rights and marketing that they are unable to
> deploy knowledge and standards that do exist since many many
> years.

That's also one for the readers to consider. Hint--there are well over 25
million copies of complete mail/news/browser software packages deployed using
S/MIME, and more copies are downloaded by the day--at a massive rate
heretofore not seen.

> 
> 
> 2. Trust "algorithms"
> 
> PGP is already on its way towards trusted third parties. And it is
> useful. Conversely, I have heard S/MIME and SSL to be used without
> real TTPs, but with a locally base of certificates. You are right,
> both methods have its uses. But you are badly wrong in pointing out
> that both methods require mutually non-interoperable software.

I didn't say "require". I said each trust model would become corrupted if it
attempted to encompass the other.

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

David

Date: 1 Dec 1997 0:39:56 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: expedience, consensus and editing
To: Hal Finney <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

> For example, I could request that someone send me a signature
>on some data I received earlier.  They could create a signature on 
>the
>data and send it to me, without having to re-send the data itself.

My mistake, I see what you mean now.

That would be very useful for software distribution - perhaps a mime type as
for certifcate distribution would be useful, e.g. Content-Type:
application/pgp-signature

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

Date: 1 Dec 1997 0:39:56 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: 25 Million S/MIME Users
To: IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>about its business, and has by far the most massively installed base 
>on the
>Internet,
>in terms of both Netscape and Microsoft, as well as by far the 
>broadest
>capital

Ok, I'll react to this, so as to resolve one myth:

1.	The 25 million+ installed user base of Netscape/MS counts as a user base
for S/MIME

Bollocks - how many of those people know, care or use the S/MIME integration
in Microsoft/Netscapes Mailers. I have IE & Communicator & Netscape 3.0
installed, but I don't use the S/MIME features in any of them. Given the
weak state of US export encryption this side of the pacific (Australia) I
doubt many people use S/MIME at all.

I doubt their is a high take of S/MIME in the US either.
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Beta Vs 2.6.1.2, on December 1, 1997, in Win95 4.0
	http://www.blackpaw.com/

Date: Sun, 30 Nov 1997 23:41:54 +0100 (MET)
From: Gunther Schadow <[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]
Sender: [email-masked]

Sorry for the massive cross-post, I just didn't know which e-mail list
David's reply came about...

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

First I'll summarize your points:

> Actually, my perception is somewhat different. It is that S/MIME is
> simply going about its business, and has by far the most massively
> installed base on the Internet, in terms of both Netscape and
> Microsoft, as well as by far the broadest capital investment, in

1. The "userbase"

> terms of its consortium. I use both, think each has its place, and
> think the difference is in trust algorithms.  I believe each trust
> algorithm has important uses and neither should try to subsume the
> other because it will lose unique advantages for the things it is
> well suited.

2. Trust "algorithms"

3. Either has "unique" advantages

> My own observation is that most such conflicts (other than religious wars)
> stem from the unwillingness on the part of PGP fans to acknowledge that
> S/MIME involves intellectual property--a fact--which is entitled to a fair
> return. This is most odd, since PGP is also a commercial product which is
> sold in the marketplace.

4. Intellectual "property"

> There is also a deeper issue involved. The Internet was originally built
> with a significant component of the "gift" model. Software was free for the
> taking, and a rich uncle, the US taxpayer, provided for much that had to be
> paid for. This is no longer the case, and
> the Internet is well and truly a free-market commercial proposition
> although some users are subsidized to this day, mostly academics and
> students. It is exactly these users who seem most vociferous about "free".
> This is both inappropriate and maladaptive.

5. The "gift model" no longer holds today

> Similarly, we've seen the sight of PGP Inc. disenfranchinsing a huge
> RSA-key PGP user base in free version 5.53, along with the web of
> signatures built up over several years. Again--never mind; the Open PGP
> working group must simply insure that that cannot happen again with Open
> PGP.

6. David, you are obviously from the S/MIME camp, and you keep
fighting against PGP, even though I did not raise my voice for PGP
vs. S/MIME. There is a misunderstanding to my open letter.

> > 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.
>
> One must face the reality of both existence and choice in the marketplace.

7. Either standards are not a reduction of choice and optionality, or
you are against the standardization. 

If yor S/MIME has the "user base" and is self sufficient in that, why
are you seeking for the blessings of being called an Internet
standard? It is probably an abuse of the term "standard" not being an
end in itself but a marketing tool.

> > 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.
>
> Like the bumblebee, S/MIME is out there in millions (well over 25 million)
> of installed base copies of Netscape and Explorer. Perhaps if there is a
> problem with the "internet infrastructure" it is that which needs
> adjustment.

What I meant by "infrastructure" is design and technology. The IETF
has early enough opened itself up to OSI concepts and ASN.1. However,
these keep to not really fit into the rest of the internet
infrastructure. One good example is that X500 needed LDAP to be
deployed within the Internet infrastructure. 

> Thus far I've not heard of the Internet crashing down because
> of the particular crypto protocols in, say, Netscape. There are far more

I am not talking about crashes -- these happened to me back in the
times when I used "userbase" and "marketplace" software :-). I am
talking about interoperability on an open an equal basis. I speak your
language, you speak mine. That is O.K. Any ideolect for the sake of
"intellectual property" (what a term after all!) is impeding
interoperability. You raised the points about RC2 elsewhere. And, was
it you, who used the term "fascist" for the people who claim that
internet standards be openly specified and freely useable from that
specification? (If it was not you, it was an other David -- but your
points where so similar)

> Actors are entitled to a return from their investment in intellectual
> property. In this case the ultimate beneficiary are the assignees of the
> inventors, e.g. MIT. You are appealing to a model here which has long been
> discredited as a basis for the stimulation and preservation of innovation..

Oops? I think I am hearing wrong. "A model which has long been
discredited as a basis for the stimulation and preservation of
innovation". Now tell me, who invented the Internet that Microsoft is
so proud of today (at last, once they became aware of it)? It was
developed at universities, funded by DARPA. This is why I think that
most innovations have been achieved by governamntal funding and *not*
on industry on a competitional basis. Think of the NASA for an other
example. 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? So how can you say that anything
else "discredits" itself as a basis for innovation? I have been
repeatedly frustrated by the intellectual poorness of software
industry, and I would long have quit informatics if there was not the
other side: inspiring researchers that live the freedom of speech and
intellectual sharing!

> It was RSADSI who, in effect, brought RSA and many other algorithms to the
> marketplace, including two used in PGP. Similarly, it was IDEA which also
> (as a commercial product via ASCOM AG) contributed to PGP. RSA Laboratories
> continues to be one source for much of the world's crypto research outside
> of government. That isn't an eelymosynary gift but must ultimately draw on

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 patent was then sold to RSADSI. Since then, RSADSI
together with US crypto legislation and NSA is effectively fighting
against the wide spread use of security standards in the name of some
"intellectual property" (and anti-kommunist paranoia at the side of US
govt. and NSA). It is the scandal that the discovery of asymmetric
ciphers is only about 10 years olter than that of packet switched
networking. While the latter succeeded revolutionizing the
informational world, the world of security still suffers from the new
advocates of the "intellectual property" construct.

> payment for intellectual property. The notion that the Internet should use
> only free crypto is a guaranteed formula to kill such innovation except in
> the glacial corridors of academe, and force the successful commercial
> actors to "tunnel" rather than benefitting the entire net. And even those
> magisterial academic confines lead to things like RSA and RSADSI; to patent
> licensing and charging for intellectual property.

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. The problem is deployment. Companies seem to be
too involved with patent rights and marketing that they are unable to
deploy knowledge and standards that do exist since many many
years. This is the kind of "anti-innovative" behavior that is
discrediting the software industry as being oriented towards commerce,
profit at first, and not towards intellectual innovations, not even
towards their user's needs: as interoperability is one of the most
important user-need being sacrificed for the sake of "intellectual
property". 

> Of course if you want guaranteed old technology, don't use anything until
> the patent has expired.

Diffie-Hellman is luckily out of that margin. It is good old
technology!

> <MOSS discussion omitted>

that was in fact my main point. But you seem to love fighting against
PGP. So, here goes ...

> > Why don't they sit together, listing their
>
> I believe this would be a major blunder.

Boy, can you explain me how in the world reconciliation can ever be a
blunder? The "world of difference" is speaking here.

I would stop here, did I not start with listing your arguments in a
few points.

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.

2. Trust "algorithms"

PGP is already on its way towards trusted third parties. And it is
useful. Conversely, I have heard S/MIME and SSL to be used without
real TTPs, but with a locally base of certificates. You are right,
both methods have its uses. But you are badly wrong in pointing out
that both methods require mutually non-interoperable software.

The interesting point is that the only real algorithmical difference
between traditional PGP vs. RSADSI was the use of IDEA vs. RC4. MOSS
-- here I am at my point -- shows clearly how easy it is to just use
these algorithms at will in a modular and interoperable way. They are
both so similar and the differences are so ridiculously unimportant
that it is a scandal that there is no common open Internet security
standard yet.

3. Either has "unique" advantages

see above. If they had, why not listing them and join all advantages
into one standard? It is blunder? It is the only intellectual work
that is missing in the field. See how the world suffers from commerce
which is obviously unable to bring this little reconciliation while
loosing the slight "difference" which they are all so proud of.

4. Intellectual "property"

It is a term that has to be discussed. But not now. The interesting
point is to study the intellectual revolution that spread from the
invention of Gutenberg's technology to spread ideas and compare it
with the recently raised issue of "property". Ridicoulous if Einstein,
Heisenberg, Zuse, Watson, or whoever you name, had insist on their
"intellectual property".

5. The "gift model" no longer holds today

I showed you the opposit above. Again tell me, who invented the
internet and what did "the industry" do about it?

6. David, you are obviously from the S/MIME camp, and you keep
fighting against PGP, even though I did not raise my voice for PGP
vs. S/MIME. There is a misunderstanding to my open letter.

My claim was to preach reconciliation on an open basis. I am sorry for
this thread to fall into a flamewar.

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: Sun, 30 Nov 1997 14:06:34 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: James Howard <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: David, get stuffed.
Sender: [email-masked]

James Howard wrote:

> Please take your borderline paranoia and correspondence-school
> legalese back to the alt groups where it belongs.  Your continued
> posts to this list under forged headers is simply the icing on the cake.

I do not post under forged headers and any charge I do so is a lie.

David

Date: Sun, 30 Nov 1997 16:16:01 -0500
To: [email-masked], [email-masked]
From: James Howard <[email-masked]>
Subject: David, get stuffed.
Sender: [email-masked]

Please take your borderline paranoia and correspondence-school 
legalese back to the alt groups where it belongs.  Your continued 
posts to this list under forged headers is simply the icing on the cake.
You refuse to acknowledge that people simply dont give a rat's ass
about what you have to say, and now you're making an effort to 
render our sternlight-filters inoperable.  The only other group to 
use such tactics are the bulk-emailers.   Nice company you're keeping.

You've said it all before.  We understand your position.  You think it
is perfectly OK that the underlying crypto routines used throughout
the net should be required to pay RSA a royalty.  This group does not.
There is no middle ground in this argument, so why waste your breath
trying to convince us?

Please, and I mean this in the nicest possible way, get the hell out
of here and don't come back.

 cheers,
   james

Date: Sun, 30 Nov 1997 13:11:09 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
Subject: Re: Helpful
Sender: [email-masked]

An anonymous coward forwarded a discussion from another newsgroup to the Open PGP mailing list in an
attempt to inflame the discussion here. The comments were in the context of the discussion and tone in
the newsgroups to which they were originally posted, but are both inflammatory and off-topic for the
style and tone of the Open PGP mailing list. I ask readers to disregard it, though the issues of
concern may be appropriate to another venue.

David

Mix wrote:

> Subject: Re: RSA Blows Standards (S/MIME) Smoke
> From: [email-masked] (David Sternlight)
> Date: 1997/11/06
> Message-ID: <[email-masked]>
> Newsgroups: alt.security.pgp,comp.security.pgp.discuss,alt.security,talk.politics.crypto,alt.privacy
>
> In article <[email-masked]>, [email-masked] (Greg Hennessy) wrote:

<omitted>

Date: Sun, 30 Nov 1997 15:00:12 -0600
To: [email-masked]
From: Black Unicorn <[email-masked]>
Subject: Re: Helpful
Sender: [email-masked]

>>If RSADSI chooses to release RC2 because they think the benefit of
>>having S/MIME be an internet standard outweighs the benefit of having
>>RC2 be a trade secret, that is RSADSI's decision to make.
>>
>>They can continue to push S/MIME without being an internet standard.
>
>You are flying in the face of many years of court rulings on such topics
>as country club discrimination. Think it through.

Oh, please.
Return the law degree you got from your box of frosted flakes, please.  You
are making a mockery even of that.

I can see I'm going to have to beef up my Sternlight filter.

Date: Sun, 30 Nov 1997 12:47:12 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: Gunther Schadow <[email-masked]>
CC: [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]

Gunther Schadow wrote:

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

Actually, my perception is somewhat different. It is that S/MIME is simply
going
about its business, and has by far the most massively installed base on the
Internet,
in terms of both Netscape and Microsoft, as well as by far the broadest
capital
investment, in terms of its consortium. I use both, think each has its
place, and think
the difference is in trust algorithms. I believe each trust algorithm has
important
uses and neither should try to subsume the other because it will lose
unique advantages for the things it is well suited.

My own observation is that most such conflicts (other than religious wars)
stem from the unwillingness on the part of PGP fans to acknowledge that
S/MIME involves intellectual property--a fact--which is entitled to a fair
return. This is most odd, since PGP is also a commercial product which is
sold in the marketplace.

There is also a deeper issue involved. The Internet was originally built
with a significant component of the "gift" model. Software was free for the
taking, and a rich uncle, the US taxpayer, provided for much that had to be
paid for. This is no longer the case, and
the Internet is well and truly a free-market commercial proposition
although some users are subsidized to this day, mostly academics and
students. It is exactly these users who seem most vociferous about "free".
This is both inappropriate and maladaptive.

As I understand it, the real Internet policy about intellectual property is
NOT "unencumbered" but rather  something like "'freely available on
non-discriminatory--or perhaps "reasonable"--terms"'. Internet policy is
supposed to be (if my understanding is correct) "intellectual property
neutral" and not hostile to intellectual property. If that is correct, much
recent pressure on RSADSI with respect to S/MIME was from a few small
actors with loud voices throwing their Internet weight around. Never
mind--we now have an S/MIME 3 working group with certain ground rules and
that's where we're proceeding from.

Similarly, we've seen the sight of PGP Inc. disenfranchinsing a huge
RSA-key PGP user base in free version 5.53, along with the web of
signatures built up over several years. Again--never mind; the Open PGP
working group must simply insure that that cannot happen again with Open
PGP.

> Unfortunately, marketing  interests
> seem to play the major role  in that fight.

I have observed this entirely as: 1. Attempts to restrict S/MIME
intellectual property and disadvantage RSADSI and 2. Attempts to tilt the
playing field to the advantage of PGP Inc.  by taking advantage of the fact
that originally PGP had little intellectual property of its own but used
the intellectual property of others and some of that intellectual property
of others has now come off patent protection. 3. Attempts to make wrong the
actions of RSADSI in protecting their intellectual property and pursuing
their legal right to insure that licensees honor their agreements. From my
perspective it has looked like a crooked dice game. When the above is
brought to attention, we often see ad hominem responses indicative of the
weaknesses of those proponents' intellectual positions.

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

One must face the reality of both existence and choice in the marketplace.
The IMC represents successful actors in that marketplace. Some of the
smaller ones support PGP but the most successful support S/MIME. The
largest supporter of PGP in that group is Qualcomm and if you strip out
their non-crypto business they are relatively small. Thus complaints about
the IMC read like more pro-PGP partisanship. The facts are that Ford, GM,
and Toyota make the cars, not MIT or DeLorean, and any realistic standard
has to take account of what is out there in the marketplace. An attempt to
impose the desires of a small self-appointed elite is doomed to fail under
the current massively public Internet model.

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

Like the bumblebee, S/MIME is out there in millions (well over 25 million)
of installed base copies of Netscape and Explorer. Perhaps if there is a
problem with the "internet infrastructure" it is that which needs
adjustment. Thus far I've not heard of the Internet crashing down because
of the particular crypto protocols in, say, Netscape. There are far more
serious threats to worry about. My fear of S/MIME creating problems for
"the rest of the internet infrastructure" is 47th on my list of fears, just
below the fear of aliens taking over my computer. I do not mean to make
light of your concerns, but given the huge installed base of S/MIME
applications out there now, some acknowledgement of the realities of the
marketplace is in order.

> Of  course the use of
> patent encumbered algorithms is  a deleterious "feature" of S/MIME  --
> this also shows whose only real interest

Here you move from a laudable discussion of principles and objectives to
the imputation of motives and make-wrong. It does not add to the
discussion.

> it is to  have S/MIME. It is
> not common sense, it is the profit  of one company: RSA Data Security,
> Inc.

Actors are entitled to a return from their investment in intellectual
property. In this case the ultimate beneficiary are the assignees of the
inventors, e.g. MIT. You are appealing to a model here which has long been
discredited as a basis for the stimulation and preservation of innovation..
It was RSADSI who, in effect, brought RSA and many other algorithms to the
marketplace, including two used in PGP. Similarly, it was IDEA which also
(as a commercial product via ASCOM AG) contributed to PGP. RSA Laboratories
continues to be one source for much of the world's crypto research outside
of government. That isn't an eelymosynary gift but must ultimately draw on
payment for intellectual property. The notion that the Internet should use
only free crypto is a guaranteed formula to kill such innovation except in
the glacial corridors of academe, and force the successful commercial
actors to "tunnel" rather than benefitting the entire net. And even those
magisterial academic confines lead to things like RSA and RSADSI; to patent
licensing and charging for intellectual property.

Of course if you want guaranteed old technology, don't use anything until
the patent has expired.

<Microsoft bogeyman analogy omitted>

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

You seem to forget that although PGP would like its royalty costs to be
"free", it charges for its commercial products. One cannot make a case here
for anything other than self-interest. It is true that PGP gives away
crippled non-commercial versions that won't affect what it sees as its self
interest. RSADSI gives away RSAREF and RSAREF2 as well, so that one is a
wash.

<MOSS discussion omitted>

> Anyway, what I refuse to accept is that the two camps (PGP and S/MIME)
> do not try to collaborate.

The two working groups are, as I understand it, under instructions to
collaborate when areas of commonality are involved. What is more, MIME
provides an overarching structure that could bring both under at least a
common "envelope" structure if desired. Let us hope such cooperation is
more than grudging lip service.

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

I believe this would be a major blunder. The advantages of web of trust are
that anyone may be his own certifier, with whatever rules he wishes to make
and perhaps publish. The advantages of rigid-heirarchical are that nobody
but audited, known-standard certifiers with particular published rule-sets
are valid. The first is extremely useful among small, mutually known groups
in which members are willing to investigate each certifier's standards. The
second is essential for arms-length and commercial interaction in which
users must rely on standardized, known, supervised assurances with respect
to trust procedures and cannot personally investigate each certifier.

Trying to make either model do the job of the other will corrupt it such
that it will lose some of its own advantages. I note that most action in
this direction is with respect to PGP trying to get some of S/MIME's
"market share". I think this to be a very bad idea. In the end, unless
there are versions of PGP software which will, hard-wired, accept only
rigid-heirarchical trust, this will corrupt both trust models with respect
to PGP.

What I am saying is that although much focus has been on particular
algorithms in the past, the "openness" of Open PGP reveals that this is
really a distraction (fundamental principle-wise), and the real crux of the
matter is trust models.

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

Again a specious dichotomy is being set up between "the sake of the
community" and "commercial viability". The two are inextricably
intertwined.

> Get back  to common sense, now! Get
> the Internet back into people's hands!

"Power to me and my friends!" uh, er, um, oops, "Power to the People!"

David

Date: Sun, 30 Nov 1997 07:33:08 -0800 (PST)
From: Mix <[email-masked]>
Comments: This message did not originate from the address above.  It was remailed by an anonymous remailing service.  If you have questions or complaints, please direct them to <http://www.obscura.com/mix.html>
To: [email-masked]
Subject: Helpful
Sender: [email-masked]

Subject: Re: RSA Blows Standards (S/MIME) Smoke
From: [email-masked] (David Sternlight)
Date: 1997/11/06
Message-ID: <[email-masked]>
Newsgroups: alt.security.pgp,comp.security.pgp.discuss,alt.security,talk.politics.crypto,alt.privacy

In article <[email-masked]>, [email-masked] (Greg Hennessy) wrote:

>>Phil took RSA and deprived RSADSI of their patent rights in PGP 1.x. The
>>IETF area chairman has been widely reported to be trying to do something
>>analogous for S/MIME.
>
>Cite.

Already published here by Stone.

>
>This constant slandering of the IETF is really getting old.

It will continue until we have an explanation. And it isn't "slander" but
criticism. You DO know the difference, don't you?

In fact I'm told that the IEG's policy is that standards should be
"intellectual-property-neutral". If true it seems to me the IETF area
chairman is in violation of that principle by refusing materials which are
the intellectual property of the inventors in favor of materials in which
intellectual property rights are conveyed.

>
>>saying that you can't be one Internet standard among several unless you
>>surrender your hard-earned intellectual property is thuggery, pure and
>>simple. 
>
>It is not "thuggery" to insist that any internet standard NOT be a
>trade secret of a company. RSADSI is under no obligation to to
>surrender trade secret status of RC2. The IETF is under no obligation
>to certify S/MIME as an internet standard.

It is thuggery to use what market power the unelected, unrepresentative
IETF area group has to insist on the surrender of property rights in aid
of an ideological axe to grind on that matter. I see it as little
different, in principle, from blackmail, particularly if the report of the
IEG's intellectual-property-neutral policy is accurate. There is nothing
wrong with adopting a proprietary standard (especially such a widespread
de facto one into which so much hard work has gone by some of the best and
brightest companies in the world). as long as it is not an exclusive
standard. The whole character of MIME is to allow diverse formats. Let the
market decide.

I am surprised that those who ordinarily make ringing cries for individual
freedom and choice should be on the side of the seeming fascists on this
one.

>
>If RSADSI chooses to release RC2 because they think the benefit of
>having S/MIME be an internet standard outweighs the benefit of having
>RC2 be a trade secret, that is RSADSI's decision to make.
>
>They can continue to push S/MIME without being an internet standard.

You are flying in the face of many years of court rulings on such topics
as country club discrimination. Think it through.

>
>>Who do these people think they are, anyway?
>
>The Internet Engineering Task Force.

They are unelected and unrepresentative. Most users not only didn't get a
vote, but their market power vote is being taken away by practices such as
those reportedly going on. If the IETF cannot practice fairness, and
instead allow an area chairman to seemingly pursue a personal ideology
about intellectual property when a context of choice is available, perhaps
it is time the government or the courts took away their power over the
public information highway.

Assuming the reports are accurate, if Schiller doesn't like the patent
laws he should talk to Congress, not beat RSADSI up about it by unfairly
using powers granted to him on everyone's behalf.

If the reports aren't accurate we are long overdue for a full explanation.
It is OUR internet, not Jeff Schiller's, and continued silence shows an
arrogance toward users.

David

From: Raviv <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'Hanan - Vanguard'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: test56
Date: Sun, 30 Nov 1997 16:43:07 +0200
Organization: Vanguard security technologies Ltd.
Sender: [email-masked]

------ =_NextPart_000_01BCFDAE.FE78D5C0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

test56 

Raviv Karnieli
CTO
Vanguard Security Technologies Ltd.

Tel. 972-4-855-1410       Fax 972-4-855-1411
www.vguard.com	[email-masked]

------ =_NextPart_000_01BCFDAE.FE78D5C0
Content-Type: text/plain; name="topsecret.txt"
Content-Transfer-Encoding: quoted-printable

Blue Sky Airlines
Top Secret!
       =20
Use secure data pipelines only!
	Proposal and=20
	Marketing Plan
Blue Sky's Best Opportunity
For East Region Expansion

Chapter
1
Blue Sky Marketing Plan
Blue Sky's Best Opportunity For Expansion
Changing the airline industry forever=09
New proprietary technology has opened new opportunities for Blue Sky.  =
Moving quickly to adopt and implement this technology will give Blue Sky =
a leading position in the industry after years of being in third place. =
Read the following carefully and ensure its confidentiality by using =
secure data pipelines only!.
1) Insert your company name and address in place of the text on the =
cover page by clicking once and typing.
2) Choose File Save As. At the bottom of the menu, choose Document =
Template in the Save File as Type: box. Save the file under a new name =
to protect the original version, or use the same template name to =
replace the existing version.
How To Create a Report
To create a report from your newly saved template, select File New to =
re-open your template as a document.  (Your company information should =
appear in place.) .  For the body of your report, use Styles such as =
Heading 1-5, Body Text, Block Quotation, List Bullet, and List Number =
from the Style control on the Formatting toolbar.
How To Create Bullets and Numbered Lists
* To create a bulleted list like this, select one or more paragraphs and =
choose the List Bullet style from the Style drop-down list on the =
formatting toolbar. To create a numbered list like the numbered =
paragraphs above, select one or more paragraphs and choose the List =
Number style from the Style drop-down list.
This Style-the Block Quotation-can be used for quotes, notes or =
paragraphs of special interest. To use the Block Quotation Style, =
highlight any paragraph and choose Block Quotation from the style =
drop-down list on the Formatting toolbar.
How To Create a Table of Contents
To create a Table of Contents for this report, position your cursor on =
the blank TOC page. From the Insert menu choose Index and Tables. Click =
on the Table of Contents tab. Be sure to user the Custom Style format.
More Template Tips
There are three ways to view the various style names of template text:
1) In Normal view, choose Tools Options. Click the View tab. In the =
Style Area Width box, dial up a number such as "1" and click OK. Observe =
the style name next to each paragraph; or
2) In Page Layout view, click on any paragraph. View the style name on =
the Formatting toolbar; or
3) From the Format menu choose Style Gallery. In the Preview section =
click on Example or Style Samples.
How To Create a Table
Choose Insert from the Table menu.  Be sure to choose the Professional =
AutoFormat if you are using a Professional style template.
To modify an existing table, such as the table below, position your =
cursor in any cell. To modify the table, access the Table menu to select =
the desired action and/or result.
Competitor Ranking
Current Share
Share in 3 Yrs.
Largest competitor
50%
30%
Second largest competitor
25%
20%
Third largest competitor
15%
12%
* Table. Projected growth of competitors over 3 years.
How to Edit Table Text
Table text can be edited and formatted like regular text. Simply select =
text and type to replace, and use the Format menu to change the font =
and/or paragraph attributes.
How To Change a Header or Footer
In Page Layout view, choose Header or Footer from the View menu. Once =
activated, you can change or delete the text just like regular text. =
When done, click Close to exit.
To delete a ruling line in the Header or Footer, from the Format menu =
choose Borders and Shading. Choose None from the Preset section, and =
click OK.
??

(footnote continued)

2

3

=20

=20

------ =_NextPart_000_01BCFDAE.FE78D5C0--

Date: Sun, 30 Nov 1997 09:11:57 -0500
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
From: Steve Crocker <[email-masked]> (by way of Steve Crocker <[email-masked]>)
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use  MOSS?
Cc: [email-masked]
Sender: [email-masked]

[This is a resend of my previous message with corrected addresses for Jim
Galvin and the ietf-open-pgp working group.  Please discard my previous
message.]

Gunther,

Thanks for your kind words about MOSS.

Let me offer a bit of perspectrive about MOSS in relation to S/MIME.  MOSS
was designed to take full advantage of MIME.  It uses the MIME facilities
for hnadling multiple parts and for encoding binary information.  Although
MIME is enormously successful, it does have some technical wrinkles that
complicated the design of MOSS and make the resulting design less elegant
than we would have liked.  I'm referring specifically to MIME's requirement
that everything be encoded in a 7bit format and that the encoding be only
in the atomic parts of the structure.

Meanwhile, S/MIME adherents usually take the position that MOSS cannot be
implemented easily unless one has a complete MIME implementation already.
S/MIME, on the other hand, is designed to make maximum use of PKCS formats.
 It implements enough MIME to be compatible with MIME format, but doesn't
use MIME mechanisms internally.

Let me also comment on one technical detail.  You suggest that messages in
the MOSS forat could be transliterated easily into other formats.  While it
is true that the text and structure of a MOSS message could be
transliterated into other formats, signatures are specific to the precise
encoding of a message and cannot be transliterated.

At the time MOSS was designed, PGP was not compatible with MIME and there
was no clear path for bringing PGP into the standards arena.  That's since
changed.

Steve

Date: Sun, 30 Nov 1997 09:11:55 -0500
To: [email-masked], [email-masked]
From: Steve Crocker <[email-masked]>
Subject: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Sender: [email-masked]

Forwarding Gunther's Schadow's message.

>Return-Path: <[email-masked]>
>Date: Sun, 30 Nov 1997 14:39:03 +0100 (MET)
>From: Gunther Schadow <[email-masked]>
>To: [email-masked], [email-masked], [email-masked], [email-masked]
>Subject: Why do people fight about S/MIME vs. PGP rather than use MOSS?
>Cc: [email-masked], [email-masked], [email-masked],
>        [email-masked], [email-masked]
>
>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>-----------
>
>
----------------------------------
Steve Crocker                                   Desk:  +1 703 716 5214
CyberCash, Inc.                                 Main:  +1 703 620 4200
2100 Reston Parkway                             Fax:   +1 703 620 4215
Reston, VA 20191                                [email-masked]

Date: Sun, 30 Nov 1997 08:56:41 -0500
To: Gunther Schadow <[email-masked]>
From: Steve Crocker <[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]
Sender: [email-masked]

Gunther,

Thanks for your kind words about MOSS.

Let me offer a bit of perspectrive about MOSS in relation to S/MIME.  MOSS
was designed to take full advantage of MIME.  It uses the MIME facilities
for hnadling multiple parts and for encoding binary information.  Although
MIME is enormously successful, it does have some technical wrinkles that
complicated the design of MOSS and make the resulting design less elegant
than we would have liked.  I'm referring specifically to MIME's requirement
that everything be encoded in a 7bit format and that the encoding be only
in the atomic parts of the structure.

Meanwhile, S/MIME adherents usually take the position that MOSS cannot be
implemented easily unless one has a complete MIME implementation already.
S/MIME, on the other hand, is designed to make maximum use of PKCS formats.
 It implements enough MIME to be compatible with MIME format, but doesn't
use MIME mechanisms internally.

Let me also comment on one technical detail.  You suggest that messages in
the MOSS forat could be transliterated easily into other formats.  While it
is true that the text and structure of a MOSS message could be
transliterated into other formats, signatures are specific to the precise
encoding of a message and cannot be transliterated.

At the time MOSS was designed, PGP was not compatible with MIME and there
was no clear path for bringing PGP into the standards arena.  That's since
changed.

Steve

----------------------------------
Steve Crocker                                   Desk:  +1 703 716 5214
CyberCash, Inc.                                 Main:  +1 703 620 4200
2100 Reston Parkway                             Fax:   +1 703 620 4215
Reston, VA 20191                                [email-masked]

Date: Sun, 30 Nov 1997 14:39:03 +0100 (MET)
From: Gunther Schadow <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

From: Erik Seaberg <[email-masked]>
To: [email-masked]
Subject: Re: expedience, consensus and editing
Date: Sun, 30 Nov 1997 10:28:19 GMT
Organization: J. Random Software
Sender: [email-masked]

On Sat, 29 Nov 1997 20:54:29 -0800 (PST), [email-masked] wrote
to [email-masked]:
> If you don't want the [message/external-body] pointer then the right
> answer is to define a MIME type for a existing PGP detached signature
> object.

Would RFC 2015 application/pgp-signature (outside a multipart/signed
body) suit?  Would this be a good way to support several signatures over
the same content?  (Possibly from different entities, or using different
algorithms, or mixing OpenPGP/MIME and S/MIME....)

Most application/pgp-signature examples I've seen put ASCII-armored sigs
in the body part, but I hope we can move towards binary detached
signatures that gateways could encode and decode at need to take
advantage of cleaner transports and storage, and without redundant
"-----BEGIN stuff" delimiters.

Date: Sat, 29 Nov 1997 20:54:29 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: expedience, consensus and editing
To: Hal Finney <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > > Could you explain how the following detached signature would be
> > > encoded using RFC1847/RFC2015?  Would you use multipart/signed or
> > > multipart/encrypted?

> > multipart/signed, with no encoding for clear text. For opaque signing we
> > could either encode it with base64 or sign & encrypt.

> This is not what I meant by a detached signature.  PGP supports the
> concept of a signature which can be sent around independently of the data
> it signs.  For example, I could request that someone send me a signature
> on some data I received earlier.  They could create a signature on the
> data and send it to me, without having to re-send the data itself.

Existing facilities can be used to do detached MIME signaturues. Specifically,
one constructs a message/external-body MIME object that contains a
content-md5 field describing the external data. One then signs this
part. The result is a detached signature that also contains a pointer
to the actual data which has been signed.

If you don't want the pointer then the right answer is to define a
MIME type for a existing PGP detached signature object.

				Ned

Date: Sat, 29 Nov 1997 10:51:06 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: expedience, consensus and editing
Sender: [email-masked]

Lindsay Mathieson, <[email-masked]>, writes, quoting Hal Finney:
> >Could you explain how the following detached signature would be
> >encoded using RFC1847/RFC2015?  Would you use multipart/signed or
> >multipart/encrypted?
>
> multipart/signed, with no encoding for clear text. For opaque signing we
> could either encode it with base64 or sign & encrypt.

This is not what I meant by a detached signature.  PGP supports the
concept of a signature which can be sent around independently of the data
it signs.  For example, I could request that someone send me a signature
on some data I received earlier.  They could create a signature on the
data and send it to me, without having to re-send the data itself.

I gave an example of a detached signature in my earlier message:

This signature could potentially sign a very large amount of data which
we would not necessarily want to send along with the signature.

Hal Finney
[email-masked]

Date: Sat, 29 Nov 1997 11:02:28 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: PGP/MIME is not an alternative to ascii armor
Sender: [email-masked]

The larger point I'd like to make with respect to PGP/MIME is that it is
not just a transfer encoding which is applied on top of PGP.  It is really
a full protocol in itself, closely related to PGP, but with its own
rules and formatting.

If it were a transfer encoding, like PGP's ascii armor, it would allow
you to take an arbitrary PGP binary message and encode it for transport.
PGP/MIME does not do this.

Instead, PGP/MIME enforces its own rules on the kinds of binary encoding
which can be created.  For example, it insists that the only data which
can be encrypted or signed MUST be in MIME body part format, with a MIME
header, blank line, and MIME body.  It also requires that the data must
be converted to 7-bit form before being signed, and it limits the kinds
of PGP binary packets which can be sent around, eliminating detached
signatures among others.

These kinds of rules require the encryption/signature engine to know
whether it is producing data that will be used for PGP/MIME or whether
the data is for straight PGP, possibly with ascii armor.  The rules for
formatting the data and determining what kinds of inputs are allowed
will be different in the two cases.

Despite their superficial similarities, PGP/MIME is really not the
equivalent of ascii armor.  They are not alternatives which can substitute
for each other.  I think people are being misled by the fact that both
produce ascii readable output and are assuming that it is an either/or
situation.  But that is not the best way to look at it.

This is why I have been objecting all along to the notion that we could
eliminate ascii armor in favor of PGP/MIME.  It might make sense to make
one or both of them be SHOULD or MUST, but they are not alternatives.
The two should be considered independently.

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

Date: 29 Nov 1997 7:58:35 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: expedience, consensus and editing
To: Hal Finney <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>Could you explain how the following detached signature would be
>encoded using RFC1847/RFC2015?  Would you use multipart/signed or
>multipart/encrypted?

multipart/signed, with no encoding for clear text. For opaque signing we
could either encode it with base64 or sign & encrypt.

An example:

     From: Hal Finney <[email-masked]>
     To: Lindsay Mathieson <[email-masked]>
     Mime-Version: 1.0
     Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
     protocol="application/pgp-signature"

     --bar
     Content-Type: text/plain; charset=iso-8859-1
     
     Lindsay Mathieson, <[email-masked]>, writes, quoting me:
     > > - There is no PGP/MIME encoding of a detached signature
     > >
     > > - There is no PGP/MIME encoding of a non-clear signed message
     >
     > ? Both points are clearly addressed (and doable) in RFC 1847 &
RFC2015, which
     > are PGP/MIME (aren't they ?)

     Could you explain how the following detached signature would be
     encoded using RFC1847/RFC2015?  Would you use multipart/signed or
     multipart/encrypted?

     --bar
     Content-Type: application/pgp-signature

     -----BEGIN PGP MESSAGE-----
     Version: PGP for Personal Privacy 5.0

     iQA/AwUBNH5DH7qVexb8FGk/EQKTagCg9NwSygbmXdVts7NbIyPkaX9p65QAn2Lu
     DTwZos6GWUDnplXYbZXolxLY
     =hgt3
     -----END PGP MESSAGE-----

     --bar--

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

Date: Wed, 26 Nov 1997 17:24:02 -0800
To: Adam Back <[email-masked]>, [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: expedience, consensus and editing
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 09:08 PM 11/26/1997 GMT, Adam Back wrote:
>I would like to see more rapid progress in this forum.
We've been too busy fighting about important political issues
to get done quickly, but I think we're near rough consensus.
IETF-SMIME hasn't had this problem, because they're already doing MIME,
and don't have a CMR feature to fight about.

>1) armor MAY/SHOULD/MUST?
SHOULD.
>2) MIME as MAY/SHOULD/MUST?
I'd prefer MAY, but won't object to SHOULD.
>3) 32 bit int clean up shelved for OpenPGPv2, or discussed now
Shelve it.  It's nice, but not a big issue.  The more important
clean up that's related is making sure there's a mechanism for
indefinite-length material so we can do things like streaming,
which the older PGP formats appeared to support better than the new one.

>4) CMR/ARR and alternatives worked through now or shelved for OpenPGPv2,
Agree with your "define subpacket type 10 as reserved for future use".

Dave Crocker writes:
> Ok.  So you implement armor and I implement MIME.  How do we interoperate?

Binary, and leave transport issues up to the user.  Works fine.
I think Armor needs to be a SHOULD to reduce this problem,
especially for compatibility with the PGP 5.0 and 2.6.2 bases,
and making MIME a SHOULD might also help with newer applications.

The main reason for not making Armor a MUST is to keep things small 
for minimal environments like smartcards, 
though Some People just don't like it and have other agendas. :-)

				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Fri, 28 Nov 1997 12:52:08 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: "Mark J. McArdle" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: The Web of Trust Has No Clothes
Sender: [email-masked]

David Sternlight wrote:

<omitted>

At the risk of compounding the number of extra bits, apologies for the
duplication of the text in my previous message. I let my fingers do the
walking on my paste key once too often.

David

Date: Fri, 28 Nov 1997 09:54:46 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: "Mark J. McArdle" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: The Web of Trust Has No Clothes
Sender: [email-masked]

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

Mark J. McArdle wrote: <totally ad hominem attack from a PGP staffer
omitted>

I have no wish to post off-topic to this group. Mark's misrepresentation
of my concern is what is off-topic. Fairness and a setting of the record
straight requires a response.

To put it simply and directly, by negating RSA in PGP 5.53, PGP
invalidated all the prior RSA web of trust signatures and keys for users
of the new version and created either a split in the web of trust or a
situation of forced conversion and re-signing for those who wish to use
the latest version. This seems both incontrovertible and unarguable, and
ad hominem attacks on those who ask about it are non-responsive. My
concern is to see that Open PGP is robust over such "improvements" to
algorithms. The current worked example by PGP Inc. is relevant to
understanding the issue.

As to the lies which have gained strong currency, I need to say a word
to clear the air and in fairness. I am a PGP user. I was one of the
earliest PGP users until I found it was infringing.  I then worked
behind the scenes (as Jim Bidzos will confirm) to try to get him to
license RSA for PGP. That effort initially failed apparently because of
what  Simson Garfinkel describes in his book on PGP as Phil's
intransigence, not because of any lack of effort on  my part or Eric
Hughes part or even Jim Bidzos' goodwill. Subsequently I was one of the
first adopters of MIT  PGP and both Jeff Schiller and Derek Atkins
signed my key. I believe PGP has its strong place when web of  trust is
appropriate to the circumstances, and rigid heirarchical (as practiced
with S/MIME and CAs such as  Verisign in Netscape and Microsoft
Explorer) has its place. I believe there is no all-purpose solution to
trust  models that won't either lose some of the advantages of web of
trust, or some of the advantages of rigid  heirarchical. Some discussion
on this point by all-or-nothing fans has also led to attempts at
demonization  and marginalization when substantive counter-arguments
were unavailable to the proponents. In particular, I  believe we need
two solutions for the Internet--one of each trust model, and I
understand this group and the  S/MIME 3 group are under instructions to
coordinate in areas of commonality.

I remain a PGP user as well as an S/MIME user. I take strong exception
to some acts of PGP Inc. and PRZ but those have nothing to do with this
group except as they affect such things as the robustness of Open PGP
over algorithmic improvements--an important topic--or as they might
affect true IETF configuration control. I do not plan to raise prior
concerns here except as they may be relevant to Open PGP.  Some who hold
either Phil or PGP Inc. as an avatar have used my criticisms of some
acts of PRZ or PGP Inc. elsewhere as an occasion to demonize or
marginalize me when they were unable to respond to such substantive
criticisms with rational counter-arguments. Shoot the messenger remains
a popular sport in some quarters.

Finally, with respect to this group my interest is solely in making what
contribution I can to Open PGP's robustness and independence. I take
very seriously the concept of IETF configuration control, and if it IS
going  to be a pacing principle, it must be complete and effective, and
not window-dressing for competitive advantage-seeking by PGP Inc. (in
the case of Open PGP) or RSADSI (in the case of S/MIME 3).

David Sternlight, Ph.D.

Mark J. McArdle wrote: <totally ad hominem attack from a PGP staffer
omitted>

I have no wish to post off-topic to this group. Mark's misrepresentation
of my concern is what is off-topic. Fairness and a setting of the record
straight requires a response.

To put it simply and directly, by negating RSA in PGP 5.53, PGP
invalidated all the prior RSA web of trust signatures and keys for users
of the new version and created either a split in the web of trust or a
situation of forced conversion and re-signing for those who wish to use
the latest version. This seems both incontrovertible and unarguable, and
ad hominem attacks on those who ask about it are non-responsive. My
concern is to see that Open PGP is robust over such "improvements" to
algorithms. The current worked example by PGP Inc. is relevant to
understanding the issue.

As to the lies which have gained strong currency, I need to say a word
to clear the air and in fairness. I am a PGP user. I was one of the
earliest PGP users until I found it was infringing.  I then worked
behind the scenes (as Jim Bidzos will confirm) to try to get him to
license RSA for PGP. That effort initially failed apparently because of
what  Simson Garfinkel describes in his book on PGP as Phil's
intransigence, not because of any lack of effort on  my part or Eric
Hughes part or even Jim Bidzos' goodwill. Subsequently I was one of the
first adopters of MIT  PGP and both Jeff Schiller and Derek Atkins
signed my key. I believe PGP has its strong place when web of  trust is
appropriate to the circumstances, and rigid heirarchical (as practiced
with S/MIME and CAs such as  Verisign in Netscape and Microsoft
Explorer) has its place. I believe there is no all-purpose solution to
trust  models that won't either lose some of the advantages of web of
trust, or some of the advantages of rigid  heirarchical. Some discussion
on this point by all-or-nothing fans has also led to attempts at
demonization  and marginalization when substantive counter-arguments
were unavailable to the proponents. In particular, I  believe we need
two solutions for the Internet--one of each trust model, and I
understand this group and the  S/MIME 3 group are under instructions to
coordinate in areas of commonality.

I remain a PGP user as well as an S/MIME user. I take strong exception
to some acts of PGP Inc. and PRZ but those have nothing to do with this
group except as they affect such things as the robustness of Open PGP
over algorithmic improvements--an important topic--or as they might
affect true IETF configuration control. I do not plan to raise prior
concerns here except as they may be relevant to Open PGP.  Some who hold
either Phil or PGP Inc. as an avatar have used my criticisms of some
acts of PRZ or PGP Inc. elsewhere as an occasion to demonize or
marginalize me when they were unable to respond to such substantive
criticisms with rational counter-arguments. Shoot the messenger remains
a popular sport in some quarters.

Finally, with respect to this group my interest is solely in making what
contribution I can to Open PGP's robustness and independence. I take
very seriously the concept of IETF configuration control, and if it IS
going  to be a pacing principle, it must be complete and effective, and
not window-dressing for competitive advantage-seeking by PGP Inc. (in
the case of Open PGP) or RSADSI (in the case of S/MIME 3).

David Sternlight, Ph.D.

From: "Mark J. McArdle" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: The Web of Trust Has No Clothes
Date: Thu, 27 Nov 1997 22:11:50 -0800
Organization: Pretty Good Privacy, Inc.
Sender: [email-masked]

[annoyingly formatted message from D. Sternlight removed]

Notwithstanding David Sternlight's interest in scrutinizing the Web of Trust, 
perhaps we could terminate this thread.  Thankfully, most people are ignoring 
it.  If David Sternlight will acknowledge that this group functioned before his 
arrival, and will continue to do so after his departure, we'll have a standard 
that much quicker.

Discussing the features of 5.x with someone who (possibly sarcastically) 
expects signatures from one key to be magically moved over to a new key is not 
germane to the mandate of this group.  I believe Hal has clearly and correctly 
explained how this implementation works.

David, calling Hal non-responsive is inappropriate, as he is working hard on 
this standard.  I've observed your PGP-related contributions to usenet in the 
past, and IMHO, you are rarely trying to be constructive.  You are certainly 
not a PGP advocate, and this group consists of people who are 
interested/motivated/impassioned to take PGP to a new level.  This isn't 
censorship, it's a question of basic respect and manners.  Please respect our 
wish to work on this standard with people who are legitimately interested in 
evolving PGP.

I am hoping the others on this list will agree to focus on the many other 
issues we have before us.   I shudder to think about the collective amount of 
time spent reading and responding to these posts.  I know it's 15 minutes of my 
Thanksgiving I'll never get back ;)

Sincerely,
Mark

Date: Thu, 27 Nov 1997 21:08:23 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
Subject: Re: The Web of Trust Has No Clothes
Sender: [email-masked]

> >
> > From OpenPGP list:
> >
> > Date: Mon, 24 Nov 1997 22:08:00 -0800
> > From: Hal Finney <[email-masked]>
> > To: [email-masked]
> > Subject: Re: The web of trust has no clothes.
> > Sender: [email-masked]
> >
> > PGP 5.X implements an extension to the trust model to address the
issue
> > raised by David Sternlight.
> >
> > > Another flaw in the web of trust and PGP is now revealed and comes
home
> > > to roost.  Now that PGP Inc. has deep-sixed RSA in new free
versions,
> > > not only does everyone with an old RSA key have to generate a new
key
> > > but also a complete new set of signatures and web of trust must be
built
> > > if they wish to use the "better" algorithms. And the new keys must
be
> > > distributed to correspondents, either directly or by "pull" from
> > > servers. This took years the first time--perhaps the second time
it will
> > > be a bit faster.
> >
> > The way it works is as follows.  If you have two keys with identical

> > userids, and the first key signs the second userid, then validity
from
> > the signatures on the first user ID gets propagated to the second
userid.
> > The effect is that if you generate a new DSA key with the same name
> > as your old RSA key, and sign it with your old key, then your new
key
> > inherits the validity from the old key.  (This propagation happens
> > irrespective of whether the old key is marked as a trusted
introducer.)
> >
> > In effect, the signatures on your old key automatically get applied
to
> > your new key.  This is an easy way to inherit the signatures from
the old
> > web of trust.  The new keys do not have to start from scratch, as
implied
> > above.

I have now tried this and either Hal's response is non-responsive to my
concern or
I did something wrong.

With Eudora PGP 5.0 and the pay RSA addition for Eudora PGP 5.0, I ran
PGP keys. I generated a
new ElGamal key pair with the same name and internet address as my 1024
bit RSA key
that had been signed by Schiller et al. I then made the old key the
default key and
signed the new key with it. The signatures were NOT transferred to the
new key, as
I had thought on reading Hal Finney's solution to the issue I raised.

Perhaps Hal intended to be taken literally. Perhaps the VALIDITY of my
old key is
transferred to my new key in the isolation of my  own keyring. The
signatures
certainly were not, in effect or otherwise. And none of the signatures
on other
people's keys could be transferred in this way. My new key did not carry
the old
signatures, and if I then send it to a keyserver it doesn't carry the
signatures on
the old key. As I at first said, the web of trust (as represented by
signatures on
keys) and all the signatures on the old RSA key has been lost to the new
key
structure.

What is more, this transfer of trust doesn't apply to any keys not my
own on my own
key ring. Thus any web of trust, signatures, etc. on the old RSA key are
lost as
far as any usefulness is concerned once I switch to Free PGP 5.53. As I
said before
Hal's response, PGP Inc HAS disenfranchised all the old web of trust,
the old
network of signatures, and the old network of keys in PGP 5.53. Everyone
has to get
new keys and to restore any semblance of the old web of trust has to get
new keys
from all their correspondents in order to communicate, and the
correspondents (namely everyone)
all have to get new signatures on their keys, etc. for the transitive
character of the web of trust to work.

I cannot believe Hal (of whom I have a high opinion) would be so
non-responsive
and misdirective to the concern I had raised. I must have misunderstood
him and
done something wrong. Please tell me what it was.

As for Open PGP, if I didn't misunderstand Hal this would certainly not
be a way to
preserve signature and key structure in the presence of algorithmic
change or
updating.

David

Date: Thu, 27 Nov 1997 20:07:53 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: expedience, consensus and editing
Sender: [email-masked]

Lindsay Mathieson, <[email-masked]>, writes, quoting me:
> > - There is no PGP/MIME encoding of a detached signature
> >
> > - There is no PGP/MIME encoding of a non-clear signed message
>
> ? Both points are clearly addressed (and doable) in RFC 1847 & RFC2015, which
> are PGP/MIME (aren't they ?)

Could you explain how the following detached signature would be
encoded using RFC1847/RFC2015?  Would you use multipart/signed or
multipart/encrypted?

Thanks,
Hal

Date: 28 Nov 1997 1:1:26 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: PGP/MIME2
To: Ian Brown <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>This is an interesting point. RFC 1847 is elegant, but it seems that
>no-one else is following it. If S/MIME isn't

S/MIME is, and also some email apps implement it

>However, for simply wrapping
>PGP data, we could have an application/pgp-data type.

I would strongly protest the use of application/pgp-data type or
application/anything. The trouble with using the MIME application type is
that is limits you to a string of binary octets, which basically  restricts
us to plain text *or* a file.

Whereas multipart/encrypted (RFC 1847) contains a single MIME object, and
that MIME object can contain anything - plain text *and* rich text *and*
file attachments. And they can all be collectively signed.

Having said this I also believe specifying a transport protocol is out of the
scope of this spec. Its a complex enough subject that it requires a group
of its own.

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

Date: 28 Nov 1997 1:1:26 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: Long term contracts
To: Ian Grigg <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

Ian,

usage of MIME RFC 1847 (multipart/signed) could probably fit your needs for
human readable clear signed documents, that fit in a single file.

Contrary to what people have been saying, MIME messages can be stored in a
single file - in fact thats a natural storage medium for them. One of
MIME's purposes was to flatten out multipart messages (text & attachments)
so they can be streamed over a connection. The MIME stream (or file)
contains formatting information which makes it easy to break out the
original components.

Included below is a example of a clear text signed message:

   Example message:

     From: Michael Elkins <[email-masked]>
     To: Michael Elkins <[email-masked]>
     Mime-Version: 1.0
     Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
     protocol="application/pgp-signature"

     --bar
     Content-Type: text/plain; charset=iso-8859-1
     Content-Transfer-Encoding: quoted-printable
     
     =A1Hola!
     
     Did you know that talking to yourself is a sign of senility?
     
     It's generally a good idea to encode lines that begin with
     From=20because some mail transport agents will insert a greater-
     than (>) sign, thus invalidating the signature.
     
     Also, in some cases it might be desirable to encode any   =20
     trailing whitespace that occurs on lines in order to ensure  =20
     that the message signature is not invalidated when passing =20
     a gateway that modifies such whitespace (like BITNET). =20
     
     me

     --bar
     Content-Type: application/pgp-signature

    -----BEGIN PGP MESSAGE-----
   Version: 2.6.2

   iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
   jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
   uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
   HOxEa44b+EI=
   =ndaj
   -----END PGP MESSAGE-----

   --bar--

In this example the text is quoted printable encoded, but it could be left
unencoded. QP is recommended for 7 bit transport over the internet though.
However this is not an issue if you are storing locally.

I'm no expert on cryptography, but I do have considerable experience in
implementing MIME. Feel free to grill me on the subject.

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

Date: Thu, 27 Nov 1997 14:11:08 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
Subject: Re: The web of trust has no clothes.
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms7CA68B5A3370106763E0EEAF
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

Ed Stone wrote in comp.security.pgp.discuss:

> I believe this is a definitive response to the unsupported assertion
that the
> web of trust is "broken" by new versions of PGP.

I respond to Finney, not Stone. I copy this to the open pgp list not
only
because Finney's post appeared there (in response to mine--I throw no
stones by
that remark), but also because there may be some valuable lessons here
for Open
PGP development.

>
>
> From OpenPGP list:
>
> Date: Mon, 24 Nov 1997 22:08:00 -0800
> From: Hal Finney <[email-masked]>
> To: [email-masked]
> Subject: Re: The web of trust has no clothes.
> Sender: [email-masked]
>
> PGP 5.X implements an extension to the trust model to address the
issue
> raised by David Sternlight.
>
> > Another flaw in the web of trust and PGP is now revealed and comes
home
> > to roost.  Now that PGP Inc. has deep-sixed RSA in new free
versions,
> > not only does everyone with an old RSA key have to generate a new
key
> > but also a complete new set of signatures and web of trust must be
built
> > if they wish to use the "better" algorithms. And the new keys must
be
> > distributed to correspondents, either directly or by "pull" from
> > servers. This took years the first time--perhaps the second time it
will
> > be a bit faster.
>
> The way it works is as follows.  If you have two keys with identical
> userids, and the first key signs the second userid, then validity from

> the signatures on the first user ID gets propagated to the second
userid.
> The effect is that if you generate a new DSA key with the same name
> as your old RSA key, and sign it with your old key, then your new key
> inherits the validity from the old key.  (This propagation happens
> irrespective of whether the old key is marked as a trusted
introducer.)
>
> In effect, the signatures on your old key automatically get applied to

> your new key.  This is an easy way to inherit the signatures from the
old
> web of trust.  The new keys do not have to start from scratch, as
implied
> above.

Since I've been somewhat critical of Jeff Schiller recently in the
context of
IETF actions toward RSADSI with respect to S/MIME and also the disabling
of RSA
key generation in MIT PGP 5.0, perhaps he'd not like to sign my newer
keys and
maybe even regrets he signed my earlier PGP key. WIth this feature , I
can get
him to "sign" my new keys iinvoluntarily. What is more, I can arrange
that my
new key, like my old one, has no expiration date, further locking Jeff
in.
(Nothing personal--this is a notional example with details to fix
ideas.)The
approach you adopted forces the entire user base to generate new keys if
they
wish the features of free 5.5x, and transfers trust in this somewhat
disadvantageous way for free 5.0.  It also cuts off first-time PGP users

choosing 5.0 and all users of free 5.5x from two-way secure
communication with
those who wish to maintain their RSA keys for compatibility with what
appears
likely to be a much larger global user base for quite some time.  It
also allows
the propagation of questionable signatures to the new web of trust at
the option
of the person with the signed key rather than the signer of the key.
Finally,
unless and until the new versions find their way somehow to
international users
at scale, it cuts that base off completely from even the possibility of
two-way
communication with first-time free 5.0 users and all free 5.5x users. I
do not
think this a very pretty picture, nor particularly considerate of the
existing
RSA-key user base which made your reputation.

> There may be some concern that this would introduce certain kinds of
> spoofing attacks.  Let us assume that the old signatures are valid,

they may have been originally but the signer may have wished
subsequently to
invalidate them for either substantive or personal reasons. Since old
PGP keys
have no expiration dates and there was no CRL mechanism originally, this
is
weak. Better if you're going to start a new key structure to require new

signatures. I recognize that this seems to contradict my comment about
obsoleting the old web to trust, but I'd argue PGP should have preserved

compatibility with the old web via compatibility with the old keys,
while making
the new key structure possible in Free PGP, thus providing a graceful
and
user-driven upgrade path rather than an imposed one. The method
described above
is, instead, a kludge to attempt to avoid one of the more egregious
consequences
of what I think to have been a mistake in the first place.

I believe the direction Open PGP is moving in allows for many agreed
algorithms
including "Classical" RSA-IDEA PGP, with appropriate flags to enable
two-way
usage, and a backwards compatible upgrade path. If this is both true and

preserved as the group goes about its business, this would be a Good
Thing.

I would suggest both in light of the realities of the existing user base
and on
principle that Open PGP include Classical PGP as either a "should" or  a
"must".
This would not violate what I understand to be the real ground rule:
non-discriminatory access to intellectual property on reasonable terms.
If there
is some difficulty in negotiating such terms, the date of coming into
effect of
such a "must" provision could be the expiration date of the RSA patent
(for
example). GIven empirically-based time tables for the completion of the
group's
work, and likely implementation times thereafter, I think this could be
a
practical approach.

> that the old key is in fact properly bound to the userid.  (If the old

> signatures are invalid, no one should trust them anyway, so they have
no
> impact on the web of trust.)

Not so fast. See above.

> Now, when that old key issues a signature
> on the same userid on another key, it is in effect asserting that the
> same keyholder controls this other key.
>
> If the other key actually does belong to the same keyholder, then
there
> is no danger in transferring validity from the signatures on the old
> key over to the new one.  The new key is in fact valid, and so
measures
> which show it as valid are proper.

See above. Also, that PGP recognizes the importance of expiry is shown
by the
option to add an expiration date to newly generated keys

> Hal Finney
> [email-masked]

While I've got you, Hal, why did PGP disable RSA key generation in free
5.0? Why
did they omit  RSA entirely in free 5.5x? Why is it an extra-cost option
in pay
5.5?  It it the intention to drop it completely in 6.x? It would be good
to have
an authoritative explanation. I think this would be of interest to all
the
groups in this distribution, since even the Open PGP folks can benefit
from
understanding PGP Inc.'s thinking and intentions with respect to its
products.

David

--------------ms7CA68B5A3370106763E0EEAF
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms7CA68B5A3370106763E0EEAF--

Date: 27 Nov 1997 20:23:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: The armour issue
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Bill Frantz)  wrote on 26.11.97 in <v03110714b0a292f4cc57@[207.94.249.75]>:

> The first piece of signed code I ever got was MacPGP 2.6.2.  I like the
> idea of detached signatures on executable files.  One use I can see is
> signing every executable on your system and storing the signatures
> separately.  Then you can periodically check the system for altered code.
> (Too bad Mac code normally alters itself.)
>
> How do armor and MIME compare in their support of this application?

You don't need either one for that functionality. Binary is quite ok.

And as both do nearly exactly the same thing, you could easily use both.

MfG Kai

Date: Thu, 27 Nov 1997 10:11:06 -0800
To: Ian Grigg <[email-masked]>
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: Long term contracts
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 05:24 PM 11/27/97 +0000, Ian Grigg wrote:
>Ian:
>>  Ian Grigg's point in favour of armour is that clearsigned documents are
...
>(I think it can be hacked into the MIME format, but thinking about it,
>there is more to it than that.)

I assume that 'clearsigned' means the text is kept in the clear?

That is exactly the purpose behind multipart/signed.  

There is no 'hacking' needed. The MIME mechanism is already supplied.
S/MIME uses is.

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

Date: Thu, 27 Nov 1997 17:24:20 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
CC: [email-masked]
Subject: Long term contracts
Sender: [email-masked]

Ian:
>  Ian Grigg's point in favour of armour is that clearsigned documents are
>  useful. Fair enough; Ian can buy/write an application which includes
>  this functionality. It does not need to be a MUST. As Adam just said, it
>  would be simple to do the same with MIME.

(I think it can be hacked into the MIME format, but thinking about it,
there is more to it than that.)

A contract is a self contained document that can be readily proven to be
what it says it is.  It uses embedded inline sigs because they cannot be
lost over time, and it can survive many different copying techniques. 
Note how the preceeding comment holds for paper documents and pgp
clearsigned messages, but not for attachments and separated sigs.

One of the design criterion is that the method of cleartext signing must
be ubiquitous.  Under current world conditions the method used is, as
pgp2.6 and pgp5.0 can read the clearsigned sigs.  If however, armour is
phased out, and MIME is not up to the job, then the application is
broken.

The reason for this is that you have to write a contract now, and
validate it in the unforeseeable future, using independant software
available anywhere.  Just like on paper.  We are trying to replace the
eyeball, and this has rather tricky demands on software.

When we designed the methods to do the contract, a reasonable assumption
was that "pgp2.6 will be available for a long time."  It was set up over
worldwide net sites to defend itself from the worst ravages of
governments.  I never in my wildest dreams guessed that PRZ and Company
would be the ones to ....

Now, the alternative is to assume that PGP/MIME or S/MIME will take
over.  This is far to risky a bet, obviously, as there are already two
choices there, and with the addition of the  incumbent, that makes
three.  No rational business case can be made at this stage that either
of these are strong enough to win.

Add to that the decision of this group to abandon RSA sigs, along with
the commercial activities of PGP Inc to deliver the coup de grace and I
suspect the signing of long term commercial contracts is now a broken
application.

Which is ammusing as I just today submitted my paper to FC98 on how good
an application this is (and received confirmation that it is in the post
:-)  Better I find out now than at the conference I suppose...

-- 
iang                                      systemics.com

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

Date: Thu, 27 Nov 1997 16:55:29 +0000
From: Ian Brown <[email-masked]>
To: Bill Stewart <[email-masked]>
CC: IETF OpenPGP <[email-masked]>
Subject: Re: The armour issue
Sender: [email-masked]

> A typical Web-based PGP application requires the user to cut&paste a
> PGP key or PGP-encrypted message into a web form and submit it.

Have a look at RFC 1867: Form-based File Upload in HTML. I believe
Netscape implements it, not sure about the rest. This would be great for
uploading binary key files.

> There's also the problem of sending PGP keys in email messages...
> It's really much cleaner if you've got a format that can stay inlined

Could we use application/pgp-keys inlined?

Ian :D

Date: 28 Nov 1997 16:11:17 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: PGP/MIME2
To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>Sorry. I also proposed to create text/pgp and
>application/pgp-encrypted.

Also the text type is usually used to indicate a text format as well, e.g.
text/html or text/etf. text/pgp would effectively be limited to plain text.

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

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Armour
Date: 27 Nov 1997 14:28:46 GMT
Organization: IKS GmbH Jena
Lines: 8
NNTP-Posting-Host: belenus.iks-jena.de
Sender: [email-masked]

* David Formosa wrote:
>If this was so we could have a complient OPEN-PGP softwhere with no
>'presentation layer'.  This would not be able to interoperate with
>anything and therefore in an internet context be useless.  We MUST have a
>MUST have some form of protection threw the vegeries of transport.

;-) Leave the presentation layer in the user agent and do the cryptographic
work on raw binary.

Date: Thu, 27 Nov 1997 13:48:58 +0000
From: Ian Brown <[email-masked]>
To: IETF OpenPGP <[email-masked]>
Subject: Re: PGP/MIME2
Sender: [email-masked]

Kazu wrote:

> If the discussion should be repeated, it would like to know how
> situation is changed comparing one year ago.

The difference this time is that armour is unlikely to be a MUST in OP.
So it shouldn't be a MUST in a standard that OP references.

> S/MIME is now coming and it does not use multipart/encrypted but
> application/pkcs7-mime. So, the alignment of PGP/MIME becomes
> meaningless from the implementation view of point.

This is an interesting point. RFC 1847 is elegant, but it seems that
no-one else is following it. If S/MIME isn't, I don't think there is an
absolute need for us to do so.

I may be at risk of starting a religious war even worse than the one
over armour here ;-) but I can see many ways in which it would be useful
NOT to follow that model. Particularly from the point of view of mailers
which do not explicitly understand PGP/MIME, but do understand MIME -
such as that 25 million base we keep hearing about.

We need two things from MIME: the ability to send raw PGP binary data,
and the ability to send clearsigned messages. It is also nice if, in the
manner of PGP/MIME, we have a separate content-type for keys so that, as
Peter Gutmann suggested, we can have separate key management programs if
desired.

We could keep the application/pgp-keys content-type, and use the
multipart/signed mechanism largely as-is. However, for simply wrapping
PGP data, we could have an application/pgp-data type. This would simply
be data which, once the transfer encoding had been removed by the
mailer, could be presented to an OP application which would then be able
to process it.

Then, *any* MIME-compliant mailer could be configured by its users so
that when it receives an application/pgp-data bodypart, it removes the
transfer encoding then executes a user-specified OP program with the
data as input. A message could contain any number of such bodyparts.

This obviously needs work, but I hope it's a gem of an idea. Comments?

Ian.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: V4 Fingerprints
Date: 27 Nov 1997 13:05:08 GMT
Organization: IKS GmbH Jena
Lines: 7
NNTP-Posting-Host: belenus.iks-jena.de
Sender: [email-masked]

* Thomas Roessler wrote:
>This seems to imply that the fingerprint is always
>generated as the hash over an old-style public key packet
>with a two-byte length qualifier and the appropriate
>packet tag.  Is this correct and intended?

Unfortunly: Yes. I documented it in the interim draft explicitly.

Date: Thu, 27 Nov 1997 22:39:15 +1100 (EST)
From: David Formosa <[email-masked]>
Reply-To: [email-masked]
To: Adam Back <[email-masked]>
cc: [email-masked]
Subject: Re: Armour
Sender: [email-masked]

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

On Wed, 26 Nov 1997, Adam Back wrote:

[...]

> I think neither MIME nor Armor should be MUST.  Both MAY.  You could
> argue for SHOULD for backwards compatibility.

If this was so we could have a complient OPEN-PGP softwhere with no
'presentation layer'.  This would not be able to interoperate with
anything and therefore in an internet context be useless.  We MUST have a
MUST have some form of protection threw the vegeries of transport.

Currently I'm favouring MUST mime for interoprabilty with the future and
SHOULD for interoperablity with the present and past versons.

- -- 
Please excuse my spelling as I suffer from agraphia see the url in my header. 
Never trust a country with more peaple then sheep.  ex-net.scum and proud
You Say To People "Throw Off Your Chains" And They Make New Chains For
Themselves? --Terry Pratchett.  I do not reply to munged addresses.

To: [email-masked]
Subject: Re: PGP/MIME2
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Thu, 27 Nov 1997 21:45:42 +0900
Lines: 39
Sender: [email-masked]

From: Ian Brown <[email-masked]>
Subject: PGP/MIME2
Date: Thu, 27 Nov 1997 10:38:31 +0000

> Hal is right. PGP/MIME needs work on:
> 
> - Removing the requirement for armor, if it is not going to be a MUST in
> OP.

Actually I proposed usage of MIME base64 instead of PGP armor on the
ietf-pgp-mime ml before RFC 2015 was published. At that time, only one
person supported my proposal. And many rejected it.

I'm afraid that we are repeating the same discussion again. Also, I
wonder why Dave Crocker did not support my proposal explicitly at that
time.

If the discussion should be repeated, it would like to know how
situation is changed comparing one year ago.

> - Defining new content-types for the types of OP data which are not
> currently covered - detached signatures, non-clearsigned messages, maybe
> others.

Sorry. I also proposed to create text/pgp and
application/pgp-encrypted. Since some guys arose objections against
the proliferation of content type, this idea was not included in RFC
2015.

The author of RFC 2015 was particular to alignment to security
multipart. Multipart/encrypted was adopted though its first part is
mostly empty.

S/MIME is now coming and it does not use multipart/encrypted but
application/pkcs7-mime. So, the alignment of PGP/MIME becomes
meaningless from the implementation view of point.

--Kazu

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: expedience, consensus and editing
Date: 27 Nov 1997 12:40:21 GMT
Organization: IKS GmbH Jena
Lines: 18
NNTP-Posting-Host: belenus.iks-jena.de
Sender: [email-masked]

* Adam Back wrote:
>1) armor MAY/SHOULD/MUST?

MAY be generated and SHOULD be read.

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

>3) 32 bit int clean up shelved for OpenPGPv2, or discussed now

32bit is an unnecessary restriction. (640k are enough for everybody!)

>4) CMR/ARR and alternatives worked through now or shelved for OpenPGPv2,

Drop it completely but mark the subsignature ID as in use.

Date: 27 Nov 1997 12:46:33 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: expedience, consensus and editing
To: Hal Finney <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

> - There is no PGP/MIME encoding of a detached signature
>
> - There is no PGP/MIME encoding of a non-clear signed message

? Both points are clearly addressed (and doable) in RFC 1847 & RFC2015, which
are PGP/MIME (aren't they ?)
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Beta Vs 2.6.1.2, on November 27, 1997, in Win95 4.0
	http://www.blackpaw.com/

Date: Thu, 27 Nov 1997 10:38:31 +0000
From: Ian Brown <[email-masked]>
To: Hal Finney <[email-masked]>
CC: [email-masked]
Subject: PGP/MIME2
Sender: [email-masked]

Hal is right. PGP/MIME needs work on:

- Removing the requirement for armor, if it is not going to be a MUST in
OP.

- Defining new content-types for the types of OP data which are not
currently covered - detached signatures, non-clearsigned messages, maybe
others.

Ian.

Date: Thu, 27 Nov 1997 10:02:08 +0000
From: Ian Brown <[email-masked]>
To: Gavan Schneider <[email-masked]>
CC: ietf-open-pgp <[email-masked]>
Subject: Re: Armour
Sender: [email-masked]

If you hadn't noticed, I am now trying to keep all my posts to around a
page. A lot of people on this list seem to simply skip anything longer
;-)

I agree with Gavin's points, and thought I would just quickly summarise
them for said people:

> O/PGP cannot define the contents of the file system at large, 
> but it can define a valid file for its own purposes.  Nothing will ever 
> stop people from sometimes serving the wrong files to an application...  
> we still need to repack the file if we want to transmit it over the
> internet and mime is the way to go in that area.

> If it 
> has not been suggested already let's get multi byte alphabets built into 
> the standard from the ground up.  No late add-on fixits to cater for the 
> Chinese, Hindu, Japanese... scripts.  These are all huge markets and 
> getting bigger, and I believe there is already an ISO standard for these 
> alphabets.  We don't have to invent this wheel.  Just use it and make 
> O/PGP savvy with it.

> >PGP/MIME does not provide methods to
> >encapsulate some legal PGP packet structures which were expected not to
> >be used for email.
> 
> Propose the packets for inclusion.

Ian :D

Date: Thu, 27 Nov 1997 09:48:06 +0000
From: Ian Brown <[email-masked]>
To: Ng Pheng Siong <[email-masked]>
CC: [email-masked]
Subject: Re: Armour
Sender: [email-masked]

Ng Pheng Siong is right. Another example that Hal has brought up is FTP.
As far as I was aware, this uses binary transfer. No need for armour or
MIME.

Ian.

Date: Thu, 27 Nov 1997 08:30:38 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
CC: [email-masked]
Subject: Re: expedience, consensus and editing
Sender: [email-masked]

Dave Crocker <[email-masked]> writes:
> Ok.  So you implement armor and I implement MIME.  How do we interoperate?

Assuming that we have reached a consensus that MIME is a MAY or SHOULD,
but not a MUST, then how indeed do we cope?  Here's some suggestions.

1. Binary.  There is a compatible interoperability mode as long as 8-bit
comms is in place.  Of course, nobody is going to use it, but this mode
at least suits the letter of the IETF dictum that there MUST be a
compatibility mode accepted by all.

2. You implement Armour.  As you have discussed, it is quite similar,
not a technical difficulty at all.  One might be able to get buy with a
subset.  I can probably hunt up some freeware code for you.  If you've
got to add PGP anyway...

3. Encourage the 4 million to somehow upgrade to MIME MUAs.  This is no
great difficulty, given the awesome marketing machine that is 25 million
and doing very nicely, thank you.

4. Encourage the software developers to implement MIME in older software
like pgp2.6.  I'm open to bribery.

5. Install ordinary PGP on your machine.  Comes with Armour.

6. Switch to cleartext.  Comms in the clear is often better than no
comms.

7. Don't Communicate.  Given the compelling view that 25.1 million MIME
users can't be wrong, you shouldn't be too worried about the 4 million
older non-MIME users.

That's the problem with a broken standard.  There'll be so many bypass
options to choose from :-)

-- 
iang                                      systemics.com

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

Date: Thu, 27 Nov 1997 07:54:36 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Hal Finney <[email-masked]>
CC: [email-masked]
Subject: Re: The armour issue
Sender: [email-masked]

Hal Finney wrote:

> There is nothing wrong with a clear-signed MIME message for email.
> (Well, maybe it is harder with existing tools to save it to its own
> file and verify it again later, but that could be addressed.)

Ta.  I meant my task actually.  Looking at the actual message before my
browser munged it, there is enough info there to handle that, with some
scripting.  So it's technically possible to do, question remains whether
it is desirable (again, for this application) which means examining all
of the other factors.

-- 
iang                                      systemics.com

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

Date: Thu, 27 Nov 1997 07:44:48 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Bill Stewart <[email-masked]>
CC: IETF OpenPGP <[email-masked]>
Subject: Re: The armour issue
Sender: [email-masked]

Bill Stewart wrote:

> Surely you're not planning to FAX your keys in these days of Email?!

Actually, yes :-)  I see a world of lawyers with printed paper contracts
with embedded cleartext signatures, which they can fax around, then scan
in and run through pgp as soon as they need to check the signature.  One
would like to get them to use email, but...

<Somebody> in <some strange place> has a plan to sell <something> as
paper documents with ascii armoured messages on them, which users scan
in, and use pgp to convert into something useful, and then mail them
<somewhere>.  The reasons for this application are quite amusing...
-- 
iang                                      systemics.com

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

Date: Wed, 26 Nov 1997 22:17:07 -0800
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: The armour issue
Sender: [email-masked]

On Wed, Nov 26, 1997 at 07:55:50PM -0800, Dave Crocker / IMC wrote:
> 
> >How do armor and MIME compare in their support of this application?
> 
> yes, it would be nice if folks developed some familiarity with the relevant
> aspects of MIME.

I think the request was for worked out examples.

-- 
Kent Crispin				"No reason to get excited",
[email-masked]			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

Comments: Authenticated sender is <[email-masked]>
From: "Ng Pheng Siong" <[email-masked]>
To: Jeremey Barrett <[email-masked]>
Date: Thu, 27 Nov 1997 13:26:14 -0800
Subject: Re: Armour
CC: [email-masked]
Sender: [email-masked]

> I thought we were discussing PGP, not email. Last time I checked noone
> has implemented file encryption, or encrypted archiving tools, or
> remailers, or keyservers, or nym servers, or anything other than
> email (and on occasion news) using MIME. Nor should they.

</lurk>

I think we are discussing if armour should be a MUST in OPGP.

I've been following this debate off and on. Just one question: are 
you saying that armour is a MUST to implement the stuff in your 
example list? 

File encryption: pgp binary format.

Encrypted archiving tool: Tar or zip (or some proprietary archival 
format), then pgp-encrypt (or des, or oily-crypt) the archive. No 
armour.

Remailers: 1. If talking via SMTP, then this is about email. 2. 
Mixmaster uses its own binary format - no armour.

Keyservers: Historically, ftp interface - no armour; email interface 
- armour; WWW interface - armour carried in text/plaintext. LDAP - is 
armour necessary? How does PGP 5.x do it?

Nymservers: Haven't played with these; any example? Likely interfaces 
are, again, email, WWW, or LDAP.

Does Perl's Penguin use armour? If something like Penguin is 
implemented natively (i.e., doing the pgp bits directly, instead of 
invoking an external pgp app), armour is not needed.

> PGP is a powerful tool, used in many different ways. ONE of them is
> vanilla email. ALL of them benefit from ASCII armoring. ASCII armoring
> is essential to the survival of PGP and to the security of the "PGP 
> system", and the many systems built on top of it now and in the future.

Too many topic sentences in one paragraph. ;-)

"ALL of them" benefit from armouring: I think this point has 
not been clearly established.

Armour "essential" to survival of PGP and to "security of the "PGP 
system"": Ditto.

> One can implement MIME support without "switching to it". PGP/MIME is
> good. PGP/MIME SHOULD be done. ASCII armor MUST be done.

If there is no consensus, surely armour support must not be a MUST, 
but should be a SHOULD. 

Whether armour is MUST or SHOULD, nobody will produce an OPGP 
implementation without armour, IMHO.

If somebody does, the market will decide.

<lurk>
Ng Pheng Siong 
<[email-masked]>

Date: Wed, 26 Nov 1997 19:55:50 -0800
To: [email-masked]
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: The armour issue
Sender: [email-masked]

>How do armor and MIME compare in their support of this application?

yes, it would be nice if folks developed some familiarity with the relevant
aspects of MIME.

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

Date: Wed, 26 Nov 1997 19:50:18 -0800
To: Bill Frantz <[email-masked]>, [email-masked]
From: Jonathan Wienke <[email-masked]>
Subject: Re: The armour issue
Sender: [email-masked]

At 07:04 PM 11/26/97 -0800, Bill Frantz wrote:
>The first piece of signed code I ever got was MacPGP 2.6.2.  I like the
>idea of detached signatures on executable files.  One use I can see is
>signing every executable on your system and storing the signatures
>separately.  Then you can periodically check the system for altered code.
>(Too bad Mac code normally alters itself.)

This could be the basis of an extremely secure anti-virus scanner.  If the
signature key and verification program are kept only on a write-protected
floppy disk that is not usually in the computer, it would be extremely
difficult for a virus/trojan to alter a file without your knowledge.

>How do armor and MIME compare in their support of this application?

Binary is the way to go here.  MIME and armor are irrelevant and
unnecessary in an environment capable of handling 32-bit binary data.  Save
them for primitive systems that cannot yet deal with 8-bit data.

Jonathan Wienke

PGP Key Fingerprints:
7484 2FB7 7588 ACD1  3A8F 778A 7407 2928
3312 6597 8258 9A9E D9FA  4878 C245 D245 EAA7 0DCC

"If ye love wealth greater than liberty, the tranquility of servitude
greater than the animating contest for freedom, go home from us in peace.
We seek not your counsel, nor your arms. Crouch down and lick the hand that
feeds you. May your chains set lightly upon you; and may posterity forget
that ye were our countrymen."
-- Samuel Adams

"Stupidity is the one arena of of human achievement where most people
fulfill their potential."
-- Jonathan Wienke

Never sign a contract that contains the phrase "first-born child."

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

Date: Wed, 26 Nov 1997 19:04:20 -0800
To: [email-masked]
From: Bill Frantz <[email-masked]>
Subject: Re: The armour issue
Sender: [email-masked]

The first piece of signed code I ever got was MacPGP 2.6.2.  I like the
idea of detached signatures on executable files.  One use I can see is
signing every executable on your system and storing the signatures
separately.  Then you can periodically check the system for altered code.
(Too bad Mac code normally alters itself.)

How do armor and MIME compare in their support of this application?

-------------------------------------------------------------------------
Bill Frantz       | One party wants to control | Periwinkle -- Consulting
(408)356-8506     | what you do in the bedroom,| 16345 Englewood Ave.
[email-masked] | the other in the boardroom.| Los Gatos, CA 95032, USA

Subject: Re: Armour
Date: Thu, 27 Nov 97 13:37:46 +1100
From: Gavan Schneider <[email-masked]>
To: <[email-masked]>
cc: "Hal Finney" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Quoting Hal Finney <[email-masked]> on or about 1997/11/27 05:28 Sydney 
time-

>Dave Crocker writes:
>> 1.  Technical
>>
>>     There is no strong argument that either MIME or Armour are superior at
>> doing protection against the vagaries of transport.
>>
>>     It is worth noting that Armour combines the control information with
>> the data, whereas MIME keeps them separate.  This facilitates processing by
>> recipients who either do not have the necessary security software or who
>> want to defer its use.  That is, for authenticated data which is not also
>> encrypted, the main data can be kept cleartext whereas with Armour it is 
not.
>
>I described several technical objections to the use of MIME which no one
>has addressed.
>
Ok ok I might only qualify for the contingency substitute reserve bench 
but I will give it a go and see how I go :-)  I apologise if I end up 
creating too much work for others.

>Many of them are related to the MIME convention you describe of separating
>control information from data.  This works well in an email environment,
>where such separation is already in place.  We have mail headers and body,
>and it is natural to add the MIME control information to the headers,
>and to put the MIME body parts into the body.  This also works for HTTP
>and news, which have a similar header/body distinction.
>
My earlier comments were designed to be for email only.  I admit after 
reading the comment by Jon Callas <[email-masked]> that my "premise" stating 
this was poorly expressed but that was my intent.  I was not trying to 
draw a conclusion.

Now I will **try** to cover a broader scope.  And I am aware from Dave 
Crocker's separate reply that many of these issues are beyond the remit 
of the proposed standard.  I will try to tie some back to the proposal as 
best I can.

>But this model breaks down when we are in an environment where such
>separation does not exist.  I used the example of disk files.
>
I am sure others will comment on this and set me right as appropriate but 
I find it extremely hard to think of any logical construction which could 
ever hope to address files in the same breath as email, usenet and web 
based cgi transactions.

#pragma personal_opinion_mode true

I will now go right out on a long limb and risk all sorts of fire and 
brimstone (and this folks, without a helmet :-) and say:

A wonderful multi purpose application like PGP 2,3,5 does not fit well 
into a single standard.  (And I expect I am not the first to have thought 
that!)

In my mind the original and subsequent PGP applications all addressed 
multiple cryptographic needs from a single code base and in doing this 
came up with the necessary (non cryptographic) fixes like ascii armour 
just to get the thing to work in the real world.  As David Sternlight is 
so fond of saying Phil Z./PGP Inc. did not invent the cryptographic 
"bricks", the algorithms.  And I always thought that was a feature not a 
problem.  One big achievement of Phil Z./PGP Inc. was to built a "house" 
with good quality pretested "bricks" and bring it to us at a price we 
could afford.  And more recently to do some "renovations" because some to 
the original "bricks" are not as good as originally thought :-).

I think it would be a nonsense to attempt to codify some version of PGP 
as a standard.  A standard is not an application programming language.  
What we want from the standard is a well defined result.  The result we 
want is effective cryptography in our existing environments.  I do 
believe this process of defining a standard is a way of thinking about 
all the different services provided by the PGP application and getting 
the same benefits in an integrated way along side all the other 
"standard" ways to achieve specific results.

I want to emphasise that I am not claiming any of this is true.  I just 
wanted to say it so you would have a better idea of my mind set and maybe 
get a better gauge of what I think is so obvious I might never think to 
say it.

Thank you for your forbearance.  Please send me my "reeducation camp" 
bookings in a plain envelope.  I do not want my family to be upset :-)

#pragma personal_opinion_mode 0.5

>Now, some
>people have said that this should not count, either because people don't
>exchange disk files, or they don't need disk files to be ascii armored.
>Actually, people do exchange disk files all the time, either as email
>attachments, or by FTP, or by sharing them in other ways.
>
Mostly I use .hqx, .uu, .b64 or whatever binary-to-ascii transmission 
format the other person needs.  My helper/application list is already 
very long just to handle the current lot.  Why add another encapsulation 
format when these will do the job just fine?

When all is said and done an encrypted file is just another binary file 
for transmission purposes.  The general internet file transfer 
conventions with O/PGP would go something like:

Start with:
   mysecret.doc -> mysecret.pgp -> mysecret.uu
send file over internet
   mysecret.uu  -> mysecret.pgp
apply the correct key and the recipient gets mysecret.doc

And the standard should make this as simple as possible.  Ascii armour is 
not needed.  It would do just fine in place of encoding with 
uu/hqx/b64/... but is not needed.

>And there
>are reasons for ascii armoring files.  One good example is a clearsigned
>file, where you want to be able to view the contents while maintaining
>the signature in the file.  There may also be situations where people
>find it convenient to be able to view their encrypted files and see BEGIN
>PGP MESSAGE, so that they are reminded that they hold encrypted data.
>
>The only way that I can see to support this with PGP/MIME is to make
>the file consist of the MIME headers, then a blank line, then the MIME
>body parts.  In effect we adopt a convention that files do have two parts,
>control information and data, and that they are separated by a blank line.
>We are forced to do this if the file system does not provide us with
>another place to put lengthy control information, as most do not.
>
AFAIK O/PGP/MIME could only address the manner in which an email message 
is constructed.  It has nothing to do with the **internal** structure of 
an attached file if that file type is not defined to the mime system as 
needing translation.  If OTOH the O/PGP standard defines a mime 
conversion for files with suffix .pgp then the standard also has to be 
specific about the internal structure of that file.  To me this implies 
some sort of delimiter setup and could still be well defined in terms of 
mime type encapsulation.  After unpacking, the result on the recipient's 
system might have any combination of blank lines, resource forks, paired 
files with the proper suffix... pick your OS and you get the most natural 
solution, and the standard should deliver from one system/format to 
another system/format via the mime packing/unpacking.  The bits and 
pieces (content, signatures, certificates, whatever) are all best 
displayed via the application interface or as a result of a unix style 
command line.  Let the code do the work, use the standard to define the 
end results.

I have a dream... (sorry! wrong holiday :-) that O/PGP will not be a 
bunch of cluncky headers and strange looking ascii strings.  Sure that 
sort of stuff will still be around but it should be "under the hood".  
Interested types can still look at the raw data, nothing is hidden we 
just move to higher level of function.

>But since this convention cannot be applied uniformly throughout the file
>system, ambiguities arise.  There is no way to tell a priori whether a
>file is in this new "MIME format" or whether it is an ordinary file.
>I described various examples of where these ambiguities could cause
>problems.
>
Agreed.  O/PGP cannot define the contents of the file system at large, 
but it can define a valid file for its own purposes.  Nothing will ever 
stop people from sometimes serving the wrong files to an application.  
All we can ever do is ensure there is enough redundancy in the system to 
allow for robust sanity checking.  Ascii-armour is only one way.  I would 
like to hear an expert talk of the other possibilities.  And there is no 
specific reason why the current PGP file part delimiters cannot remain in 
files stored on the file system.  But we still need to repack the file if 
we want to transmit it over the internet and mime is the way to go in 
that area.

>I also pointed out other places where PGP/MIME conventions that would be
>logical for email don't make sense in more constrained applications, such
>as the convention that data to be signed MUST be converted to 7 bit form
>beforehand.
>
This is an excellent point.  Maybe the convention is wrong.  Let us not 
to hobble this new standard with an outmoded one byte alphabet.  If it 
has not been suggested already let's get multi byte alphabets built into 
the standard from the ground up.  No late add-on fixits to cater for the 
Chinese, Hindu, Japanese... scripts.  These are all huge markets and 
getting bigger, and I believe there is already an ISO standard for these 
alphabets.  We don't have to invent this wheel.  Just use it and make 
O/PGP savvy with it.

>In addition, I mentioned that PGP/MIME does not provide methods to
>encapsulate some legal PGP packet structures which were expected not to
>be used for email.
>
Propose the packets for inclusion.

>Sorry to be redundant here, but since my first message apparently made
>so little impact, perhaps a repetition will help.
>
No problem for me.  Got me off the bench.  But there are so many good 
players in this game I always think I look stupid :-)

Quoting Adam Back <[email-masked]> on or about 1997/11/27 07:51 Sydney 
time-
>
>A minimal implementation should be allowed to call itself OpenPGP
>compliant without implementing either MIME or armor.
>
I would worry about a standard which did not define a minimum 
functionality so that all implementations could talk to each other.  I 
think mime should be MUST, this is looking ahead, and means all 
conformant implementations can talk to each other via this format.  Allow 
ascii-armour as a MAY, does the right thing by history and the method is 
available between consenting parties.

Enjoy the turkey and holiday folks, it is already Thanksgiving in 
Australia

Regards,
Gavan.

Gavan Schneider           | In a world without fences,
<[email-masked]>      | who needs Gates?

Date: Wed, 26 Nov 1997 16:55:04 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: The armour issue
Sender: [email-masked]

--=--
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Ian Grigg wrote:

> OK.  I know it's not strictly within the gambit of the WG, but could
> somebody send me a clear-signed MIME message.  I'd like to see what it
> looks like and hazard a guess as to whether it can handle the task.

There is nothing wrong with a clear-signed MIME message for email.
(Well, maybe it is harder with existing tools to save it to its own
file and verify it again later, but that could be addressed.)

The issue I was raising is whether it would be useful in other contexts,
where the header/body distinction was not so natural.

Hal

--=--
Content-Type: application/pgp-signature

--=----

Date: Wed, 26 Nov 1997 16:23:10 -0800
To: Ian Brown <[email-masked]>, IETF OpenPGP <[email-masked]>
From: Bill Stewart <[email-masked]>
Subject: Re: The armour issue
Sender: [email-masked]

At 11:41 AM 11/26/1997 +0000, Ian Brown wrote:
>> Ascii armor allows PGP binary data to be held or transmitted in
>> any environment that may not be safe to raw binary data.
>Can you give us an example of this apart from mail? Web-based keyservers
>only use armour because they are based on mail servers. HTTP allows
>binary data to be transferred directly.

The Web-based keyserver isn't just using armor because it's on a mailserver.
A typical Web-based PGP application requires the user to cut&paste a
PGP key or PGP-encrypted message into a web form and submit it.
Not only are window systems highly prone to munging such data
(at least white space, backspaces, CRLFs, NULs, and other control characters,
if not necessarily munging 8-bit data), but web forms aren't always
friendly about accepting it, and are likely to turn it into forms like
%FF which need to be unmunged by the receiving program.
Some of this can be avoided by adding MIME support into PGP,
so it produces MIME-armored stuff to cut&paste instead of PGP-ASCII-armored,
but you still need armor.  (If you've got a friendly way around this problem,
I'd love to see it, because I'd like to be able to have users paste 
Microsoft Word/Excel/PPT documents into forms to autoadd to web pages.)

There's also the problem of sending PGP keys in email messages,
which MIME attachments aren't always the best user interface for:
	Bob - Sorry your corporate 	maildroids are using LookOutXChange!  
		(No Resemblence To Any Microsoft Product Intended.)
	If you want to buy GoodMTA, send email to [email-masked] using my
	PGP key <<KEY HERE>> and remember to also encrypt to accounting's
	key <<KEY HERE>> so the SMTP filter doesn't bounce it.
	If you want to send us your resume, purchasing's key is <<KEY>>.
It's really much cleaner if you've got a format that can stay inlined,
rather than getting transformed to ATTACH1.BIN, ATTACH2.BIN, ATTACH3.BIN.

MIME would do, if you've got a convenient interface for pasting MIME into,
but this requires making PGP aware of MIME headers - and if you do that,
you need to decide whether to build in full-scale MIME support or just
support some subset of features PGP is likely to use - do you build in both
base64 (for Real Binaries and keys) and Quoted-Printable (for clearsigned text)?

Then there's including keys inside encrypted messages - you need to
nest the armored key structure inside the encrypted message,
which means doing MIME-inside-MIME or Armor-inside-MIME or Armor-inside-Armor.
See above for difficulties with MIME-inside.

>I can see very little reason why people would want to store PGP data
>armoured in a system that supports 8-bit data.

1) Storing clearsigned text in files, in editor-readable form.
	Even if you use EMACS, it's nicer to have the signature
	in Armored for, and with Evil GUI Editors, it's more important,
	and in Dumb Text Editors over telnet, you'd really like
	to be able to read the signature undamaged so you can copy
	it into things.
2) Storing keys along with clear text, in editor-readable form.
	Bob - here's my Revocation Certificate - only use it 
	if my name shows up in the Dissociated Press wire stories
	or you hear periodic beeps when you call me.
		<<REVOCATION KEY>>
			Alice.
3) Keyservers that are going to output the data armored anyway,
whether it's by email or web.

>> Lastly, there are systems that use (or would like to use) PGP over systems
>> that are not the internet. I have given the example of pager systems
>> before. There are other systems that use telephones, private networks, or
>> other non-Internet means of data transfer.

That web form for that pager service isn't the Internet!
That web form for the text-to-speech reader isn't the Internet!
Surely you're not planning to FAX your keys in these days of Email?!
And then there's telex and TDDs ....  I'm not sure if base64 works there,
	or if you really need monocase base32 or binhex or something;
	PGP's ASCII armor may not be enough.

>> To forbid armor is to say that there is no conceivable use for it.
>No-one has suggested this.
Heh.  Dave Crocker's sure come real close :-)

				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Thu, 27 Nov 1997 00:34:36 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
CC: [email-masked]
Subject: Re: The armour issue
Sender: [email-masked]

Dave Crocker / IMC wrote:

> on the other hand, considerable community push-back on s/mime finally got
> it to support clear signing, through support of multipart/signed.  The
> market desire for this feature is rather high.

OK.  I know it's not strictly within the gambit of the WG, but could
somebody send me a clear-signed MIME message.  I'd like to see what it
looks like and hazard a guess as to whether it can handle the task.

I can see that a clear-signed S/MIME message won't float.  I'd hope that
a clear-signed PGP/MIME message was approximately similar to the
Armoured variety.
-- 
iang                                      systemics.com

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

Date: Wed, 26 Nov 1997 15:29:00 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Armour
Cc: [email-masked]
Sender: [email-masked]

Dave Crocker, <[email-masked]>, writes:
> At 10:28 AM 11/26/97 -0800, Hal Finney wrote:
> >Actually, people do exchange disk files all the time, either as email
> >attachments, or by FTP, or by sharing them in other ways.  And there
>
> In which case they are disk files and, again, are outside of the scope of
> this effort.
>
> This is effort is about adding security to Internet objects.

That seems to be a relatively restrictive description of what we are
doing, especially if you define Internet objects to only encompass
MIME objects.

I would suggest that this effort is about an Internet standard for
exchanging PGP encrypted/signed data.  FTP transfers of disk files do
appear to be within the scope of the OP standard.

Here is the WG description, from
http://www.ietf.org/html.charters/openpgp-charter.html:

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

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

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

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

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

Date: Wed, 26 Nov 1997 23:07:24 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: expedience, consensus and editing
Sender: [email-masked]

Dave Crocker <[email-masked]> writes:
> At 09:08 PM 11/26/97 +0000, Adam Back wrote:
> >My suggestions are:
> >
> >1) armor MAY
> >2) MIME SHOULD (with update to rfc2015 where missing parts)
> 
> Ok.  So you implement armor and I implement MIME.  How do we interoperate?

I understand fully your point, and I agree.  The difference is just
labelling.

The labelling problem I see is that people are planning to use OpenPGP
for different purposes.

What I meant above was:

2) MIME MUST if the data is transferred over 7 bit comms channel.

I'm not fussy, if people implement a full OpenPGP packet set but don't
plug it in to a MIME handler, it is true that they can't communicate
directly with people who send them MIMEd packets.  If we say (as I
take your previous posts to argue):

2) MIME MUST (always, no exceptions)

this means the 8 bit only people are not allowed to call their
implementation OpenPGP complaint.  Well I can live with a "that's their
problem", answer, and doesn't seem that big an issue.

Any other opinions?

Adam

Date: Wed, 26 Nov 1997 14:54:32 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: expedience, consensus and editing
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Keep in mind that you cannot do some things in PGP/MIME that you can with
ascii armor.

 - There is no PGP/MIME encoding of a detached signature

 - There is no PGP/MIME encoding of a non-clear signed message

 - I'm not sure if there is a natural encoding of a signed message which
   also includes a key certificate for verification.  Maybe you could use
   a multipart for this, but it's not in the spec, and it's not clear that
   it would interoperate.

It is also unclear what you do with the output when you decrypt a
PGP/MIME message.  People may not be aware that before encrypting you
MUST convert your input into a MIME body part, with a MIME header,
if it is not already in that form.

For example, to encrypt the one-line message:

   This is a test

you convert it to something like these three lines:

   Content-type: text/plain

   This is a test

and encrypt that.

Now, some issues arise on decryption.  If you added headers on encryption,
probably you should remove them on decryption, right?  That would
be pretty easy in the case above.  The first line is "Content-type:
text/plain", so you strip that and any related MIME headers off.

But what if that first line was "Content-type: multipart/mixed"?  Now do
you leave the MIME header lines on?  You can't really strip them because
the message body has structure and it can't be interpreted without the
headers.

What if it says "content-type: audio/basic"?  Just strip it and save
the raw data?  How about text/richtext?  Leave it, strip it, or try to
include a richtext interpreter?  At a minimum we would have to specify
the rules to follow for these various cases.

Or do we specify that PGP/MIME MUST only put simple Content-types into
the encrypted body part?  That wouldn't work well; the PGP Inc. plug-in
already encrypts multiparts and other cases.

The problem here is that PGP/MIME was designed to encrypt MIME-ish things.
That makes sense for email, especially given that MIME is available or
you wouldn't be using PGP/MIME.  But in the PGP world we want to encrypt
a wider range of things than that.  This introduces ambiguities such as
I have been describing here and in other messages.  Within a MIME-aware
mailer, all the PGP/MIME decryption module has to do is to strip off
the encryption and hand the MIME encoded body part back to the mailer
to worry about all these things.  But that is not an adequate solution
for the full range of applications we want to support.

I have struggled with these issues, because I've implemented PGP/MIME
within our SDK.  It does not lend itself to the "filter" model used
with the ascii armor and binary messages, where you have a single input
stream and a single output stream.  Thorny problems arise when you try to
implement it, as I have described.  I don't think it is a good substitute
for ascii armor in its full generality.  For email it's fine.

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

Date: Wed, 26 Nov 1997 23:11:23 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: expedience, consensus and editing
Sender: [email-masked]

Adam Back wrote:

> 1) armor MAY/SHOULD/MUST?

SHOULD (sorry, I'm an old-timer who sees armour as part of PGP)

> 2) MIME as MAY/SHOULD/MUST?

SHOULD

> 3) 32 bit int clean up shelved for OpenPGPv2, or discussed now

Defer

[ equals back-burner start in parallel.  Danger of stalling of V1 needs
alternate survival strategy. ]

> 4) CMR/ARR and alternatives worked through now or shelved for OpenPGPv2,

Define subpacket type 10 as reserved for future use.

[ "for OpenPGPv2" is not an option for the WG as someone (presumably PGP
Inc) must propose it for that first. ]

> ... and let's not perform the 32 bit
> clean up operation with OpenPGPv1, or it will delay the delivery date
> enormously.

What we lost in the cleanup discussions we might save in the coding :-)
-- 
iang                                      systemics.com

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

Date: Wed, 26 Nov 1997 14:43:14 -0800
To: Ian Brown <[email-masked]>
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: The armour issue
Cc: ietf-open-pgp <[email-masked]>
Sender: [email-masked]

At 09:49 PM 11/26/97 +0000, Ian Brown wrote:
>Ian Grigg's point in favour of armour is that clearsigned documents are
>useful. Fair enough; Ian can buy/write an application which includes
>this functionality. It does not need to be a MUST. As Adam just said, it
>would be simple to do the same with MIME.

on the other hand, considerable community push-back on s/mime finally got
it to support clear signing, through support of multipart/signed.  The
market desire for this feature is rather high.

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

Date: Wed, 26 Nov 1997 14:12:19 -0800
To: ietf-open-pgp <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Features issues...
Sender: [email-masked]

Our WG chair is unfortunately down with pneumonia. I talked to him a couple
of times yesterday, but he's severely under the weather now. Given that
this is also the start of a long weekend in the US, I think moving forward
is something *we* have to do.

Determining what the consensus is on the features we're continuing to talk
on (armor, ARR) is his responsibility, and none of us are presently adding
content (and I hold up my own last responses as being content-free).

	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, 26 Nov 1997 21:49:47 +0000
From: Ian Brown <[email-masked]>
To: Paul Rarey <[email-masked]>
CC: ietf-open-pgp <[email-masked]>, Adam Back <[email-masked]>
Subject: Re: The armour issue
Sender: [email-masked]

Paul - thanks for that post. Input like yours - from companies deciding
which standards to implement - is EXACTLY what we need in this debate.
We can sit around all day discussing the technical and political issues.
If the standard is not implemented, these discussions will be entirely
pointless.

As Adam says: S/MIME is racing ahead. Never mind completing at the same
time; Open PGP needs a good head start if we are going to overcome the
enormous odds we have against us (such as the 25 million installed base
of Netscape and Microsoft software). (Please flame me directly if you
must; this group cannot afford any more time to be wasted).

Ian Grigg's point in favour of armour is that clearsigned documents are
useful. Fair enough; Ian can buy/write an application which includes
this functionality. It does not need to be a MUST. As Adam just said, it
would be simple to do the same with MIME.

On Adam's other points: MIME SHOULD, shelve 32-bit cleanup for OP2,
define subpacket 10 as reserved for future use.

Can we move forward, *please*?

Ian.

Date: Wed, 26 Nov 1997 13:46:08 -0800
To: Adam Back <[email-masked]>
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: expedience, consensus and editing
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 09:08 PM 11/26/97 +0000, Adam Back wrote:
>My suggestions are:
>
>1) armor MAY
>2) MIME SHOULD (with update to rfc2015 where missing parts)

Ok.  So you implement armor and I implement MIME.  How do we interoperate?

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

Date: Wed, 26 Nov 1997 21:08:20 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: expedience, consensus and editing
Sender: [email-masked]

Dave Crocker / IMC <[email-masked]> writes:
> Jon Callas writes:
> >The compromise that I, as editor am working with (with thanks to Ian Brown,
> >who came up with it) is as follows:
> 
> Jon, those who serve as working group chairs and document editors have a
> difficult job.  They are usually senior, talented folk.  They get to work
> hard and almost never are adequately appreciated.
> 
> Worst of all, they are often architects who do not see their own
> preferences chosen.
> 
> The editor of an IETF working group document is required to be responsive
> to the rough consensus of the working group.  I hope no one has forgotten
> this minor point.

I would like to see more rapid progress in this forum.

I am subscribed to ietf-smime also, and the rate of progress there is
much quicker.  Suggestions are made for modifications, the active
editor says after some discussion, "ok added this, hows this", etc.
Consensus appears to be followed with minimal political intrigue.

Multiple revisions per day.

So can we have a decision on what is the consensus on these four
items:

1) armor MAY/SHOULD/MUST?
2) MIME as MAY/SHOULD/MUST?
3) 32 bit int clean up shelved for OpenPGPv2, or discussed now
4) CMR/ARR and alternatives worked through now or shelved for OpenPGPv2,

My suggestions are:

1) armor MAY

2) MIME SHOULD (with update to rfc2015 where missing parts)

3) shelve until for OpenPGPv2

4) define subpacket type 10 as reserved for future use and get on with
   things.

I already made 2 detailed posts explaing reasons for my recommendation
for 4, and have had 2, or 3 people agree with my conclusion and have
seen no disagreements on list.

It seems the least controversial path, and the quickest path to take,
and doesn't affect compatibility.  The alternative of hashing out a
consensus here of which method best allows for lost passphrase
recovery seems that it will take forever.  PGP Inc seem to be using
message snooping techniques which reduce communications security to
implement passphrase recovery, which in my and most of the non-PGP
peoples opinion is bad design.

Let's not get adventurous, and let's not have a massive brawl over
controversial experimental features, and let's not perform the 32 bit
clean up operation with OpenPGPv1, or it will delay the delivery date
enormously.

Adam

Date: Wed, 26 Nov 1997 20:51:17 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Armour
Sender: [email-masked]

Hal Finney <[email-masked]> writes:
> Many of them are related to the MIME convention you describe of separating
> control information from data.  This works well in an email environment,
> where such separation is already in place.  We have mail headers and body,
> and it is natural to add the MIME control information to the headers,
> and to put the MIME body parts into the body.  This also works for HTTP
> and news, which have a similar header/body distinction.
> 
> But this model breaks down when we are in an environment where such
> separation does not exist.  [...]
> 
> The only way that I can see to support this with PGP/MIME is to make
> the file consist of the MIME headers, then a blank line, then the MIME
> body parts.  In effect we adopt a convention that files do have two parts,
> control information and data, and that they are separated by a blank line.
> We are forced to do this if the file system does not provide us with
> another place to put lengthy control information, as most do not.

Sounds reasonable, and the way that I would expect MIME encoding to be
implemented in files where this is required.

You could view armor as already having this same two part structure
.. it has to have a blank line (in pgp5 ... pgp2.x did not have this
restriction, btw).  So with armor your header is:

: -----BEGIN PGP MESSAGE-----
: Version: 2.6.3i

and the body is:

: hQEMA1u1vznKKgBtAQf/ZOZpqGBKIprmGUtUq/B/IPgGKE68r/D90fiSsKW3saCR
: L8doacYM8PnRsKRrWq1MMxcn9AE3keAuqYUnosn/Wokd9zYtKJho13Yc7VxHqV2I
: /dRkq4WxZlogmChxtaGFFSEiPC/bgFBbMryA0QQleCbArp3+16+TtLvG+uz9jezU
: R+N+rzCILKJIUxt3HG14kz4RRA+x4VwV8h9A/TnCDgxGiUwDCxOranMJwmHPAsZa
: Dr2xBFFe7Ael/D2ZbPfHdLWHnbZI81kuS1uE1YnLdt8xWtaUkPTCuHKANY1ccXj/
: 0v5CKfh27QqRACNeU+QBxaWTpBb4fXyjN6A5uqnDBqYAAAEwIG8UxuzfMPGPHFl4
: B0jISuJP/3FCnTgxl7gihtiwRDmdoOB7K8Tvw4YVhsl/oObo/kfx+pBAB0G65J+6
: f3IFU2a8SR6Gfm9g5pJjTSkt++q5R5qV7OAbenlYs5+w1Dh1plpWb46q4gpjrpqN
: +TnHl3HPvB6OfkUrU2KogvI/R8TEkb0qfojI4qexk305TRb+X46Zm9/kY41yOZoB
: 3tWCnjFN4dWBy5KZYk/TsToCyzzQ2mo/CPRTLrD3Ib99+Iwwd97u4pCIc0vLeFXZ
: CYOdgOujyFw3ooI5P0drX9skZWd7bndg3T/TeZfdxXpDc0YQFREFI9WjvZ9Cqj7g
: DnZS7mOhlc1wsS7rZDrNSqsDAz/a+Tlq92xRQzBjF2Wh8ca5z1KV6MLq3MtZWEJ6
: 9NPC9A==
: =JEnb
: -----END PGP MESSAGE-----

Where they are separated by a blank line.

Same thing for MIME, header:

: Content-Type: application/pgp
: Content-Transfer-Encoding: radix64

and body:

: hQEMA1u1vznKKgBtAQf/ZOZpqGBKIprmGUtUq/B/IPgGKE68r/D90fiSsKW3saCR
: L8doacYM8PnRsKRrWq1MMxcn9AE3keAuqYUnosn/Wokd9zYtKJho13Yc7VxHqV2I
: /dRkq4WxZlogmChxtaGFFSEiPC/bgFBbMryA0QQleCbArp3+16+TtLvG+uz9jezU
: R+N+rzCILKJIUxt3HG14kz4RRA+x4VwV8h9A/TnCDgxGiUwDCxOranMJwmHPAsZa
: Dr2xBFFe7Ael/D2ZbPfHdLWHnbZI81kuS1uE1YnLdt8xWtaUkPTCuHKANY1ccXj/

> But since this convention cannot be applied uniformly throughout the file
> system, ambiguities arise.  There is no way to tell a priori whether a
> file is in this new "MIME format" or whether it is an ordinary file.

If it is a MIME format file, it will have Content-Type: etc. fields
saying what kind of PGP object it is.

Same as the armor header.

I personally am accustomed to armor because my mailer uses it and
because I haven't bothered installing direct MIME support.

However it seems that MIME is the way forward, and that having Armor
as a MAY allows implementors to implement it for backwards
compatibility.

I think neither MIME nor Armor should be MUST.  Both MAY.  You could
argue for SHOULD for backwards compatibility.

(Note: with IDEA and RSA relegated to SHOULD or is that MAY already,
backwards compatibility is already lost for a minimal MUST only
implementation.)

A minimal implementation should be allowed to call itself OpenPGP
compliant without implementing either MIME or armor.

You might need to define some new MIME types to go with rfc2015 for
the MIME types for the objects which you say are missing.

Adam

Date: Wed, 26 Nov 1997 12:47:34 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
CC: [email-masked]
Subject: Re: PGP evolving, improving
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms2B0D2D6E9EDD702B61C36323
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

A. Padgett Peterson P.E. Information Security wrote:

> >
> >Free PGP had used RSAREF (for RSA), a software package made available free
> >by RSADSI for anyone's non-commercial use. No patent issues, fees, or
> >litigation are involved. This is TOTALLY clear, not "not exactly clear"
> >as Peterson claims.  There is no "may be exempt" about those versions of
> >free PGP. Thay are, in fact, fully licensed for non-commercial use of RSA.
> >He should read the RSAREF license.
>
> May have changed but when it first came out I looked into the RSAREF and
> was rather astounded by the wording of the "free" license agreement - looked
> like something Microsoft might have written. Wasn't even something the I,
> as a hobbyist, would sign since the restrictions seemed to outlive the
> patent.

I don't know what the above hand-waving paragraph means, but it is
non-responsive to my correction.

> Not going into the fact that you missed my point entirely since it is more
> properly directed at PGP Inc.

Your point turned on there being a licensing cloud or licensing fees over Free
PGP. There wasn't.

> - Is there something in the license you have
> with RSA for the commercial product that limits what you can put into a
> "free" version without paying RSA a fee ?

I assume you mean the commercial licnnse PGP Inc. has. The RSAREF license used
with Free PGP has nothing to do with any other license PGP Inc. may or may not
have. It stands on its own.

> If that is "no" then I too will
> ask why the free version should not contain the older mechanisms for
> compatability. (I use the commercial version so do not know if it does or
> does not).

Welcome to the club.

David

--------------ms2B0D2D6E9EDD702B61C36323
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms2B0D2D6E9EDD702B61C36323--

Date: Wed, 26 Nov 1997 20:46:26 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Ian Brown <[email-masked]>
CC: [email-masked]
Subject: Re: The armour issue
Sender: [email-masked]

Ian Brown wrote:
> > Ascii armor allows PGP binary data to be held or transmitted in
> > any environment that may not be safe to raw binary data.
> 
> Can you give us an example of this apart from mail? Web-based keyservers
> only use armour because they are based on mail servers. HTTP allows
> binary data to be transferred directly.

( Armour also allows cut and paste.  Presumably MIME would as well, I
don't know. )

...
> I can see very little reason why people would want to store PGP data
> armoured in a system that supports 8-bit data.

I can't think of a reason either.  What I do want to do is to store
clear text  signatures.  That I need.  I don't know whether MIME can do
that, or whether it is applicable ...

The specific instance is the contract.  The cleartext sig must be
embedded, obvious, and small (a la PRZ bit-culling).  I would see S/MIME
as a non-starter here as people talk about multiple K sigs, but maybe a
MIME encoding of a PGP sig is ok.  I won't know until I see one and look
at how scriptable it is.

I don't understand enough about the MIME vs Armour debate to know
whether clear text sigs are effected.  Is this Armour or something
else?  It's certainly PGP.

> > There are other applications that use PGP technology
> > for authentication, enveloping, etc. and use armor.
> 
> Is this because they transfer data by mail?

If assuming the above contract is included in the notion of Amour, then
the answer is "not only mail, they have to be readable by humans in a
wide variety of contexts."

...
> > To forbid armor is to say that there is no conceivable use for it.
> 
> No-one has suggested this.

I suggest you be boring and repeat (every second post) what it is that
is being suggested.  One of the problems I had with this debate was
working out what the proposal was (that's partly why I kept away from
it, waiting for someone to state what).

> > Armor itself is
> > still a preferred way of transmitting OP objects that are not messages.
> 
> Could you give us a case where it is vital to the understanding of an
> object that it is armoured - i.e. just interpreting the underlying
> binary packet(s) will not give you the full meaning of the object.

The contract above must be clear, not binary.  The reasons for this are
complex and messy.  I'll fill you in if we can decide if a clear text
sig is applicable to this debate.

-- 
iang                                      systemics.com

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

Date: Wed, 26 Nov 1997 15:41:16 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: PGP, MIME, and Armour
To: [email-masked]
Sender: [email-masked]

Actually Hal make a valid point that appears to need emphasis: in a
recursive message such as would exist in a PGP encrypted file which was 
then MIME encoded, how would the recipient know what it was ?

Today, I can recognize PGP files for me by the "h" as the first character
just as the typical UUENCODE first character is "M". It would seem to
make sense that part of the standard be to bring forth to the top level
each of the successive levels of encoding so that the recipient can tell
what has been received without unbundling.

Note that this is not something that is specific to PGP and AsciiArmouring
but rather pertinant to any recursive mechanism.

					Warmly,
						Padgett

ps of course maybe this is not a bug but a feature to make automatic
   universal decoders to spend as much time on each message as possible 8*)

Date: Wed, 26 Nov 1997 11:11:58 -0800
To: Hal Finney <[email-masked]>
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: Armour
Cc: [email-masked]
Sender: [email-masked]

At 10:28 AM 11/26/97 -0800, Hal Finney wrote:
>separation does not exist.  I used the example of disk files.  Now, some
>people have said that this should not count, either because people don't
>exchange disk files, or they don't need disk files to be ascii armored.

No, the major reason for dismissing it is that it is outside the scope of
this effort, since this is a standards effort for the Internet, which means
it is for transport across data networks, not storage on files.

>Actually, people do exchange disk files all the time, either as email
>attachments, or by FTP, or by sharing them in other ways.  And there

In which case they are disk files and, again, are outside of the scope of
this effort.

This is effort is about adding security to Internet objects.

>The only way that I can see to support this with PGP/MIME is to make
>the file consist of the MIME headers, then a blank line, then the MIME
>body parts.  In effect we adopt a convention that files do have two parts,
>control information and data, and that they are separated by a blank line.

The idea that armour does not impose its own encoding conventions is really
rather strange.  The fact that you seem to think it does not probably
reflects a comfort with one approach and discomfort with another.  This is
not a technical issue, it is psychological.

>In addition, I mentioned that PGP/MIME does not provide methods to
>encapsulate some legal PGP packet structures which were expected not to
>be used for email.

Details?

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

Date: 	Wed, 26 Nov 1997 13:32:10 -0500
From: [email-masked]
To: David Sternlight <[email-masked]>
cc: [email-masked]
Subject: Re: PGP evolving, improving
Sender: [email-masked]

I would dearly like that the discussions on here revolve around the
guidelines set up for this mailing list.

I'm tired of seeing your arguements seemingly multiply to wherever any pgp
mailing list or newsgroup is to be found. If you  want to contribute
to advancing the open pgp project then you are more than welcome,
otherwise please don't distract the many people on here who are trying to
advance a noble project.

regards

robert

Date: Wed, 26 Nov 1997 10:28:25 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Armour
Sender: [email-masked]

Dave Crocker writes:
> 1.  Technical
>
>     There is no strong argument that either MIME or Armour are superior at
> doing protection against the vagaries of transport.
>
>     It is worth noting that Armour combines the control information with
> the data, whereas MIME keeps them separate.  This facilitates processing by
> recipients who either do not have the necessary security software or who
> want to defer its use.  That is, for authenticated data which is not also
> encrypted, the main data can be kept cleartext whereas with Armour it is not.

I described several technical objections to the use of MIME which no one
has addressed.

Many of them are related to the MIME convention you describe of separating
control information from data.  This works well in an email environment,
where such separation is already in place.  We have mail headers and body,
and it is natural to add the MIME control information to the headers,
and to put the MIME body parts into the body.  This also works for HTTP
and news, which have a similar header/body distinction.

But this model breaks down when we are in an environment where such
separation does not exist.  I used the example of disk files.  Now, some
people have said that this should not count, either because people don't
exchange disk files, or they don't need disk files to be ascii armored.
Actually, people do exchange disk files all the time, either as email
attachments, or by FTP, or by sharing them in other ways.  And there
are reasons for ascii armoring files.  One good example is a clearsigned
file, where you want to be able to view the contents while maintaining
the signature in the file.  There may also be situations where people
find it convenient to be able to view their encrypted files and see BEGIN
PGP MESSAGE, so that they are reminded that they hold encrypted data.

The only way that I can see to support this with PGP/MIME is to make
the file consist of the MIME headers, then a blank line, then the MIME
body parts.  In effect we adopt a convention that files do have two parts,
control information and data, and that they are separated by a blank line.
We are forced to do this if the file system does not provide us with
another place to put lengthy control information, as most do not.

But since this convention cannot be applied uniformly throughout the file
system, ambiguities arise.  There is no way to tell a priori whether a
file is in this new "MIME format" or whether it is an ordinary file.
I described various examples of where these ambiguities could cause
problems.

I also pointed out other places where PGP/MIME conventions that would be
logical for email don't make sense in more constrained applications, such
as the convention that data to be signed MUST be converted to 7 bit form
beforehand.

In addition, I mentioned that PGP/MIME does not provide methods to
encapsulate some legal PGP packet structures which were expected not to
be used for email.

Sorry to be redundant here, but since my first message apparently made
so little impact, perhaps a repetition will help.

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

Date: Wed, 26 Nov 1997 10:04:27 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Critical bit (was: case for removing subpacket type 10)
Sender: [email-masked]

Ian Grigg, <[email-masked]>, writes regarding the critical bit:
> In the case of the Criticality bit, you will still have comms, but the
> various MUAs will alert you to problems, which is ideal.  No loss of
> functionality, but an annoying reminder to upgrade every time you talk
> to  someone :-)   On this basis alone, I think we'd like to avoid a
> standardised "please upgrade me" virus.

The claim seems to be that the critical bit will lead to annoying software
which pesters the user to upgrade.  But this would not necessarily happen.
There is no more reason to tell the user about an unknown packet with
a critical bit than to tell him about an unknown packet without the
bit set.  Either way, upgrading might be a good idea as it will add some
(inherently unknown) functionality.  All the critical bit changes is
the default handling of the signature containing the unknown packet.

> I think the issue here surrounds the nature of the extension.  Normally,
> if one wanted to hack in and add the <i>whatiwant</i> feature, one would
> do it in such a way that the feature was innocuous to older
> non-conforming software.  So the feature has to be an addition, without
> which the sum is unchanged from the older standard.
>
> In the new packets as discussed here, the PGP Inc whatiwant feature is a
> *subtraction* in that it applies some limit to the power of the
> signature.  Now, you can't take something away, and then put it back
> whilst talking to those that don't understand the new mathematics.  PGP
> Inc people have recognised this, and have added an additional feature
> that says "on any subtraction, reject the lot."  If everybody
> understands that there is a subtraction going on, then at least if they
> can't put back that which was lost, then they can consider the whole
> things broken.

The purpose of the critical bit is to make it easier to add extensions
to the meaning of signatures.  One thing we have found in 5.X is the
difficulty of trying to maintain backwards compatibility with old versions
of PGP.  We want to try to avoid this in the future by designing so that
future implementations will have an easier job being backwards compatible.

The critical bit greatly increases the flexibility and ease of adding
new features without breaking old implementations.  You can create new
kinds of signature qualifications, which would otherwise be interpreted
wrongly by old code.  For example, suppose we hadn't thought of adding
signature expirations and we wanted to add a field for that purpose.
Issuing a signature with an expiration field will be dangerous because
old software won't understand the expiration part and will treat it
as valid even when it has expired.  This breaks the security model.
By setting the critical bit we make the old software ignore signatures
with expirations rather than treating them as lasting forever.

It's a matter of whether the old software errs on the secure side versus
on the risky side.  The critical bit increases security by making the
software err conservatively.

> Hal said:
>         - On a self-signature, ignore the key if you don't understand the
>           subpacket type.  This is because the self-signature may be
>           saying something important qualifying the meaning of the key or
>           how it is intended to be used by the owner.  If you don't know
>           what he's saying, it's safest not to use the key.
>
> This is trouble piled upon trouble.  Trying to set this sort of
> behaviour up in complex software is tricky, and is best avoided unless
> you're well paid to do precisely that (and I hope the folks at PGP Inc
> are indeed well paid).  Putting it into a standard is equivalent to
> institutionalising software failures.

I don't understand why this simple rule is so troublesome.  But even if
this particular case seems difficult, the more general rule of ignoring
signatures with unknown critical subpackets should be straightforward
enough.  (The self-signature rule would then follow automatically if we
adopted the convention of not using userids that were lacking self-sigs,
as Lutz has suggested.)

> I would suggest that the Criticality bit be dropped.

This will limit the scope of future expansions.  Designers who want to
add new semantics to signatures (e.g. see the SPKI work, PolicyMaker,
or any of the many research projects on trust models) will find their
options limited.  They will probably have to create new kinds of signature
packets just so that old software will ignore their signatures.  This will
lead to redundancy, with different signature packets defined with the
same or similar semantics, solely to prevent old software from treating
the signatures the wrong way.

The critical bit is a benefit to future designers.  It helps to make
the spec more robust and able to accommodate future needs.  It does not
add much complexity to just ignore signatures which have unrecognized
critical subpackets.  It will be a useful feature.

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

Date: Wed, 26 Nov 1997 12:44:05 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: Re: PGP evolving, improving
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>Peterson is quite mistaken in his post below.
(who  8*)

>Free PGP had used RSAREF (for RSA), a software package made available free 
by RSADSI for anyone's non-commercial use. No patent issues, fees, or 
litigation are involved. This is TOTALLY clear, not "not exactly clear" 
as Peterson claims.  There is no "may be exempt" about those versions of 
free PGP. Thay are, in fact, fully licensed for non-commercial use of RSA.  
He should read the RSAREF license.

May have changed but when it first came out I looked into the RSAREF and 
was rather astounded by the wording of the "free" license agreement - looked
like something Microsoft might have written. Wasn't even something the I,
as a hobbyist, would sign since the restrictions seemed to outlive the 
patent.

Not going into the fact that you missed my point entirely since it is more
properly directed at PGP Inc. - Is there something in the license you have
with RSA for the commercial product that limits what you can put into a 
"free" version without paying RSA a fee ? If that is "no" then I too will
ask why the free version should not contain the older mechanisms for 
compatability. (I use the commercial version so do not know if it does or
does not).
					Warmly,
						Padgett

Reply-To: "Paul Rarey" <[email-masked]>
From: "Paul Rarey" <[email-masked]>
To: <[email-masked]>
Subject: Re: The armour issue
Date: Wed, 26 Nov 1997 09:20:28 -0800
Sender: [email-masked]

I've been reading quite a bit about the virtues of MIME vs. ASCII Armor (AA)
for secure messages. Frankly - I don't understand the delima. AA was a great
tool to solve problems Secure Message Exchange (SME) imposed when AA was
envisioned and implemented. AA solved problem's that don't need solving in
today's message exchange standards (and.. most relevant.. pervasive
installation) for progressing SME as a "dial tone" service.

I don't see the fruits of this effort as only germane to SMTP {supporting
business to business information transactions (Inter/Intra/Xtra or whatever
the flavor of the day wants to call it)}. There is a clear need within my
organization's intranet (gee.. the terms we stoop to today....:-) for secure
heterogeneous message exchange. Folks.. CICS, IMS, MQ, HTTP, ODBC servers,
Notes, --and-- Exchange exchange message units. As the principle architect
for infrastructure systems in my organization I can emphatically state - AA
has no place, MIME with [ pretty good ] privacy services does. PGP/MIME is
an excellent candidate to date.... (MOSS is ..nice.. - but there's little to
no chance of pervasive deployment).

I have no problem with those that desire inclusion of AA as an option for
receiving... then let the market decide on sending. Clorox won't be in the
"buy" category for any "Must support send with AA" product....

Some grunt w/a budget....
[ psr ]

-----Original Message-----
From: Dave Crocker / IMC <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Gavan Schneider <[email-masked]>; [email-masked]
<[email-masked]>
Date: Tuesday, November 25, 1997 6:52 PM
Subject: Re: The armour issue

>At 06:01 PM 11/25/97 -0800, Jon Callas wrote:
>>or transmitted in any environment that may not be safe to raw binary data.
>
>so does MIME.
>
>>For example, PGP key servers transmit keys both to and from the server in
>
>so can MIME.
>
>>Armor is also useful for future applications.
>
>so is MIME.
>
>>Lastly, there are systems that use (or would like to use) PGP over systems
>>that are not the internet.
>
>Then they are not relevant to an Internet standards process.
>
>>Furthermore, I disagree with this strongly. MIME is a preferrered way (by
>
>MIME is the standard way.  As I try to make clear, that's not just a matter
>of bureaucratic formaltiy, it is a matter of actual use.  The purpose of a
>standard is to achieve interoperability.  The more choices there are, the
>less interoperability there is.
>
>Absent a strong claim as to the technical superiority of armour or
>something else, the only reason to support an alternative mechanism which
>does the same job is... well, nothing constructive.
>
>>text describing it was done by Paul Hoffman, who used MIME as a base. So
>>it's quite easy to do both.
>
>The question remains:  what functional basis is there for retaining
>armouring in the standards-based specification.  The argument of
>compatibility with the pre-standards installed base has already been
>countered for a number of different issues, not just armouring.  The idea
>of possible uses in the future is an argument for MIME, not a legacy
>mechanism.
>
>>The compromise that I, as editor am working with (with thanks to Ian
Brown,
>>who came up with it) is as follows:
>
>Jon, those who serve as working group chairs and document editors have a
>difficult job.  They are usually senior, talented folk.  They get to work
>hard and almost never are adequately appreciated.
>
>Worst of all, they are often architects who do not see their own
>preferences chosen.
>
>The editor of an IETF working group document is required to be responsive
>to the rough consensus of the working group.  I hope no one has forgotten
>this minor point.
>
>>(1) I'm going to remove anything in OP-FORMAT that requires the use of
>>ascii armor. Following my touchstone that any feature needed for backwards
>>compatibility is a SHOULD, it'll be a SHOULD.
>
>Now if you just move it to an appendix and note that it has been the basis
>for "packaging" PGP in pre-standards versions of the technology, then we'd
>be in perfect shape.  This would leave the document with one standard way
>to do the packaging, but with full documentation about the prior
>(non-standard) way of doing it.
>
>d/
>--------------------
>Dave Crocker                                          [email-masked]
>Internet Mail Consortium                               +1 408 246 8253
>675 Spruce Dr.                                    fax: +1 408 249 6205
>Sunnyvale, CA 94086 USA              [email-masked] , http://www.imc.org

Date: Wed, 26 Nov 1997 08:57:59 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: PGP evolving, improving
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msF9FDBF5E9A87FDB35AAF7313
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

(This message is being copied to the S/MIME list only for the matter in the last
paragraph of my response. Readers of the S/MIME list are requested to ignore the
matter that is PGP-specific).

Peterson is quite mistaken in his post below.

Free PGP had used RSAREF (for RSA), a software package made available free by
RSADSI for anyone's non-commercial use. No patent issues, fees, or litigation are
involved. This is TOTALLY clear, not "not exactly clear" as Peterson claims.  There
is no "may be exempt" about those versions of free PGP. Thay are, in fact, fully
licensed for non-commercial use of RSA.  He should read the RSAREF license.

The usage has nothing to do with Viacrypt, mergers, or anything else of the sort.
It was that package, used in MIT PGP 2.x, (as well as the use of RSA overseas) that
produced the huge RSA key base that made PGP's reputation and which they wave in
front of the IETF to legitimiize themselves,. That PGP Inc. dropped RSA key
generation in Free PGP 5.0 (while continuing to use RSAREF--so it was a completely
gratuitous act), and then in Free 5.52 completely disabled any RSA compatibility
with that huge user base, is, I assert, unconscionable. SInce they have done that,
leaving aside the 'biting the hand that feeds one' aspect, the IETF should not
credit any PGP Inc. user base claims involving number of holders of RSA PGP keys.
This leaves PGP as a minuscule segment of the market compared with, for example,
the installed base of S/MIME applications (well over 25 million) from Netscape and
Microsoft. Any IETF standards activities must take account of that physical reality
in the marketplace.

Of more technical importance, this group should insure that this cannot happen
again. "Open" anything should not be designed so that an entire user base of keys
and certificates resulting from the standard will later become obsolete just
because a post-release algorithm is later added to the standard or an existing
algorithm in the release is "improved".

PGP Inc., having proven (in my view) their untrustworthiness on this point, should
not be allowed any configuration influence at all with an Open PGP standard, and
the IETF should insure that no control or influence of any kind over intellectual
property can be exercised on Open PGP by PGP Inc. I make this point not as a
general principle (since "non-discriminatory access on equitable terms" is the IETF
policy mantra despite the attempts of some to go beyond that in the case of
S/MIME), but rather because of PGP  Inc's specific behavior in obsoleting this
entire user base of PGP RSA keyholders in their latest versions of Free PGP..

Finally, a related point. If the pace of the Open PGP standards group is anything
like the past history of voluntary PGP efforts (or maybe voluntary anything
efforts), by the time the standard is done the RSA patent will have expired (or
close enought not to make much difference to reasonable market penetration rates).
It seems to me a realistic view of that eventuality and of realistic project
scheduling might be useful in avoiding much of the to and fro fussing on this topic
as well as totally avoiding all the noise about PGP Inc. vs. RSADSI. So to do would
have the advantage that one resultant IETF standard (Open PGP) could be designed to
be equally available to commercial users while using as "musts" two widely-trusted
algorithms, RSA and TDES.

If that thinking were accepted, the focus, as between the Open PGP standard and the
S/MIME 3 standard, can become what at least this writer thinks it ought to be--one
standard for web of trust and another for rigid heirarchical certification. This
would insure the (security) purity of each model, its use for the things it is most
suited for, and avoid any attempt to corrupt either (to try to emulate the other
and get some of its market share). To do otherwise would lose some of either the
free-form character of web of trust, or the exclusionary assurance character of
rigid heirarchical. (By "exclusionary" I mean that every certifier must fall within
the overall tree structure and to do so must meet specified, audited standards for
certification operations assured from the top down, as an "if and only if"
condition.)

David

A. Padgett Peterson P.E. Information Security wrote:

> Note: this is really politics and not RFC business - my apologies but something
>       of a sore point.
>
> David rote:
>
> >And free PGP users didn't deserve an eased upgrade path, but rather to forcibly
> >obsolete all their keys, signatures and web of trust in the new version?
> >Especially since the RSA-key Free PGP user base is where PGP Inc. made their
> >reputation and the size of that base is constantly cited to the IETF and in
> >press releases as PGP's "customer base". Don't be ridiculous. And watch who you
> >throw stones at--can you say "glass house"?
>
> Am surprised at this posting as it seems to forget one major problem: RSA is
> patented. I have been told repeatedly by PGP that one of the reasons they do
> not offer a site license (nor a real personal license for that matter in the
> sense of being authorized to operate on all solely-used computers) is a
> requirement by RSA for a "per CPU" fee.
>
> True, the "free" version may be exempt under the terms of the patent but
> this has never been exactly clear. Do suspect that when PGP and Viacrypt
> did their inverse triangular multibuyout which resulted in a common point
> for both free and commercial versions that some of the clauses of the RSA
> license began covering PGP Inc and thus the "free" version as well (do you
> realize that there are fifty thousand lawyers in Florida alone ?  Twice as
> many Southern Bell yellow pages of attorneys as doctors and churches
> combined ?)
>
> Would be nice if RSA put the mechanism into the public domain but since they
> reniged on the S/MIME components, I have doubts that this will happen.
>
> Sounds like an opportunity for some programmer to create a "front end" to
> determine which is being used and to invoke the correct version but this is
> the reason that RSA (or any proprietary mechanism) should *never* be a MUST.
>
>                                                 Warmly,
>                                                         Padgett

--------------msF9FDBF5E9A87FDB35AAF7313
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msF9FDBF5E9A87FDB35AAF7313--

Date: Wed, 26 Nov 1997 11:41:48 +0000
From: Ian Brown <[email-masked]>
To: Jon Callas <[email-masked]>, IETF OpenPGP <[email-masked]>
Subject: Re: The armour issue
Sender: [email-masked]

> Ascii armor allows PGP binary data to be held or transmitted in
> any environment that may not be safe to raw binary data.

Can you give us an example of this apart from mail? Web-based keyservers
only use armour because they are based on mail servers. HTTP allows
binary data to be transferred directly.

>From RFC 2068 (HTTP 1.1)

   Transfer codings are analogous to the Content-Transfer-Encoding
   values of MIME , which were designed to enable safe transport of
   binary data over a 7-bit transport service. However, safe transport
   has a different focus for an 8bit-clean transfer protocol. In HTTP,
   the only unsafe characteristic of message-bodies is the difficulty in
   determining the exact body length (section 7.2.2), or the desire to
   encrypt data over a shared transport.

I can see very little reason why people would want to store PGP data
armoured in a system that supports 8-bit data.

> There are other applications that use PGP technology
> for authentication, enveloping, etc. and use armor.

Is this because they transfer data by mail?

> I am presently working with
> someone who is using the new extension mechanism to build an SPKI-like
> authorization system for a network server. They want to use armored
> blocks.

Unless they want to transmit data by mail, there is no need for them to.
They can send it as 8-bit data. If they do need to, they can use MIME as
they don't need backwards compatibility.

> Lastly, there are systems that use (or would like to use) PGP over systems
> that are not the internet. I have given the example of pager systems
> before. There are other systems that use telephones, private networks, or
> other non-Internet means of data transfer.

I would have thought the vast majority of non-Internet means of data
transfer allow 8-bit data to be transmitted over them.

> Armor has little to do with message
> transmission, and everything to do with *OBJECT* (keys, authorizations,
> etc.) transmission.

PGP objects are made up of binary packet(s). They have very little to do
with armour. The labelling is in most cases a convenience feature. For
example:

contains a binary encoded Signature packet. It is the format of the
underlying binary data which defines the object, not the armour.

> To forbid armor is to say that there is no conceivable use for it.

No-one has suggested this.

> Armor itself is
> still a preferred way of transmitting OP objects that are not messages.

Could you give us a case where it is vital to the understanding of an
object that it is armoured - i.e. just interpreting the underlying
binary packet(s) will not give you the full meaning of the object.

> (1) I'm going to remove anything in OP-FORMAT that requires the use of
> ascii armor. Following my touchstone that any feature needed for backwards
> compatibility is a SHOULD, it'll be a SHOULD.
> 
> (2) A description of OP-MIME will be in Michael Elkin's RFC 2015.

In this case, RFC2015 need updating as it currently *requires* the use
of Armour.

> We'll leave it to implementors which they prefer to implement and
> encourage the use of MIME for messages.

Perfect!

Ian :D

Date: Wed, 26 Nov 1997 04:53:36 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Bill Stewart <[email-masked]>
CC: Adam Back <[email-masked]>, [email-masked]
Subject: Re: expediency and avoidance of politics
Sender: [email-masked]

Bill Stewart wrote:

> We should probably mark Subpacket Type 10 as "reserved" or something.

Spot on, Bill.  I was thinking along these lines today.

Avoidance of any name means that there is no possibility of endorsement
or future confusion along those lines.  Marking it as an RFU leaves PGP
Inc free to use it within their proprietary client sites, until they are
ready to propose this method as general and successful enough to be
admitted to the standard.

And as an experimental system, the right thing to do is to mark out the
space, and wait for PGP Inc to get back to us with a case.  As an
informational RFC or a proposed extension, this is fine.  It also does
more merit to the question, as it is far more complex than one bit or
field can cope with.

Seems like a win for everbody, no?  If we are agreed that type 10 is
marked as reserved for future use, then we can move ahead.

> Figuring out the semantics of the Critical Bit is going to be more complex.

I think I've made my case that this is a "bad thing" at this stage, I'll
see what others say.
-- 
iang                                      systemics.com

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

Date: Wed, 26 Nov 1997 12:27:25 +1100 (EST)
From: David Formosa <[email-masked]>
Reply-To: [email-masked]
To: Jim McCoy <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Armour
Sender: [email-masked]

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

On Mon, 24 Nov 1997, Jim McCoy wrote:

[...]

> David Formosa wrote:

> >The second group is all the scrips, hacks, glue and basic
> >applications of cyrto wich works with pgp[2|5].

[...]

> Why do these things need to use 7-bit armored output? [...] (although I
> would not doubt that lazy script writers keyed on things like ---BEGIN
> PGP...)  

Its more the hacks like that then 7-bit armored nature of the post itself.
Most of the applications work off the PGP delimitters.

- -- 
Please excuse my spelling as I suffer from agraphia see the url in my header. 
Never trust a country with more peaple then sheep.  ex-net.scum and proud
You Say To People "Throw Off Your Chains" And They Make New Chains For
Themselves? --Terry Pratchett.  I do not reply to munged addresses.

Date: Tue, 25 Nov 1997 18:41:40 -0800
To: Jon Callas <[email-masked]>
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: The armour issue
Cc: Gavan Schneider <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 06:01 PM 11/25/97 -0800, Jon Callas wrote:
>or transmitted in any environment that may not be safe to raw binary data.

so does MIME.

>For example, PGP key servers transmit keys both to and from the server in

so can MIME.

>Armor is also useful for future applications. 

so is MIME.

>Lastly, there are systems that use (or would like to use) PGP over systems
>that are not the internet. 

Then they are not relevant to an Internet standards process.

>Furthermore, I disagree with this strongly. MIME is a preferrered way (by

MIME is the standard way.  As I try to make clear, that's not just a matter
of bureaucratic formaltiy, it is a matter of actual use.  The purpose of a
standard is to achieve interoperability.  The more choices there are, the
less interoperability there is.

Absent a strong claim as to the technical superiority of armour or
something else, the only reason to support an alternative mechanism which
does the same job is... well, nothing constructive.

>text describing it was done by Paul Hoffman, who used MIME as a base. So
>it's quite easy to do both.

The question remains:  what functional basis is there for retaining
armouring in the standards-based specification.  The argument of
compatibility with the pre-standards installed base has already been
countered for a number of different issues, not just armouring.  The idea
of possible uses in the future is an argument for MIME, not a legacy
mechanism.

>The compromise that I, as editor am working with (with thanks to Ian Brown,
>who came up with it) is as follows:

Jon, those who serve as working group chairs and document editors have a
difficult job.  They are usually senior, talented folk.  They get to work
hard and almost never are adequately appreciated.

Worst of all, they are often architects who do not see their own
preferences chosen.

The editor of an IETF working group document is required to be responsive
to the rough consensus of the working group.  I hope no one has forgotten
this minor point.

>(1) I'm going to remove anything in OP-FORMAT that requires the use of
>ascii armor. Following my touchstone that any feature needed for backwards
>compatibility is a SHOULD, it'll be a SHOULD.

Now if you just move it to an appendix and note that it has been the basis
for "packaging" PGP in pre-standards versions of the technology, then we'd
be in perfect shape.  This would leave the document with one standard way
to do the packaging, but with full documentation about the prior
(non-standard) way of doing it.

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

Date: Wed, 26 Nov 1997 11:59:46 +1100 (EST)
From: David Formosa <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: Armour
Sender: [email-masked]

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

On Mon, 24 Nov 1997, Ian Grigg wrote:

> Dave Crocker / IMC wrote:

[...]

> > 2.  Installed base compatibility
> > 
> >     It has been observed a number of times that that is already lost for
> > other reasons, so use of MIME rather than Armour does not create a new
> > problem.

[...]

> 1.  Is this WG happy to take as a given, or a working assumption, or a
> fundamental position (pick your own term), that the compatibility with
> the installed base is lost?

I am not happy with this assumpion/position  installed base compasty is
only realy lost for a subset of users.  Thouse living outside the range of
the patents or willing to bye a licence can recover backwards capasity.
That being said the loss of armour would create a new problem for the
unemcombered population.

> 2.  If compatibility with the installed base (as inferred above) is
> *not* lost, does the proposal that MIME should "replace" Armour
> (ignoring how&what) still have any merit?

Advanigers for Mime

  Preexisting code liberys.
  Neetness of standerisation

Advanigers for Armour

  Interoperbility with existing versons of PGP
  Interoperbility with existing scrips.

- -- 
Please excuse my spelling as I suffer from agraphia see the url in my header. 
Never trust a country with more peaple then sheep.  ex-net.scum and proud
You Say To People "Throw Off Your Chains" And They Make New Chains For
Themselves? --Terry Pratchett.  I do not reply to munged addresses.

Date: Tue, 25 Nov 1997 18:01:05 -0800
To: Gavan Schneider <[email-masked]>, <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: The armour issue
Sender: [email-masked]

At 11:29 AM 11/26/97 +1100, Gavan Schneider wrote:

Thanks for writing this up. I'm addressing your message as a logical
argument. Please forgive the pickiness that follows.

   My premises:
   
   PGP ascii-armour is a 7-bit ascii form of the 8-bit encrypted content, 
   includes a fixed line-wrap, and uses base64 encoding.  This allows 
   transmission through 7-bit channels over the internet.

This is true, but incomplete. Ascii armor allows PGP binary data to be held
or transmitted in any environment that may not be safe to raw binary data.
For example, PGP key servers transmit keys both to and from the server in
ascii armoured blocks. There are other applications that use PGP technology
for authentication, enveloping, etc. and use armor.

Armor is also useful for future applications. I am presently working with
someone who is using the new extension mechanism to build an SPKI-like
authorization system for a network server. They want to use armored blocks.

Lastly, there are systems that use (or would like to use) PGP over systems
that are not the internet. I have given the example of pager systems
before. There are other systems that use telephones, private networks, or
other non-Internet means of data transfer.
   
   Therefore armour has little to do with files stored on disk, and a lot to 
   do with email transmission, which is where mime comes into play.

Well, this isn't a premise, this is a conclusion. Structurally, it's not
fair to start derivations in your statement of premises of an argument.
Even so, logically, I don't see what chain of reasoning leads one to
conclude this from the previous paragraph.

Furthermore, I disagree with this strongly. MIME is a preferrered way (by
many people) to encode email transmissions. Many people believe it is *the*
preferred way to transmit email. Other people believe that MIME is the best
solution long term, but not at the present date. Still other people don't
like MIME at all. I think we've heard on this list from representatives of
all of these classes of people. Armor has little to do with message
transmission, and everything to do with *OBJECT* (keys, authorizations,
etc.) transmission.

Lastly, for what it's worth, factually there are cases where armored PGP
objects are stored on a disk, in spite of its inefficencies. In any event,
this is an implementor's decision. To forbid armor is to say that there is
no conceivable use for it.
   
   There are already mime formats for asciified binary, eg., base64, which 
   mime compliant applications already need to implement.  So there is no 
   need for additional code if O/PGP uses existing mime/base64 as the format 
   to protect the encrypted binary data during transmission over 7-bit 
   channels.  This also means there is no particular need to keep the PGP 
   version of ascii-armour in the O/PGP standard.

I agree with the first part, but not the last. There is no need to keep
PGP's armor only if all applications that do not want to use raw binary
want to use MIME. If there is one application that falls in the middle,
then there is a need. We may choose to discount this need in the standard,
but the need still exists. Again, pickily, this mixes conclusions with the
premises.
   
   But there is a need to specify the encapsulation of O/PGP email parts as 
   they are interpreted by the mime parsing system.  I personally think the 
   standard should specify base64 and not leave it to printed quotable.  I 
   accept that since printed quotable is not actually wrong (just less 
   efficient) this issue would he handled by way of very strong advice in 
   the standard.
   
   Base64 increases a message size by 25%. (Each byte transmitted carries 
   6-bits of original information).

Actually, it increases the message size by 1/3. Three octets of data become
four octets of armor. There is thus a 1 octet overhead for each 3 octets of
actual data for an overhead of 33 1/3%.
   
   Printed quotable would more than double the message size since about half 
   the bytes of the encrypted text would have the high order bit true (ie., 
   char [128..255]) and need to be encoded with a 3 byte sequence, eg. 
   "=9A", the char "=" is coded as "=3D".  Not to mention the soft wrapping 
   "=\r" sequence every 80 characters.
       Ref: "Winning the MIME QP Doll" by Will Mayall <[email-masked]>
             NetBITS#005/23-Oct-97 <http://www.netbits.net/>
   
   Both formats (base64 and printed quotable) break the transmitted text 
   into lines of about 80 characters.  These are removed by the receiving 
   end during decoding/unpacking.  Depending on the system base64 adds 1 
   [Unix,MacOS] or 2 [DOS,WIN] characters per line, printed quotable adds an 
   extra one again.
   
   My conclusions:
   
   1. Printed quotable should be avoided for the encrypted message body 
   because of its much higher overhead.

No one has ever suggested such a thing, and I would be surprised if anyone
disagreed.
   
   2. Existing mime/base64 encapsulation can replace PGP ascii-armour in the 
   O/PGP standard for transmission of encrypted email over the internet.

I agree completely. For email etc. (Dave Crocker has written some nice
words on how in spite of its acronym, MIME isn't just for mail, so I say
email etc.) MIME is long-term the preferred way to go. Armor itself is
still a preferred way of transmitting OP objects that are not messages.
   
   3. The O/PGP standard will not incur higher implementation cost by using 
   mime/base64, rather it will be using existing code.
   
Actually, PGP's ascii armor uses the same mechanisms as MIME's base 64. The
text describing it was done by Paul Hoffman, who used MIME as a base. So
it's quite easy to do both.

The compromise that I, as editor am working with (with thanks to Ian Brown,
who came up with it) is as follows:

(1) I'm going to remove anything in OP-FORMAT that requires the use of
ascii armor. Following my touchstone that any feature needed for backwards
compatibility is a SHOULD, it'll be a SHOULD.

(2) A description of OP-MIME will be in Michael Elkin's RFC 2015.

(3) We'll leave it to implementors which they prefer to implement and
encourage the use of MIME for messages.

(4) I'm going to restructure the placement the armor discussion in
OP-FORMAT so that it doesn't just spew from section 2, which is supposed to
be an introductory section. It'll get its own chapter towards the back of
the document.

I'm going to digress here and note that in the WG's charter, we are to
strive for "limited backwards compatibility." These are weasel-words. Full
backwards compatibility is desirable, but not possible. When necessary, we
will break backwards compatibility, but we won't do it gratuitously. I
think that encouraging and supporting the use of MIME is a Good Thing, but
forbidding armor is draconian and an overreaction.

	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: Tue, 25 Nov 1997 17:03:08 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: V4 Fingerprints
Sender: [email-masked]

Thomas Roessler, <[email-masked]>, writes:
> >From the draft:
> 8.2 V4 Key IDs and Fingerprints
> [...]
>
> This seems to imply that the fingerprint is always
> generated as the hash over an old-style public key packet
> with a two-byte length qualifier and the appropriate
> packet tag.  Is this correct and intended?

Yes, this is correct, for the new 20-byte fingerprints.

Hal

Subject: Re: The armour issue
Date: Wed, 26 Nov 97 11:29:38 +1100
From: Gavan Schneider <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Quoting A. Padgett Peterson P.E. Information Security 
<[email-masked]> on or about 1997/11/26 05:25 Sydney time-

>
>>Compatibility with Classic PGP has become optional. All OP implementations
>>will be compatible with each other. I suspect most will also be compatible
>>with the Classic PGP, but that's up to implementers and users. 
>
>Agree in principle. Armour/Mime/etc is really a mail issue with one 
>exception:
>I would really be bothered if installation of PGPv14 made it impossible to 
>decrypt the thousands of instances of malicious software I keep in the 
>original PGP message format (easy to tell who it came from). Would also 
>like to read the ones received in the future as well.
>
...snip...
>
>So would like to see something such as it MUST be an OPTION to any product
>claiming PGP compatibility (is there such a thing as a mandatory option ?). 
>Personally, would not mind paying extra for the capability but would want to 
>be sure that it was available (I know - keep the old version around. Ever 
>read an upgrade license ?).
>
At the risk of sounding pedantic and apologies if this is really an 
example of very dry humour (if intended it is very good :-)  A 'mandatory 
option' sets the scene where a product can only be compliant if there is 
an option to support some list of old (proprietary) implementations.  And 
products which do support these implementations must allow this function 
to be disabled.  In order to bring the implementations into the standard 
(ie., they cannot remain proprietary) each version of PGP Inc. product 
(and Phil Z.'s shareware versions) would have to have an exact definition 
of its behaviour spelled out into the O/PGP standard along with the 
proposed behaviour we are now discussing.

One result of the O/PGP standard will (I hope) be more than one O/PGP 
standard compliant product.  One of those versions will no doubt come 
from PGP Inc.  And PGP Inc. can (and should) use backwards compatibility 
as one of many product differentiations in the market place.  Others may 
also want to add this feature.  This is a commercial and licensing issue. 
 The O/PGP standard does not need to mandate backwards compatibility (it 
can but does not have to).  IMHO this functionality should be left to 
actual products.

Which leads me back to the issue of this thread viz., ascii-armour.

I have watched this issue over a couple of threads, joined some ideas, 
added my thoughts, had some help Dave Crocker <[email-masked]>, and 
present the following (hopefully useful) summary.  (Many thanks to Dave 
but the opinions and mistakes are mine :-)

My premises:

PGP ascii-armour is a 7-bit ascii form of the 8-bit encrypted content, 
includes a fixed line-wrap, and uses base64 encoding.  This allows 
transmission through 7-bit channels over the internet.

Therefore armour has little to do with files stored on disk, and a lot to 
do with email transmission, which is where mime comes into play.

There are already mime formats for asciified binary, eg., base64, which 
mime compliant applications already need to implement.  So there is no 
need for additional code if O/PGP uses existing mime/base64 as the format 
to protect the encrypted binary data during transmission over 7-bit 
channels.  This also means there is no particular need to keep the PGP 
version of ascii-armour in the O/PGP standard.

But there is a need to specify the encapsulation of O/PGP email parts as 
they are interpreted by the mime parsing system.  I personally think the 
standard should specify base64 and not leave it to printed quotable.  I 
accept that since printed quotable is not actually wrong (just less 
efficient) this issue would he handled by way of very strong advice in 
the standard.

Base64 increases a message size by 25%. (Each byte transmitted carries 
6-bits of original information).

Printed quotable would more than double the message size since about half 
the bytes of the encrypted text would have the high order bit true (ie., 
char [128..255]) and need to be encoded with a 3 byte sequence, eg. 
"=9A", the char "=" is coded as "=3D".  Not to mention the soft wrapping 
"=\r" sequence every 80 characters.
    Ref: "Winning the MIME QP Doll" by Will Mayall <[email-masked]>
          NetBITS#005/23-Oct-97 <http://www.netbits.net/>

Both formats (base64 and printed quotable) break the transmitted text 
into lines of about 80 characters.  These are removed by the receiving 
end during decoding/unpacking.  Depending on the system base64 adds 1 
[Unix,MacOS] or 2 [DOS,WIN] characters per line, printed quotable adds an 
extra one again.

My conclusions:

1. Printed quotable should be avoided for the encrypted message body 
because of its much higher overhead.

2. Existing mime/base64 encapsulation can replace PGP ascii-armour in the 
O/PGP standard for transmission of encrypted email over the internet.

3. The O/PGP standard will not incur higher implementation cost by using 
mime/base64, rather it will be using existing code.

Regards,
Gavan

Gavan Schneider           | In a world without fences,
<[email-masked]>      | who needs Gates?

Date: Tue, 25 Nov 1997 14:10:36 -0800
To: Adam Back <[email-masked]>, [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: expediency and avoidance of politics
Sender: [email-masked]

At 12:13 AM 11/25/1997 GMT, Adam Back wrote:
>It seems to me that the debate over CMR and it's more secure
>alternatives could easily be deferred to OpenPGPv2 with no
>compatibility issues.
>
>The way that CMR/ARR field is encoded in the draft is that it is a
>signature subpacket type.  Signature subpacket types are extensible;
>that is an implementation already has a defined method to safely
>ignore subpackets it does not understand.  This means that no one will
>experience compatibility problems if the experimental CMR subpacket is
>only implemented by PGP Inc.

I agree.  

We should probably mark Subpacket Type 10 as "reserved" or something.

Figuring out the semantics of the Critical Bit is going to be more complex.

>- it would allow more time for PGP Inc to get feed-back on this
>  controversial experimental feature from their customers as to how
>  CMR performs functionally in practice (I am expecting there will
>  be complaints about the lack of ergonomic recovery from forgotten
>  passphrases -- all files have to be re-encrypted), how the security
>  of the system holds up (how well companies are managing very
>  sensitive CMR master keys), and to gauge customers acceptance of the
>  feature politically.

>- it will give time for more secure competing proposals (such as local
>  escrow) to be developed for recovery from forgotten passphrases.

Yeah, Stealth is going to take some discussion, and OPv2 is probably
a good venue for it.

				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Tue, 25 Nov 1997 21:48:46 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Adam Back <[email-masked]>
CC: [email-masked]
Subject: Re: expediency and avoidance of politics
Sender: [email-masked]

Adam Back wrote:
> 
> It seems to me that the debate over CMR and it's more secure
> alternatives could easily be deferred to OpenPGPv2 with no
> compatibility issues.
...
> Avoiding, or deferring the political debate seems like it would be a
> good idea for a number of reasons:
> 
> - it would allow us to focus on getting OpenPGPv1 out in a timely
>   manner.

Agreed.  The existance of the CMR/AAR field could erupt again I guess.

> - it would allow more time for PGP Inc to get feed-back on this
>   controversial experimental feature from their customers as to how
>   CMR performs functionally in practice (I am expecting there will
>   be complaints about the lack of ergonomic recovery from forgotten
>   passphrases -- all files have to be re-encrypted), how the security
>   of the system holds up (how well companies are managing very
>   sensitive CMR master keys), and to gauge customers acceptance of the
>   feature politically.

I'd also add that it would allow more time to actually develop internal
experience with this method.  The design as I understand it has existed
on paper for some time, and within the code since pgp5.0, but has not
really been deployed until recently at test sites.

Such a change of infrastructural import needs to be put in the field for
some time before we could really state that it is working how we
intended.  As there's no evidence that any experience  has been gained,
it remains in the "interesting proposal" basket, contents of which
aren't really ready for prime time WG consideration.

> - it will give time for more secure competing proposals (such as local
>   escrow) to be developed for recovery from forgotten passphrases.

Yeah, well, enhancement of competition, the level playing field, all
that interventionist stuff, is not really in the mission statement for
the IETF.  Not that I don't sympathise with your paper that is :-)

> The consolidation phase would then be in OpenPGPv2 where the better
> solution would be chosen in OpenPGPv2 for standardisation.

You could say that the choice phase is conducted in the market place,
and the acceptance phase is the job of V2.  But, in an absence of
competition, no choice is possible.  So no decision at this time.

(my incoming mail's been broken for a day or two, so this might be out
of time.)
-- 
iang                                      systemics.com

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

Date: 25 Nov 1997 21:08:15 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: 103-microsecond 2048-bit verification on a Pentium-133
Sender: [email-masked]

I have a variant of the Rabin-Williams signature system that speeds up
verification by an order of magnitude with no effect on security. This
might be useful for web pages or USENET postings.

See http://pobox.com/~djb/papers/sigs.ps.

> People have been scared of Rabin encryption because it has a chosen
> ciphertext attack which reveals the key. 

Rabin's signature system, as published in 1979, uses a one-way hash
function and is invulnerable to chosen-message attacks.

(The original RSA signature system was vulnerable, as were various
oversimplified versions of Rabin's system.)

The only reason to use RSA signatures instead of Rabin signatures is to
line RSADSI's pockets.

---Dan

Date: Tue, 25 Nov 1997 18:49:10 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: V4 Fingerprints
Sender: [email-masked]

>From the draft:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

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.1) 0x99 (1 byte)
    a.2) high order length byte of (b)-(f) (1 byte)
    a.3) low order length byte of (b)-(f) (1 byte)
    b) version number = 4 (1 byte);
    c) time stamp of key creation (4 bytes);
    e) algorithm (1 byte):
         17 = DSA;
    f) Algorithm specific fields.

    Algorithm Specific Fields for DSA keys (example):
    f.1) MPI of DSA prime p;
    f.2) MPI of DSA group order q (q is a prime divisor of p-1);
    f.3) MPI of DSA group generator g;
    f.4) MPI of DSA public key value y (= g**x where x is secret).

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

This seems to imply that the fingerprint is always
generated as the hash over an old-style public key packet
with a two-byte length qualifier and the appropriate
packet tag.  Is this correct and intended?

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

Date: Tue, 25 Nov 1997 13:54:05 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: Re: PGP evolving, improving
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Note: this is really politics and not RFC business - my apologies but something
      of a sore point.

David rote:

>And free PGP users didn't deserve an eased upgrade path, but rather to forcibly
>obsolete all their keys, signatures and web of trust in the new version?
>Especially since the RSA-key Free PGP user base is where PGP Inc. made their
>reputation and the size of that base is constantly cited to the IETF and in
>press releases as PGP's "customer base". Don't be ridiculous. And watch who you
>throw stones at--can you say "glass house"?

Am surprised at this posting as it seems to forget one major problem: RSA is
patented. I have been told repeatedly by PGP that one of the reasons they do 
not offer a site license (nor a real personal license for that matter in the 
sense of being authorized to operate on all solely-used computers) is a
requirement by RSA for a "per CPU" fee.

True, the "free" version may be exempt under the terms of the patent but
this has never been exactly clear. Do suspect that when PGP and Viacrypt
did their inverse triangular multibuyout which resulted in a common point
for both free and commercial versions that some of the clauses of the RSA
license began covering PGP Inc and thus the "free" version as well (do you 
realize that there are fifty thousand lawyers in Florida alone ?  Twice as 
many Southern Bell yellow pages of attorneys as doctors and churches 
combined ?)

Would be nice if RSA put the mechanism into the public domain but since they
reniged on the S/MIME components, I have doubts that this will happen. 

Sounds like an opportunity for some programmer to create a "front end" to
determine which is being used and to invoke the correct version but this is
the reason that RSA (or any proprietary mechanism) should *never* be a MUST.

						Warmly,
							Padgett

From: Uri Blumenthal <[email-masked]>
Subject: Re: PGP evolving, improving
To: [email-masked] (Adam Back)
Date: Tue, 25 Nov 1997 13:29:02 -0500 (EST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Adam Back says:
> > Also, since this is an IETF forum, let me remind you,  that the
> > official IETF security guideline is: "For all the new standards
> > MD5 shall not be used - but SHA-1".
> 
> MD5 is in the draft as a MAY.  You want to change that to a MUST NOT?

Oh, certainly not. I was simply pointing out that "MUST" for the
new drafts should exclude MD5. "MAY" - is a different story, and
I personally see no reason  why backward compatibility cannot be
offered as an option. With the understanding that an implementor
does not HAVE to be backward compatible - it's just nice of him,
if he is.

> I don't think the situation with MD5 is serious enough currently to
> warrant the loss of backwards compatibility as an implementation
> option.

IESG does not require this either, to the best of my knowledge.
Actually, even SHA-1 MUST and MD5 SHOULD would wash well, I think.

> Where we came in to this discussion was that by having backwards
> compatibility more people migrate to new algorithms more quickly.

Granted - except I think we differ on where the crucial backwards
compatibility is. For me [apologies for repeating myself :-] the
"schwerpunkt" is the external interface - the ability or inability
to use the existing software by just editing config files and
dropping a new PGP executable in.

> > ...............but I absolutely hate
> > the fact that I can no longer use Mailcrypt-3.4 from XEmacs.
> 
> Well I use mailcrypt also, so I can share on that one.  However I keep
> getting emails from people with pgp5.x which are addressed to my RSA
> key, and yet which pgp2.x simply can't read.  I think this must either
> be the bug Hal described, or people are signing the message with a DSS
> key which I thought pgp5.x was supposed to warn against when the
> recipient is using an RSA key.

Don't know... Maybe Hal could comment?

> > Yes and no. Of course transparency will help. HOWEVER, many of PGP
> > users have either no time, or no skills (or "no" both) to modify
> > the software that interfaces between their favorite whatever
> > and PGP. For me it is Mailcrypt/XEmacs. Until *that* part
> > is taken care of - don't expect people to switch.
> 
> I think mailcrypt users are small in number.  We should ask Pat
> LoPresti if he wants to hack in pgp5.x support.

(:-) Well, I tend to doubt that all the other e-mailers have no
problem with the new PGP interface, and only big bad Mailcrypt
does... But if you can ask Pat - by all means, please do so.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Tue, 25 Nov 1997 13:25:36 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: The armour issue
To: [email-masked]
Sender: [email-masked]

>Compatibility with Classic PGP has become optional. All OP implementations
>will be compatible with each other. I suspect most will also be compatible
>with the Classic PGP, but that's up to implementers and users. 

Agree in principle. Armour/Mime/etc is really a mail issue with one exception:
I would really be bothered if installation of PGPv14 made it impossible to 
decrypt the thousands of instances of malicious software I keep in the original
PGP message format (easy to tell who it came from). Would also like to read 
the ones received in the future as well.

Would imagine that many of the people who have supported Viacrypt/PGP Inc
through the years have similar concerns.

OTOH the thought of FIPS compliant PGP flowing on the DMS with DH/TripleDES
also has a certain appeal to the absurd 8*).

So would like to see something such as it MUST be an OPTION to any product
claiming PGP compatability (is there such a thing as a mandatory option ?). 
Personally, would not mind paying extra for the capability but would want to 
be sure that it was available (I know - keep the old version around. Ever read
an upgrade license ?).

					Warmly,
						Padgett

Date: Tue, 25 Nov 1997 10:23:19 +0000
From: Ian Brown <[email-masked]>
To: Black Unicorn <[email-masked]>
CC: [email-masked]
Subject: Re: PGP, evolving.
Sender: [email-masked]

> Has anyone bothered with a netscape plug-in?

See http://www.cs.ucl.ac.uk/staff/I.Brown/enigma/ - a plugin that will
work with any POP/SMTP mailer such as Netscape. Doesn't do PGP 5 formats
yet, though - am working on that now.

Ian.

Date: Tue, 25 Nov 1997 04:12:10 -0600
To: [email-masked]
From: Black Unicorn <[email-masked]>
Subject: PGP, evolving.
Sender: [email-masked]

At 01:15 AM 11/25/97 -0800, you wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Adam Back writes:
> > 
> > > Yes and no. Of course transparency will help. HOWEVER, many of PGP
> > > users have either no time, or no skills (or "no" both) to modify
> > > the software that interfaces between their favorite whatever
> > > and PGP. For me it is Mailcrypt/XEmacs. Until *that* part
> > > is taken care of - don't expect people to switch.
> > 
> > I think mailcrypt users are small in number.  We should ask Pat
> > LoPresti if he wants to hack in pgp5.x support.

Has anyone bothered with a netscape plug-in?

Eudora is nice, get that and netscape and OE and you'd be close to quitting
(since I gather there is already a pine integration).

Date: Tue, 25 Nov 1997 01:15:03 -0800
To: Adam Back <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: PGP evolving, improving
From: Jeremey Barrett <[email-masked]>
Organization: BlueMoney Software Corp.
Sender: [email-masked]

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

Adam Back writes:
 > 
 > > Yes and no. Of course transparency will help. HOWEVER, many of PGP
 > > users have either no time, or no skills (or "no" both) to modify
 > > the software that interfaces between their favorite whatever
 > > and PGP. For me it is Mailcrypt/XEmacs. Until *that* part
 > > is taken care of - don't expect people to switch.
 > 
 > I think mailcrypt users are small in number.  We should ask Pat
 > LoPresti if he wants to hack in pgp5.x support.
 > 

This is a project on my list. I use XEmacs and mailcrypt exclusively,
and want DSS/EG support fairly badly. If someone else gets to it
first, more power to them.

I plan to get to it sometime over the next month.

Regards,
Jeremey.
- -- 
Jeremey Barrett                                BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems               http://www.bluemoney.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64

Date: Tue, 25 Nov 1997 02:33:45 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: PGP evolving, improving
Sender: [email-masked]

Uri Blumenthal <[email-masked]> writes:
> > > b. There have been no practical cases of signature spoofing with MD5--it
> > > hasn't been broken.
> > 
> > I agree, in the general case it has not.  I'll discuss a better
> > user migration path below.
> 
> Excuse me, gentlemen, were there any practical cases of signature
> spoofing with MD4?
> 
> Also, since this is an IETF forum, let me remind you,  that the
> official IETF security guideline is: "For all the new standards
> MD5 shall not be used - but SHA-1".

MD5 is in the draft as a MAY.  You want to change that to a MUST NOT?

I don't think the situation with MD5 is serious enough currently to
warrant the loss of backwards compatibility as an implementation
option.

> However, as an algorithm starts showing cracks, a cryptographer with
> brains replaces it before the "practical" cases start piling up.

Of course, that much is a given.

Where we came in to this discussion was that by having backwards
compatibility more people migrate to new algorithms more quickly.

> Well, the only compatibility concerns that *I* have as a user are
> related to the broken *interface*. I.e. I APPLAUD the move to DSS
> and EG (would like to see ECC too, BTW) - but I absolutely hate
> the fact that I can no longer use Mailcrypt-3.4 from XEmacs.

Well I use mailcrypt also, so I can share on that one.  However I keep
getting emails from people with pgp5.x which are addressed to my RSA
key, and yet which pgp2.x simply can't read.  I think this must either
be the bug Hal described, or people are signing the message with a DSS
key which I thought pgp5.x was supposed to warn against when the
recipient is using an RSA key.

> > Now the discussion of a better migration path.  It seems to me that a
> > nice thing to do would be to generate two keys at key gen time: an RSA
> > key and an DSS/EG pair.
> 
> What if I *don't* want to generate RSA keys. Why cramming those down my 
> throat? Make it possible to geterate DSS *or* DSS+RSA, if you REALLY
> insist...

Default operation.  Same as you get a default operation with pgp5.x of
using cooked primes.

> > Largely transparent interoperability on all versions
> > would I suspect paradoxically have meant many more people made the
> > switch.
> 
> Yes and no. Of course transparency will help. HOWEVER, many of PGP
> users have either no time, or no skills (or "no" both) to modify
> the software that interfaces between their favorite whatever
> and PGP. For me it is Mailcrypt/XEmacs. Until *that* part
> is taken care of - don't expect people to switch.

I think mailcrypt users are small in number.  We should ask Pat
LoPresti if he wants to hack in pgp5.x support.

Adam

Date: Tue, 25 Nov 1997 07:34:55 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Hal Finney <[email-masked]>
CC: [email-masked]
Subject: Re: Complexity not a dominant strategy for independant deployment
Sender: [email-masked]

Hal Finney wrote:

> It sounds like the lack of documentation was a significant factor in
> making the implementation difficult.  Hopefully with the new draft this
> will change.

It will certainly help.  However I would stress that a simple, clear
protocol and formats architecture will make nice documentation easy. 
The alternate, good  documentation on top of a complicated protocol,
remains second best.

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

Oh, and when you say "where people are afraid," you are of course
referring to project leaders who are afraid of programmers who are not
afraid?  This is the fear that I most often experience :-)

-- 
iang                                      systemics.com

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

Date: Mon, 24 Nov 1997 22:31:48 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re:  MUST accept 32 bit lols everywhere?
Sender: [email-masked]

Keep in mind that part of the reason for going to the new length headers
is that we were running out of tag values.  The old PGP "CTB" had only
16 possible tags.  Getting rid of the "length of length" field added two
more bits allowing 64 possible packet types.  So whatever new proposals
are considered for OP V2, we should not retain the original "lol" field.

Hal

Date: Mon, 24 Nov 1997 22:29:23 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Complexity not a dominant strategy for independant deployment
Sender: [email-masked]

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:

: The data is encrypted in CFB mode, with a CFB shift size equal to the
: cipher's block size [Ref].  The Initial Vector (IV) is specified as all
: zeros.  Instead of using an IV, OP prepends a 10 octet string to the
: data before it is encrypted.  The first eight octets are random, and
: the 9th and 10th octets are copies of the 7th and 8th octets,
: respectivelly. After encrypting the first 10 octets, the CFB state is
: resynchronized if the cipher block size is 8 octets or less.  The last
: 8 octets of ciphertext are passed through the cipher and the block
: boundary is reset.

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.)

> I am *not* suggesting that we should make the existing CFB_PGP anything
> less than a MUST to read.  The current generation can suffer.  We did.
>
> But it would be nice to have straight CFB that could be coded up from
> Schneier without resorting to black magic.  That way a non-conforming
> implementation would be  quicker to get going, and if it is successful,
> we could start to deprecate the CFB_PGP in the V2 that people are
> looking to.  Slowly slowly, none of this unseemly rush that leaves
> customers suddenly with a split email community.

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.

In other words, you encrypt the first 64 bits (8 bytes) and shift the
shift register by 64 bits, bringing in new data; then you encrypt the
next 16 bits (2 bytes) and shift the shift register by 16 bits, bringing
in new data; and then you go back to encrypting 64 bits at a time and
shifting in 64 bits of new data each time.

Someone familiar with the meaning of CFB-n might find this description
to be clearer.  Any preferences?

Hal

Date: Mon, 24 Nov 1997 22:08:00 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: The web of trust has no clothes.
Sender: [email-masked]

PGP 5.X implements an extension to the trust model to address the issue
raised by David Sternlight.

> Another flaw in the web of trust and PGP is now revealed and comes home
> to roost.  Now that PGP Inc. has deep-sixed RSA in new free versions,
> not only does everyone with an old RSA key have to generate a new key
> but also a complete new set of signatures and web of trust must be built
> if they wish to use the "better" algorithms. And the new keys must be
> distributed to correspondents, either directly or by "pull" from
> servers. This took years the first time--perhaps the second time it will
> be a bit faster.

The way it works is as follows.  If you have two keys with identical
userids, and the first key signs the second userid, then validity from
the signatures on the first user ID gets propagated to the second userid.
The effect is that if you generate a new DSA key with the same name
as your old RSA key, and sign it with your old key, then your new key
inherits the validity from the old key.  (This propagation happens
irrespective of whether the old key is marked as a trusted introducer.)

In effect, the signatures on your old key automatically get applied to
your new key.  This is an easy way to inherit the signatures from the old
web of trust.  The new keys do not have to start from scratch, as implied
above.

There may be some concern that this would introduce certain kinds of
spoofing attacks.  Let us assume that the old signatures are valid,
that the old key is in fact properly bound to the userid.  (If the old
signatures are invalid, no one should trust them anyway, so they have no
impact on the web of trust.)  Now, when that old key issues a signature
on the same userid on another key, it is in effect asserting that the
same keyholder controls this other key.

If the other key actually does belong to the same keyholder, then there
is no danger in transferring validity from the signatures on the old
key over to the new one.  The new key is in fact valid, and so measures
which show it as valid are proper.

The questionable aspect arises if the new key does not actually belong
to the keyholder.  For example, someone might create a key and put Phil
Zimmermann's name and email address on it.  If Phil signed that name, he
would be falsely claiming that this other key belonged to him.  With the
5.X extension to the trust model, other signatures on Phil's true key
would be treated as though they apply to this new key.  Someone trying
to encrypt a message to Phil might find their software encrypting it to
this new key instead of Phil's real key.  This might appear to be a
security weakness.

Note, though, that this can only occur with Phil's active cooperation.
He has knowingly signed a userid which matches his own but is bound to
someone else's key.  Only in this circumstance can it occur that other
people will encrypt to this key when they mean to encrypt to Phil.
However, since this was done with Phil's active cooperation, he is
intentionally sharing the contents of messages with the other keyholder.
But if this is his intention, he can do that even with the old trust
model.  He has the power to share the contents of his encrypted messages
with anyone he wants.

It was our conclusion that this feature does not add any new weaknesses
to the PGP trust model, and it greatly improves its robustness and
usability as new keys are introduced.  In fact, the basic idea can
probably be improved to make it easier to retire and replace old keys
in a more general way, while retaining the validity of old signatures.
This would be a good topic for OP V2.

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

Date: Mon, 24 Nov 1997 22:13:52 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Complexity not a dominant strategy for independant deployment
Sender: [email-masked]

Ian Grigg, <[email-masked]>, writes:
> Well, I have to disagree on that.  The difficulty is high.  I recall the
> swearing going on when each one of the infamous bit twiddles was finally
> debugged out of the Cryptix code - not pleasant to be on the same
> mailgroup as that discussing yet another PGP furfy.
> [...]
> Up until now, it has been the fact that the only documentation was the
> code.  PGP code is not the worst I've come across, but it's not the
> best.  Having the code-as-dox is a reasonable strategy when it is well
> written, but elsewise, you're adding a cost.  Having a complicated
> standard will result in a three-way reliance of programmers on the
> standard, the code and the conformance tests.

It sounds like the lack of documentation was a significant factor in
making the implementation difficult.  Hopefully with the new draft this
will change.

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.

Hal

Date: Mon, 24 Nov 1997 19:54:49 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: Ian Grigg <[email-masked]>
CC: [email-masked]
Subject: Re: The web of trust has no clothes.
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msCDDA59CF3501ED496475ADA3
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

Ian Grigg wrote:

> David Sternlight wrote:
> >
> > Another flaw in the web of trust and PGP is now revealed and comes home
> > to roost.  Now that PGP Inc. has deep-sixed RSA in new free versions,
> > not only does everyone with an old RSA key have to generate a new key
> > but also a complete new set of signatures and web of trust must be built
> > if they wish to use the "better" algorithms. And the new keys must be
> > distributed to correspondents, either directly or by "pull" from
> > servers. This took years the first time--perhaps the second time it will
> > be a bit faster.
>
> Slow down David.  You are right that there are now two WoTs and they
> don't look like getting back together, assuming good takeup on the
> freeware pgp5.5.
>
> However, the new Open PGP format does have the ability to separate out
> your signing key from your usage keys.  I think there is an ability to
> sign keys of different algorithms, as in SSL V3.  Is that the case?

Dunno. My purpose in posting this to the Open PGP list was to point out that
Open PGP needs a mechanism, if it hasn't already been created, that will
avoid invalidating or slicing off an entire web of trust structure if a
crucial algorithm changes. There's nothing like a worked example to clear
minds.

David

>
>
> > In contrast, with S/MIME-Verisign-Netscape/Microsoft if they were to
> > change the algorithm you just generate a new key and get one certificate
> > and you're done. And as you e-mail your correspondents using your new
> > certificate, they get a copy of your new key automatically.
> >
> > And some say PGP's trust model is "better". Can you say "needs work",
> > boys and girls?
>
> The work *is* being done.  I agree that the PGP Inc schedule leaves the
> customer cold or dead, and this WG perplexed, but the direction is
> reasonable.
>
> --
> iang                                      systemics.com
>
> FP: 1189 4417 F202 5DBD  5DF3 4FCD 3685 FDDE on pgp.com

--------------msCDDA59CF3501ED496475ADA3
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msCDDA59CF3501ED496475ADA3--

Date: Tue, 25 Nov 1997 03:15:52 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
CC: [email-masked]
Subject: Re: The web of trust has no clothes.
Sender: [email-masked]

David Sternlight wrote:
> 
> Another flaw in the web of trust and PGP is now revealed and comes home
> to roost.  Now that PGP Inc. has deep-sixed RSA in new free versions,
> not only does everyone with an old RSA key have to generate a new key
> but also a complete new set of signatures and web of trust must be built
> if they wish to use the "better" algorithms. And the new keys must be
> distributed to correspondents, either directly or by "pull" from
> servers. This took years the first time--perhaps the second time it will
> be a bit faster.

Slow down David.  You are right that there are now two WoTs and they
don't look like getting back together, assuming good takeup on the
freeware pgp5.5.

However, the new Open PGP format does have the ability to separate out
your signing key from your usage keys.  I think there is an ability to
sign keys of different algorithms, as in SSL V3.  Is that the case?

> In contrast, with S/MIME-Verisign-Netscape/Microsoft if they were to
> change the algorithm you just generate a new key and get one certificate
> and you're done. And as you e-mail your correspondents using your new
> certificate, they get a copy of your new key automatically.
> 
> And some say PGP's trust model is "better". Can you say "needs work",
> boys and girls?

The work *is* being done.  I agree that the PGP Inc schedule leaves the
customer cold or dead, and this WG perplexed, but the direction is
reasonable.

-- 
iang                                      systemics.com

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

Date: Tue, 25 Nov 1997 03:03:02 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Adam Back <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Complexity not a dominant strategy for independant deployment
Sender: [email-masked]

Adam Back wrote:

> I found the non-standard CFB mode consumed more time than the LOL
> twiddling (spent a bit of time with two gdb's up to get that one
> working).  Not tackled the rest of the bit twiddling to date, nor the
> WoT and revocation semantics.  (I only coded the PRZ style CFB and LOL
> bit twiddling as an extra confidence test that my app was doing
> something sensible with it's vanilla IDEA and 32 bit ints).

You raise an interesting point.  No, more than interesting, this brings
up dark memories.  Ian will confirm that there was nothing that caused
more strife in the entire Cryptix development effort over the last 2.5
years than the CFB_PGP (as it is called at the minute within
Cryptix-Java).  Five people have had a go at coding it up in an
architecturally good way such that users can see what's happening.  I
think the sixth is just about to have another go <evil chuckle>.

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.

I am *not* suggesting that we should make the existing CFB_PGP anything
less than a MUST to read.  The current generation can suffer.  We did.

But it would be nice to have straight CFB that could be coded up from
Schneier without resorting to black magic.  That way a non-conforming
implementation would be  quicker to get going, and if it is successful,
we could start to deprecate the CFB_PGP in the V2 that people are
looking to.  Slowly slowly, none of this unseemly rush that leaves
customers suddenly with a split email community.

I defer to the bit-twiddlers amongst us as to the appropriate way to do
this.

-- 
iang                                      systemics.com

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

Date: Mon, 24 Nov 1997 21:45:49 -0500 (EST)
From: Tony Mione <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
cc: Tony Mione <[email-masked]>
Subject: PGP Implementor's survey
Sender: [email-masked]

PGP Implementor's survey

	The IETF OpenPGP Working Group is currently formalizing message
certificate formats used by PGP. As part of this effort, we are trying to
find out what implementations exist of various pgp-based products and
tools.

	This survey is designed to gather that information. We ask that you
take time to fill out and return this survey if you fall into one of the
following catagories:

	- You have written a pgp-based tool or an implementation of pgp
	- You are in the process of writing one of the above
	- You are planning to write one of the above

	If you are only in the planning stages (or very early in the
development stage), answer the questions as though in the future tense
"What platforms do you plan to support?", "Will it be compatible with
2.6.x?", etc.

	Please answer the following questions as completely as possible.
When completed, email back to [email-masked] or print the form,
fill it out and FAX it to Antonino Mione at +1 (732)-445-2968.

	Thanks for your help.

						Antonino N. Mione

						[email-masked]

----- BEGIN PGP SURVEY FORM -----

			PGP Implementation Survey

Identification of the Package and Legal Issues
----------------------------------------------

 1) Name of Package: ______________________________________________________

 2) Contact Name:__________________________________________________________

            Phone #:_______________________________________________________

	    Email Address:_________________________________________________

 3) Is the software a commercial product, shareware, freeware, other?

        ___________________________________________________________________

 4) How can one obtain it (URL, anonymous ftp, prepaid ftp retrieval, etc)?

        ___________________________________________________________________

        ___________________________________________________________________

        ___________________________________________________________________

General Characteristics of the Package
--------------------------------------

5) On which platform(s) does it run?
	__ Windows 3.1.x
	__ Windows 95
	__ Windows NT
	__ MS-DOS
	__ Mac/OS (7.5, 8.0, etc)
	__ Unix (list flavors) : __________________________________________

			___________________________________________________
	__ Amiga
	__ MVS
	__ OpenVMS
	__ Handheld/embeded devices : _____________________________________
	__ Other(s) : _____________________________________________________

 6) Is source distributed or available? ___________________________________

 7) What type of product is this (check all that apply)?

	__ Full PGP application?
	__ Email plug-in (i.e. Eudora)?
	__ Browser plug-in (i.e. Netscape)?
	__ Programming API
		__ C, C++
		__ Perl
		__ Other

 8) Does it support PGP 2.6.x compatibility? ______________________________

	Exceptions? : _____________________________________________________

 9) Does it support PGP 5.x compatibility? ________________________________

	Exceptions? : _____________________________________________________

10) With what other PGP-Based implementations or products (that you know of)
	does it interoperate? 

        ___________________________________________________________________

        ___________________________________________________________________

        ___________________________________________________________________

Technical Characteristics of the Package
----------------------------------------

11) Which Symmetric Encryption algorithms does it support?
	__ DES
	__ 3-DES
	__ CAST
	__ IDEA
	__ Blowfish
	__ SAFER
	__ Others : _______________________________________________________

12) Which Public Key Encryption algorithms does it support?
	__ RSA
	__ ElGammal
	__ D/H
	__ Elliptic Curve
	__ Others : _______________________________________________________

13) Which Message Digest algorithms does it support?
	__ MD4
	__ MD5
	__ SHA-1
	__ Tiger
	__ RIPEMD-160
	__ Others : ______________________________________________________

14) Which Signature algorithms does it support?
	__ RSA
	__ DSS
	__ Others : ______________________________________________________

15) Which email armoring algorithms does it support?
	__ RADIX-64 ASCII Armor
	__ Mime
	__ UUENCODE/UUDECODE
	__ Others : _______________________________________________________

16) Besides standard PGP message formats, does it support any additional
	certificate formats? If so, which ones?
	__ X.509
	__ PKIX
	__ Others :  ______________________________________________________

Thanks again!

----- END PGP SURVEY FORM -----

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

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re:  MUST accept 32 bit lols everywhere?
Cc: [email-masked]
Reply-To: [email-masked]
Date: Tue, 25 Nov 1997 15:35:54 (NZDT)
Sender: [email-masked]

>So pgp2.x has lol field values 0, 1, 2 to mean 1 byte, 2 bytes and 4
>bytes.  All that needs to be done is to depracate lol field values 0
>and 1.  Ian Grigg said he tried this with his systemics pgp2.x
>implementation cryptix2.x but found cases where the pgp2.x code base
>could not handle 4 byte lengths!
 
I think there are portions of 2.x code which assume the CTB will be in a 
certain form, eg that the lol will indicate an 8-bit length so it's possible 
to process the CTB in a single byte comparison rather than having to pick 
apart the lol.
 
Peter.

Date: Mon, 24 Nov 1997 18:13:32 -0800
To: [email-masked]
From: Will Price <[email-masked]>
Subject: Sternlight Drivel
Sender: [email-masked]

In the past few days, an individual named David Sternlight has begun
posting abusive progaganda-style messages to this and other lists.  He
usually sticks to the newsgroups, but since he he has appeared here, I
think it is important for any who have not previously heard of him to know
just what kind of person this guy is with a multiyear history of posting
nonsensical drivel about PGP and many other products to suit his own
suspect motives.  Here are 2 whole websites dedicated to exposing this guy
for what he is:

http://www.synernet.com/estone/   (Click the "Sternlight" button)
http://www.austinlinks.com/Crypto/sternlight.html

I assume there is no procedure on an IETF list to ban a particular poster.
If there isn't, his presence will undoubtedly be a great hindrance to
intelligent and calm discussion.  My philosophy along with many others with
his posts has been to simply not reply especially on this list where his
posts are completely outside the realm of this list.

-Will

Date: Tue, 25 Nov 1997 01:52:17 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Complexity not a dominant strategy for independant deployment
Sender: [email-masked]

Ian Grigg <[email-masked]> writes:
> Hal Finney wrote in "Re: hand huffman encoding at PGP world HQ:"
> > 
> > It is true that Phil Zimmermann has been the chief advocate of making
> > PGP data structures as concise as possible.  (I don't know whether Jon
> > actually goes around the office singing songs about it or not.)  Phil is
> > out of the country now so I will try to relay some of his thinking.
> > 
> > First, the difficulty is really not as large as people are making out.
> 
> Well, I have to disagree on that.  The difficulty is high.  I recall the
> swearing going on when each one of the infamous bit twiddles was finally
> debugged out of the Cryptix code - not pleasant to be on the same
> mailgroup as that discussing yet another PGP furfy.

I found the non-standard CFB mode consumed more time than the LOL
twiddling (spent a bit of time with two gdb's up to get that one
working).  Not tackled the rest of the bit twiddling to date, nor the
WoT and revocation semantics.  (I only coded the PRZ style CFB and LOL
bit twiddling as an extra confidence test that my app was doing
something sensible with it's vanilla IDEA and 32 bit ints).

Really I am an oddity in this discussion.  I am a hand huffman
encoding freak if ever there was one.  But at the same time there is
another side: mostly I code optimised for clarity and simplicity.
Perhaps it's just my freakish optimisation for amusement tendencies
coming out again, but I actually went over and reimplemented 3 or 4
times optimising for simplicity my SHA1 implementation.  Same thing
for IDEA, and MD5.  (Note not for speed -- for clarity, speed was
secondary concern).

Now it seemed to me that aside from the enjoyment found in the
optimisation to simplify, simplicity is a valuable feature of crypto
coding -- firstly it reduces scope for errors, and secondly it enables
others to more easily read the code and get confidence that they
understand it.

The same thing could be said for the standard, as Ian was arguing.
The simpler the better.

Now this is amusing from my point of view, because as soon as Hal
talks about the challenge of using the serendipity of 160 bit DSS
sigs, I get the urge to join in and figure out ways to save a few more
bytes :-)

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

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

Date: Mon, 24 Nov 1997 17:26:26 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
Newsgroups: alt.security.pgp,comp.security.pgp.discuss
To: [email-masked]
Subject: The web of trust has no clothes.
Sender: [email-masked]

Another flaw in the web of trust and PGP is now revealed and comes home
to roost.  Now that PGP Inc. has deep-sixed RSA in new free versions,
not only does everyone with an old RSA key have to generate a new key
but also a complete new set of signatures and web of trust must be built
if they wish to use the "better" algorithms. And the new keys must be
distributed to correspondents, either directly or by "pull" from
servers. This took years the first time--perhaps the second time it will
be a bit faster.

In contrast, with S/MIME-Verisign-Netscape/Microsoft if they were to
change the algorithm you just generate a new key and get one certificate
and you're done. And as you e-mail your correspondents using your new
certificate, they get a copy of your new key automatically.

And some say PGP's trust model is "better". Can you say "needs work",
boys and girls?

David

Date: Tue, 25 Nov 1997 00:39:09 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Hal Finney <[email-masked]>
CC: [email-masked]
Subject: Complexity not a dominant strategy for independant deployment
Sender: [email-masked]

It seems that every time that one of the technical people from PGP Inc
post that we leap forward in our understanding of what's happening. 
Thanks Hal.

Hal Finney wrote in "Re: hand huffman encoding at PGP world HQ:"
> 
> It is true that Phil Zimmermann has been the chief advocate of making
> PGP data structures as concise as possible.  (I don't know whether Jon
> actually goes around the office singing songs about it or not.)  Phil is
> out of the country now so I will try to relay some of his thinking.
> 
> First, the difficulty is really not as large as people are making out.

Well, I have to disagree on that.  The difficulty is high.  I recall the
swearing going on when each one of the infamous bit twiddles was finally
debugged out of the Cryptix code - not pleasant to be on the same
mailgroup as that discussing yet another PGP furfy.

There are only a handfull of people who really understand the formats,
and they have invested years in the exercise.  You're probably one of
them, I'd hazard a guess that Derik and Will are too.  Outside that
small group, which might think of it as "not so hard," we have a whole
bunch of people who are working on this, but have different motivations:

  * hack something up to please the boss / move onto the
    next project.  Somebody's paying for this.
  * no particular loyalty to pgp formats, above say SMTP
    or IP or ... most will be expert in many things rather
    than just one protocol, so there's only a limited
    attention span.
  * no particular loyalty to pgp, against say SMIME or
    hacking up their own, which would be a *lot* simpler
    and would do the the same job.

Another factor is that many of these people did not choose to be in the
PGP bit-twiddling profession, their paymasters sent them into it.  We've
all got our cross to bear, but in this case there is the valid
difference between those that are conscripted and those that volunteer. 
The people who are going to coding up the future generation of OP might
not actually be the right programmers for the job.  The more you head in
to the standards and respectable systems field, the lesser becomes the
benefit from programmer self-selection.

And then there's the simple documentation exercise.  The standard, huge
as it is, will be a daunting factor in itself.  The bigger it gets, the
more difficult it is to go through all the conformance exercises that
are now necessary - something that until now has been ignored in
programmer calculations.   Conformance testing is generally more complex
than writing the code in the first place...

Up until now, it has been the fact that the only documentation was the
code.  PGP code is not the worst I've come across, but it's not the
best.  Having the code-as-dox is a reasonable strategy when it is well
written, but elsewise, you're adding a cost.  Having a complicated
standard will result in a three-way reliance of programmers on the
standard, the code and the conformance tests.

Complexity is not a good strategy for widespread adoption by independant
developers.  I think the notion of going for a MUST 32 bits,
MUST/SHOULD? read others and MAY produce others has some merit, which
still allows PGP Inc to pursue their minimalist signature aspirations.

-- 
iang                                      systemics.com

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

Date: Tue, 25 Nov 1997 00:13:21 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
Subject: expediency and avoidance of politics
Sender: [email-masked]

It seems to me that the debate over CMR and it's more secure
alternatives could easily be deferred to OpenPGPv2 with no
compatibility issues.

The way that CMR/ARR field is encoded in the draft is that it is a
signature subpacket type.  Signature subpacket types are extensible;
that is an implementation already has a defined method to safely
ignore subpackets it does not understand.  This means that no one will
experience compatibility problems if the experimental CMR subpacket is
only implemented by PGP Inc.

Avoiding, or deferring the political debate seems like it would be a
good idea for a number of reasons:

- it would allow us to focus on getting OpenPGPv1 out in a timely
  manner.

- it would allow more time for PGP Inc to get feed-back on this
  controversial experimental feature from their customers as to how
  CMR performs functionally in practice (I am expecting there will
  be complaints about the lack of ergonomic recovery from forgotten
  passphrases -- all files have to be re-encrypted), how the security
  of the system holds up (how well companies are managing very
  sensitive CMR master keys), and to gauge customers acceptance of the
  feature politically.

- it will give time for more secure competing proposals (such as local
  escrow) to be developed for recovery from forgotten passphrases.

The consolidation phase would then be in OpenPGPv2 where the better
solution would be chosen in OpenPGPv2 for standardisation.

Adam

Date: Mon, 24 Nov 1997 23:50:34 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: MUST accept 32 bit lols everywhere?
Sender: [email-masked]

Will Price <[email-masked]>
> >All this bit twiddling and little hacks to scrimp on an extra bit here
> >and there is dangerous!  Which hacker is it at PGP Inc that thrives on
> >these bit twiddling hacks?  Come one 'fess up!
> 
> I couldn't agree more with you on this one issue.  I've been saying this
> for years.  Unfortunately, I think the point is really moot.  These are
> format issues.  The format is already there and you can't really change it
> fundamentally without violating the WG charter.

I think Peter Gutmann's suggestion shows how the move to 32 bit could
be made without any major changes.

So pgp2.x has lol field values 0, 1, 2 to mean 1 byte, 2 bytes and 4
bytes.  All that needs to be done is to depracate lol field values 0
and 1.  Ian Grigg said he tried this with his systemics pgp2.x
implementation cryptix2.x but found cases where the pgp2.x code base
could not handle 4 byte lengths!

A good start in depracating 1 and 2 byte length fields would be to 
firstly define that everywhere in OpenPGP1.0 that the implementation
MUST be able to accept a 32 bit int.

Adam

Date: Mon, 24 Nov 1997 23:59:18 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: OpenPGP version2 plan?
Sender: [email-masked]

Jon Callas <[email-masked]> writes:
> The "hand huffman-coded" structures go all the way back to the origins of
> PGP, they're hardly new.

There are a number of bit packing methods which were not in
pgp2.x.which are in the OpenPGP draft:

- 8 bit floatpoint format for S2k iteration count
- new 192 format

Someone suggested that these were mostly decided prior to company
formation -- which suggests that Colin Plumb, Derek Atkins are the
guilty parties (and perhaps PRZ).

> I agree with the sentiment that it would be nice to have a system
> laid out with long constants, but I think that that would be a good
> thing to do in V2 of the spec. I'd like to get this one done, and
> then let the working group debate new formats.

This (saving 32 bit constants for OpenPGPv2) only makes sense, and
will only really be possible if the plan is to have an OpenPGPv2 which
only has SHOULD for backwards compatibility options.  Is this the
plan?  That OpenPGPv2 should be the clean up version?

Adam

Date: Mon, 24 Nov 1997 15:15:23 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
CC: Adam Back <[email-masked]>, [email-masked]
Subject: Re: PGP evolving, improving
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms2F430162516CDCC8FC52644B
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

Uri Blumenthal wrote:

> Adam Back says:
> > > b. There have been no practical cases of signature spoofing with MD5--it
> > > hasn't been broken.
> >
> > I agree, in the general case it has not.  I'll discuss a better
> > user migration path below.
>
> Excuse me, gentlemen, were there any practical cases of signature
> spoofing with MD4?
>
> Also, since this is an IETF forum, let me remind you,  that the
> official IETF security guideline is: "For all the new standards
> MD5 shall not be used - but SHA-1".
>
> 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.

> However, as an algorithm starts showing cracks, a cryptographer
> with brains replaces it before the "practical" cases start
> piling up. For a commercial product to get into such a
> situation would mean death, I think (unless you are
> Micro$oft, of course :-).

They didn't replace it in pay PGP 5.0.

>
>
> > > c. PGP Inc. has made no attempt to remove MD5 in pay PGP 5.0
> >
> > It is possible that Will was talking about the fingerprint spoofing
> > attack, which you are probably aware of.  This flaw is nothing to do
> > with MD5 or RSA per se, but more to do with a flaw introduced in the
> > way that the fingerprint is calculated in pgp2.x.
>
> It was possibly to ease the upgrade path for paying customers. Like:
> "Yes, we strongly suggest you move to SHA-1, but to make sure your
> traffic isn't interrupted, here's 'bilingual' PGP for you."

And free PGP users didn't deserve an eased upgrade path, but rather to forcibly
obsolete all their keys, signatures and web of trust in the new version?
Especially since the RSA-key Free PGP user base is where PGP Inc. made their
reputation and the size of that base is constantly cited to the IETF and in
press releases as PGP's "customer base". Don't be ridiculous. And watch who you
throw stones at--can you say "glass house"?

David

--------------ms2F430162516CDCC8FC52644B
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms2F430162516CDCC8FC52644B--

Date: Mon, 24 Nov 1997 13:59:42 -0800
To: [email-masked]
From: Vinnie Moscaritolo <[email-masked]>
Subject: RE: PGP API
Sender: [email-masked]

>does anyone know of any docs for the Windows PGP 5.0 DLL's ?
>....
>I beleive that there is a PGP Developers Kit for the Windows platform for
>integrating PGP into application.

sorry for the delay, I just recently re-joined the list.

I recently posted a webpage at http://www.pgp.com/sdk/ that descibes and
lets you download a copy of the the developer kit from PGP.

THere are libraries for Mac, Win32 and Unix.

I have also set up provisions for using it for freeware/shareware. since
this is a commercial product, I wont go about it on this list, drop me an
email if you need more info.

__________________________________________________________________________
Vinnie Moscaritolo	    tel:  415.524.6222      Pretty Good Privacy, Inc.
Senior Consulting Engineer  main: 415.572.0430      2121 S. El Camino Real

<[email-masked]>	    web: http://www.pgp.com San Mateo, CA 94403

DH Key: http://keys.pgp.com:11371/pks/lookup?op=get&search=0x070A5CFF

1 if by land, 2 if by sea.
	 Paul Revere - encryption 1775
__________________________________________________________________________

Date: Mon, 24 Nov 1997 12:04:55 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: hand huffman encoding at PGP world HQ
Sender: [email-masked]

The "hand huffman-coded" structures go all the way back to the origins of
PGP, they're hardly new.

I agree with the sentiment that it would be nice to have a system laid out
with long constants, but I think that that would be a good thing to do in
V2 of the spec. I'd like to get this one done, and then let the working
group debate new formats.

	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: Mon, 24 Nov 1997 10:59:29 -0800
To: Ian Brown <[email-masked]>, Jeremey Barrett <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: The case against redundancy and isolation
Cc: IETF OpenPGP <[email-masked]>, [email-masked]
Sender: [email-masked]

At 02:56 PM 11/22/97 +0000, Ian Brown wrote:

   1. We should not MUST MIME *or* Armour. Both increase the amount of code
   needed for a minimal implementation, which none of us want. As Dave
   said, linearly increased code increases exponentially the potential for
   errors.
   
   2. We are not trying to eliminate Armour. It is entirely appropriate
   that it should be in there as an option to provide backward
   compatibility, if implementors so wish.
   
   3. Both systems are for converting fully secure binary PGP data into a
   form which can be safely stored in/sent across 7-bit systems. Mail is
   such a system. Armour/MIME does nothing for security. As Dave and Jon
   have both said, OP is NOT a mail standard. It is a security standard.
   7-bit conversion should therefore not be a MUST. As Lindsay Mathieson
   said, we can safely assume most file systems can cope with 8-bit data.
   
Excellent statement, Ian. I can live with not MUSTing any of them.

	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: Mon, 24 Nov 1997 11:00:41 -0800
To: [email-masked]
From: Jim McCoy <[email-masked]>
Subject: Re: Armour
Cc: [email-masked]
Sender: [email-masked]

David Formosa wrote:
[...]
>The second group is all the scrips, hacks, glue and basic
applications of
>cyrto wich works with pgp[2|5].  These things tend to use pgp as a
tool
>rather then aplication all by itself. [...]

Why do these things need to use 7-bit armored output?  If they are
using PGP as a tool then the scripts must implicitly lack the ability
to actually do anything with the blob of data other than pass it
around and run it through PGP.  Neither of these functions requires
armored output (although I would not doubt that lazy script writers
keyed on things like ---BEGIN PGP...)  

jim

Date: Mon, 24 Nov 1997 11:36:07 -0600
To: Ian Grigg <[email-masked]>, Dave Crocker / IMC <[email-masked]>
From: David Hayes <[email-masked]>
Subject: Re: Armour
Cc: [email-masked]
Sender: [email-masked]

At 08:07 AM 11/24/97 +0000, Ian Grigg wrote:
>1.  Is this WG happy to take as a given, or a working assumption, or a
>fundamental position (pick your own term), that the compatibility with
>the installed base is lost?

There is a tendancy to assume that there will be an unbridgable rift
between OP and pre-standard Classic PGP (2.6, Viacrypt 4, PGP Inc 5.x).
This is not so, and is unlikely ever to be so. 

It is misleading to speak of compatibility "being lost". It _may_ be
forgone by some implementations, which choose not to implement RSA/IDEA.
They are still documented, for those who wish to use them. 

Compatibility with Classic PGP has become optional. All OP implementations
will be compatible with each other. I suspect most will also be compatible
with the Classic PGP, but that's up to implementers and users. 

It is true that a de-minimis implementation of OP will not be compatible
with old PGP. 

--
David Hayes                                       [email-masked]
Switch Systems Engineering                        voice: 972-918-7236
MCI Communications, Inc.                               VNET: 777-7236
--If these thoughts were MCI's official opinions, the line above would
--read "MCI - Law & Public Policy Department".

Date: Mon, 24 Nov 1997 07:37:47 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: hand huffman encoding at PGP world HQ
Sender: [email-masked]

Adam Back <[email-masked]> writes:
> Hal Finney <[email-masked]> writes:
> > First, the difficulty is really not as large as people are making out.
> > The code to read the packet lengths in the various cases is less than a
> > page, and it's very simple.  Read a byte to see if it is the old or new
> > packet formats.  In the old case, read 1, 2, or 4 bytes to get the length;
> > in the new case, read 1 byte and if it's 0xc0 or over, read a second.
>
> The issue is the complexity and the code bloat.
>
> So with universal 32 bit length values, the code looks like:
> [code samples, maybe with some endianness problems]

Ideally you only have to write this code once, in a subroutine.  You
test it and get it right, and from then on you can rely on it.  Yes, it's
a few more lines of code, but it is not a major part of implementing OP.

> Seems to me there is more likely to be an error in the second set of
> code (probably is -- I haven't compiled it), also that the second
> example will be larger, and the second example took about 4 times
> longer to code.  Multiply by the other bit twiddling operations (new
> 192 bit twiddling, proprietry floating point stuff, and the same kind
> of philosophy applied throughout etc) stir in some programmer error,
> and there is significant extra complexity and code bloat, adding to
> development time, creating errors, and dissuading people from coding
> to OpenPGP.  The code bloat will affect smart card implementations.

I agree, as I said, that there is some additional cost to the coder.
And you may be right that this will dissade some people from attempting
the project, since apparently developers within this WG are concerned
about the difficulty of implementing these fields.  I can only reiterate
that the payoff is intended to be for end users and not developers, and
that compared to the level of effort for an OP implementation, writing
a page of code to handle packet headers is not that large a burden.

> I don't think it's that big a deal.  The only place where size at the
> bit scrimping level matters much is signatures.  I reckon use of 32
> bit ints will add at max 3 bytes to the length of the signature.  That
> won't even cause an additional line wrap on your DSS sig example.  The
> longer keyID will be much more significant.

This is one example we see now.  Note that until we went to DSS it was
not a very effective point.  RSA signatures are many times larger than
DSS ones.  "Bit scrimping" was not very effective there.

However, the point is that its philosophy of parsimony put PGP in position
to exploit the concise nature of DSS signatures.  The raw data for DSS
sigs is only 40 bytes long.  Saving a few bytes here and there is a
significant percentage improvement.  So this design philosophy gave us
the advantage of a beautifully compact signature even though it was not
specifically intended to address that case.

When a philsophical approach gives you a serendipitous result like this,
it creates hope that the philosophy is valid and will have similar
unexpected payoffs in the future.  (Or contrariwise that abandoning it
in favor of bulky 32 bit and 64 bit lengths is going to foreclose some
future opportunities.)  This is a philosophical argument rather than a
practical one since we can't point to specific future applications where
it will matter.  But generally it leaves more options open.

> If you really want some nasty hacks to save space, I'm sure I could
> construct some -- I am something of a past master at hand huffman
> encoding cf the RSA in perl and dc signature -- an implementation of
> RSA which is smaller than most PGP signatures :-)

Yes, no doubt you could.  You and Phil would probably make quite a team.

> > Compare that with SMIME.  If you've seen an SMIME signed message
> > in any public forum, you've probably also seen complaints about it.
> > The signature block is about 50+ lines long.  
>
> Yes David Sternlight just posted one to this forum.  I had just
> previously picked apart a x509 signature made by a colleague -- 4350
> bytes, and most of it turned out to be text disclaimers and legalese.

Yes, and level 2 certs include the cert holders street address!  People
didn't even know.

> One pass processing is a useful feature -- perhaps we could do
> something simple like SSLv3 does -- max of 16k -- a simple 16 bit
> integer.  No need for this > 192 means something odd hacking -- the 1
> byte of bloat I don't think will be a problem.

However you do it, it will add some complexity, which may reduce the
attractiveness of the simple-seeming 32 or 64 bit length field.

Hal

Date: Mon, 24 Nov 1997 07:16:56 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: PGP 5.x will communicate with 2.6.x
Sender: [email-masked]

There was a bug in the initial release of 5.5 (but not in 5.0) which
impaired the intended backward compatibility.  Key signatures issued
by an RSA key on another RSA key were using v4 packets, instead of the
intended v3 packets.  Older versions of PGP will complain when they
see v4 signature packets.  This can cause some interoperability
problems even when using RSA keys.

This bug has been fixed in update release 5.5.2.  (Sorry, I am not in the
distribution chain, and I am not familiar with the procedures involved
in acquiring updates.)

Hal Finney

From: Uri Blumenthal <[email-masked]>
Subject: Re: PGP evolving, improving
To: [email-masked] (Adam Back)
Date: Mon, 24 Nov 1997 11:26:17 -0500 (EST)
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Adam Back says:
> > b. There have been no practical cases of signature spoofing with MD5--it
> > hasn't been broken.
> 
> I agree, in the general case it has not.  I'll discuss a better
> user migration path below.

Excuse me, gentlemen, were there any practical cases of signature
spoofing with MD4?

Also, since this is an IETF forum, let me remind you,  that the
official IETF security guideline is: "For all the new standards
MD5 shall not be used - but SHA-1".

Of course, Security Area folks don't have the depth of knowledge
tat David has been exhibiting on the Net for quite a while (:-).

However, as an algorithm starts showing cracks, a cryptographer
with brains replaces it before the "practical" cases start 
piling up. For a commercial product to get into such a
situation would mean death, I think (unless you are
Micro$oft, of course :-).

> > c. PGP Inc. has made no attempt to remove MD5 in pay PGP 5.0
> 
> It is possible that Will was talking about the fingerprint spoofing
> attack, which you are probably aware of.  This flaw is nothing to do
> with MD5 or RSA per se, but more to do with a flaw introduced in the
> way that the fingerprint is calculated in pgp2.x.

It was possibly to ease the upgrade path for paying customers. Like:
"Yes, we strongly suggest you move to SHA-1, but to make sure your
traffic isn't interrupted, here's 'bilingual' PGP for you."

> > Brave talk, but if you had any integrity you would have explained
> > any concerns and left it up to users by preserving all options--not
> > crammed it down the free user's throats.
> 
> I think that unencumbered algorithms are a good thing, however I think
> the method of "encouraging" migration to DSS/EG algorithms has largely
> backfired.  I did a survey of pgp users, which I'll colate shortly,
> and several commented that they scrapped 5.0 and went back to 2.x when
> they discovered the various compatibility problems (eg. not being able
> to generate RSA keys).

Well, the only compatibility concerns that *I* have as a user are
related to the broken *interface*. I.e. I APPLAUD the move to DSS
and EG (would like to see ECC too, BTW) - but I absolutely hate
the fact that I can no longer use Mailcrypt-3.4 from XEmacs.
This is my "compatibility problem", not the ability or
inability to generate RSA keys (which you can take
with you on your way out :-).

> Now the discussion of a better migration path.  It seems to me that a
> nice thing to do would be to generate two keys at key gen time: an RSA
> key and an DSS/EG pair.

What if I *don't* want to generate RSA keys. Why cramming those down my 
throat? Make it possible to geterate DSS *or* DSS+RSA, if you REALLY
insist...

> Largely transparent interoperability on all versions
> would I suspect paradoxically have meant many more people made the
> switch.

Yes and no. Of course transparency will help. HOWEVER, many of PGP
users have either no time, or no skills (or "no" both) to modify
the software that interfaces between their favorite whatever
and PGP. For me it is Mailcrypt/XEmacs. Until *that* part
is taken care of - don't expect people to switch.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Mon, 24 Nov 1997 15:32:25 +0000
From: Ian Brown <[email-masked]>
To: Kent Crispin <[email-masked]>
CC: IETF OpenPGP <[email-masked]>
Subject: Re: Armour
Sender: [email-masked]

> That's an entertaining possibility.  The implication being that a mail
> program that could handle all the possibilities would require me
> keeping copies of pgp2 and 5, along with a new OP compliant program, and
> the mail program would have to be written to deal with them all.  Am I
> the only one who thinks this is nuts?  

No you aren't, as this wasn't what I said.

People are complaining that old services won't work if we do x to the
standard. People who currently use such services obviously have a
current version of PGP. They will be able to continue using such
services if they so wish. Meanwhile, said services can be upgrading to
use the new standard.

I really have lost count of how many times people have made the point
that MUST OP implementations will not be backward compatible because of
decisions we have made already.

Ian.

Date: Mon, 24 Nov 1997 10:30:30 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: re: CMR
To: [email-masked]
Sender: [email-masked]

> So you accept it as a given that shredding evidence is appropriate and
> desirable behavior in a free society?  Even if said shredding is
> conducted by the White House (or #10 Downing Street)?

It can be - depends on the context. I use a shredder daily to produce kitty 
litter. I only use my own property to do this (and pity anyone who tries to
go through my trash 8*).

In other contexts, where retention is a condition for use established by the
property owner then clearly destruction is not appropriate.

Think the major area of concern is of demands by a third party for access.
Since citizens, unlike those in the military, are not the property of the 
government (yet,here), whether shredding is or is not done is not anyone
else's business without due process.

Could be rong. Hope not.
				Warmly,
					Padgett

Date: Mon, 24 Nov 1997 10:20:55 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: RE: Ancient Technology
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

>The defacto standard for sending anything but plain-text-English 
>emails is MIME. Ascii Armour is from the time that UUEncoding was the 
>hip thing. The mailreaders of 99% of the internet users today already 
>understand MIME, they don't understand AA, so adding support for 
>PGP/MIME to them should be trivial.

I tend to agree at least for corporate use since Eudora, Exchange, 
and ccMail all understand MIME which would seem to simplify plug-ins.

AsciiArmouring is not necessary for PGP to operate properly, rather it
is a "nice" but is ready to be considered a hysterical element along with
TekHex and UUencode (which could also be easily supported).

However I must agree that the prevalent mechanism today is Base64 encoding.

					Warmly,
						Padgett

Date: Mon, 24 Nov 1997 07:05:41 -0800
From: Kent Crispin <[email-masked]>
To: IETF OpenPGP <[email-masked]>
Subject: Re: Armour
Sender: [email-masked]

On Mon, Nov 24, 1997 at 11:21:43AM +0000, Ian Brown wrote:
[...]
> Don't forget, as Ian Grigg pointed out, that PGP 2|5 software won't
> disappear overnight. We can continue to use them in many situations
> where backward compatibility is important.

That's an entertaining possibility.  The implication being that a mail
program that could handle all the possibilities would require me
keeping copies of pgp2 and 5, along with a new OP compliant program, and
the mail program would have to be written to deal with them all.  Am I
the only one who thinks this is nuts?  

Five messages ago there was a rant about pgp 5 breaking
interoperability with pgp2.  Now we are talking about an OP that won't
be interoperable with with either.  

-- 
Kent Crispin				"No reason to get excited",
[email-masked]			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Draft comments
Date: 24 Nov 1997 14:39:53 GMT
Organization: IKS GmbH Jena
Lines: 33
NNTP-Posting-Host: belenus.iks-jena.de
Sender: [email-masked]

* Jon Callas wrote:
>I've already said my part on why I think armour is *not* primarily for
>backwards compatibility. The PART X headers are not a new header, though.
>They are an old header. I don't mind losing them, or deprecating them.

No. they are new.

>I meant that new combined header that has a begin-message and the hash
>announcement. I think that as long as the "Hash:" header line can have
>multiple hashes there (or it is legal to have multiple hash headers), then
>we don't need this, and it simplifies to just remove it.

Hash headers can contain multiple values. They are specified as:
  <HASH> ::= 'Hash:' <WS> <HASHS> <CRLF>
  <HASHS> ::= <HASHVAL> | <HASHVAL> ',' <WS> <HASHS>
  <HASHVAL> ::= 'SHA1' | 'MD5' | 'MD2' | 'RIPEM160'

Btw: <WS> ::= <LWS> | <CRLF> <LWS> | <WS><WS>

>When PGP 2.6 was created, the version number of the packets was bumped from
>2 to 3, but nothing else was changed. It's really only there so you can

That's not true. V2 has a different padding for encrypted session keys and
digests than V3. So V2 and V3 are totally incompatible. It's absolutly
necessary to respond to an V2 key using the old format.

>you send me a compressed message, I can't read it." This is so that a
>minimal implementation -- one that does not have compression (remember, the
>MUST algorithm for compression is uncompressed) -- can advertise that it
>doesn't have compression. 

So the default has to be changed to 'prefered = no compression'.

Date: Mon, 24 Nov 1997 12:05:37 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: PGP evolving, improving
Sender: [email-masked]

Ian Grigg <[email-masked]> writes:
> 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.

That's an easy one to solve: just use a different value for the
automated keyserver lookup.  eg keyID||fingerprint.

For manual pgp2.x users of the same keyservers (rather than software
automated pgp5.x lookups) just provide an additional CGI form for
fingerprint, and a short text explaining the problem, and how to avoid
it.  Display the fingerprint by default also might be a good idea.

Adam

Date: Mon, 24 Nov 1997 13:32:45 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: PGP 5.x will communicate with 2.6.x
Sender: [email-masked]

Jonathan Wienke <[email-masked]> writes:
> As long as only old-style RSA keys are used when encrypting a message 5.x
> will talk to 2.6.x.  If you create an RSA key with a CMRK packet or other
> 5.x features, it is not hard to understand why 2.6.x would break.

Just a nit: I don't think pgp5.x will let you put a CMR (aka packet no
666) signature subpacket on an RSA key.  (At least it was described
that PGP 5.x for business had RSA keys disabled for this reason).

This breaks orthogonality, not that I'm complaining in this case, for
obvious reasons.  Also it may be that this is an implementation choice
rather than a restriction of the standard.

Adam

Date: Mon, 24 Nov 1997 13:21:36 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: hand huffman encoding at PGP world HQ
Sender: [email-masked]

Hal Finney <[email-masked]> writes:
> It is true that Phil Zimmermann has been the chief advocate of making
> PGP data structures as concise as possible. [...]
> 
> First, the difficulty is really not as large as people are making out.
> The code to read the packet lengths in the various cases is less than a
> page, and it's very simple.  Read a byte to see if it is the old or new
> packet formats.  In the old case, read 1, 2, or 4 bytes to get the length;
> in the new case, read 1 byte and if it's 0xc0 or over, read a second.

The issue is the complexity and the code bloat.

So with universal 32 bit length values, the code looks like:

word32 len;
char ctb = getc(fp);
read(fp,&len,4);
len = ntohl(len);
...

With bit twiddling the code looks more like:

word32 len = 0;
char lchar[4]=(char*)&len;
char ctb = getc(fb);
int lol = ctb & 3;
ctb &= ~3;
if (lol == 0) { read(fp,lchar+3,1); }
else if (lol == 1) { read(fp,lchar+2,2); }
else if (lol == 2) { read(fp,lchar,4); }
len = ntohl(len);
...

Seems to me there is more likely to be an error in the second set of
code (probably is -- I haven't compiled it), also that the second
example will be larger, and the second example took about 4 times
longer to code.  Multiply by the other bit twiddling operations (new
192 bit twiddling, proprietry floating point stuff, and the same kind
of philosophy applied throughout etc) stir in some programmer error,
and there is significant extra complexity and code bloat, adding to
development time, creating errors, and dissuading people from coding
to OpenPGP.  The code bloat will affect smart card implementations.

> The payoff is that you have slightly reduced the size of all the PGP
> exchanged data.  By itself it is not so much, but as a philosophy applied
> throughout the design, these savings add up.  The alternative philosophy
> of making everything 32 or 64 bits can lead to bloated data structures.
> It's easier on the coder, but every user pays the cost in terms of
> larger data.

I don't think it's that big a deal.  The only place where size at the
bit scrimping level matters much is signatures.  I reckon use of 32
bit ints will add at max 3 bytes to the length of the signature.  That
won't even cause an additional line wrap on your DSS sig example.  The
longer keyID will be much more significant.

> -----BEGIN PGP SIGNATURE-----
> Version: PGP for Business Security 5.5.2
> 
> iQA/AwUBNHijtqy7FkvPc+xMEQJ9EQCg98ARQWaclA7enOcIroIRiaGJeQsAn1om
> OZVLRqiOTCRBMJSZ6QX2pbUZ
> =Juy1
> -----END PGP SIGNATURE-----

> (He'd like to see the -----END line go away, too, since it is redundant.)
> You can hardly imagine a more concise signature block than this.

If you really want some nasty hacks to save space, I'm sure I could
construct some -- I am something of a past master at hand huffman
encoding cf the RSA in perl and dc signature -- an implementation of
RSA which is smaller than most PGP signatures :-)

> Compare that with SMIME.  If you've seen an SMIME signed message
> in any public forum, you've probably also seen complaints about it.
> The signature block is about 50+ lines long.  

Yes David Sternlight just posted one to this forum.  I had just
previously picked apart a x509 signature made by a colleague -- 4350
bytes, and most of it turned out to be text disclaimers and legalese.

ISO 7816-9 is being re-written to come up with a smaller x509 style
certificate because the project involved couldn't fit three of the
x509 bloaters on their cards!  So that is an example of at least one
standard which might find OpenPGP interesting, and proof that this
issue is a problem.

> Now, this is largely a design error in the client software, in that
> it is including the whole certificate chain in the signature.  But
> it is probably going to be a factor in slowing acceptance of SMIME.
> Nobody likes a technology which brings them tons of flames every
> time they send a clearsigned message.

Agree.

Another neat trick to remove this problem is what mailcrypt used to
offer: to puts the PGP signature in an X-signature header (can't find
it in the docs for v3.4 he may have removed it).  (Course you wouldn't
want an X509 sig in your headers -- the huge header might crash some
software!)

> PGP's philosophy has been one of being willing to pay a cost in
> implementation complexity in order to reduce objectionable aspects
> of the software to end users.  Part of that has been making the data
> structures as compact as possible.

I am confident I can shave a few more percent or so off your current
data structures... you really want to see the hacks?

> Let me make one technical point, in case all this philosophizing is
> unpersuasive.  Part of the purpose of the new packet length headers is
> to allow "one pass" processing.  You can put out a packet length header
> which says "will be followed by 2K of data, then another packet length
> header".  This allows you to start emitting data even when you don't
> know the total length of the data in advance, and also allows lengths
> greater than 2^32 bits.

One pass processing is a useful feature -- perhaps we could do
something simple like SSLv3 does -- max of 16k -- a simple 16 bit
integer.  No need for this > 192 means something odd hacking -- the 1
byte of bloat I don't think will be a problem.

> This is one of several technical changes which are designed to allow
> one-pass processing.  Yesterday I explained how the new ascii armor header
> line and the one-pass signature packets also supported this capability.
> It's an important feature which allows software to get by without the use
> of temporary files.
> 
> Any changes to another packet length header format should provide some
> way of allowing one-pass processing.  A simple 32 bit length will not
> be adequate.

You could either have a 16 bit length field, or a 32 bit length field.
You can still have the continuation feature, this is useful and
largely separable feature.

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

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

Date: Mon, 24 Nov 1997 09:53:17 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: PGP evolving, improving
Sender: [email-masked]

David Sternlight <[email-masked]> writes:
> This is a bogus explanation for two reasons:
> 1. PGP Inc. disabled RSA key generation in free PGP 5.0 but kept it in most
> versions of pay PGP 5.0.
> 2. Their "explanation" wasn't about RSA keys but the MD5 algorithm (see
> below). Yet :
> a. MD5 is a hash function not an encryption algorithm.
> b. There have been no practical cases of signature spoofing with MD5--it
> hasn't been broken.

I agree, in the general case it has not.  I'll discuss a better
user migration path below.

> c. PGP Inc. has made no attempt to remove MD5 in pay PGP 5.0

It is possible that Will was talking about the fingerprint spoofing
attack, which you are probably aware of.  This flaw is nothing to do
with MD5 or RSA per se, but more to do with a flaw introduced in the
way that the fingerprint is calculated in pgp2.x.

Here's a key with a spoofed fingerprint:

Type Bits/KeyID    Date       User ID
pub   704/977EE465 1997/06/08 Adam Back <spoofed fingerprint DO NOT USE>

It has the same fingerprint as my low security 1024 bit key attached
below.

However it does not have the same keyid.  It is fairly unlikely that
pgp2.x key generation code would generate a key for which it is
possible to spoof both keyid and fingerprint at the same time.
Therefore a simple solution is to always consider the keyid part of
the fingerprint information, say like this:

556a4a67/18b8a0659d381483615ae6ac918b9e57

This would then be a user education task.  Many people do include the
keyid in their signatures along with fingerprints already.  pgp2.x
already displays the keyid at the same time.

(I downloaded the 25Mb key ring and searched all the keys to see if
there was anyone a double keyid and fingerprint spoof was possible for
-- there was not.  It was something like a 25% chance I think I
calculated given the size of the key database.)

> In short, PGP Inc. has taken the weakest and most vulnerable sector--the
> free users, and shoved it to them in an authoritarian "big brother" way.
> (Ironic, that, given many PGP' staffers' and the founder's ideological
> pretensions). Since that is the "huge" RSA-key user base (check the MIT and
> linked international servers) PGP is waving around to justify itself both
> in press releases and to the IETF, a more egregious case of biting the hand
> that indirectly feeds one is hard to imagine.

When you subscribe to this list (ietf-open-pgp), it says this:

: PGP has become a very popular method for establishing trust between
: internet users for securing communications. In order to grow the
: installed-base of over 4 million users, ...

So yes, PGP uses the freely installed base in it's figures.  RSADSI
used to be fond of this also (using freeware PGP installed base in
their figures of RSA users).

> Brave talk, but if you had any integrity you would have explained
> any concerns and left it up to users by preserving all options--not
> crammed it down the free user's throats.

I think that unencumbered algorithms are a good thing, however I think
the method of "encouraging" migration to DSS/EG algorithms has largely
backfired.  I did a survey of pgp users, which I'll colate shortly,
and several commented that they scrapped 5.0 and went back to 2.x when
they discovered the various compatibility problems (eg. not being able
to generate RSA keys).

> This is especially underhanded-seeming since Free PGP 5.0 uses RSAREF,
> which can generate RSA keys, carries no fees, and is not in legal dispute
> as between PGP Inc. and RSADSI.

Yes, I agree with this... there is no legal reason not to include RSA
keygen in freeware.. it already includes RSA encrypt decrypt, and
RSAREF allows this anyway.

Now the discussion of a better migration path.  It seems to me that a
nice thing to do would be to generate two keys at key gen time: an RSA
key and an DSS/EG pair.  The software could then cross authenticate
the keys (thus retaining the web of trust if the RSA key was an old
one.)  The software could then use DSS/EG keys when talking to other
pgp5 users (as determined by their public key, or a feature such as a
comment field embedded in a 2.x message which would not upset a pgp2.x
implementation), and revert to RSA when the user could not cope with
5.x DSS/EG keys.  Largely transparent interoperability on all versions
would I suspect paradoxically have meant many more people made the
switch.

Adam

The real key the above spoofed key is a fingerprint spoof of:

Type Bits/KeyID    Date       User ID
pub  1024/556A4A67 1993/06/08 Adam Back <[email-masked]>

Date: Mon, 24 Nov 1997 11:21:43 +0000
From: Ian Brown <[email-masked]>
To: [email-masked]
CC: IETF OpenPGP <[email-masked]>
Subject: Re: Armour
Sender: [email-masked]

> There is in my view two
> groups of appiliactions that we should try and retain compatabilty unless
> there is a very good resons against.
> 
> The first group is the pgp[2|5] programs themselfs propper,  this has been
> already meantioned often and there is nothing orginal in this argument.
> 
> The second group is all the scrips, hacks, glue and basic applications of
> cyrto wich works with pgp[2|5].  These things tend to use pgp as a tool
> rather then aplication all by itself.  Meany of these things don't have
> (or would be inapproprate to a have) Mime capatability but have a sence of
> asscii armor.  I would not like to see these things broken for the sake of
> computaional estitics.

Don't forget, as Ian Grigg pointed out, that PGP 2|5 software won't
disappear overnight. We can continue to use them in many situations
where backward compatibility is important.

Ian :D

Date: Mon, 24 Nov 1997 20:47:13 +1100 (EST)
From: David Formosa <[email-masked]>
Reply-To: [email-masked]
To: Dave Crocker / IMC <[email-masked]>
cc: [email-masked]
Subject: Re: Armour
Sender: [email-masked]

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

On Sun, 23 Nov 1997, Dave Crocker / IMC wrote:

> At 05:29 AM 11/24/97 +1100, David Formosa wrote:
> >And consider all the aplications that have been built ontop of PGP.
> 
> well, we really are re-cycling arguments.  this one is the compatibility
> issue again.

It however is a diffrent compatibility argument.  There is in my view two
groups of appiliactions that we should try and retain compatabilty unless
there is a very good resons against.

The first group is the pgp[2|5] programs themselfs propper,  this has been
already meantioned often and there is nothing orginal in this argument.

The second group is all the scrips, hacks, glue and basic applications of
cyrto wich works with pgp[2|5].  These things tend to use pgp as a tool
rather then aplication all by itself.  Meany of these things don't have
(or would be inapproprate to a have) Mime capatability but have a sence of
asscii armor.  I would not like to see these things broken for the sake of
computaional estitics.

[...]

> 2.  Installed base compatibility
> 
>     It has been observed a number of times that that is already lost for
> other reasons, so use of MIME rather than Armour does not create a new
> problem.

The second population will have problems if Ascii armour is removed, in
addtion as the backwards compatiblity will be only lost for a subsection
of the population (thouse covered by verious patents) why brake it for
everybody else?

[...]

>     The need to document prior use is well served by having an appendix
> which describes how to do armouring, for implementations needing to
> interwork with pre-standards implementation.

However it is clear that most implementaitons will need to interwork with
the pre-standards indeed it should be a SHOULD.

[...]

>     The argument that it is acceptable to require both or make both
> optional misunderstand the additional overhead caused by requiring
> redundant mechanisms or the difficulty achieving interworking when
> everything is optional.

Of cause but interworking is not going to happen unless we have
interopablity with the old code base.

- -- 
Please excuse my spelling as I suffer from agraphia see the url in my header. 
Never trust a country with more peaple then sheep.  ex-net.scum and proud
You Say To People "Throw Off Your Chains" And They Make New Chains For
Themselves? --Terry Pratchett.  I do not reply to munged addresses.

Date: Mon, 24 Nov 1997 19:37:24 +1100 (EST)
From: David Formosa <[email-masked]>
Reply-To: [email-masked]
To: IETF OpenPGP <[email-masked]>
Subject: Re: hand huffman encoding at PGP world HQ
Sender: [email-masked]

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

On Sun, 23 Nov 1997, Ian Brown wrote:

> I also absolutely agree with Adam's suggestion of simplifying data
> structures. I'm just starting to implement PGP 5 packets; they are
> *horrendously* over-complicated by the facts Adam mentioned. As he has
> said before, "bits are cheap" - we can spare a few here and there ;-)

I would have to dissagry with this comment.  There is anouther signiture
standard wich seems to approxmitly double the size of the post.  If this
item is mailed to a popular email list or a usenet newsgroup, it is very
likely that the cost of sending redundent bits will eceed any value lost
by forgery.

[...]

> Of course keep the description of the current system for backward
> compatibility as a MAY.

It is my view that meany peaple are under valueing backwards
compatibility.  The first thing that peaple are going to ask when thay
download there new Open-PGP based product is "Will this work with PGP?".

We must view backward compatibility as one of the over wealming factor
that should only be sacrifesed for a condtion that would stop us from
getting O-PGP into the 'marketplace'.  Niceities like tidying up the
presentaion layer protocol (Mime vs Ascii armor) or the way PGP veiws
objects is not worth loosing the related backwards capisty.

- -- 
Please excuse my spelling as I suffer from agraphia see the url in my header. 
Never trust a country with more peaple then sheep.  ex-net.scum and proud
You Say To People "Throw Off Your Chains" And They Make New Chains For
Themselves? --Terry Pratchett.  I do not reply to munged addresses.

Date: Mon, 24 Nov 1997 08:59:57 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
CC: [email-masked]
Subject: Re: PGP evolving, improving
Sender: [email-masked]

David Sternlight wrote:
> 
> I became aware of the post below only indirectly. I'll comment.

David,
there are some things that are obviously wrong, and some things that
are, well, not quite absolutely wrong.  Regardless, this is not really a
forum for bashing PGP Inc and their product, although it seems like it
at times.

I'll just add what I know to your comments.

> > >=====================8<===================
> >
> > >At 5:30 PM -0800 11/22/97, David Sternlight wrote:
> > >>And while you're introducing gratuitous issues unrelated to the
> > discussion,
> > >>why did PGP disable RSA key generation in Free PGP 5.0, and remove RSA
> > >>compatibility completely from Free PGP 5.5
> >
> > >Very simple.  How can we with good conscience allow users to generate
> > >keys
> > >which we don't feel meet our security standards?  We can't.  Case
> > >closed.
> 
> This is a bogus explanation for two reasons:
> 1. PGP Inc. disabled RSA key generation in free PGP 5.0 but kept it in most
> versions of pay PGP 5.0.

I agree that there are lot of questions here... 

> 2. Their "explanation" wasn't about RSA keys but the MD5 algorithm (see
> below). Yet :
> a. MD5 is a hash function not an encryption algorithm.

OK.  Actually there are concerns with PGP.  It is not with the RSA
algorithm, that remains strong, and it is not with the actual RSA
usage.  Rather, it is with the format of the 2.6 packets and
identifiers.

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.

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.

-- 
iang                                      systemics.com

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

Date: Mon, 24 Nov 1997 00:04:34 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
Subject: Re: PGP evolving, improving
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms6508C516026A442844B60424
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

I became aware of the post below only indirectly. I'll comment.

> >=====================8<===================
>
> >At 5:30 PM -0800 11/22/97, David Sternlight wrote:
> >>And while you're introducing gratuitous issues unrelated to the
> discussion,
> >>why did PGP disable RSA key generation in Free PGP 5.0, and remove RSA
> >>compatibility completely from Free PGP 5.5
>
> >Very simple.  How can we with good conscience allow users to generate
> >keys
> >which we don't feel meet our security standards?  We can't.  Case
> >closed.

This is a bogus explanation for two reasons:
1. PGP Inc. disabled RSA key generation in free PGP 5.0 but kept it in most
versions of pay PGP 5.0.
2. Their "explanation" wasn't about RSA keys but the MD5 algorithm (see
below). Yet :
a. MD5 is a hash function not an encryption algorithm.
b. There have been no practical cases of signature spoofing with MD5--it
hasn't been broken.
c. The concern is mostly theoretical and remote. Even if one could generate
a spurious message with the same hash as a real one, the spurious messages
would overwhelmingly likely be gibberish.
d. No general method has been shown which generates a hashed message with
spurious but substantive motivated content having the same hash as a
particular "real" message.
e. The alternatives PGP 'likes" simply have a larger hash space but the
same weakness. If a general solution to faking hashes is found the "new"
hashes PGP uses would be just as vulnerable as MD5. Absent a general
solution, chances of a motivated and genuine-seeming message having the
same hash as the one being spoofed are essentially nil for MD5 as for
longer substitutes.
f. Moving to a new, longer hash function is about of the same class as
moving from a 1024 to a 2048 bit key--theoretically more secure but not, in
general, practically so. There is plenty of time to do so in an
evolutionary way without vitiating existing keys, existing signatures, and
the existing web of trust, as PGP Inc. has so vitiated with Free PGP 5.52.
c. PGP Inc. has made no attempt to remove MD5 in pay PGP 5.0

In short, PGP Inc. has taken the weakest and most vulnerable sector--the
free users, and shoved it to them in an authoritarian "big brother" way.
(Ironic, that, given many PGP' staffers' and the founder's ideological
pretensions). Since that is the "huge" RSA-key user base (check the MIT and
linked international servers) PGP is waving around to justify itself both
in press releases and to the IETF, a more egregious case of biting the hand
that indirectly feeds one is hard to imagine.

> >If you're unfamiliar with why RSA keys are not as secure as we'd like,
> >you
> >should check archives of the newsgroups for the past few years.  The
> >weaknesses of MD5

MD5 is not "RSA keys".  RSA keys have not been shown in any way to be
insecure any more than other keys of comparable length. The author purports
to be a PGP expert. Not a very impressive demonstration of expertise.

> and the KeyID attacks were the two primary security
> >issues we felt absolutely had to be addressed in 5.0.

But they weren't by dropping RSA. Pay PGP 5.0 still has RSA in most
versions.

> The development
> >team
> >couldn't have cared less about RSA licensing issues.  The only issue
> was
> >security.

Nonsense.Free PGP 5.0 still has RSA encryption and decryption. Only key
generation has been disabled. Pay PGP 5.0 (most versions) have RSA key
generation as well. This is a bogus explanation.

> Fixing those required a new key format.  As long as we were
> >changing the key format, we decided to switch to unencumbered
> algorithms
> >at
> >the same time since the hit was the same either way -- everyone would
> >need
> >new keys.

Then why didn't you drop RSA encryption and decryption in Free PGP, and RSA
key generation as well in pay PGP.? And it's a lot more than screwing users
by making them get new keys. The free user base on which PGP made its
reputation is now forced to get new signatures and reconstruct the entire
web of trust as well with Free PGP 5.52, which contains no RSA. Brave talk,
but if you had any integrity you would have explained any concerns and left
it up to users by preserving all options--not crammed it down the free
user's throats.

This is especially underhanded-seeming since Free PGP 5.0 uses RSAREF,
which can generate RSA keys, carries no fees, and is not in legal dispute
as between PGP Inc. and RSADSI.

>  If a particular user doesn't mind the security issues with
> >RSA
> >keys, they should feel free to continue using them although the number
> >of
> >versions supporting those keys available from us will undoubtedly
> >continue
> >to dwindle, and at the same time the number of versions and platforms
> >supporting DH/DSS keys will continue to grow dramatically.

Pretty evasive and doesn't resolve the blatant contradictions in the above.

>
>
> >-Will
>
> >Will Price, Architect/Sr. Mgr.
> >Pretty Good Privacy, Inc.
>

David Sternlight, Ph.D.

--------------ms6508C516026A442844B60424
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms6508C516026A442844B60424--

Date: Mon, 24 Nov 1997 08:07:14 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Dave Crocker / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: Armour
Sender: [email-masked]

Dave Crocker / IMC wrote:

> well, we really are re-cycling arguments.  this one is the compatibility
> issue again.

Well, I guess we'll keep re-cycling until the WG has reached that
concensus that is required to accept each and every proposal.

Pedalling on...

> 1.  Technical

I agree that technical concerns are not of prime importance.

> 2.  Installed base compatibility
> 
>     It has been observed a number of times that that is already lost for
> other reasons, so use of MIME rather than Armour does not create a new
> problem.

OK.  This is a missing assumption that I for one did not pick up, but am
now seriously thinking about.  It has taken a long time to get here, I
hope everybody is still with us.  A few (open) questions:

1.  Is this WG happy to take as a given, or a working assumption, or a
fundamental position (pick your own term), that the compatibility with
the installed base is lost?

2.  If compatibility with the installed base (as inferred above) is
*not* lost, does the proposal that MIME should "replace" Armour
(ignoring how&what) still have any merit?

(I don't know the answers to these questions myself, I'm very interested
to hear what others have to say.)

> In this case
> standardizing the prior use of armour will prevent PGP from being fully
> integrated into the Internet technical suite and would require
> implementation of redundant technology.

Dave, I don't think you and I are connected over the same Internet.  The
net I am connected to includes PGP, and has for a number of years.  It
will continue to do so, and I say this with complete and utter
conviction as the Internet I am connect to does not exclude technologies
because they are old, because there is an alternative, or because some
bunch of bureaucrats at the IETF might deign to pronounce otherwise.

One of the wonderful discoveries of the Internet was to never limit the
possibilities of multiple, apparantly competing standards.  In this
sense, the Internet is a pure market.  It remains pure and unlimited
until some limit comes along.  PGP is currently facing no high level
technologically imposed limits, and thus will remain as a viable
security protocol for many many years, in whatever variant we can think
of.

I consider the above sweeping generalisation, "prevent PGP from being
fully integrated into the Internet technical suite," to be out of place,
unbacked and generally plain wrong.

Statements such as whether we wish to "participate in the suite of
Internet technology,"   and whether the group is being "uncooperative
towards true integration with Internet mail and web standards..."  only
serve to flag to me, and perhaps others, that the rest of the discussion
has nothing to add to the group, so if there are good points in there,
they tend to be hidden.  Maybe this is why I missed the very important
assumption I discuss above.

-- 
iang                                      systemics.com

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

Date: Sun, 23 Nov 1997 17:54:03 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: hand huffman encoding at PGP world HQ
Sender: [email-masked]

It is true that Phil Zimmermann has been the chief advocate of making
PGP data structures as concise as possible.  (I don't know whether Jon
actually goes around the office singing songs about it or not.)  Phil is
out of the country now so I will try to relay some of his thinking.

First, the difficulty is really not as large as people are making out.
The code to read the packet lengths in the various cases is less than a
page, and it's very simple.  Read a byte to see if it is the old or new
packet formats.  In the old case, read 1, 2, or 4 bytes to get the length;
in the new case, read 1 byte and if it's 0xc0 or over, read a second.

The payoff is that you have slightly reduced the size of all the PGP
exchanged data.  By itself it is not so much, but as a philosophy applied
throughout the design, these savings add up.  The alternative philosophy
of making everything 32 or 64 bits can lead to bloated data structures.
It's easier on the coder, but every user pays the cost in terms of
larger data.

Phil contrasts PGP's philosophy of a clean interface with SMIME.  Look at
a PGP cleartext signature:

Phil has proposed simplifications to shorten this to:

(He'd like to see the -----END line go away, too, since it is redundant.)
You can hardly imagine a more concise signature block than this.

Compare that with SMIME.  If you've seen an SMIME signed message
in any public forum, you've probably also seen complaints about it.
The signature block is about 50+ lines long.  Now, this is largely a
design error in the client software, in that it is including the whole
certificate chain in the signature.  But it is probably going to be a
factor in slowing acceptance of SMIME.  Nobody likes a technology which
brings them tons of flames every time they send a clearsigned message.

Phil has worked from the beginning to make PGP be as usable and attractive
to end users as possible, taking into consideration "real world" issues.
Where PEM envisioned a complex hierarchical certification structure which
didn't exist except on paper, PGP created the web of trust which could
work locally and be useful from the beginning.  In the case of SMIME,
probably the designers of the client software envisioned a world where
everyone was using MIME and no one would care how big and bloated the
signatures were, since they wouldn't see them.  But that's not the
real world.

PGP's philosophy has been one of being willing to pay a cost in
implementation complexity in order to reduce objectionable aspects of the
software to end users.  Part of that has been making the data structures
as compact as possible.

These efforts to use concise data structures are costly to implementors,
but beneficial to users.  You pay the cost once per implementation -
a few pages of code for this and similar features.  But the benefit is
felt every time a message is sent.  It doesn't take much to swing the
cost-benefit balance in favor of making things nicer for users.

Let me make one technical point, in case all this philosophizing is
unpersuasive.  Part of the purpose of the new packet length headers is
to allow "one pass" processing.  You can put out a packet length header
which says "will be followed by 2K of data, then another packet length
header".  This allows you to start emitting data even when you don't
know the total length of the data in advance, and also allows lengths
greater than 2^32 bits.

This is one of several technical changes which are designed to allow
one-pass processing.  Yesterday I explained how the new ascii armor header
line and the one-pass signature packets also supported this capability.
It's an important feature which allows software to get by without the use
of temporary files.

Any changes to another packet length header format should provide some
way of allowing one-pass processing.  A simple 32 bit length will not
be adequate.

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

Date: Sun, 23 Nov 1997 17:02:34 -0800
To: Ian Grigg <[email-masked]>, Adam Back <[email-masked]>
From: Jonathan Wienke <[email-masked]>
Subject: PGP 5.x will communicate with 2.6.x
Cc: [email-masked]
Sender: [email-masked]

At 06:27 PM 11/23/97 +0000, Ian Grigg wrote:

>This is not the effect that is occurring with the pgp5.0, as that has
>IMHO failed, because it is practically incompatible.  I'm not saying
>pgp5 has failed, just that you need to consider other models.  The
>result with pgp5.0 is that if you upgrade, you won't be able to talk to
>all your non-upgraded contacts at all, so you won't upgrade.  (I'm not
>entirely sure what is going on here, but I think what happens is that as
>soon as the RSA keys get any of the extra packets added to them, it
>appears that 2.6 will reject them in a variety of ways.  I've tried with
>3 different people to get comms between 2.6 (and Cryptix) and pgp5.0. 
>No joy yet.).

As long as only old-style RSA keys are used when encrypting a message 5.x
will talk to 2.6.x.  If you create an RSA key with a CMRK packet or other
5.x features, it is not hard to understand why 2.6.x would break.  I
created the following key with 2.6.2 and then imported it into PGP 5.5:

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP for Business Security 5.5

mQBNAzR4zmUAAAECAMYAlJypnCgZOLMnXu/RAdbhKtMGbMgFcKP9TEWN18aruWbj
7tyb1X1O5j0CRhg81Db+bVugZHpzWCtwekTC0TkABRG0FFNtYWxsIDIuNi4yIFRl
c3QgS2V5
=cQvS
- -----END PGP PUBLIC KEY BLOCK-----

Here is the preceding text encrypted with PGP 5.5:

- -----BEGIN PGP MESSAGE-----
Version: PGP for Business Security 5.5

=YsJ8
- -----END PGP MESSAGE-----

Here is the preceding ciphertext successfully decrypted by PGP 2.6.2 (line
breaks added during encryption):

At 06:27 PM 11/23/97 +0000, Ian Grigg wrote:

>This is not the effect that is occurring with the pgp5.0, as that has
>IMHO failed, because it is practically incompatible.  I'm not saying
>pgp5 has failed, just that you need to consider other models.  The
>result with pgp5.0 is that if you upgrade, you won't be able to talk to
>all your non-upgraded contacts at all, so you won't upgrade.  (I'm not
>entirely sure what is going on here, but I think what happens is that as
>soon as the RSA keys get any of the extra packets added to them, it
>appears that 2.6 will reject them in a variety of ways.  I've tried with
>3 different people to get comms between 2.6 (and Cryptix) and pgp5.0. 
>No joy yet.).

As long as only old-style RSA keys are used when encrypting a message 5.x
will talk to 2.6.x.  If you create an RSA key with a CMRK packet or other
5.x features, it is not hard to understand why 2.6.x would break.  I
created the following key with 2.6.2 and then imported it into PGP 5.5:

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP for Business Security 5.5

mQBNAzR4zmUAAAECAMYAlJypnCgZOLMnXu/RAdbhKtMGbMgFcKP9TEWN18aruWbj
7tyb1X1O5j0CRhg81Db+bVugZHpzWCtwekTC0TkABRG0FFNtYWxsIDIuNi4yIFRl
c3QgS2V5
=cQvS
- -----END PGP PUBLIC KEY BLOCK-----

Jonathan Wienke

PGP Key Fingerprints:
7484 2FB7 7588 ACD1  3A8F 778A 7407 2928
3312 6597 8258 9A9E D9FA  4878 C245 D245 EAA7 0DCC

"If ye love wealth greater than liberty, the tranquility of servitude
greater than the animating contest for freedom, go home from us in peace.
We seek not your counsel, nor your arms. Crouch down and lick the hand that
feeds you. May your chains set lightly upon you; and may posterity forget
that ye were our countrymen."
-- Samuel Adams

"Stupidity is the one arena of of human achievement where most people
fulfill their potential."
-- Jonathan Wienke

Never sign a contract that contains the phrase "first-born child."

RSA export-o-matic:
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: Mon, 24 Nov 1997 00:30:29 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
CC: [email-masked]
Subject: Interoperability Policy of PGP Inc Clarified
Sender: [email-masked]

Attached is a conversation between David Sternlight and PGP Inc's Will
Price conducted on mac-crypto (and X-posted by  Bob Hettinga).

I believe this offers sufficient insight into the interoperability issue
to be of importance to this WG.  I am cross-posting without comment for
the moment.

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

At 5:30 PM -0800 11/22/97, David Sternlight wrote:
>And while you're introducing gratuitous issues unrelated to the discussion,
>why did PGP disable RSA key generation in Free PGP 5.0, and remove RSA
>compatibility completely from Free PGP 5.5

Very simple.  How can we with good conscience allow users to generate
keys
which we don't feel meet our security standards?  We can't.  Case
closed.
If you're unfamiliar with why RSA keys are not as secure as we'd like,
you
should check archives of the newsgroups for the past few years.  The
weaknesses of MD5 and the KeyID attacks were the two primary security
issues we felt absolutely had to be addressed in 5.0.  The development
team
couldn't have cared less about RSA licensing issues.  The only issue was
security.  Fixing those required a new key format.  As long as we were
changing the key format, we decided to switch to unencumbered algorithms
at
the same time since the hit was the same either way -- everyone would
need
new keys.  If a particular user doesn't mind the security issues with
RSA
keys, they should feel free to continue using them although the number
of
versions supporting those keys available from us will undoubtedly
continue
to dwindle, and at the same time the number of versions and platforms
supporting DH/DSS keys will continue to grow dramatically.

-Will

Will Price, Architect/Sr. Mgr.
Pretty Good Privacy, Inc.
555 Twin Dolphin Dr, Ste.570
Redwood Shores, CA 94065
Direct (650)596-1956
Main   (650)572-0430
Fax    (650)631-1033
Pager  (310)247-6595
[email-masked]
=====================8<===================

-- 
iang                                      systemics.com

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

Date: Sun, 23 Nov 1997 14:23:43 -0800
To: Ian Brown <[email-masked]>
Cc: IETF OpenPGP <[email-masked]>
Subject: Re: The case against redundancy and isolation
From: Jeremey Barrett <[email-masked]>
Organization: BlueMoney Software Corp.
Sender: [email-masked]

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

Ian Brown writes:
 > > No, Armor doesn't effect the
 > > security of PGP itself, but it does affect how OP products will or
 > > can be used in the "real world" and therefore affects the "level of
 > > security provided by" the PGP system. (if noone used PGP, PGP is still
 > > secure, but the system is not because it isn't used).
 >  
 > Jeremey, you are trying to redefine the meaning of "security of a
 > system". I have never read any security literature which says, for
 > example, "DES is more secure than IDEA because it is more widely
 > used."

Certainly not, I do not mean that PGP is "more secure" because it has
ASCII armoring capability (I thought I made this clear in that
paragraph). 

What I mean is that a communications security system benefits from
wide deployment and use. Re-designing the system in ways that render
previous versions incompatible does not promote security. If there
is a compelling reason to change it (for instance if past versions
had protocol flaws, etc) then so be it, but I see no such reason here.
All I see is 'standardization'. One can provide countless examples
of standardization gone haywire (S/MIME, ASN.1, X.509, SET, etc.) and 
it does not always serve the end goal.

I absolutely agree that support for MIME is important, MIME is a
standard that is widely used. My argument is simply that ASCII armor
is not a transport issue, rather it is an important functionality of
PGP itself.

 > Taking Jon's point: is the ability to do armour critical to an OP
 > implementation on a smartcard, used for example to authenticate a user
 > at login?
 > 

Probably not, I can't see a case where it would be used. This is a 
good point, and makes a strong case for making ASCII armor a SHOULD 
and not a MUST. I wonder how feasible 100% compliance with OP is on 
a smartcard at all, with or without ASCII armor. Unfortunately, I 
think ASCII armor should be a MUST in almost every other case. Hrm.

Jeremey.
- -- 
Jeremey Barrett                                BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems               http://www.bluemoney.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: hand huffman encoding at PGP world HQ
Cc: [email-masked]
Reply-To: [email-masked]
Date: Mon, 24 Nov 1997 11:12:37 (NZDT)
Sender: [email-masked]

>>The last time I vented about this issue (I think on this list) someone
>>relayed that at PGP they had gone stomping around the office singing
>>"every bit you save, we'll be watching you,..." to the tune of the
>>"every move you make, ..." melody.
>A complete fabrication of course.  I've never heard of this nor the perversion
>of it posted by Guttman.  The bit savers in the development group were soundly
>criticized, but by that time it was too late.  Most of this format stuff was
>done before the company was even formed.
 
Just to set the record straight on this:
 
>I concur completely. I once got so fed up with this habit that I tromped
>around the office singing, "Every bit is sacred / Every bit is great / When a
>bit is wasted / Phil gets quite irate."
>
>Consider this to be one of the prime things to correct. Personally, I think
>that numbers should never (well, hardly ever) be smaller than 32 bits.
>
>       Jon
>---
>Jon Callas                                         [email-masked]
>Chief Scientist                                    555 Twin Dolphin Drive
>Pretty Good Privacy, Inc.                          Suite 570
>(415) 596-1960                                     Redwood Shores, CA 94065
 
Could we resolve this by making 32 bits a MUST and the other oddball stuff a
MAY, or a deprecated MAY?  Since the format gives you the option of choosing
what you like, all that's necessary is to deprecate the weird stuff (perhaps
MUST emit 32-bit lengths, MUST read 32-bit lengths, MAY read other types).
 
Peter.

Date: Sun, 23 Nov 1997 13:44:20 -0800
To: [email-masked]
From: Will Price <[email-masked]>
Subject: Re: hand huffman encoding at PGP world HQ
Sender: [email-masked]

At 8:08 AM -0800 11/23/97, Adam Back wrote:
>I just read the draft.  Lots and lots of bit twiddling, 0 < x < 192 if
>this bit is set, then 2 << x-192+y if this bit set, 8 bit proprietry
>floating point format, the legacy length of length bit twiddling (0 in
>two bit field masked out of CTB is 1 byte length field, 1 is 2 byte, 2
>is 3 byte 3 is undefined).
>
>Arrrgh!
>
>All this bit twiddling and little hacks to scrimp on an extra bit here
>and there is dangerous!  Which hacker is it at PGP Inc that thrives on
>these bit twiddling hacks?  Come one 'fess up!

I couldn't agree more with you on this one issue.  I've been saying this
for years.  Unfortunately, I think the point is really moot.  These are
format issues.  The format is already there and you can't really change it
fundamentally without violating the WG charter.

>The last time I vented about this issue (I think on this list) someone
>relayed that at PGP they had gone stomping around the office singing
>"every bit you save, we'll be watching you,..." to the tune of the
>"every move you make, ..." melody.

A complete fabrication of course.  I've never heard of this nor the
perversion of it posted by Guttman.  The bit savers in the development
group were soundly criticized, but by that time it was too late.  Most of
this format stuff was done before the company was even formed.

- -Will

Will Price, Architect/Sr. Mgr.
Pretty Good Privacy, Inc.
555 Twin Dolphin Dr, Ste.570
Redwood Shores, CA 94065
Direct (650)596-1956
Main   (650)572-0430
Fax    (650)631-1033
Pager  (310)247-6595
[email-masked]
Internet Text Paging: <mailto:[email-masked]>
<pgpfone://clotho.pgp.com>
<http://www.pgp.com>

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

Date: Sun, 23 Nov 1997 12:26:08 -0800
To: [email-masked]
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: Armour
Cc: Kent Crispin <[email-masked]>, [email-masked]
Sender: [email-masked]

At 05:29 AM 11/24/97 +1100, David Formosa wrote:
>And consider all the aplications that have been built ontop of PGP.

well, we really are re-cycling arguments.  this one is the compatibility
issue again.

To whit, these seem to be the categories of concerns and their answers:

1.  Technical

    There is no strong argument that either MIME or Armour are superior at
doing protection against the vagaries of transport.

    It is worth noting that Armour combines the control information with
the data, whereas MIME keeps them separate.  This facilitates processing by
recipients who either do not have the necessary security software or who
want to defer its use.  That is, for authenticated data which is not also
encrypted, the main data can be kept cleartext whereas with Armour it is not.

2.  Installed base compatibility

    It has been observed a number of times that that is already lost for
other reasons, so use of MIME rather than Armour does not create a new
problem.

    There needs to be a distinction between pre-standards work, versus
requirements of the standard.  When incorporating existing technology into
the standards process, this is always a challenge.  In this case
standardizing the prior use of armour will prevent PGP from being fully
integrated into the Internet technical suite and would require
implementation of redundant technology.

    The need to document prior use is well served by having an appendix
which describes how to do armouring, for implementations needing to
interwork with pre-standards implementation.

    The argument that it is acceptable to require both or make both
optional misunderstand the additional overhead caused by requiring
redundant mechanisms or the difficulty achieving interworking when
everything is optional.

If there are other categories of argumentation, I've missed them.

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

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re:  hand huffman encoding at PGP world HQ
Cc: [email-masked]
Reply-To: [email-masked]
Date: Mon, 24 Nov 1997 09:08:10 (NZDT)
Sender: [email-masked]

>The last time I vented about this issue (I think on this list) someone
>relayed that at PGP they had gone stomping around the office singing
>"every bit you save, we'll be watching you,..." to the tune of the
>"every move you make, ..." melody.
 
It was "Every bit is sacred, every bit is great, if a bit gets wasted, Phil 
gets quite irate", but your suggestion is equally appropriate.
 
>I hereby call for length fields to be universally encoded as a 32 bit 
>integer.  And all the above bit twiddling to be trashed.  Relegate LOL 
>(length of length) and all the other length bit twiddling to MAY for 
>backwards compatibility.
>
>I would also argue for scrapping the non standard CFB hack (resyncing on 
>semantic boundaries) and putting in place standard cipher-block-sized CFB.
 
I agree with both of these in principle, but how much hassle will it cause for 
implementors (and existing users)?  If you do this then you're completely 
breaking compatibility with existing implementations, in which case you may as 
well do it properly and use ASN.1 or something similar which allows you to 
write a very precise definition of the message format which is simultaneously 
usable as the input to a parser which interprets the format.  At the moment 
every PGP implementation has to be hand-coded and tuned, creating the 
potential for any number of bugs and problems, as Adam has pointed out.

(The 32-bit fixed length may be a problem in the future when files grow over 
 4GB.  Can the PGP encoding handle > 4GB data units at all?).
 
It depends on how essential backwards compatibility is - if you're going to 
break it, it would be nice to move other things more into line with what the 
rest of the world is doing (eg use real X.509v3 cert extensions rather than 
trying to reinvent them yourself and ending up with something which is 
functionally identical to, but completely incompatible with, the X.509 certs 
which everyone else uses).
 
Peter.

Date: Mon, 24 Nov 1997 05:29:10 +1100 (EST)
From: David Formosa <[email-masked]>
Reply-To: [email-masked]
To: Kent Crispin <[email-masked]>
cc: [email-masked]
Subject: Re: Armour
Sender: [email-masked]

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

On Fri, 21 Nov 1997, Kent Crispin wrote:

> On Fri, Nov 21, 1997 at 01:27:38PM -0800, Dave Crocker / IMC wrote:

[...]

> In particular, the fact that simple MUA interfaces appear in many many
> scripts, cgi programs, and so on virtually guarantees a 10 year 
> lifetime.  So think about the following:
> 
> 	mail $user <$file
> 
> Imagine it is embedded in a cgi script, possibly sending a requested 
> file to a user.  How do I leave an encrypted file on disk so it can 
> be sent?

And consider all the aplications that have been built ontop of PGP.
Things such as anon-remailers, secure (new|rm)group commands, NoCeM
implentations ect.  All of wich will have to be converted over to MIME,
this makes Ascii armor a MUST for the forseeable future.

- -- 
Please excuse my spelling as I suffer from agraphia see the url in my header. 

Date: Sun, 23 Nov 1997 18:27:21 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Adam Back <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: case for removing subpacket type 10
Sender: [email-masked]

Adam Back wrote:

> > The bad news is that, while the Criticality Bit is only sketchily
> > documented, it sounds like part of a CMRist plot, to make use of the
> > ARR mandatory if the recipient requests it
> 
> I see the problem -- ouch -- if a vendor choses to, they can make
> their software mark ARRs as critical and old software will say that
> the self signature failed.  Which could result in the software not
> using the key.
> 
> I think the fact that doing so introduces compatibility problems
> protects us from this happening, a vendor's corporate customers may
> get irate when they are unable to communicate with OpenPGP compliant
> implementations due to such a purposely introduced incompatibility.

Nope, just the reverse.  Your comment above has helped me see what Bill
was talking about.

Introducing compatibility problems in this way can be solved by
upgrading to the latest release, so it becomes a tool for migrating your
user base onto the new software.  The technique is to make the software
basically work, so as to limit the downside.  MS are the masters of
knowing which bugs not to fix.  Mathematically, look to epidemic theory,
which says something to the effect that if each instance causes k people
to upgrade, where k is some number greater than 1 (i.e., 1.1) then it
will work.  Of course, it also works a lot better if you can offer a few
new features with the upgrade.

This is not the effect that is occurring with the pgp5.0, as that has
IMHO failed, because it is practically incompatible.  I'm not saying
pgp5 has failed, just that you need to consider other models.  The
result with pgp5.0 is that if you upgrade, you won't be able to talk to
all your non-upgraded contacts at all, so you won't upgrade.  (I'm not
entirely sure what is going on here, but I think what happens is that as
soon as the RSA keys get any of the extra packets added to them, it
appears that 2.6 will reject them in a variety of ways.  I've tried with
3 different people to get comms between 2.6 (and Cryptix) and pgp5.0. 
No joy yet.).

In the case of the Criticality bit, you will still have comms, but the
various MUAs will alert you to problems, which is ideal.  No loss of
functionality, but an annoying reminder to upgrade every time you talk
to  someone :-)   On this basis alone, I think we'd like to avoid a
standardised "please upgrade me" virus.

I think the issue here surrounds the nature of the extension.  Normally,
if one wanted to hack in and add the <i>whatiwant</i> feature, one would
do it in such a way that the feature was innocuous to older
non-conforming software.  So the feature has to be an addition, without
which the sum is unchanged from the older standard.

In the new packets as discussed here, the PGP Inc whatiwant feature is a
*subtraction* in that it applies some limit to the power of the
signature.  Now, you can't take something away, and then put it back
whilst talking to those that don't understand the new mathematics.  PGP
Inc people have recognised this, and have added an additional feature
that says "on any subtraction, reject the lot."  If everybody
understands that there is a subtraction going on, then at least if they
can't put back that which was lost, then they can consider the whole
things broken.

Hal said:
        - On a self-signature, ignore the key if you don't understand
the
          subpacket type.  This is because the self-signature may be
          saying something important qualifying the meaning of the key
or
          how it is intended to be used by the owner.  If you don't know
          what he's saying, it's safest not to use the key.

This is trouble piled upon trouble.  Trying to set this sort of
behaviour up in complex software is tricky, and is best avoided unless
you're well paid to do precisely that (and I hope the folks at PGP Inc
are indeed well paid).  Putting it into a standard is equivalent to
institutionalising software failures.

I would suggest that the Criticality bit be dropped.

> > (there _is_ the semantics issue of what the program should do if it
> > understands the Additional Recipient Request and doesn't feel like
> > cooperating :-)
> 
> Well a cypherpunk or pro privacy advocate's PGP patch / implementation
> can do one of a number of things:

Precisely.

-- 
iang                                      systemics.com

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

Date: Sun, 23 Nov 1997 18:20:55 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Adam Back <[email-masked]>
CC: [email-masked]
Subject: Re: hand huffman encoding at PGP world HQ
Sender: [email-masked]

Adam Back wrote:
> 
> I just read the draft.  Lots and lots of bit twiddling, 0 < x < 192 if
> this bit is set, then 2 << x-192+y if this bit set, 8 bit proprietry
> floating point format, the legacy length of length bit twiddling (0 in
> two bit field masked out of CTB is 1 byte length field, 1 is 2 byte, 2
> is 3 byte 3 is undefined).
> 
> Arrrgh!
> 
> All this bit twiddling and little hacks to scrimp on an extra bit here
> and there is dangerous!  Which hacker is it at PGP Inc that thrives on
> these bit twiddling hacks?  Come one 'fess up!

To be fair, when pgp[12].x was being hacked up, modems where slow, the
Internet was still non-commercial, hacker power rulze OK.  The whole net
was singing "every bit you save, we'll be watching you,..."

It's also true that PGP Inc still believe that bit-saving is a Good
Thing; someone on mac-crypto is arguing (Will Price?) that S/MIME is bad
because it has sigs in the two to ten K range, in complete contrast to
the lessons of Microsoft and the Internet.

Simplifying the structure and so forth is a good idea.  I wish.  But you
are arguing for a new standard that would be completely non-compatible. 
It's logical that you would argue that a minimal implementation such as
this would only include pgp2.6 compatibility, and even pgp5.x
compatibility, as a may.

Many have argued on this list for this sort of thing, and maybe it is
time to reverse the opportunity versus interoperability priorities.

Maybe it is time to recognise that the Open PGP result will be
incompatible with the user base, and no holds are barred.  That the
current software base is not suitable for standardisation.

>From a commercial point of view this is very attractive.  Rewrite from
the ground up makes more sense, as I agree with you that the cost of
implementating a simple  standard from scratch is less than the cost of
implementing the pgp5.x model.  Then, introduce a compatibility hack
using pgp2.6 for the "classic" segment (if you can, simply invoke the
old pgp.  Guarunteed interoperability :-) .

There is an issue here on commercial grounds that will probably provoke
some interesting discussions.
-- 
iang                                      systemics.com

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

Date: Sun, 23 Nov 1997 17:58:43 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
Subject: Re: why MIME in the standard?
Sender: [email-masked]

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.

-- 
iang                                      systemics.com

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

Date: Sun, 23 Nov 1997 09:44:21 -0800
To: Kent Crispin <[email-masked]>
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: The case against redundancy and isolation
Cc: IETF OpenPGP <[email-masked]>
Sender: [email-masked]

At 06:18 AM 11/23/97 -0800, Kent Crispin wrote:
>If the mailer does all the work for you, then why argue that mime is
>necessary as a part of the OP spec? I don't mean that to be flip; I am

Kent, et al,

One of the problems in this discussion is that we seem to have a collection
of people lobbying hard for a particular position, without having
sufficient technical understanding of the position they are arguing
against.  This means that what is really needed is a tutorial, rather than
a debate.  Tutorials are fine, but not in the middle of a debate.

In this case, the tutorial is about the basics of specifying MIME usage.

First, "the mailer" does not do all the work for you.  When you define a
new kind of data you must specify details about the way MIME is used for
that object, in particular naming the content type and any associated
parameters, as well as the likely need for content transfer encoding.

When the object gets interesting, you also need to specify whether it is
treated as monolithic, with a single MIME wrapper around it or whether it
is separated into pieces, using MIME's Multipart mechanism.

"The work" that mailers can do, now, is that they already have all the code
for parsing and dispatching these issues.  If they must support armour,
they must add code for it, yet it is entirely redundant with the services
provided by MIME.

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

Date: Sun, 23 Nov 1997 16:59:15 +0000
From: Ian Brown <[email-masked]>
To: Adam Back <[email-masked]>
CC: IETF OpenPGP <[email-masked]>
Subject: Re: hand huffman encoding at PGP world HQ
Sender: [email-masked]

I also absolutely agree with Adam's suggestion of simplifying data
structures. I'm just starting to implement PGP 5 packets; they are
*horrendously* over-complicated by the facts Adam mentioned. As he has
said before, "bits are cheap" - we can spare a few here and there ;-)

A scheme with "32 bit length fields, whole byte (gasp the extravagance,
a whole 8 bits!) packet types, 64 bit CFB etc." would be much easier for
new implementors. Using standard cipher-block-sized CFB would make it
*much* easier for people to implement PGP with any of the crypto
libraries springing up, without requiring said libraries to do
non-standard encryption modes. It may also reassure relatively new
crypto people that we are not doing anything 'funny' which may
compromise security. (I know we're not, but it's easier to explain to
someone who doesn't know that if you can simply point to a page in
Schneier).

Of course keep the description of the current system for backward
compatibility as a MAY. But to quote Dave Crocker yet again ;-), we can
view our nascent standard's non-MUST backward compatibility as a problem
or an opportunity. I think we should seize this opportunity now while we
have the chance.

Ian.

Date: Sun, 23 Nov 1997 16:47:43 +0000
From: Ian Brown <[email-masked]>
To: Adam Back <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: case for removing subpacket type 10
Sender: [email-masked]

> OK: so I call for subpacket 10 to be removed.  Anyone else?

I second that.

Ian.

Date: Sun, 23 Nov 1997 16:37:04 +0000
From: Ian Brown <[email-masked]>
To: Kent Crispin <[email-masked]>
CC: IETF OpenPGP <[email-masked]>, Adam Back <[email-masked]>
Subject: Re: The case against redundancy and isolation
Sender: [email-masked]

Kent Crispin wrote:

> If the mailer does all the work for you, then why argue that mime is
> necessary as a part of the OP spec? I don't mean that to be flip; I am
> asking for actual technical reasoning, maybe even with a concrete
> example.  How, precisely, do you imagine OP interacting with a mime
> mailer such that OP has to know mime?

I absolutely agree, Kent. This is the beauty of the MIME solution - it
doesn't need to be part of the standard at all, apart from labelling the
content-types - and that can go in OP-MIME instead. 

As Dave Crocker said, we can leave the 7-bit encoding functionality to
MIME and concentrate on the security of the underlying binary data.

Adam Back wrote:

> However, there is another 7 bit transport problem which gets solved by
> ascii armor currently: cut and paste operations on keys, eg look up on
> a keyserver manually, or via finger, or appended to a mail.
> 
> This could actually be acheived with MIME in place of armor -- just
> include the Content-Type: headers and skip the checksum, and it's
> basically the same thing.
> 
> This would then need minimal MIME handling ability within the standard
> and an implementation -- to be able to accept MIMEd key packets.

There is actually already an application/pgp-keys content-type defined
in PGP/MIME. Therefore, we can do the key-acceptance process even more
easily than PGP 5 makes it (adding keys via the clipboard).

Your mailer simply needs to be configured to use PGP as the "viewer" for
an application/pgp-keys bodypart. The mailer could remove the MIME
encoding and run PGP with the binary key data as input. PGP would
recognise this and add the key. This would work just as well with
keyserver output - when you retrieved a key, you wouldn't need to cut
and paste it from your browser, the browser itself would run PGP on the
key data.

Ian.

Date: Sun, 23 Nov 1997 15:40:03 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: why MIME in the standard?
Sender: [email-masked]

Kent Crispin <[email-masked]> writes:
> On Sun, Nov 23, 1997 at 12:40:33PM +0000, Ian Brown wrote:
> [...]
> > MIME 1) already exists, 2) is far more widely used than Armor, and 3)
> > won't need to be implemented by an OP-MIME system as the mailer will do
> > the work for you.
> 
> If the mailer does all the work for you, then why argue that mime is
> necessary as a part of the OP spec? I don't mean that to be flip; I am
> asking for actual technical reasoning, maybe even with a concrete
> example.  How, precisely, do you imagine OP interacting with a mime
> mailer such that OP has to know mime?

I think that is a good point, and that for the purposes of mailer
integration MIME could be defined to be outside the standard.

Armor could then be the MAY legacy backwards compatibility mode for
people who are not yet using a MIME aware mailer.

However, there is another 7 bit transport problem which gets solved by
ascii armor currently: cut and paste operations on keys, eg look up on
a keyserver manually, or via finger, or appended to a mail.

This could actually be acheived with MIME in place of armor -- just
include the Content-Type: headers and skip the checksum, and it's
basically the same thing.

This would then need minimal MIME handling ability within the standard
and an implementation -- to be able to accept MIMEd key packets.

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.

Adam

Date: Sun, 23 Nov 1997 16:08:14 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
Subject: hand huffman encoding at PGP world HQ
Sender: [email-masked]

I just read the draft.  Lots and lots of bit twiddling, 0 < x < 192 if
this bit is set, then 2 << x-192+y if this bit set, 8 bit proprietry
floating point format, the legacy length of length bit twiddling (0 in
two bit field masked out of CTB is 1 byte length field, 1 is 2 byte, 2
is 3 byte 3 is undefined).

Arrrgh!

All this bit twiddling and little hacks to scrimp on an extra bit here
and there is dangerous!  Which hacker is it at PGP Inc that thrives on
these bit twiddling hacks?  Come one 'fess up!

It adds complexity all over the place, introduces numerous extra
branches and possible failure points in the code... the likely coding
failures could turn out to adversely affect security.

To test all of the decision points in your software to check for
correct operation, you construct test messages, and run a test job to
exercise branches -- with all the extra conditions and combinations
introduced by the bit twiddling it adds significant extra risk of a
coding error slipping through.

Also (thinking of the notional smart card hacker that Jon mentioned)
bit twiddling causes code bloat, and performance degradation.

Simplicity is important for security software.  Add no more complexity
than absolutely necessary.

Simplicity is also important if we want people to implement to the
standard.

I hereby call for length fields to be universally encoded as a 32 bit
integer.  And all the above bit twiddling to be trashed.  Relegate LOL
(length of length) and all the other length bit twiddling to MAY for
backwards compatibility.

I would also argue for scrapping the non standard CFB hack (resyncing
on semantic boundaries) and putting in place standard
cipher-block-sized CFB.

I'll relay a little hacking I did.  I coded up an RSA and IDEA
encryption app.  I did the obvious things, used 32 bit length fields,
whole byte (gasp the extravagance, a whole 8 bits!) packet types, 64
bit CFB etc.  I used bits of SSLeay for bigints, the rest I coded
myself.  Took me about a week in total.

It took me as long to frig with the bit twiddling that gives the
bit-fetishist at PGP jollies (and diddling with the non standard CFB
mode) to get it so that PGP could decode conventional encrypted
messages my app created as it did to code the app!

I expect other people will rediscover this experience if we keep this
hand huffman encoding mentality in the standard.

The last time I vented about this issue (I think on this list) someone
relayed that at PGP they had gone stomping around the office singing
"every bit you save, we'll be watching you,..." to the tune of the
"every move you make, ..." melody.

Adam

Date: Sun, 23 Nov 1997 15:24:21 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: case for removing subpacket type 10
Sender: [email-masked]

Bill Stewart <[email-masked]> writes:
> So the Infamous Additional Recipient Request is just a subpacket of
> known length, in a table of zero or more extension-like subpackets,
> and the description of the Criticality Bit seems to imply that it's
> ok to have subpacket types that aren't recognized and can be skipped
> over because their lengths are known.  So that's the good news.

Seems to me that there is no problem at all just removing subpacket
type 10 (the ARR/CMR subpacket).  The draft already says that if an
unrecognised subpacket is present in a self signature that it will be
ignored.  This is obviously needed to allow backwards compatibility
when new subpackets are introduced.

OK: so I call for subpacket 10 to be removed.  Anyone else?

> The bad news is that, while the Criticality Bit is only sketchily
> documented, it sounds like part of a CMRist plot, to make use of the
> ARR mandatory if the recipient requests it

I see the problem -- ouch -- if a vendor choses to, they can make
their software mark ARRs as critical and old software will say that
the self signature failed.  Which could result in the software not
using the key.

I think the fact that doing so introduces compatibility problems
protects us from this happening, a vendor's corporate customers may
get irate when they are unable to communicate with OpenPGP compliant
implementations due to such a purposely introduced incompatibility.

> (there _is_ the semantics issue of what the program should do if it
> understands the Additional Recipient Request and doesn't feel like
> cooperating :-)

Well a cypherpunk or pro privacy advocate's PGP patch / implementation
can do one of a number of things:

a) as a special case ignore the criticality bit if combined with
   subpacket type 10 (ARR/CMR)

b) pretend to capitulate with the "request" and stuff garbage in the
   extra PKE field instead of the session key; this will fool a policy
   enforcer policeman software which doesn't have the private key.

c) capitulate and include a valid extra PKE field but automatically
   super encrypt to the real key holder only (optionally pad with a
   bit of garbage and white space to allow easy reconstruction with
   cut and paste, but to make auto detection difficult).

Adam

Date: Sun, 23 Nov 1997 06:18:08 -0800
From: Kent Crispin <[email-masked]>
To: IETF OpenPGP <[email-masked]>
Subject: Re: The case against redundancy and isolation
Sender: [email-masked]

On Sun, Nov 23, 1997 at 12:40:33PM +0000, Ian Brown wrote:
[...]
> MIME 1) already exists, 2) is far more widely used than Armor, and 3)
> won't need to be implemented by an OP-MIME system as the mailer will do
> the work for you.

If the mailer does all the work for you, then why argue that mime is
necessary as a part of the OP spec? I don't mean that to be flip; I am
asking for actual technical reasoning, maybe even with a concrete
example.  How, precisely, do you imagine OP interacting with a mime
mailer such that OP has to know mime?

-- 
Kent Crispin				"No reason to get excited",
[email-masked]			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

Date: Sun, 23 Nov 1997 12:40:33 +0000
From: Ian Brown <[email-masked]>
To: Jeremey Barrett <[email-masked]>
CC: IETF OpenPGP <[email-masked]>
Subject: Re: The case against redundancy and isolation
Sender: [email-masked]

> No, Armor doesn't effect the
> security of PGP itself, but it does affect how OP products will or
> can be used in the "real world" and therefore affects the "level of
> security provided by" the PGP system. (if noone used PGP, PGP is still
> secure, but the system is not because it isn't used).
 
Jeremey, you are trying to redefine the meaning of "security of a
system". I have never read any security literature which says, for
example, "DES is more secure than IDEA because it is more widely used."

Even accepting your redefinition, making armour a MUST increases the
effort needed to implement an OP-compatible system, so will reduce the
use of the standard - thus reducing its 'security'.

> It is reasonably easy to go
> get a new version of PGP which doesn't use RSA or IDEA, or doesn't
> default to them. You don't have to change the way you "do things" to
> switch to ElGamal and CAST. MIME is different, because it is external
> to PGP.

And, as Dave Crocker has had to say over and over again, MIME is
becoming very widely used in mailers. The vast majority of people don't
even need to go out and get a new mailer to take advantage of it.

> ASCII armor 1) already exists, 2) is widely used, and 3) is
> quite trivial to implement

MIME 1) already exists, 2) is far more widely used than Armor, and 3)
won't need to be implemented by an OP-MIME system as the mailer will do
the work for you.

> My point is that the capacity for
> 7-bit encoding is critical to PGP, and all OP-compliant products
> should provide it regardless of what other 7-bit transport schemes
> are supported.

Taking Jon's point: is the ability to do armour critical to an OP
implementation on a smartcard, used for example to authenticate a user
at login?

> I don't have
> LDAP in my mail reader. Neither does anyone else, with the exception
> of Netscape and Micro$oft users.

Totally irrelevant to the argument.

Regards,

Ian.

Date: Sat, 22 Nov 1997 23:03:13 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: CMR as an extension _inside_ the standard (Re: CMR & ROT-13)
Sender: [email-masked]

Bill Stewart writes, regarding signature subpackets:

> 		2  - signature creation time  [And a bunch of similar good entries]
> 		4  - exportable [This isn't ITAR - this indicates whether
> 			the signature can be transmitted to other people or is
> 			for your own use only.  So don't panic :-)]
> 		10 - The Infamous Additional Recipient Request 
> 		16 - Issuer KeyID - Sounds Ominous and Not documented!

Issuer keyid is what tells you who issued the signature.  This information
is in V3 signatures as well.

> 		12 - Revocation Key - Only for self-signatures(??)
> 			so you can revoke your key after losing your key
> 		21 - Preferred hash algorithms
> 		22 - Preferred compression algorithms
> 		23 - key server preferences
> 		24 - preferred key server - presumably the Signer's preference
> 			for finding further data about the Signer's key?
> 	Bit 7    - Criticality Bit - [Semantics: I don't quite understand it?	
> 			Reject Key If you don't support the Subpacket Type,
> 			or reject the signature rather than the whole key?]

The criticality bit is intended to have two different meanings:

	- On a self-signature, ignore the key if you don't understand the
	  subpacket type.  This is because the self-signature may be
	  saying something important qualifying the meaning of the key or
	  how it is intended to be used by the owner.  If you don't know
	  what he's saying, it's safest not to use the key.

	- On other signatures, ignore the signature if you don't understand
	  the subpacket type.  The idea is that you understand the uses of
	  the key that the owner specifies, but you don't understand what
	  someone else is saying about the key.  You ignore the whole
	  signature by this other person because the subpacket may qualify
	  the meaning of the signature (it may not be an identity
	  signature, for example).

> So the Infamous Additional Recipient Request is just a subpacket of known length,
> in a table of zero or more extension-like subpackets,
> and the description of the Criticality Bit seems to imply that it's
> ok to have subpacket types that aren't recognized
> and can be skipped over because their lengths are known.
> So that's the good news.
>
> The bad news is that, while the Criticality Bit is only sketchily documented,
> it sounds like part of a CMRist plot, to make use of the ARR mandatory if the
> recipient requests it (there _is_ the semantics issue of what the program
> should do if it understands the Additional Recipient Request and doesn't
> feel like cooperating :-)

The critical bit is intended to provide guidelines for the case where you
don't recognize the subpacket type.  It does not apply to cases where you
recognize the subpacket but are choosing to ignore it.  So it is irrelevant
to the issue of the ARR subpacket.

> The ugly news is that Additional Recipient Requests are a really weird thing
> to attach to a signature, rather than part of the key itself - 
> I suppose that makes it easier for the Corporate Security Bureaucrats to request,
> rather than having some special case part of the key generation, which would
> be uglier, but it's still a strange place to put it.  

Putting information in a self-signature allows the user to modify it
without invalidating all of the other signatures he has collected on
his key.  Preferred algorithms are another example where this may be
very useful.

> But in conjunction with the Criticality Bit, this extension method is a
> Denial Of Service Attack - unless I'm misunderstanding the bit,
> if the bit is set and the subpacket type is unrecognized, the recipient
> is supposed to reject the entire key packet and not just the signature packet -
> does this mean that somebody can sign your key with a Critically Bogus Subpacket
> and prevent anybody from using your key?  (e.g. by signing a keyserver key...)

No, because this would be the second case above.  All they can do is to
make you ignore their signature, so they would accomplish nothing by it.

Hal

Date: Sun, 23 Nov 1997 06:35:30 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Bill Stewart <[email-masked]>
CC: [email-masked], [email-masked], Adam Back <[email-masked]>
Subject: Re: CMR as an extension _inside_ the standard (Re: CMR &   ROT-13)
Sender: [email-masked]

Bill Stewart wrote:

> Jon's done a great job on the standard - I still find it hard to read,
> partly because it's bottom-up rather than top-down, which makes it
> easier to follow syntax and harder to follow semantics, and partly because
> there's just a _lot_ of detail, and the newer features are pretty complex.

Yes, I was always afraid of that, which was part of the reason I was
concerned at getting the document out there.  To be fair it was never
likely to be anything else, as the architecture of PGP evolved from
mysterious roots into the beast we now know and love.

I hope there is time left after these other discussions going on for the
WG to actually read the standard.

> But if I do understand what's going on, the CMR support is just one entry
> in a table that's needed anyway, plus a paragraph of apologies (:-),
> and may be the primary motivation for one other feature.
> 
> If I can modifiy Jon's syntax description a bit:
> A Packet is a record containing the following in a tersely encoded format (:-)

I'm sure ASN.1 would have been terser :-)

>         Packet Tag    - indicates packet type, 0-15 (old) or 0-63 (new)
...

> A Subpacket - [!!! FINALLY - THE FUN PART !!!]
>         Subpacket Length - (packed, one or two octets)
>         Subpacket Type-And-Criticality-Indicator - Octet
>         Subpacket Body - format is Subpacket Type dependent.
> A Subpacket-Type-And-Criticality-Indicator Octet
>         Bits 0-6 - Subpacket Type, an entry from a table including
...
>                 10 - The Infamous Additional Recipient Request
>                 16 - Issuer KeyID - Sounds Ominous and Not documented!
>                 12 - Revocation Key - Only for self-signatures(??)
>                         so you can revoke your key after losing your key
>                 21 - Preferred hash algorithms
>                 22 - Preferred compression algorithms
>                 23 - key server preferences
>                 24 - preferred key server - presumably the Signer's preference
>                         for finding further data about the Signer's key?
>         Bit 7    - Criticality Bit - [Semantics: I don't quite understand it?
>                         Reject Key If you don't support the Subpacket Type,
>                         or reject the signature rather than the whole key?]
> 
> So the Infamous Additional Recipient Request is just a subpacket of known length,
> in a table of zero or more extension-like subpackets,
> and the description of the Criticality Bit seems to imply that it's
> ok to have subpacket types that aren't recognized
> and can be skipped over because their lengths are known.
> So that's the good news.

In a sense what you are proposing is that sub packet 10 is reserved, has
a length for skipping reasons, but no more.  Yet another RFU number? 
I'll have to think about that (it took me about two weeks to develop my
argument in the previous post - it's tricky stuff).

> The bad news is that, while the Criticality Bit is only sketchily documented,
> it sounds like part of a CMRist plot, to make use of the ARR mandatory if the
> recipient requests it (there _is_ the semantics issue of what the program
> should do if it understands the Additional Recipient Request and doesn't
> feel like cooperating :-)

And the notion that one would not support the subpacket but would
support the bit - which you develop further below.  I feel this is
intuitively a non-starter.  Once a progammer (or whoever) decides the
subpacket(s) are not supported, then it is most likely the bit will be
ignored, just from the human effort of trying to work out what the
semantics of taking instructions from something you don't understand
are.

> The ugly news is that Additional Recipient Requests are a really weird thing
> to attach to a signature, rather than part of the key itself -
> I suppose that makes it easier for the Corporate Security Bureaucrats to request,
> rather than having some special case part of the key generation, which would
> be uglier, but it's still a strange place to put it.

I guess this is a consequence of asking the respondent to participate in
your recovery needs.  Always likely to be clumsy as it bears no
relationship to normal communications models.  The only model where I
can think of the respondent needing to play a part is secrets security,
where everyone is   encouraged to report comrades with treacherous
thoughts.

I suppose the effect looked for is that the recoveree initiator should
sign their willfull acceptance so that the accessory responder can
authenticate the entrance of the recoveror into the protocol.  The
special black box secret key generation methods would have been more
robust.

What I find the weirdest is that this system is at least deployed in
test arenas, and for all we know in real customer sites.  Somehow, the
software engineering difficulties have been overcome, but I couldn't
begin to work out the ramifications of such.  Auditing, provability,
reliability, ...  my bind moggles!

> But in conjunction with the Criticality Bit, this extension method is a
> Denial Of Service Attack - unless I'm misunderstanding the bit,
> if the bit is set and the subpacket type is unrecognized, the recipient
> is supposed to reject the entire key packet and not just the signature packet -
> does this mean that somebody can sign your key with a Critically Bogus Subpacket
> and prevent anybody from using your key?  (e.g. by signing a keyserver key...)

Highly amusing :-) I'm sure there is an explanation on its way.  In the
meantime, one could try it.  I believe that pgp5.0 supports all the
above fields, and there are keyservers.

Well spotted!  Thinking about it, there's something odd in the way the
signature tells the software where to pick up the key to check the
signature...

-- 
iang                                      systemics.com

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

Date: Sat, 22 Nov 1997 21:46:23 -0800
To: Lindsay Mathieson <[email-masked]>
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: The case against redundancy and isolation
Cc: Ian Brown <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

At 03:43 AM 11/23/97 +0000, Lindsay Mathieson wrote:
>>From your points (not quoted) I would assume you prefer the option of
>basically ignoring the Armour issue - leave it documented and as a MAY. I
>would prefer that myself. It keeps the spec simple and fast out the door.

It is unlikely that the work of the group with be either useful or
acceptable if it ignores specification of at least one "transport"
environment, such as for email or the web.

The reason for pressing the point about full and legitimate integration
with MIME is that it takes care of at least two major Internet application
environments at the same time.

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

Date: Sat, 22 Nov 1997 20:54:01 -0800
To: [email-masked], [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: CMR as an extension _inside_ the standard (Re: CMR & ROT-13)
Cc: Adam Back <[email-masked]>, [email-masked]
Sender: [email-masked]

>> That leaves us with the fourth option.  Say nothing and do not document it.
>> This of course will be problematic for programmers, as they test their
>> code against 5.x, and discover the strange packets.  

It may be that it doesn't cause a problem.

Jon's done a great job on the standard - I still find it hard to read,
partly because it's bottom-up rather than top-down, which makes it
easier to follow syntax and harder to follow semantics, and partly because
there's just a _lot_ of detail, and the newer features are pretty complex.
But if I do understand what's going on, the CMR support is just one entry
in a table that's needed anyway, plus a paragraph of apologies (:-),
and may be the primary motivation for one other feature.

If I can modifiy Jon's syntax description a bit:
A Packet is a record containing the following in a tersely encoded format (:-)
	Packet Tag    - indicates packet type, 0-15 (old) or 0-63 (new)
	Packet Length - optionally indeterminate
	Packet Body   - format and semantics depend on Packet Tag
A Transferable Key Packet probably has Public Key syntax Packet Tag = 6?
A Transferable Key Packet has
	One Public Key Packet
	Zero or more revocation signatures
	One or more User-ID-With-Optional-Signatures entities
	Zero or more Subkey-With-Signature entities
		["entity" isn't a PGP Packet format, 
		it's a group of packets I've defined for
		increased syntactical precision]
A User-ID-With-Optional-Signatures entity is
	One UserID Packet
	Zero or more Signature_Packets
		[Semantics: These signature packets each sign the 
		concatenation of the public key, the user id, and signature info.]
A Subkey-With-Signature entity is
	One Subkey Packet
	Maybe[??] zero or more subkey revocation packets[??]
	One or more Signature_Packets
		[Semantics: These signature packets each sign the 
		concatenation of the public key, the subkey, and signature info.]
A Signature_Packet is a packet with PacketTag=2, 
	either Version 3 or Version 4 Signature Packet Format
A Version 4 Signature Packet contains
	Version Number (octet = 4)
	Signature Type (octet - e.g. binary, text, several keycerts, revocations)
	Public Key Algorithm (octet - e.g. RSA, DSA, EG, ...)
	Hash Algorithm (octet - e.g. SHA-1, MD5, RIPEMD-160, ...)
	Octet Count for following hashed subpacket data (2 octets, weird format)
	Subpacket_Data_Entity - gets hashed
	Octet Count for following unhashed subpacket data (2 octets, weird format)
	Subpacket_Data_Entity - doesn't get hashed
	Left-16-bits-of-signed-hash-value Field - for checking success
	Signature - Algorithm-specific collection of multi-precision integers
A Subpacket_Data_Entity - [My term.  Draft section 5.2.2.1]
	Length-Of-Subpacket-Set (two octets, probably packed format?)
	Zero or More Subpackets 
A Subpacket - [!!! FINALLY - THE FUN PART !!!]
	Subpacket Length - (packed, one or two octets)
	Subpacket Type-And-Criticality-Indicator - Octet
	Subpacket Body - format is Subpacket Type dependent.
A Subpacket-Type-And-Criticality-Indicator Octet
	Bits 0-6 - Subpacket Type, an entry from a table including
		2  - signature creation time  [And a bunch of similar good entries]
		4  - exportable [This isn't ITAR - this indicates whether
			the signature can be transmitted to other people or is
			for your own use only.  So don't panic :-)]
		10 - The Infamous Additional Recipient Request 
		16 - Issuer KeyID - Sounds Ominous and Not documented!
		12 - Revocation Key - Only for self-signatures(??)
			so you can revoke your key after losing your key
		21 - Preferred hash algorithms
		22 - Preferred compression algorithms
		23 - key server preferences
		24 - preferred key server - presumably the Signer's preference
			for finding further data about the Signer's key?
	Bit 7    - Criticality Bit - [Semantics: I don't quite understand it?	
			Reject Key If you don't support the Subpacket Type,
			or reject the signature rather than the whole key?]

So the Infamous Additional Recipient Request is just a subpacket of known length,
in a table of zero or more extension-like subpackets,
and the description of the Criticality Bit seems to imply that it's
ok to have subpacket types that aren't recognized
and can be skipped over because their lengths are known.
So that's the good news.

The bad news is that, while the Criticality Bit is only sketchily documented,
it sounds like part of a CMRist plot, to make use of the ARR mandatory if the
recipient requests it (there _is_ the semantics issue of what the program
should do if it understands the Additional Recipient Request and doesn't
feel like cooperating :-)

The ugly news is that Additional Recipient Requests are a really weird thing
to attach to a signature, rather than part of the key itself - 
I suppose that makes it easier for the Corporate Security Bureaucrats to request,
rather than having some special case part of the key generation, which would
be uglier, but it's still a strange place to put it.  

But in conjunction with the Criticality Bit, this extension method is a
Denial Of Service Attack - unless I'm misunderstanding the bit,
if the bit is set and the subpacket type is unrecognized, the recipient
is supposed to reject the entire key packet and not just the signature packet -
does this mean that somebody can sign your key with a Critically Bogus Subpacket
and prevent anybody from using your key?  (e.g. by signing a keyserver key...)

				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: 23 Nov 1997 3:43:17 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: The case against redundancy and isolation
To: Ian Brown <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>As Dave said, I think this argument is just going round in circles 
>now.
>We seem to have clarified at least some points. I believe none of the
>following is contentious:

>From your points (not quoted) I would assume you prefer the option of
basically ignoring the Armour issue - leave it documented and as a MAY. I
would prefer that myself. It keeps the spec simple and fast out the door.

We are in danger of getting into discussion on how PGP objects are
transported, which I believe is best left to other groups/specs.
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Beta Vs 2.6.1.2, on November 23, 1997, in Win95 4.0
	http://www.blackpaw.com/

Date: Sun, 23 Nov 1997 12:08:06 +1100 (EST)
From: David Formosa <[email-masked]>
Reply-To: [email-masked]
To: Ian Grigg <[email-masked]>
cc: [email-masked]
Subject: Re: CMR & ROT-13 (Re: Draft comments)
Sender: [email-masked]

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

On Fri, 21 Nov 1997, Ian Grigg wrote:

[...]

> > > 6.2   - I know the inclusion of ROT-n started as a joke - but it's in
> > > there! Eeeek!
> > 
> > I thought Jon was joking about these!  Remove at once please!
> 
> Yes, there should be no weakness.  I know ROT-n is a joke to some, but
> if Caeser used it, then so can others.  If a test case is needed, it
> should be plain and open.  Not that I think one is.

I too can see a need for something like ROT-n for testinng.  As PGP is not
just an encytion system but also has key manigment, signing ascii armore
ect it would be usefull to be able to sepreate off one part of the system
with know working code.

- -- 
Please excuse my spelling as I suffer from agraphia see the url in my header. 
Never trust a country with more peaple then sheep.  ex-net.scum and proud
You Say To People "Throw Off Your Chains" And They Make New Chains For
Themselves? --Terry Pratchett.  I do not reply to munged addresses.

Date: Sun, 23 Nov 1997 11:55:37 +1100 (EST)
From: David Formosa <[email-masked]>
Reply-To: [email-masked]
To: Alex Le Heux <[email-masked]>
cc: [email-masked]
Subject: Re: Ancient Technology
Sender: [email-masked]

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

On Fri, 21 Nov 1997, Alex Le Heux wrote:

> In an ever faster changing world of computers regular users of PGP 
> seem to be very reluctant to change anything.

Securaty applications tend to encourage a conservative[1] viewpoint even
when the person is noramly quite open to cahnge.  This is most likly a
good thing.

[...]

> Of course there is a strong case for continuing support for AA 
> (backwards compatibility and all that), but the new standard should 
> not be based on it. It's ancient technology.

But as I understand this is _not_ a new standard.  It is the documentation
of an existing standard.  So it is neccery to retain backwards capasity
with pgp itself.

[1] Conservitive as meaning unwilling to change.

- -- 
Please excuse my spelling as I suffer from agraphia see the url in my header. 
Never trust a country with more peaple then sheep.  ex-net.scum and proud
You Say To People "Throw Off Your Chains" And They Make New Chains For
Themselves? --Terry Pratchett.  I do not reply to munged addresses.

Date: Sat, 22 Nov 1997 17:21:51 -0800
From: Gary Liu <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: Why Rabin algorithm has mostly been ignored?
Sender: [email-masked]

Jon Callas wrote:
> It's in there now. Obviously, there needs to be more discussion of what
> kind of Rabin you want, straight Rabin, Williams's variants, or what.
> Please bring this up on the list.

Jon, thanks for putting it in.

I think the Rabin algorithm may use the following specifics, 
which can be found in "Handbook of Applied Cryptography" by 
Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone.

1) In key generation, generate two primes p and q such that
p=3 mod 8 and q=7 mod 8. The public key is simply n=p*q and the
private key is p and q. Quantities a, b satisfying a*p+b*q=1
and d=(n-p-q+5)/8 may also be calculated at the stage of key 
generation and stored as private key data (to simplify decryption 
and signature generation calculations).

2) Encryption: 
c=m**2 mod n.
Note: It is necessary to have some salt and redundancy in m. 
Since m is at least 512 bits and the symetric key is something 
around 128 bit, there is plenty of room to put redundancy and 
salt in ESK. At this time, it is probably sufficient to specify 
that the first octet of m signifies the salting and redundancy 
scheme. (Redundancy will prevent the chosen ciphertext attack
mentioned by Hal Finney.)

3) Decryption:
compute the four square roots of c.
r=c**((p+1)/4) mod p
s=c**((q+1)/4) mod q
x=(a*p*s + b*q*r) mod n
y=(a*p*s - b*q*r) mod n
where a and b are intergers satisfying a*p+b*q=1.
Then use the redundancy information in m to determine which 
of r,s,x,and y is the decrypted message m.

4) Signature generation:
(a) Compute m1=R(m) where R(m) is the redundancy function 
specified by ISO/IEC-9796. Note: This ensures that m1=6 mod 16.
(b) Compute Jacobi symbol J=(m1,n).
(c) If J=1 then the signature is s=m1**d mod n.
(d) If J=-1 then the signature is s=(m1/2)**d mod n.

5) Signature verification:
(a) Compute m2=s**2 mod n.
(b) If m2=6 mod 8 take m1=m2.
(c) If m2=3 mod 8 take m1=2*m2.
(d) If m2=7 mod 8 take m1=n-m2.
(e) If m2=2 mod 8 take m1=2*(n-m2).
(f) Verify that m1 has the correct format specified in 
ISO/IEC-9796.
(g) Recover signed message m=Rinv(m1), where Rinv is the 
inverse function of R.

I think the above Rabin scheme is pretty neat. It does not 
double the ciphertext as ElGamal does. It is extremely fast
in encryption and verification. Althogh the decryption and
signature generation is slightly more complicated than RSA,
the complication is not in the computation intensive part,
and therefore, does not affect the efficiency of the algorithm.
I have implemented the above algorithm without much difficulty 
and found that the decryption and signature generation are
just as fast as RSA but the encryption and verification are 
much faster.

The above may be the scheme you call "straight Rabin". we 
probably should also reserve a number for Williams's variant, 
which takes modular cube instead of modular square.

Gary Liu

Date: Sat, 22 Nov 1997 23:07:19 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Adam Back <[email-masked]>
CC: [email-masked]
Subject: Re: CMR as an extension outside the standard (Re: CMR & ROT-13)
Sender: [email-masked]

Adam Back wrote:

> > This of course will be problematic for programmers, as they test their
> > code against 5.x, and discover the strange packets.
> 
> This problem highlights the usefulness of the extension mechanism Jon
> Callas described briefly.  If PGP implements controversial extensions
> as extensions, the compatibility problem vanishes -- implementations
> which don't have the extension coded already have a defined way to
> safely ignore it.

I agree that it would be nice to have a defined extension mechanism. 
There are lots of things one could do with the PGP infrastructure if one
had the time, and a decent way of adding some extra features.

My normal rule is "no change" and I've pushed that on many occasions
here.  That's probably because I'm old and tired and have been on the
business end of many a programmer's last minute addition.  They are
usually simple in the mind of the proposer and a nightmare, or worse,
for everybody else down the chain of software deployment.

However, given the trauma caused by the CMR feature and the likely cost
to the credibility of the standard if this goes in, I think a change is
needed here.  The addition of the extension mechanism would (as a MAY to
provide and a MAY to ignore and a SHOULD or MUST to not blow up) might
be sufficient to provide the flexibility to replace the CMRK, for those
who have decided it is a good thing. 

> > I don't however see this as a problem, as there is little to stop
> > PGP Inc from publishing a separate document which can become known.
> > As the programmers are coding up the pgp code, and as this feature
> > is only used by PGP Inc code, they know where to ask.
> 
> I'd sooner discourage them also from using the CMR feature at all, due
> to the security risks, and negative political aspects.  However, if
> they insist, it's their reputation, but I would think a good way to
> implement it would be to implement it using the extension mechanism.

Well, it is not up to the IETF or anyone to stop any company from
shooting itself in the corporate foot.  The standard should be neutral
on that, and not try and discourage such and such a feature.

OTOH, it should definately not leave the way open for generations of
programmers to copy footwear ventilation features into their code.

-- 
iang                                      systemics.com

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

Date: Sat, 22 Nov 1997 22:16:22 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: CMR as an extension outside the standard (Re: CMR & ROT-13)
Sender: [email-masked]

Ian Grigg <[email-masked]> writes:
> [about ARR/CMR]
> 
> That leaves us with the fourth option.  Say nothing and do not document
> it.
> 
> This of course will be problematic for programmers, as they test their
> code against 5.x, and discover the strange packets.  

This problem highlights the usefulness of the extension mechanism Jon
Callas described briefly.  If PGP implements controversial extensions
as extensions, the compatibility problem vanishes -- implementations
which don't have the extension coded already have a defined way to
safely ignore it.

> I don't however see this as a problem, as there is little to stop
> PGP Inc from publishing a separate document which can become known.
> As the programmers are coding up the pgp code, and as this feature
> is only used by PGP Inc code, they know where to ask.

I'd sooner discourage them also from using the CMR feature at all, due
to the security risks, and negative political aspects.  However, if
they insist, it's their reputation, but I would think a good way to
implement it would be to implement it using the extension mechanism.

> Or, we can simply say nothing and leave the feature as a new, untried
> idea by one commercial venture in the marketplace for Open PGP product.

Absolutely.  Also they should implement it within the extension
frameworks so that they do not introduce compatibility problems.

Adam

Date: Sat, 22 Nov 1997 09:10:36 -0800
To: Ian Brown <[email-masked]>
Cc: IETF OpenPGP <[email-masked]>
Subject: Re: The case against redundancy and isolation
From: Jeremey Barrett <[email-masked]>
Organization: BlueMoney Software Corp.
Sender: [email-masked]

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

Ian Brown writes:
 > As Dave said, I think this argument is just going round in circles now.
 > We seem to have clarified at least some points. I believe none of the
 > following is contentious:

Indeed, so I'll go 'round once more :-)

 > 
 > 1. We should not MUST MIME *or* Armour. Both increase the amount of code
 > needed for a minimal implementation, which none of us want. As Dave
 > said, linearly increased code increases exponentially the potential for
 > errors.

We differ in opinion here, but so be it. I agree MIME should not be
a MUST, but I believe Armor should be a MUST.

 > 
 > 2. We are not trying to eliminate Armour. It is entirely appropriate
 > that it should be in there as an option to provide backward
 > compatibility, if implementors so wish.
 > 
 > 3. Both systems are for converting fully secure binary PGP data into a
 > form which can be safely stored in/sent across 7-bit systems. Mail is
 > such a system. Armour/MIME does nothing for security. As Dave and Jon
 > have both said, OP is NOT a mail standard. It is a security standard.
 > 7-bit conversion should therefore not be a MUST. As Lindsay Mathieson
 > said, we can safely assume most file systems can cope with 8-bit
 > data.

I'll disagree one last time with this. No, Armor doesn't effect the
security of PGP itself, but it does affect how OP products will or
can be used in the "real world" and therefore affects the "level of
security provided by" the PGP system. (if noone used PGP, PGP is still
secure, but the system is not because it isn't used).

7-bit conversion is fundamental to the viability of a tool like PGP,
and is therefore not external to defining OP. 

 > 
 > Jeremey Barrett wrote:
 > 
 > > As Jon pointed out, PGP is not email software, there are a host
 > > of other applications for PGP, which might well benefit (and do)
 > > from ASCII armor.
 > 
 > The only way these applications will benefit from armor is if they need
 > to send data across a 7-bit system. Everywhere else can store objects in
 > their original 8-bit format.

Agreed. I find myself doing this quite regularly.

 > 
 > > My point is that _requiring_ MIME eliminates a set of users. That's
 > > all. Eliminating users decreases the security of the system, because
 > > less people have the necessary tools. If security is the goal (and
 > > as I read the wg charter, "The whole purpose of Open-PGP is to provide
 > > security services") then the elimination of ASCII armor is 
 > > contradictory to the goals of the wg, IMO. It should be a MUST.
 > 
 > If we follow this logic, RSA and IDEA should be a MUST. We eliminate far
 > more users by not specifying this than by not making armor
 > compulsory.

Perhaps true, but not in the same sense. It is reasonably easy to go
get a new version of PGP which doesn't use RSA or IDEA, or doesn't
default to them. You don't have to change the way you "do things" to
switch to ElGamal and CAST. MIME is different, because it is external
to PGP.

 > 
 > > I thought we were discussing PGP, not email. Last time I checked noone
 > > has implemented file encryption, or encrypted archiving tools, or
 > > remailers, or keyservers, or nym servers, or anything other than
 > > email (and on occasion news) using MIME. Nor should they.
 > 
 > That's right. Armor is used in systems that use 7-bit mail systems as
 > their transport mechanism. Therefore, Armor is only relevant if we are
 > discussing PGP as an e-mail standard. You are arguing against yourself
 > here.

It is only relevant in the case of any 7-bit transport, yes. (be that
email or news or what-have-you). My point is that the capacity for
7-bit encoding is critical to PGP, and all OP-compliant products
should provide it regardless of what other 7-bit transport schemes
are supported. Relying on the existence of an external infrastructure
(MIME) for the simple ability to send OP messages over 7-bit transport
mechanisms is not sound, as Rodney said.

And since ASCII armor 1) already exists, 2) is widely used, and 3) is
quite trivial to implement, it is the logical choice for built-in
7-bit support.

 > 
 > File encryption and archiving tools can support 8-bit data. They do not
 > require armor. Remailers are using mail transport. The main reason
 > keyservers use armor is that they originally used mail transport. It
 > would be just as appropriate, and faster, for the Web/LDAP-based systems
 > to transfer keys as binary data. See http://solo.dc3.com/pks/kfmts.html
 > for one that allows this.

The idea that we should reimplement all the existing PGP
infrastructure in the name of 'standards' is hogwash. I don't have
LDAP in my mail reader. Neither does anyone else, with the exception
of Netscape and Micro$oft users. Supporting all those things is great,
but removing the simple functionality of PGP in favor of increasingly
complex and difficult protocols and software is not a step in the
right direction.

Anyway... the horse is dead.

Regards,
Jeremey.
- -- 
Jeremey Barrett                                BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems               http://www.bluemoney.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64

Date: Sat, 22 Nov 1997 08:24:29 -0800
From: Kent Crispin <[email-masked]>
To: IETF OpenPGP <[email-masked]>
Subject: Re: The case against redundancy and isolation
Sender: [email-masked]

On Sat, Nov 22, 1997 at 02:56:28PM +0000, Ian Brown wrote:
> As Dave said, I think this argument is just going round in circles now.
> We seem to have clarified at least some points. I believe none of the
> following is contentious:
> 
> 1. We should not MUST MIME *or* Armour. Both increase the amount of code
> needed for a minimal implementation, which none of us want. As Dave
> said, linearly increased code increases exponentially the potential for
> errors.
> 
> 2. We are not trying to eliminate Armour. It is entirely appropriate
> that it should be in there as an option to provide backward
> compatibility, if implementors so wish.
> 
> 3. Both systems are for converting fully secure binary PGP data into a
> form which can be safely stored in/sent across 7-bit systems. Mail is
> such a system. Armour/MIME does nothing for security. As Dave and Jon
> have both said, OP is NOT a mail standard. It is a security standard.
> 7-bit conversion should therefore not be a MUST. As Lindsay Mathieson
> said, we can safely assume most file systems can cope with 8-bit data.

All sounds good to me...

-- 
Kent Crispin				"No reason to get excited",
[email-masked]			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

Date: Sat, 22 Nov 1997 08:22:27 -0800
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: The case against redundancy and isolation
Sender: [email-masked]

On Fri, Nov 21, 1997 at 01:14:10PM -0800, Jim McCoy wrote:
> I hate to burst the bubble of everyone at PGP, Inc. but right now and
> for the forseeable future PGP is _only_ email.  It is not for general
> purpose encryption because in those cases people use toolkits that do
> not carry around as much bogus baggage as PGP does (like Ascii
> Armoring for example...)

I beg to differ.  When I encrypt a file (which I do on occasion) PGP 
is the tool of choice.

-- 
Kent Crispin				"No reason to get excited",
[email-masked]			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

Date: Sat, 22 Nov 1997 15:06:35 +0000
From: Ian Brown <[email-masked]>
To: Kent Crispin <[email-masked]>
CC: IETF OpenPGP <[email-masked]>
Subject: Re: CMR
Sender: [email-masked]

Black Unicorn wrote:

> Which is why, as part of a general document destruction and retention
> policy, you cycle the CMR key every year (or other period), securely delete
> the old secret key, and thus kill all the "tobacco memos."

The problem with this, as Adam and others have pointed out, is that you
have different storage requirements for different types of material.
Regulatory bodies may require certain materials to be stored for say 7
years. Other types of material may need to be securely wiped ASAP.

This means that you need different CMR keys for different purposes. But
how do you implement this properly using CMR? Say I work for such a
company. Which CMR request should be on my general-purpose public key?

Kent Crispin wrote:

> Of couse, this is a problem intrinsic to either CMR or CKE.  You are in
> precisely the same trouble with key escrow -- they save the mail, then
> demand the escrowed key via court order.

You're right, if it is simple CKE. However, following Adam's
GAK-resistant design principles, the escrow should be done as close to
the user as possible. So to take Microsoft's example: these dynamite
messages should have ONLY been encrypted to the message recipient. Once
the recipient received and decrypted the message, if it was necessary to
store it, they would then encrypt it with the company escrow key. This
escrowed storage copy would remain physically inside the organisation -
no competitor or regulatory body could have intercepted and stored a
copy. If the organisation wished to securely wipe the data, it could do
so knowing that no-one else could have intercepted the copy. And since
the recipient used Forward Secrecy ;-), by the time the courts came to
demand the recipient's private key so they can decrypt their intercepted
and stored message, said private key would have been long ago securely
wiped.

Ian.

Date: Sat, 22 Nov 1997 14:56:28 +0000
From: Ian Brown <[email-masked]>
To: Jeremey Barrett <[email-masked]>
CC: IETF OpenPGP <[email-masked]>, [email-masked]
Subject: Re: The case against redundancy and isolation
Sender: [email-masked]

As Dave said, I think this argument is just going round in circles now.
We seem to have clarified at least some points. I believe none of the
following is contentious:

1. We should not MUST MIME *or* Armour. Both increase the amount of code
needed for a minimal implementation, which none of us want. As Dave
said, linearly increased code increases exponentially the potential for
errors.

2. We are not trying to eliminate Armour. It is entirely appropriate
that it should be in there as an option to provide backward
compatibility, if implementors so wish.

3. Both systems are for converting fully secure binary PGP data into a
form which can be safely stored in/sent across 7-bit systems. Mail is
such a system. Armour/MIME does nothing for security. As Dave and Jon
have both said, OP is NOT a mail standard. It is a security standard.
7-bit conversion should therefore not be a MUST. As Lindsay Mathieson
said, we can safely assume most file systems can cope with 8-bit data.

Jeremey Barrett wrote:

> As Jon pointed out, PGP is not email software, there are a host
> of other applications for PGP, which might well benefit (and do)
> from ASCII armor.

The only way these applications will benefit from armor is if they need
to send data across a 7-bit system. Everywhere else can store objects in
their original 8-bit format.

> My point is that _requiring_ MIME eliminates a set of users. That's
> all. Eliminating users decreases the security of the system, because
> less people have the necessary tools. If security is the goal (and
> as I read the wg charter, "The whole purpose of Open-PGP is to provide
> security services") then the elimination of ASCII armor is 
> contradictory to the goals of the wg, IMO. It should be a MUST.

If we follow this logic, RSA and IDEA should be a MUST. We eliminate far
more users by not specifying this than by not making armor compulsory.

> I thought we were discussing PGP, not email. Last time I checked noone
> has implemented file encryption, or encrypted archiving tools, or
> remailers, or keyservers, or nym servers, or anything other than
> email (and on occasion news) using MIME. Nor should they.

That's right. Armor is used in systems that use 7-bit mail systems as
their transport mechanism. Therefore, Armor is only relevant if we are
discussing PGP as an e-mail standard. You are arguing against yourself
here.

File encryption and archiving tools can support 8-bit data. They do not
require armor. Remailers are using mail transport. The main reason
keyservers use armor is that they originally used mail transport. It
would be just as appropriate, and faster, for the Web/LDAP-based systems
to transfer keys as binary data. See http://solo.dc3.com/pks/kfmts.html
for one that allows this.

Ian.

Date: Sat, 22 Nov 1997 09:53:17 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: CMR
Sender: [email-masked]

Jon Callas <[email-masked]> writes:
> At 04:20 PM 11/21/97 +0000, Ian Brown wrote:
>    
>    No, I don't. But as PGP Inc are pushing CMR as a corporate solution
>    which gives the ability to snoop on employees' e-mail, I just wanted to
>    point out one of the negative consequences for such unethical companies
>    ;-)
>    
> We are doing no such thing.

Could we have some clarification on what purpose PGP is pushing the
CMR feature for.  Lots of disclaimers about what it's not for: but
what _is_ it for?  The fact that it is currently in the draft I think
entitles the WG to some kind of explanation.

PGP might not be pushing CMR for the purpose of allowing corporate
snooping; but that is what the CMR design is ideal for.

We already went through the process of showing that recovering from 
lost passphrases is better achieved with local escrow.

CMR doesn't acheive it's stated purpose, weakens security, and is
politically dangerous to boot.

David Kemp was arguing for snooping:

> So you accept it as a given that shredding evidence is appropriate
> and desirable behavior in a free society?

Yes.  This is what Phil Zimmermann designed the pgp -w option is for:
to shred files.  Communications and storage security is all about
denying third party access to communications and storage.  What better
way to deny access of communications than to destroy them after
reading.  This is what the pgp -m option is for: to discourage the
recipient from storing in plaintext.

> Even if said shredding is conducted by the White House (or #10
> Downing Street)?

Everything cuts two ways.  Next thing you'll be telling us sending
messages the government can't read "isn't appropriate and desirable
behaviour in a free society".

When Phil Zimmermann spoke at the Privacy International organised
conference in London he made the point that he hoped the new Labour
government would not forget the wire taps and snooping they had been
subjected to by GCHQ on the behalf of the Tory government prior to
winning the election.  He hoped they would remember these lessons, and
avoid government key escrow.

PGP Inc is firmly against government key escrow.  The name PGP must
_never_ become associated with untoward backdoors.

Companies have a perfectly legitimate need to "shred" their data after
it is no longer needed by them.  Saying that individuals or companies
must keep records to enable others to incriminate them is prior
restraint.  Some companies are required to keep various records for
periods of time.  There is no obligation to keep records after these
stipulated times, and many company communications are not kept at all,
by design.  To do otherwise would be fool hardy.  Tim May, an ex-Intel
engineer, gave the example that they had a policy of purging old
notes, papers, periodically.  He considered the purpose of this to
prevent discovery processes.

It is dangerous for companies to keep around old communications which
they no longer need.  Ian posted another example.

Why do you think companies have paper shredders?  Companies legal
departments set policies for records keeping; several people who have
spent much time in corporate environments gave examples of destroying
old records.  The motive is obvious: to minimise information available
in a discovery processes, such as Microsoft is enduring now.

Adam

Date: 22 Nov 1997 8:5:9 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: Armour
To: Dave Crocker / IMC <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>>In particular, what format would MIME leave encrypted files on disk 
>so
>>my above simple archaic email example would work?  How well does 
>MIME 
>>work with stored objects?  How does the MIME standard actually deal 
>with 
>>stored objects?

Another point - pgp 2.6.x  is quite capable of generating & decoding 8 bit
binary objects for storage on disk, and I believe we can safely assume most
file systems can cope with 8 bit data <g>
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Beta Vs 2.6.1.2, on November 22, 1997, in Win95 4.0
	http://www.blackpaw.com/

Date: Fri, 21 Nov 1997 22:57:34 -0800
From: Kent Crispin <[email-masked]>
To: IETF OpenPGP <[email-masked]>
Subject: Re: CMR
Sender: [email-masked]

On Fri, Nov 21, 1997 at 10:02:22AM +0000, Ian Brown wrote:
> Several people have made the point that, while companies may wish to be
> able to recover some stored e-mail, they most definitely do NOT want
> other items to be recoverable in the case of court demands that material
> be handed over. Microsoft is providing a prime example of this right
> now. The Department of Justice is using, to great effect, internal
> Microsoft e-mail to show that they did not originally intend to
> integrate Internet Explorer with Windows.
> 
[...]
> 
> Your company may take great steps to securely delete such sensitive
> mail. If it has already travelled over an insecure network, it could be
> intercepted and stored by a competitor. Encryption will prevent them
> reading it then. But what if they get a court order demanding you hand
> over your Corporate Message Recovery Key? If all your mail is also
> encrypted to this CMRK, you're in trouble.

Of couse, this is a problem intrinsic to either CMR or CKE.  You are in
precisely the same trouble with key escrow -- they save the mail, then
demand the escrowed key via court order.

-- 
Kent Crispin				"No reason to get excited",
[email-masked]			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

Date: Fri, 21 Nov 1997 22:47:30 -0800
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: Armour
Sender: [email-masked]

On Fri, Nov 21, 1997 at 09:05:21PM -0800, Dave Crocker / IMC wrote:
> Kent,
> 
> Well, how about this?  Opposite sides of the fence...

Not really -- I don't have a position on this.  But it seems that it's
being debated as a religious issue, rather than a technical one.  That
is, you assert that mime solves the full pgp problem domain; others
assert that there are areas that mime doesn't address.  You seem to be
taking the tack that these individuals are reacting in a patently
reactionary mode, and express a lot of frustration over it. 

There is a real possiblity that you indeed *are* dealing with purely
reactionary thinking.  But there is also the possibility that "the
other side" has a valid intuition that they aren't expressing well, or
that you just aren't hearing -- they aren't dumb, you know.  If there 
are valid reasons for ascii armor, then it would be good if they are 
brought out.

> At 04:47 PM 11/21/97 -0800, Kent Crispin wrote:
> >  It is quite possible that
> >"simple" mailers will persist for another 10 or more years. 
> 
> This is certain to be true, but is a likelihood which needs to be used
> carefully.  For example, why project that the MUA will be unchanged but
> that fancy new encryption sofware will be added?

I'm not thinking that fancy new encryption technology will be added. 
Someone could produce a standard compliant simple OP application next
year, and it could be in use for another 10 years. 

> More importantly, why
> jerk the standards specification around to accomodate that particular
> scenario?

Why do you view it as "jerking around"?  It is a completely valid 
thing for a standard to codify an existing practice, is it not?

> If they want new security technology, why is it unreasonable to
> require that relevant additional capabilities be added.

There's an "if" there.  I'm not sure that the sole purpose of the 
standard is to define "new security technology".

[...]
> >The claim is that PGP has uses independent of the net [so IETF
> >standardization?] -- that is, independent of the problem of
> >transmitting data securely over the net; and it really may be that
> 
> The IETF does interchange standards, not file standards.

Indeed.  But half the functionality of PGP has to do with files, not
interchange.  If I encrypt something on disk, that's not an
interchange.  That something may be transported by ftp, or kermit, or
any number of ad hoc transfer protocols, instead of smtp or http.  

> >MIME is not the best way to support *those* uses. 
> 
> The sun might not come up tomorrow, to.  "Might" is a mighty weak approach
> to debating technical choices.  If there is a specific problem with MIME
> for specific situations, let's hear about them and look at them.

I believe that Hal Finney did just post a lengthy post on this very topic.

> Across the many messages on this topic, the arguments for retaining
> amouring seem to be using cases which are irrelevant to IETF work,
                                            ^^^^^^^^^^^^^^^^^^^^^^^ 

This is precisely the point of my bracketed comment above -- some
parts of pgp *are* irrelevant to IETF work, I believe.  But they are
*important* parts of pgp.  It may well be that an IETF standard is
inappropraite for pgp -- file security is a vital component of pgp, I 
don't see the IETF relevance, for example.

>  matters
> of unfounded fantasy, or based on errors.  
> 
> All in all, this is getting to be rather frustrating.
> 
> >I am not an expert in either MIME or PGP, so I may just be blowing
> >smoke. 
> 
> Gad, what an opening.  I appreciate the opportunity, Kent, except for the
> effort needed to skip rise above it...

Perhaps if you could avoid thinking about this as combat :-)

> >In particular, what format would MIME leave encrypted files on disk so
> >my above simple archaic email example would work?  How well does MIME 
> >work with stored objects?  How does the MIME standard actually deal with 
> >stored objects?
> 
> MIME is not about storage, it is about transmission. 

BINGO!

> In any event, if you
> need information about MIME, I encourage you to read the relevant RFCs and
> learn about it.  It's remarkably difficult to condut a debate in which one
> of the sides is not familiar with basic facts.  (On the other hand, it's
> pretty easy when BOTH sides are ignorant...)

Actually, Dave, I *have* read the rfcs (though it's been a while) and
I *do* understand the "basic facts" of mime -- in fact, I understand
mime better than I understand pgp [OK, hold your breath, the urge will
pass, I'm just testing you :-)].  I said I "wasn't an expert".  I
didn't say I was "totally ignorant". 

-- 
Kent Crispin				"No reason to get excited",
[email-masked]			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

Date: Fri, 21 Nov 1997 21:29:53 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Draft comments
Sender: [email-masked]

Jon Callas writes:
> At 11:04 AM 11/19/97 +0000, Ian Brown wrote:
>    Sec	Comments
>    
>    2.4.1	- Just one quibble. Since Armour is largely for backward
>    compatibility with the 4 million users of PGP 2.6, do we *really* need
>    to add a new header (BEGIN PGP MESSAGE, PART X)? If this went, could
>    Message-ID also go? It does say in PGP/MIME that "When the amount of
>    data to be transmitted requires that it be sent in many parts, the MIME
>    message/partial mechanism should be used rather than the multipart ASCII
>    armor PGP format."
>
> I've already said my part on why I think armour is *not* primarily for
> backwards compatibility. The PART X headers are not a new header, though.
> They are an old header. I don't mind losing them, or deprecating them.

There is a new mechanism here.  It used to be that you had to say
PART X/Y, like PART 3/10.  This meant that you had to know how many parts
there would be, total.

One of the design goals of several of the new changes (new format message
length headers, one-pass signature packets) is to allow processing data
where you don't know how big it is ahead of time.  Old PGP had to use
a lot of temp files because it kept having to complete one phase of
the processing before it could begin the next one.  Any time you use a
temp file, this could potentially leave incriminating data on the disk
(even a secure wipe is not guaranteed to work).  Eliminating temp files
reduces this risk.

The new PART X combined with the MessageID armor header is designed to
allow one-pass processing without knowing how many parts there will be
in advance.  The MessageID also allows different messages to be
decoded even when they are interspersed.

>    2.6	- I'm not sure what jdcc means by "Should the armor header line stay
>    or go... I think anything that reduces parsing complexity is a Good
>    Thing." I agree, but by this do you mean it saves implementations
>    parsing the algorithm fields in the actual signature itself?
>
> I meant that new combined header that has a begin-message and the hash
> announcement. I think that as long as the "Hash:" header line can have
> multiple hashes there (or it is legal to have multiple hash headers), then
> we don't need this, and it simplifies to just remove it.

This is just meant as a shorthand, moving the hash line up to the end
of the armor header line.  A similar change allows the CRC hash to be
at the end of the last signature line instead of on a line of it own.
It's really to reduce visual clutter.  PGP cleartext signatures are so
clean and nice, especially compared with the S/MIME alternative, that
there has been a desire expressed to keep them as clean as possible.

>    5.2.2.2
>    > {{Editor's note:  It would be nice to have a signature that applied to
>    > the key alone, rather than a key plus a user name... --jdcc}}
>    
>    What would it mean to have just key material signed by someone else?
>
> Right now, all the signatures sign the key material and a user name, thus
> binding the user name to to the key. All of the subpackets, because they
> are on an identity signature, apply only to that one username. I added in
> this draft language to make that specific -- see the paragraph on them
> being interpreted narrowly. If you wanted, for example, to set a symmetric
> algorithm preference for the entire key, or for someone to issue some
> statement about the entire key, then there has to be a signature type that
> spans the entire key.

Actually, key-revocation signatures are directly on keys, and subkey
signatures are directly on subkeys.  No userids are involved in either of
these kinds of signatures.  I agree with Jon that there could be other
kinds of signatures which would be most logical to apply directly to a
key or subkey.

>    5.4	- Is the one-pass signature packet *really* necessary?
>
> It depends on what you mean by really. Without it, you have to verify a
> signature with a two-pass scheme (hence the name "one-pass signature") and
> this requires storing the whole message during the time that the signature
> is being computed. This leads either to a slowdown, or a breakdown of the
> whole system (a relay system could not verify a signature on a message
> larger than its storage). So no, it's not *really* necessary -- PGP has
> survived for years without it. Is it useful? Yes, very.

It's actually an issue more for signature creation than verification.
The signature packet has to go at the front of the message.  But you don't
have the hash until you've gotten to the end of the message.  Now you have
to go back and stick the signature at the front.  This requires a lot of
buffering, temp files, and such.  With the one-pass packet you put the
signature at the end.  No more temp files, one less security risk.

>    8.1	- Why not use the BNF-like notation from section 7.2 to describe
>    keyring structure also?
>    
> I think the keyring structure is outside the scope of this document. All
> the current implementations I know of use a sequential file of keys, but I
> think that longterm that is going to be inadequate, and a real database is
> required. Beyond that statement, I have to do a lot of handwaving.
> Traditionally, IETF documents leave on-disk structure, and things like that
> to the implementor. 

A related issue is transferrable key structure.  A BNF would seem
appropriate in that case.

Hal Finney

Date: Fri, 21 Nov 1997 21:07:58 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Why Rabin algorithm has mostly been ignored?
Sender: [email-masked]

People have been scared of Rabin encryption because it has a chosen
ciphertext attack which reveals the key.  The attacker needs to be able
to get the key holder to Rabin decrypt the encrypted session key, then
to tell him what the decrypted value was.

In normal circumstances this is unlikely to be a problem.  If the
decryption of the ESK packet produces garbage, there is no reason to
send the decrypted garbage back to the attacker.  As long as you just
destroy the garbage, you are OK.

Still I think there may be some fear about using an algorithm which has
this potential vulnerability.

Hal Finney

Date: Fri, 21 Nov 1997 21:05:21 -0800
To: Kent Crispin <[email-masked]>
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: Armour
Cc: [email-masked]
Sender: [email-masked]

Kent,

Well, how about this?  Opposite sides of the fence...

At 04:47 PM 11/21/97 -0800, Kent Crispin wrote:
>  It is quite possible that
>"simple" mailers will persist for another 10 or more years. 

This is certain to be true, but is a likelihood which needs to be used
carefully.  For example, why project that the MUA will be unchanged but
that fancy new encryption sofware will be added?  More importantly, why
jerk the standards specification around to accomodate that particular
scenario?  If they want new security technology, why is it unreasonable to
require that relevant additional capabilities be added.

>file to a user.  How do I leave an encrypted file on disk so it can 
>be sent?

This line of question is based on the possibility that MIME formatting is
somehow meaningfully different from PGP amouring.  With respect to this
line of question, it isn't.

>The claim is that PGP has uses independent of the net [so IETF
>standardization?] -- that is, independent of the problem of
>transmitting data securely over the net; and it really may be that

The IETF does interchange standards, not file standards.

>MIME is not the best way to support *those* uses. 

The sun might not come up tomorrow, to.  "Might" is a mighty weak approach
to debating technical choices.  If there is a specific problem with MIME
for specific situations, let's hear about them and look at them.

Across the many messages on this topic, the arguments for retaining
amouring seem to be using cases which are irrelevant to IETF work, matters
of unfounded fantasy, or based on errors.  

All in all, this is getting to be rather frustrating.

>I am not an expert in either MIME or PGP, so I may just be blowing
>smoke. 

Gad, what an opening.  I appreciate the opportunity, Kent, except for the
effort needed to skip rise above it...

>In particular, what format would MIME leave encrypted files on disk so
>my above simple archaic email example would work?  How well does MIME 
>work with stored objects?  How does the MIME standard actually deal with 
>stored objects?

MIME is not about storage, it is about transmission.  In any event, if you
need information about MIME, I encourage you to read the relevant RFCs and
learn about it.  It's remarkably difficult to condut a debate in which one
of the sides is not familiar with basic facts.  (On the other hand, it's
pretty easy when BOTH sides are ignorant...)

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

Date: Fri, 21 Nov 1997 18:20:14 -0800
To: Ian Brown <[email-masked]>, IETF OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Draft comments
Sender: [email-masked]

At 11:04 AM 11/19/97 +0000, Ian Brown wrote:
   Took a while to plough through!
   
   It's a pretty good document overall - please don't take the following
   comments as quibbling in any way, I'm just trying to contribute ;-)

Thanks. Now you see why it took so long to produce. I couldn't have gotten
it out even *this* fast without Hal, Rodney, Lutz, and Paul Hoffman. They
did about 95% of the writing, and I just pulled it together.
   
   Sec	Comments
   
   2.4.1	- Just one quibble. Since Armour is largely for backward
   compatibility with the 4 million users of PGP 2.6, do we *really* need
   to add a new header (BEGIN PGP MESSAGE, PART X)? If this went, could
   Message-ID also go? It does say in PGP/MIME that "When the amount of
   data to be transmitted requires that it be sent in many parts, the MIME
   message/partial mechanism should be used rather than the multipart ASCII
   armor PGP format."

I've already said my part on why I think armour is *not* primarily for
backwards compatibility. The PART X headers are not a new header, though.
They are an old header. I don't mind losing them, or deprecating them.
   
   2.6	- I'm not sure what jdcc means by "Should the armor header line stay
   or go... I think anything that reduces parsing complexity is a Good
   Thing." I agree, but by this do you mean it saves implementations
   parsing the algorithm fields in the actual signature itself?

I meant that new combined header that has a begin-message and the hash
announcement. I think that as long as the "Hash:" header line can have
multiple hashes there (or it is legal to have multiple hash headers), then
we don't need this, and it simplifies to just remove it.
   
   3.5	- Are the S2K functions really necessary? Are dictionary attacks on
   passphrases in an (at least) 128-bit keyspace likely to be successful?
   If so, I still agree with jdcc that the Iterated-Salted algorithm should
   be dropped.

Yes, I think dictionary attacks are trivial to do successfully, and salted
hashes are the way to thwart them. 
   
   5.1	- "An implementation should accept, but not generate a version of 2,
   which is equivalent to V3 in all other respects." Is this purely for
   legal (RSAREF) reasons? The international version of PGP 2.6 can
   generate V2 packets for backwards compatibility (LEGAL_KLUDGE=off). Is
   there any *technical* reason why OP implementations should not generate
   version 2 packets?

When PGP 2.6 was created, the version number of the packets was bumped from
2 to 3, but nothing else was changed. It's really only there so you can
tell whether a message was made by 2.5 or 2.6. There is no technical reason
not to generate a V2 packet, but there is no technical reason *to* generate
them, either. RFC 1991 says on the subject: 

"A version number of 2 or 3 is currently allowed for each packet
 format.  New versions will probably be numbered sequentially up from
 3.  For backwards compatibility, implementations will usually be
 expected to support version N of a packet whenever they support
 version N+1.  Version 255 may be used for experimental purposes."

This paragraph is my rationale for preferring V4 to V3, and noting that V2
is identical to V3, but that it must not be generated.
   
   5.2.2.2
   
   "Preferred hash algorithms" - you mention "If this subpacket is not
   included, ZIP is preferred." Would it be useful to put a sentence of
   this type in the preferred symmetric and hash algorithms also? We have
   3DES and SHA-1 as MUSTs, so they could be used...

The reason I put that there is that this preference is different in
semantics from the others. You see, most implementations of PGP compress by
default. The main reason for this packet is so that a key can say, "Hey, if
you send me a compressed message, I can't read it." This is so that a
minimal implementation -- one that does not have compression (remember, the
MUST algorithm for compression is uncompressed) -- can advertise that it
doesn't have compression. 

I put that sentence in there so that all the existing keys in the world
will continue to work the way they always have.
   
   > {{Editor's note:  It would be nice to have a signature that applied to
   > the key alone, rather than a key plus a user name... --jdcc}}
   
   What would it mean to have just key material signed by someone else?

Right now, all the signatures sign the key material and a user name, thus
binding the user name to to the key. All of the subpackets, because they
are on an identity signature, apply only to that one username. I added in
this draft language to make that specific -- see the paragraph on them
being interpreted narrowly. If you wanted, for example, to set a symmetric
algorithm preference for the entire key, or for someone to issue some
statement about the entire key, then there has to be a signature type that
spans the entire key.
   
   > {{Editor's note:  There is presently no way for a key-signer (a.k.a.
   > certifier) to sign a main key along with a subkey.  There are a number
   > of useful situations for a set of keys (main plus subkeys) to all be
   > signed together... --jdcc}}
   
   Could you give a few examples?

A feature of the V4 keys is to have a main key and some number of subkeys.
Certifications (a.k.a. key signatures) are over the main key only. This
means that you can replace your encryption key without losing your
signatures. This is a Good Thing.

However, a number of people, including you and Adam, are proposing that as
an alternative to ARR/CMR/whatever that some form of "key escrow" be used.
Adam and I are starting to work on a paper that compares "shared key" (the
Crypto-Correct term for placing a secret key in a third party's possession)
and "multiple encryption" schemes for providing access to data.

As presently described, the key-replacement mechanisms make it impossible
to implement a shared-key access system. (In the Bad Old Days, I bragged
that PGP 5 was "escrow-resistant" -- but it now seems that what I used to
think of escrow is actually a feature to a lot of people.) So we need to
have a mechanism that lets someone sign not only your top-level key, but
some number of subkeys, too.

I can think of two main ways to do this:

(1) Add a new signature type. This new signature type is like an existing
certification signature, but certifies a list of subkeys, too. We'd have to
devise a syntax for it.

(2) Add a subpacket type. This subpacket would be included in a
certification signature and would state that a subkey (specified by algid
and fingerprint) is to be included in the hash. More than one of these
subpackets means more than one key is part of the certification. 

I think (2) is better -- which you can probably tell because I started to
design the thing. There are other ways to do it, but I think that a
subpacket is preferable, because it piggybacks on the existing
signature-plus-subpacket framework.
   
   5.4	- Is the one-pass signature packet *really* necessary?

It depends on what you mean by really. Without it, you have to verify a
signature with a two-pass scheme (hence the name "one-pass signature") and
this requires storing the whole message during the time that the signature
is being computed. This leads either to a slowdown, or a breakdown of the
whole system (a relay system could not verify a signature on a message
larger than its storage). So no, it's not *really* necessary -- PGP has
survived for years without it. Is it useful? Yes, very.
   
   5.10	- I think you're right about there being so many problems with
   Trust packets, we should forget them. Your idea about them being
   implementation dependent is good, except that different OP
   implementations may want to use the same keyring. For example, I use PGP
   2.6.3i and my mail encrypting program with the same keyring. If they
   implement trust packets differently, it would be very confusing. I think
   we should just specify that they should be ignored.

All PGP implementations have "export" and "import" functions, and don'e
merely pass keyrings around. Passing a keyring *works* but it's not a good
idea, because it leaks all your trust information. If an implementation 
   
   8.1	- Why not use the BNF-like notation from section 7.2 to describe
   keyring structure also?
   
I think the keyring structure is outside the scope of this document. All
the current implementations I know of use a sequential file of keys, but I
think that longterm that is going to be inadequate, and a real database is
required. Beyond that statement, I have to do a lot of handwaving.
Traditionally, IETF documents leave on-disk structure, and things like that
to the implementor. 

	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: Fri, 21 Nov 1997 17:02:10 -0800
To: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Why Rabin algorithm has mostly been ignored?
Sender: [email-masked]

At 04:42 PM 11/21/97 -0800, Gary Liu wrote:
   
   Why Rabin algorithm has been mostly ignored in discussions,
   implementations and
   standards? It seems to me that Rabin algorithm is a very decent
   alternative to RSA. 
   It is extremely fast in encryption and verification (only one modular
   square),
   just as efficient as RSA in signing and decryption, and as secure as RSA
   (also depends on the difficulty of factoring). I just do not understand
   why it
   has been mostly ignored. Have I missed something? 
   
Had you suggested it to me, I would have gladly put it in. Would you like
me to do that now?

	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: Fri, 21 Nov 1997 16:47:57 -0800
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: Armour
Sender: [email-masked]

On Fri, Nov 21, 1997 at 01:27:38PM -0800, Dave Crocker / IMC wrote:
> One more time, folks:  If you are using the absence of MIME from some
> current usage of email then you are using a fundamentally flawed argument.
> MIME is being adopted.  The rate of adoption (i.e., growth in use) is
> proceeding nicely.  We are not early in the process, so the assessment does
> not represent fantasy.

I don't know if this is the argument, but I am not sure I believe that
it is flawed, in any case.  "Widespread" adoption of MIME is not the
same as "universal" adoption of MIME.  It is quite possible that
"simple" mailers will persist for another 10 or more years. 

In particular, the fact that simple MUA interfaces appear in many many
scripts, cgi programs, and so on virtually guarantees a 10 year 
lifetime.  So think about the following:

	mail $user <$file

Imagine it is embedded in a cgi script, possibly sending a requested 
file to a user.  How do I leave an encrypted file on disk so it can 
be sent?

> If you are noting that some use of PGP is, or can be, outside of
> environments that use MIME (i.e., not Internet mail and not the Web), then
> you are right that they would have to add MIME support to work.  What you
> are missing is that MIME has become the standard way of solving such
> packaging, labeling and protecting requirements for the net.  

The claim is that PGP has uses independent of the net [so IETF
standardization?] -- that is, independent of the problem of
transmitting data securely over the net; and it really may be that
MIME is not the best way to support *those* uses. 

I am not an expert in either MIME or PGP, so I may just be blowing
smoke.  But perhaps there may be some actual technical issues here. 

In particular, what format would MIME leave encrypted files on disk so
my above simple archaic email example would work?  How well does MIME 
work with stored objects?  How does the MIME standard actually deal with 
stored objects?

Here's another use for ascii armor -- suppose I want to send an 
encrypted file via email and I *don't* want it to be automatically 
presented for decryption?  How do I instruct PGP to produce such a 
file? 

-- 
Kent Crispin				"No reason to get excited",
[email-masked]			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

Date: Fri, 21 Nov 1997 16:42:18 -0800
From: Gary Liu <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Why Rabin algorithm has mostly been ignored?
Sender: [email-masked]

In draft-ietf-openpgp-formats-00.txt:
> 6.1 Public Key Algorithms
>
> 1              - RSA (Encrypt or Sign)
> 2          - RSA Encrypt-Only
> 3          - RSA Sign-Only
> 16             - Elgamal 
> 17             - DSA (Digital Signature Standard)
> 100 to 110 - Private/Experimental algorithm.
>
> Implementations MUST implement DSA for signatures, and Elgamal for
> encryption.  Implementations SHOULD implement RSA encryption.
> Implementations MAY implement any other algorithm.
>
> {{Editor's note: reserve an algorithm for elliptic curve?  Note that
> I've left Elgamal signatures completely unmentioned.  I think this is
> good. --jdcc}}

Why Rabin algorithm has been mostly ignored in discussions,
implementations and
standards? It seems to me that Rabin algorithm is a very decent
alternative to RSA. 
It is extremely fast in encryption and verification (only one modular
square),
just as efficient as RSA in signing and decryption, and as secure as RSA
(also depends on the difficulty of factoring). I just do not understand
why it
has been mostly ignored. Have I missed something? 

Gary Liu

Date: Fri, 21 Nov 1997 16:18:12 -0800
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Armour
Sender: [email-masked]

I would have some questions about using PGP-MIME for all the ascii output
modes, outside of the email environment.

With email (and the web and news) there is a distinction between header
and body.  MIME requires some data to go into the header, and some to go
into the body.  If you're just encrypting files but you want ascii output
for some reason, you would have to introduce the notion of a header and
body within a file.  You'd have header lines as for email, then a blank,
then the body of the encrypted data, all within the file.

So an encrypted, ascii-encoded file would look like this (example from
RFC2015):

     Mime-Version: 1.0
     Content-Type: multipart/encrypted; boundary=foo;
        protocol="application/pgp-encrypted"

     --foo
     Content-Type: application/pgp-encrypted

     Version: 1

     --foo
     Content-Type: application/octet-stream

     -----BEGIN PGP MESSAGE-----
     Version: 2.6.2

     hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
     eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
     g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
     AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
     1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
     =zzaA
     -----END PGP MESSAGE-----

     --foo--

Now if you want to send this to someone, you have two ways you can go.
First, you can just send the file itself as an attachment.  In that case
the recipient would receive the file, then he needs to run his MIME parser
on that disk file.  But if his MIME parser is part of his mail client,
he may have difficulty convincing it to parse the MIME information in a
disk file.

The second approach is to take that file and put the headers from it
(the first three lines above) into the outgoing mail header part, with
the rest of the file going into the outgoing mail body.  If you do this,
then the recipient will see the file as an ordinary MIME message and he
will be able to decrypt it easily.  However this sending mechanism is
a bit ad hoc.  The sending mail client would have to have a special kind
of file-sending mode, or recognize that a file being sent as an attachment
looks like it already has MIME headers in it, so it should be treated
specially.

Another issue related to headers is that all encrypted or signed parts
must themselves be in "MIME canonical format (body and headers)".  This
means (I think) that there needs to be one or more MIME header lines put
before the cleartext of the data which will be signed or encrypted.

As with the earlier case, confusion can arise once you move outside the
email environment.  You could clearsign a file on disk, and then later
want to encrypt it.  Now, the file already has MIME headers from clear-
signing.  Should the encryption program check and/or ask whether the file
is already in MIME canonical form, or should it just assume that it is
not, and always wrap the file in its own headers before encrypting?

Or suppose you are decrypting a PGP-MIME file.  Are you supposed to leave
the MIME headers in the output?  If the output is just some data which
the user encrypted, it would probably be best to remove the MIME headers
and undo whatever content-transfer-encoding is specified.  On the other
hand if the output is a MIME multipart, then maybe you should leave them
in.

It seems to me that MIME is not very well suited to providing the ascii
encoding for a general purpose encryption utility, unless it is tightly
integrated into a MIME-aware environment.  I would welcome suggestions for
how these situations would be handled.

A limitation with PGP-MIME is that data which is signed and encrypted must
be in 7-bit form.  This means that if you are signing and encrypting 8-bit
data, and you are going to produce ASCII output using PGP-MIME, you must
first convert the input to 7-bit form, probably using base64 encoding.
This will bloat the size of the output file.

This restriction makes sense in the email environment, where gateways may
want to strip off the encryption and leave a legal MIME message which has
no 8-bit data.  But if we are generalizing beyond mail applications this
limitation may not be appropriate.

Related to this, with PGP we have two types of "ascii" signatures:
cleartext signatures, and ascii armored non-cleartext signatures.
PGP-MIME has only one type.  There is no mechanism in PGP-MIME to create
the equivalent of an ascii armored non-cleartext signature (like what
would be created with "pgp -sa" using PGP 2.6.2).  There is also no
PGP-MIME way of encoding a detached signature, as far as I know.

In this sense, PGP-MIME is more than just a transport layer for PGP
messages.  It applies its own set of rules and semantics to the data
being transported.  While these rules are often reasonable and appropriate
for the email environment, they are not as flexible as the general
capability to transport any PGP data which PGP's ascii armor provides.

Hal Finney

Date: Fri, 21 Nov 1997 15:06:43 -0800
To: [email-masked]
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: Armour
Sender: [email-masked]

At 02:19 PM 11/21/97 -0800, Jeremey Barrett wrote:
>I thought we were discussing PGP, not email. Last time I checked noone

Responses like this are coming from a number of people.  They are, frankly,
beginning to look like willful and selective listening.  In other words,
they are highly counterproductive.

I made the email comment in response to the clear misunderstanding about
the status of email and the status of MIME usage within email.  I.e., about
the status of MIME.  The focus was not email, it was MIME.

     IS THIS CLEAR, FOLKS?  WE ARE DISCUSSING MIME, NOT EMAIL.

This point is being ignored.  We need, instead, to pay attention to it.

Let me try it yet again:

     The Internet standard way of packaging, labeling and adding transport
protection is MIME.

     It is not a political correctnet issue about the "official" choice.
It is a 
     matter of what is actually being USED.  The fact that it is not
"universal" is 
     because it is new enough to be still going through adoption, i.e.,
growing in 
     use.  The growth is going just fine, thank you very much.

     If this group insists on trying to standardize a separate mechanism
for doing the 
     same things as MIME, it will be declaring itself as separate from the
general Internet
     technical community and it will be adding entirely unnecessary
redundancy and 
     complexity to its specification and to the resulting products.

     One would think that those interested in promoting the commercial
success of PGP
     would want to be careful to avoid taking any step which would
(further) marginalize
     it from the commercial sector.

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

Date: Fri, 21 Nov 1997 15:10:47 -0800
To: Jon Callas <[email-masked]>
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: Armour
Cc: [email-masked]
Sender: [email-masked]

John,

At 05:32 PM 11/20/97 -0800, Jon Callas wrote:
>PGP objects (messages, keys, files, etc.) are constructed so as to not have
>a lot of known plaintext in them. Whatever your opinion is about this, it's

Actually, the "bracketing" aspect of armouring is specifically about adding
known plaintext, so that the boundaries of the PGP data can be detect.
But, as you say, we digress...

>Most of the present key servers, from the HTTP ones to the LDAP ones
>transport their keys in armored form. The idea that the key server has to
>have a MIME handler in it seems silly.

The web already supports MIME.  What seems REALLY silly is making it
support an additional mechanism for accomplishing the same functions.

People have been tending to refer to this debate as having to do with MIME
for email.  While it does include that, it's important to think larger.
MIME has become the Internet standard mechanism for wrapping 'documents'.
Not just for email.  

Again I would like to remind people that this debate is really about the
question of having PGP properly integrate into the Internet standards data
architecture or whether it wants to remain an independent effort (which one
might call a 'wart on the side' but that would sound more dismissive or
condescending than I really intend.)  

>PGP objects are not just mail messages. Any data-thingie that you want to

That's correct.  They need to be MIME objects and MIME isn't just email.

>encrypt can be put into PGP format, and if you don't trust raw binary,
>armor works. Let me say this again, OP is *NOT* an email-encryption
>standard, it is a data-object encryption standard (I'm quoting our esteemed

Right.  And MIME is a data packaging, labeling and protecting standard.
Each should try to focus on their own topics and not do the work of the other.

>There are people who want to put PGP, especially OP, especially a
>minimalistic OP into a number of limited environments -- pagers, PDAs,
>smart cards (which are still a few years off, as they are *really*
>limited). These people need to have a minimal set of things to implement.

If you think that these object will not already be doing MIME, you need to
look more closely into their product plans.

>I think that it is wrong to make MIME a MUST feature. It is obvious to me

See above.

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

Date: Fri, 21 Nov 1997 15:07:55 -0800
To: Dave Crocker / IMC <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Armour
Sender: [email-masked]

At 01:27 PM 11/21/97 -0800, Dave Crocker / IMC wrote:
   One more time, folks:  If you are using the absence of MIME from some
   current usage of email then you are using a fundamentally flawed argument.
   MIME is being adopted.  The rate of adoption (i.e., growth in use) is
   proceeding nicely.  We are not early in the process, so the assessment does
   not represent fantasy.
   
One more time: PGP is not limited to email. I agree wholeheartedly that in
the long-term, MIME is the answer for email and related technologies. PGP
can be used for other technologies too.

In the OpenPGP working group, we are working on a suite of documents. One
of them is OP-FORMATS. One is OP-MIME. I think it is right and proper to
encourage the use of MIME with email. I do not think it is at all proper to
saddle a pager network, an electronic commerce system, or other legitimate
uses of OpenPGP with MIME handling, when all they want to do is move a
secure block of data around.

At the BOF for the working group, our area director described PGP as an
"object encryption system" -- a term I've been using ever since, because I
think it's a good description of what PGP is. One of the important uses of
PGP is email encryption, but that is not the only use for it.

The place to solve the PEM/MOSS problem is the OP-MIME spec. Here, I have
no problems with a statement saying when someone SHOULD use MIME, and I'd
love to discuss that.

The only thing that I, Rodney, Bill Geiger, and others are objecting to is
pushing MIME into places where it is not needed nor wanted. If this stops
being a "there can be only one" type of discussion, I think you'll find us
being more cooperative. I'd love to see some suggestions on how to word
such a paragraph.

	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: Fri, 21 Nov 1997 14:19:24 -0800
To: Dave Crocker / IMC <[email-masked]>
Cc: [email-masked]
Subject: Re: Armour
From: Jeremey Barrett <[email-masked]>
Organization: BlueMoney Software Corp.
Sender: [email-masked]

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

Dave Crocker / IMC writes:
 > One more time, folks:  If you are using the absence of MIME from some
 > current usage of email then you are using a fundamentally flawed argument.
 > MIME is being adopted.  The rate of adoption (i.e., growth in use) is
 > proceeding nicely.  We are not early in the process, so the assessment does
 > not represent fantasy.

I thought we were discussing PGP, not email. Last time I checked noone
has implemented file encryption, or encrypted archiving tools, or
remailers, or keyservers, or nym servers, or anything other than
email (and on occasion news) using MIME. Nor should they.

PGP is a powerful tool, used in many different ways. ONE of them is
vanilla email. ALL of them benefit from ASCII armoring. ASCII armoring
is essential to the survival of PGP and to the security of the "PGP 
system", and the many systems built on top of it now and in the future.

 > 
 > If you are noting that some use of PGP is, or can be, outside of
 > environments that use MIME (i.e., not Internet mail and not the Web), then
 > you are right that they would have to add MIME support to work.  What you
 > are missing is that MIME has become the standard way of solving such
 > packaging, labeling and protecting requirements for the net.  
 > 
 > There is nothing wrong with PGP's having invented its own solution, at the
 > time that was done.
 > 
 > There is everything wrong with failing to switch to MIME use now.
 > 

One can implement MIME support without "switching to it". PGP/MIME is
good. PGP/MIME SHOULD be done. ASCII armor MUST be done.

Regards,
Jeremey.
- -- 
Jeremey Barrett                                BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems               http://www.bluemoney.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64

Date: Sat, 22 Nov 1997 07:43:22 +1100 (EST)
From: David Formosa <[email-masked]>
Reply-To: [email-masked]
To: Jim McCoy <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: The case against redundancy and isolation
Sender: [email-masked]

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

On Fri, 21 Nov 1997, Jim McCoy wrote:

> Contrary to the claims
> being made, a vast majority of the mail agents in use today support
> reading MIME message 

While this is true, mime complient newsreaders are not as commen.  I would
argue for the armor to be retained for news.

[...]

> Eliminating Ascii Armor has nothing to do with the security of the
> system

Agreed but I beleave that backwards capasity would cause a reduction of
the system's securaty.  Open-PGP should be capatable with PGP or we can't
call it PGP.

- -- 
Please excuse my spelling as I suffer from agraphia see the url in my header. 
Never trust a country with more peaple then sheep.  ex-net.scum and proud
You Say To People "Throw Off Your Chains" And They Make New Chains For
Themselves? --Terry Pratchett.  I do not reply to munged addresses.

Date: Fri, 21 Nov 1997 13:27:38 -0800
To: [email-masked]
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: Armour
Sender: [email-masked]

One more time, folks:  If you are using the absence of MIME from some
current usage of email then you are using a fundamentally flawed argument.
MIME is being adopted.  The rate of adoption (i.e., growth in use) is
proceeding nicely.  We are not early in the process, so the assessment does
not represent fantasy.

If you are noting that some use of PGP is, or can be, outside of
environments that use MIME (i.e., not Internet mail and not the Web), then
you are right that they would have to add MIME support to work.  What you
are missing is that MIME has become the standard way of solving such
packaging, labeling and protecting requirements for the net.  

There is nothing wrong with PGP's having invented its own solution, at the
time that was done.

There is everything wrong with failing to switch to MIME use now.

We went through this same, silly problem when PEM was being developed and
it was one of the reasons PEM died.  MOSS attempted to fix the problem but
it was too late.

It sure would be nice if folks learned some lessons from that experience.

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

Date: Fri, 21 Nov 1997 13:14:10 -0800
To: [email-masked]
From: Jim McCoy <[email-masked]>
Subject: Re: The case against redundancy and isolation
Cc: [email-masked]
Sender: [email-masked]

Jeremey Barrett <[email-masked]> wrote:
>It is equally obvious to the non-MIME mail reader that this ASCII
>armored mail message was signed. However, it is not obvious that
>a PGP/MIME signed message has anything but gibberish in it. Ever 
>used 'mail' to read a MIME message? :-)

No, and I never tried to write a device driver using 'cat'.  I know
it can be done but so what?  There comes a time when you just have to
admit that there is only so far that you will go to be backwards
compatible and these "but what if the mail agent doesn't understand
MIME?" cries are becoming a bit rediculous.  Contrary to the claims
being made, a vast majority of the mail agents in use today support
reading MIME message (and most of the people who are still using
/bin/mail or versions of elm compiled in the 1980s are smart enough
to be able to pipe things through mmencode, etc.)

>In some cases, it is useful. In other cases, it's the wrong policy.
>As Jon pointed out, PGP is not email software, there are a host
>of other applications for PGP, which might well benefit (and do)
>from ASCII armor.

I hate to burst the bubble of everyone at PGP, Inc. but right now and
for the forseeable future PGP is _only_ email.  It is not for general
purpose encryption because in those cases people use toolkits that do
not carry around as much bogus baggage as PGP does (like Ascii
Armoring for example...)

>My point is that _requiring_ MIME eliminates a set of users. That's
>all. Eliminating users decreases the security of the system, because
>less people have the necessary tools. If security is the goal (and
>as I read the wg charter, "The whole purpose of Open-PGP is to
provide
>security services") then the elimination of ASCII armor is 
>contradictory to the goals of the wg, IMO. It should be a MUST.

Requiring MIME eliminates a very small set of users and makes it
easier for developers to include support in future mailers so that
those people stuck with obsolete mail agents can find a new and
better one without too much trouble.  Eliminating Ascii Armor has
nothing to do with the security of the system (other than increasing
its complexity and the probability of bugs), if the tools use
Internet-Standard parts then it is likely that there will be more
tools available and more users.

jim

Date: Fri, 21 Nov 1997 14:36:31 -0500
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Re: Armour
Sender: [email-masked]

I don't think it is architecturally sound to assume MIME is present where
PGP is used.  I also don't think it is reasonable to assume people will
"just pipe it into their favorite un-mime/mime filter", as you can't assume
a command line environment.  I also don't think MIME is equivalent to
Armoring, as it involves multi-part processing which is more complex.

I think the armoring technique that OP inherits from PGP was useful, is
still usefull, and should not be dropped.  I don't think it's sound to
assume that "everone can do MIME", any more than it is sound to assume
"everyone can print PostScript".

>Date: Fri, 21 Nov 1997 09:27:53 +0000
>From: Ian Brown <[email-masked]>
>X-Mailer: Mozilla 4.02 [en] (WinNT; U)
>To: Jon Callas <[email-masked]>
>CC: IETF OpenPGP <[email-masked]>
>Subject: Re: Armour
>Sender: [email-masked]
>
>Jon Callas wrote:
>
>> I mean safely holding an object in any system that can't handle raw binary.
>> PGP objects (messages, keys, files, etc.) are constructed so as to not have
>> a lot of known plaintext in them. Whatever your opinion is about this, it's
>> the way PGP was designed. Phil has explained this to me in detail. This is
>> also the rationale behind such things as that a V3 private key encrypts the
>> body of the MPIs but not their length -- the length is known plaintext.
> 
>I cannot see the relevance of this to the Armour debate. All that armour
>does is take some binary PGP data and put it in a format which can be
>used in 7-bit systems. Anyone can trivially reverse the process. It
>certainly has nothing to do with the security of the underlying data.
>The binary data is fully secure before it ever sees armour. I'm
>surprised you seem to be arguing otherwise.
>
>Also, as much as I admire Phil, I thought we had agreed that "Phil has
>spoken - it must be so" was not the attitude this group should take.
>
>> There are a number of places where having an armored binary object is
>> useful. Mail is one. Network transport is another.
>
>Where MIME is also available, and does exactly the same job.
>
>> Any place where the
>> receiving program is a C program is a third (anyone who is careless enough
>> to call strfoo intead of memfoo can hurt themselves, and this is a hard bug
>> to find -- I know, I've done it).
>
>So you're suggesting that programmers can't cope with handling binary
>data, so we should convert everything to armour format first?
>
>> Most of the present key servers, from the HTTP ones to the LDAP ones
>> transport their keys in armored form. The idea that the key server has to
>> have a MIME handler in it seems silly.
>
>Why is it any sillier than having an armour handler, apart from the fact
>that you've already implemented one?
>
>> PGP objects are not just mail messages. Any data-thingie that you want to
>> encrypt can be put into PGP format, and if you don't trust raw binary,
>> armor works.
>
>What do you mean by 'trust'? The security of the underlying data?
>Armouring it doesn't increase that. Or 'trust' the encrypted object will
>be safely transported across a 7-bit system? Are you saying MIME won't
>do that?
>
>> P is *NOT* an email-encryption
>> standard, it is a data-object encryption standard (I'm quoting our esteemed
>> area director here). Of course, the most obvious use of a data-object
>> encryption standard is to send secure mail, but that is among the uses of
>> OP, not the sole one.
>
>Why are we arguing here? This is precisely the point several people have
>made. Armour is only relevant to sending binary PGP objects across 7-bit
>systems, of which mail is vastly the most common. Of course OP is not
>just an e-mail standard. This is exactly why we shouldn't be making
>systems largely used for mail transport an integral part of the
>standard.
>
>> There are people who want to put PGP, especially OP, especially a
>> minimalistic OP into a number of limited environments -- pagers, PDAs,
>> smart cards (which are still a few years off, as they are *really*
>> limited). These people need to have a minimal set of things to implement.
>
>Again, precisely the argument several people have made.
>
>> I think that it is wrong to make MIME a MUST feature.
>
>I agree! Did anyone ever say this? I said in my "draft comments" post
>that I liked the armour description in the draft, which is:
>
>> 2.4 Conversion to Radix-64
>> 
>> OP's underlying native representation for encrypted messages, signature
>> certificates, and keys is a stream of arbitrary octets.  Some systems
>> only permit the use of blocks consisting of seven-bit, printable text.
>> For transporting OP's native raw binary octets through email channels,
>> a printable encoding of these binary octets is needed.  OP provides the
>> service of converting the raw 8-bit binary octet stream to a stream of
>> printable ASCII characters, called Radix-64 encoding or ASCII Armor.
>> 
>> In principle, any printable encoding scheme that met the requirements
>> of the email channel would suffice, since it would not change the
>> underlying binary bit streams of the native OP data structures.  The OP
>> standard specifies one such printable encoding scheme to ensure
>> interoperability.
>
>> it is wrong to cut out small developers by
>> adding complexity and code size
>
>Absolutely! This is why armor shouldn't be a MUST!
>
>> I'll add as a related note that making MIME a requirement actually helps
>> PGP Inc. Our toolkit does all the MIME/armor/compression handling
>> transparently for the caller. We'll just shrug. I feel compelled myself,
>> though, as editor of this spec to argue for a simple format spec, and then
>> layer MIME handling on top of it for the benefit of the small developer.
>
>I couldn't agree more! I'm delighted it helps PGP Inc.!
>
>Ian.
>
>

Date: Fri, 21 Nov 1997 10:56:38 -0800
To: Ian Brown <[email-masked]>, "David P. Kemp" <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: CMR
Cc: IETF OpenPGP <[email-masked]>
Sender: [email-masked]

At 04:20 PM 11/21/97 +0000, Ian Brown wrote:
   
   No, I don't. But as PGP Inc are pushing CMR as a corporate solution
   which gives the ability to snoop on employees' e-mail, I just wanted to
   point out one of the negative consequences for such unethical companies
   ;-)
   
We are doing no such thing.

	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: Fri, 21 Nov 1997 10:20:58 -0800
To: Thomas Roessler <[email-masked]>
Cc: [email-masked]
Subject: Re: The case against redundancy and isolation
From: Jeremey Barrett <[email-masked]>
Organization: BlueMoney Software Corp.
Sender: [email-masked]

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

Thomas Roessler writes:
 > On November 19 1997, Jeremey Barrett wrote:
 > 
 > With MIME, it is immediately obvious to the recipient that
 > the message was signed or encrypted, whether or not they
 > may have a PGP-capable mail reader.  It is also trivial to
 > use this non-PGP-aware software to handle PGP/MIME signed
 > messages correctly when replying.  

It is equally obvious to the non-MIME mail reader that this ASCII
armored mail message was signed. However, it is not obvious that
a PGP/MIME signed message has anything but gibberish in it. Ever 
used 'mail' to read a MIME message? :-)

I'm not saying MIME is bad, I'm saying that eliminating ASCII armor
is a step in the wrong direction.

 > 
 > > I want to be able to send secure email to people who don't
 > > use MIME, that is a very useful feature of PGP in the
 > > context of email, and I don't see any reason at all to not
 > > include ASCII armoring in the draft.
 > 
 > I want to be able to send PGP-signed email to mailing
 > lists where not everybody has PGP at hand.  Nevertheless,
 > everybody should be able to properly handle my messages
 > (which might quite well include diff(1) output and similar
 > things).  Separating the cryptographic signature from the
 > message's content proper is one of the most useful
 > features of multipart/signed messages.

In some cases, it is useful. In other cases, it's the wrong policy.
As Jon pointed out, PGP is not email software, there are a host
of other applications for PGP, which might well benefit (and do)
from ASCII armor.

 > 
 > > Yes, PGP is about security, and requiring PGP users to use
 > > MIME mail readers does not result in an increase in
 > > security. Quite the opposite.
 >             ^^^^^^^^^^^^^^^^^^^
 > 
 > How do you come to this conclusion?  I'm actually quite
 > glad to use a MIME and PGP capable Mail User Agent.  And
 > yes, I'm using it from my Unix shell.  And yes, it's
 > freely available.

My point is that _requiring_ MIME eliminates a set of users. That's
all. Eliminating users decreases the security of the system, because
less people have the necessary tools. If security is the goal (and
as I read the wg charter, "The whole purpose of Open-PGP is to provide
security services") then the elimination of ASCII armor is 
contradictory to the goals of the wg, IMO. It should be a MUST.

 > 
 > > IMO ASCII-armored PGP is not a competing standard on encoding
 > > techniques, rather it is an integral part of PGP and security.
 > 
 > I beg your pardon - PGP just works fine with binaryly
 > transmitted packet files.

Yes, but ASCII armor has quite alot of use, both in email and other
applications. It's crazy to require MIME _and_ eliminate ASCII armor.

Regards,
Jeremey.
- -- 
Jeremey Barrett                                BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems               http://www.bluemoney.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64

Date: Fri, 21 Nov 1997 16:20:23 +0000
From: Ian Brown <[email-masked]>
To: "David P. Kemp" <[email-masked]>
CC: IETF OpenPGP <[email-masked]>
Subject: Re: CMR
Sender: [email-masked]

> So you accept it as a given that shredding evidence is appropriate and
> desirable behavior in a free society?  Even if said shredding is
> conducted by the White House (or #10 Downing Street)?

No, I don't. But as PGP Inc are pushing CMR as a corporate solution
which gives the ability to snoop on employees' e-mail, I just wanted to
point out one of the negative consequences for such unethical companies
;-)

Ian.

From: Uri Blumenthal <[email-masked]>
Subject: Re: Armour
To: [email-masked] (Jon Callas)
Date: Fri, 21 Nov 1997 10:16:08 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Jon Callas says:
>    Armour was a very necessary part of PGP. But now we have MIME, which is
>    meant for the same purpose - safely transmitting binary data across
>    7-bit or less mail systems.
>    
> There are a number of places where having an armored binary object is
> useful. Mail is one. Network transport is another. Any place where the
> receiving program is a C program is a third (anyone who is careless enough
> to call strfoo intead of memfoo can hurt themselves, and this is a hard bug
> to find -- I know, I've done it).

Let me summarize. MIME-things can use PGP. But MIME doesn't have to use
PGP - there could be other, alternative tools. PGP-things may use MIME.
But they may use other tools.

Thus, both PGP and MIME need to be able to cope with armouring objects
they deal with, independently from each other. Of course, when PGP is
used *with* MIME, it is enough to armour only once - but PGP does not
*force* you to armour, does it...

What's the problem?
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Fri, 21 Nov 1997 12:33:31 +0100
To: [email-masked]
From: Alex Le Heux <[email-masked]>
Subject: Ancient Technology
Sender: [email-masked]

I've been following the discussion about AsciiArmour and MIME for a 
while now, and I note some similarities with the storms of protest I 
got when I started using PGP 5.0.

In an ever faster changing world of computers regular users of PGP 
seem to be very reluctant to change anything. When something new 
comes along (or threatens to come along as is the case here), PGP 
users everywhere seem to reject it immediately. There are some people 
who _still_ refuse to upgrade to version 5.0 because 'it sucks'. The 
same argument seems to be applied to MIME here. This may be true, but 
MIME is infinitely better than Yet-Another-Way-To-Encode-Things.

The defacto standard for sending anything but plain-text-English 
emails is MIME. Ascii Armour is from the time that UUEncoding was the 
hip thing. The mailreaders of 99% of the internet users today already 
understand MIME, they don't understand AA, so adding support for 
PGP/MIME to them should be trivial.

Of course there is a strong case for continuing support for AA 
(backwards compatibility and all that), but the new standard should 
not be based on it. It's ancient technology.

Alex Le Heux

---
atrak: Don't tickle me while I'm thinking!

Date: Fri, 21 Nov 1997 11:29:31 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
Subject: Re: CMR & ROT-13 (Re: Draft comments)
Sender: [email-masked]

Adam Back wrote:
> 
> Ian Brown <[email-masked]> writes:
> > "Additional request recipients" - as this is still such a controversial
> > topic, I don't think it should be included in this first version of the
> > standard.
> 
> Seconded.
> 
> Please let's concentrate on the core functionality without dragging in
> controversial "message recovery" features.

I must have missed the start of this conversation.

I think there has been a lot of discussion on the issue.  When the CMR
thing hit the mailgroups, traffic jumped from about 2 a day (on this
group) to something like 10 per day (on the subject, that I recorded).

It would appear that community remains split on this issue, with the
mostly PGP Inc-led proponents squaring off against the mostly Cypherpunk
crypto-programmers.  This is highly unusual.  Normally, technical
discussion results in consensus on these forums, as one would expect
when one puts many highly expert voices into one confined space.

I would suggest that nobody could deny the controversiality of the
ARR/CMR feature.

If we accept the controversy as something we must deal with, then there
appear to be several options:

  1. Document the feature, and include views on the
     pros and cons, in order to guide the future programmer.

  2. Document the feature and say nothing.

  3. Propose an alternative.

  4. Stay silent.

The first option means that we have an opinion, and we have to express
it in words that will survive the critical assessment of generations of
coders.  I judge this as too difficult;  if there is no consensus in the
community, and by extension, no consensus in the WG, then we have no
opinion.  Further, to write such an opinion will require an unbiased
editor, and we have none such.

The second, then, avoids the opinion and simply leaves the programmers
to pursue at their discretion.  Such a tactic would seem innocuous, but
is in fact more insiduous than that.  Programmers and managers tend to
avoid politics.  Whilst those here are well versed on the topic, and
other in the core crypto community are equally capable of making an
independant judgement, not so the rest of the community.

Programmers, designers and managers alike look to and IETF standard as a
document of  guidance.  They have neither the time nor the patience to
pursue subtleties as they pursue the race to market.  If the feature is
in there, it will be coded up.  The appearance of the feature in the
standard is an open and solid endorsement by the WG of the merits of
this feature.  Coders will give the WG its due.

I am guessing that the WG is not happy with silent endorsement of the
AAR feature.  If it is, then the debate has not shown it, IMHO.

Proposal of an alternative is technically plausible, but not appropriate
in this forum.  We are standards body, seeking to take existing good
protocols, tidy them up into a single document and all agree to use this
single document.  Whilst there are many ways in which we can address the
general class of issues in mind, they are all experimental, and it is
not our job to sit here and write the methods in advance of market
acceptance.  That latter approach is the forte of the ISO standards
committeess, which have not been shown to be a huge success.

That leaves us with the fourth option.  Say nothing and do not document
it.

This of course will be problematic for programmers, as they test their
code against 5.x, and discover the strange packets.  I don't however see
this as a problem, as there is little to stop PGP Inc from publishing a
separate document which can become known.  As the programmers are coding
up the pgp code, and as this feature is only used by PGP Inc code, they
know where to ask.

One could say a lot more about the difficulties of ignoring a feature in
the standard.  I've found some objections, such as existing code,
conformance with the code base, need for such a feature, and I don't
think they are sufficient under this most exceptional of circumstances. 
I plumb squarely for the fourth option.  Say nothing.

In summary, I think that the WG can attempt to describe the pros and
cons, but we have no obvious means for doing that.  Or we can simply
document, at the cost of endorsing the feature as a WG supported
method.  We are not in a position to start hacking in new ideas.  

Or, we can simply say nothing and leave the feature as a new, untried
idea by one commercial venture in the marketplace for Open PGP product.

> > 6.2   - I know the inclusion of ROT-n started as a joke - but it's in
> > there! Eeeek!
> 
> I thought Jon was joking about these!  Remove at once please!

Yes, there should be no weakness.  I know ROT-n is a joke to some, but
if Caeser used it, then so can others.  If a test case is needed, it
should be plain and open.  Not that I think one is.

-- 
iang                                      systemics.com

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

Date: 21 Nov 1997 11:23:16 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: The case against redundancy and isolation
To: "A. Padgett Peterson P.E. Information Security" <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>Perhaps I am missing something but why not a MIME module type for
>AsciiArmouring ?

Its not needed - something that seems to be understated is that ASCII
Armouring is identical to the standard MIME encoding (Base64) with the
addition of a checksum, and as far as I can tell tht checksum is
unneccessary as (some) PGP packets include checksums.

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

Date: Fri, 21 Nov 1997 10:02:22 +0000
From: Ian Brown <[email-masked]>
To: IETF OpenPGP <[email-masked]>
Subject: CMR
Sender: [email-masked]

Several people have made the point that, while companies may wish to be
able to recover some stored e-mail, they most definitely do NOT want
other items to be recoverable in the case of court demands that material
be handed over. Microsoft is providing a prime example of this right
now. The Department of Justice is using, to great effect, internal
Microsoft e-mail to show that they did not originally intend to
integrate Internet Explorer with Windows.

>From today's news.com dispatches
(http://www.news.com/News/Item/0%2C4%2C16676%2C00.html?ndh.idirect):

> Through a number of
> internal Microsoft communications, the government
> attempted to counter the company's contention that
> it long intended to integrate the two technologies
> and that it clearly conveyed that intention to the
> government. 
> 
> "The sequence of documents demonstrates not only
> that the United States was not on notice of the
> alleged 'integration' of Internet Explorer, but that in
> fact Internet Explorer was not designed or
> 'developed' to be an integrated product with
> Windows 95," the government argued. 
> 
> The most dramatic piece of evidence submitted was
> email sent by [Jim] Allchin, who now heads Microsoft's
> personal and business systems group.
> 
> "I don't understand how IE is going to win," Allchin
> wrote in an email to Paul Maritz, now group vice
> president for Microsoft's platforms and applications
> group. "The current path is simply to copy
> everything that Netscape does, packaging and
> product wise...My conclusion is that we must
> leverage Windows more. Treating IE as just an
> add-on to Windows [is] losing our biggest
> advantage--Windows market share." 

Your company may take great steps to securely delete such sensitive
mail. If it has already travelled over an insecure network, it could be
intercepted and stored by a competitor. Encryption will prevent them
reading it then. But what if they get a court order demanding you hand
over your Corporate Message Recovery Key? If all your mail is also
encrypted to this CMRK, you're in trouble.

Ian.

Date: 21 Nov 1997 10:55:22 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: The Case Against MIME
To: "William H. Geiger III" <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>For the majority of e-mail messages that are currently generated 
>there is
>no reason to use MIME formatting including PGP formated messages!

There most certainly is. 

•	Any form of rich text and/or attachments must be sent via MIME. 
•	It is extremely useful to be able to separate the signature from the
message (aka RFC 1847). 
•	It co-exists comfortably with other encryption standards that use RFC 1847
•	It allows for automatic handling of PGP messages with out scanning every
message body.

OpenPGP is going to be used mainly for email messages, and MIME is the future
of email. Lack of support for MIME is not an option for email clients.

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

Date: Fri, 21 Nov 1997 09:27:53 +0000
From: Ian Brown <[email-masked]>
To: Jon Callas <[email-masked]>
CC: IETF OpenPGP <[email-masked]>
Subject: Re: Armour
Sender: [email-masked]

Jon Callas wrote:

> I mean safely holding an object in any system that can't handle raw binary.
> PGP objects (messages, keys, files, etc.) are constructed so as to not have
> a lot of known plaintext in them. Whatever your opinion is about this, it's
> the way PGP was designed. Phil has explained this to me in detail. This is
> also the rationale behind such things as that a V3 private key encrypts the
> body of the MPIs but not their length -- the length is known plaintext.
 
I cannot see the relevance of this to the Armour debate. All that armour
does is take some binary PGP data and put it in a format which can be
used in 7-bit systems. Anyone can trivially reverse the process. It
certainly has nothing to do with the security of the underlying data.
The binary data is fully secure before it ever sees armour. I'm
surprised you seem to be arguing otherwise.

Also, as much as I admire Phil, I thought we had agreed that "Phil has
spoken - it must be so" was not the attitude this group should take.

> There are a number of places where having an armored binary object is
> useful. Mail is one. Network transport is another.

Where MIME is also available, and does exactly the same job.

> Any place where the
> receiving program is a C program is a third (anyone who is careless enough
> to call strfoo intead of memfoo can hurt themselves, and this is a hard bug
> to find -- I know, I've done it).

So you're suggesting that programmers can't cope with handling binary
data, so we should convert everything to armour format first?

> Most of the present key servers, from the HTTP ones to the LDAP ones
> transport their keys in armored form. The idea that the key server has to
> have a MIME handler in it seems silly.

Why is it any sillier than having an armour handler, apart from the fact
that you've already implemented one?

> PGP objects are not just mail messages. Any data-thingie that you want to
> encrypt can be put into PGP format, and if you don't trust raw binary,
> armor works.

What do you mean by 'trust'? The security of the underlying data?
Armouring it doesn't increase that. Or 'trust' the encrypted object will
be safely transported across a 7-bit system? Are you saying MIME won't
do that?

> P is *NOT* an email-encryption
> standard, it is a data-object encryption standard (I'm quoting our esteemed
> area director here). Of course, the most obvious use of a data-object
> encryption standard is to send secure mail, but that is among the uses of
> OP, not the sole one.

Why are we arguing here? This is precisely the point several people have
made. Armour is only relevant to sending binary PGP objects across 7-bit
systems, of which mail is vastly the most common. Of course OP is not
just an e-mail standard. This is exactly why we shouldn't be making
systems largely used for mail transport an integral part of the
standard.

> There are people who want to put PGP, especially OP, especially a
> minimalistic OP into a number of limited environments -- pagers, PDAs,
> smart cards (which are still a few years off, as they are *really*
> limited). These people need to have a minimal set of things to implement.

Again, precisely the argument several people have made.

> I think that it is wrong to make MIME a MUST feature.

I agree! Did anyone ever say this? I said in my "draft comments" post
that I liked the armour description in the draft, which is:

> 2.4 Conversion to Radix-64
> 
> OP's underlying native representation for encrypted messages, signature
> certificates, and keys is a stream of arbitrary octets.  Some systems
> only permit the use of blocks consisting of seven-bit, printable text.
> For transporting OP's native raw binary octets through email channels,
> a printable encoding of these binary octets is needed.  OP provides the
> service of converting the raw 8-bit binary octet stream to a stream of
> printable ASCII characters, called Radix-64 encoding or ASCII Armor.
> 
> In principle, any printable encoding scheme that met the requirements
> of the email channel would suffice, since it would not change the
> underlying binary bit streams of the native OP data structures.  The OP
> standard specifies one such printable encoding scheme to ensure
> interoperability.

> it is wrong to cut out small developers by
> adding complexity and code size

Absolutely! This is why armor shouldn't be a MUST!

> I'll add as a related note that making MIME a requirement actually helps
> PGP Inc. Our toolkit does all the MIME/armor/compression handling
> transparently for the caller. We'll just shrug. I feel compelled myself,
> though, as editor of this spec to argue for a simple format spec, and then
> layer MIME handling on top of it for the benefit of the small developer.

I couldn't agree more! I'm delighted it helps PGP Inc.!

Ian.

Date: Thu, 20 Nov 1997 18:48:31 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: The case against redundancy and isolation
Sender: [email-masked]

--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

On November 19 1997, Jeremey Barrett wrote:

> With ASCII armored messages, it is immediately obvious to
> the recipient that the message was signed or encrypted,
> whether or not they have a MIME-capable mail reader. It is
> also trivial, with few exceptions, to invoke pgp and
> decrypt or verify the message, or to use an sdk and do it
> internally.

With MIME, it is immediately obvious to the recipient that
the message was signed or encrypted, whether or not they
may have a PGP-capable mail reader.  It is also trivial to
use this non-PGP-aware software to handle PGP/MIME signed
messages correctly when replying. =20

> I want to be able to send secure email to people who don't
> use MIME, that is a very useful feature of PGP in the
> context of email, and I don't see any reason at all to not
> include ASCII armoring in the draft.

I want to be able to send PGP-signed email to mailing
lists where not everybody has PGP at hand.  Nevertheless,
everybody should be able to properly handle my messages
(which might quite well include diff(1) output and similar
things).  Separating the cryptographic signature from the
message's content proper is one of the most useful
features of multipart/signed messages.

> There is an awful lot of utility in ASCII armoring, and it
> would be unfortunate to "standardize" it out of future PGP
> implementations. Especially considering how bloody easy it
> is to implement, relative to PGP/MIME.

Oh, a minimal PGP/MIME implementation just hands off the
second part of a multipart/encrypted attachment (which is
itself application/octet-stream) to pgp ands feeds it
output to the MIME parser once again.  This could even be
done with something like Metamail.  multipart/signed isn't
a problem at all for MIME implementations - if it doesn't
support PGP/MIME, the signature will be handled as an
unknown attachment which is absolutely correct.  Seeing
this from the implementor's side, doing PGP/MIME inside of
a MIME-capable MUA is more or less trivial, while hadling
application/pgp (aka ASCII armor) attachments properly
requires quite a bit of work.

> Yes, PGP is about security, and requiring PGP users to use
> MIME mail readers does not result in an increase in
> security. Quite the opposite.
            ^^^^^^^^^^^^^^^^^^^

How do you come to this conclusion?  I'm actually quite
glad to use a MIME and PGP capable Mail User Agent.  And
yes, I'm using it from my Unix shell.  And yes, it's
freely available.

> IMO ASCII-armored PGP is not a competing standard on encoding
> techniques, rather it is an integral part of PGP and security.

I beg your pardon - PGP just works fine with binaryly
transmitted packet files.

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

--X1bOJ3K7DJ5YkBrT
Content-Type: application/pgp-signature

--X1bOJ3K7DJ5YkBrT--

Date: Thu, 20 Nov 1997 17:32:37 -0800
To: Ian Brown <[email-masked]>, Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Armour
Cc: Bill Stewart <[email-masked]>, Adam Back <[email-masked]>, [email-masked]
Sender: [email-masked]

At 02:37 PM 11/15/97 +0000, Ian Brown wrote:
   Jon Callas wrote:
   
   > From PRZ's first documents, he labeled
   > armoring as an integral piece of PGP. It's too useful as a generalized
   > mechanism for holding an object (data, keys, etc.) without having to
worry
   > about what odd thing something will do to your binary.
   
   I'm not sure what you mean. Do you mean safely holding an object while
   it is transmitted by mail?
   
   Armour was a very necessary part of PGP. But now we have MIME, which is
   meant for the same purpose - safely transmitting binary data across
   7-bit or less mail systems.
   
I mean safely holding an object in any system that can't handle raw binary.
PGP objects (messages, keys, files, etc.) are constructed so as to not have
a lot of known plaintext in them. Whatever your opinion is about this, it's
the way PGP was designed. Phil has explained this to me in detail. This is
also the rationale behind such things as that a V3 private key encrypts the
body of the MPIs but not their length -- the length is known plaintext. But
I digress.

There are a number of places where having an armored binary object is
useful. Mail is one. Network transport is another. Any place where the
receiving program is a C program is a third (anyone who is careless enough
to call strfoo intead of memfoo can hurt themselves, and this is a hard bug
to find -- I know, I've done it).

Most of the present key servers, from the HTTP ones to the LDAP ones
transport their keys in armored form. The idea that the key server has to
have a MIME handler in it seems silly.

PGP objects are not just mail messages. Any data-thingie that you want to
encrypt can be put into PGP format, and if you don't trust raw binary,
armor works. Let me say this again, OP is *NOT* an email-encryption
standard, it is a data-object encryption standard (I'm quoting our esteemed
area director here). Of course, the most obvious use of a data-object
encryption standard is to send secure mail, but that is among the uses of
OP, not the sole one.

There are people who want to put PGP, especially OP, especially a
minimalistic OP into a number of limited environments -- pagers, PDAs,
smart cards (which are still a few years off, as they are *really*
limited). These people need to have a minimal set of things to implement.
These are, of course, all the MUST features. This is also why other
features like the hash preference are there -- there's no other way an
encrypted pager system can advertise that it has only implemented SHA-1.

I think that it is wrong to make MIME a MUST feature. It is obvious to me
that it is a SHOULD feature, but it is wrong to cut out small developers by
adding complexity and code size.

I'll add as a related note that making MIME a requirement actually helps
PGP Inc. Our toolkit does all the MIME/armor/compression handling
transparently for the caller. We'll just shrug. I feel compelled myself,
though, as editor of this spec to argue for a simple format spec, and then
layer MIME handling on top of it for the benefit of the small developer.

	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, 20 Nov 1997 13:37:04 -0800
To: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: The case against redundancy and isolation
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 08:43 AM 11/20/97 -0500, A. Padgett Peterson P.E. Information Security
wrote:
>Perhaps I am missing something but why not a MIME module type for
>AsciiArmouring ?

>However I also suspect that recognition of the type and provision for
>reduction to binary as a single pass would take so little code as to be
>negligible (easy for me to say since have not tried to do it 8*).

>However I do not understand what the controversy is about since it
>seems to be a simple matter of yet another code form.

There are two reason for the controversy, which I tried to cover in my
previous note and will try to state a bit differently:

1.  The incremental effect of more code seems to have exponential, not
linear, effects on reducing reliability while increasing deployment time
and effort.  

2.  The features that are in armouring are the same as for MIME.  I believe
that any features which armouring has which MIME does not either should be
discarded or should be added to MIME.  The botton line is that one should
not propagate multiple ways of doing the same thing.

Contrary to your assessment, I'd say that MIME can be used for exactly the
same purposes as armouring, as well as some other, possibly more general
goals.

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

Date: Thu, 20 Nov 1997 19:52:53 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: CMR & ROT-13 (Re: Draft comments)
Sender: [email-masked]

Ian Brown <[email-masked]> writes:
> "Additional request recipients" - as this is still such a controversial
> topic, I don't think it should be included in this first version of the
> standard.

Seconded.

Please let's concentrate on the core functionality without dragging in
controversial "message recovery" features.

> 6.2	- I know the inclusion of ROT-n started as a joke - but it's in
> there! Eeeek! 

I thought Jon was joking about these!  Remove at once please!

Adam

Date: Thu, 20 Nov 1997 08:43:47 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: Re: The case against redundancy and isolation
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

>IMO ASCII-armored PGP is not a competing standard on encoding
>techniques, rather it is an integral part of PGP and security.

Sorry, I may be a bit dense but do not understand this statement.

A PGP-encrypted message may be transmitted in binary or may be 
converted to an RFC 821/22 compliant form via ASCII Armoring. 
This may also be done with UUENCODE, XXENCODE, or any of a
number of different mechanisms from TekHex to YAAA - all of
which were designed to avoid filtering.

Now in my worldview, a mailreader or universal decryptor needs
to be recursive, that is it needs to examine a file for a format
that it recognizes, perform a conversion if necessary, and then
examine the result to determine if another conversion needs to
be invokes.

Further, it should be modular so that new mechanisms may be added
or old one removed as desired. My though is that an IETF standard
should be flexible in permitting addition of new mechanisms with
as little fuss as possible.

The main difference I see between AsciiArmouring and MIME is that
the former is desinged to enclose a single PGP module while the 
latter can contain multiple elements which different charactoristics.
This IMNSHO is a Good Thing. 

Perhaps I am missing something but why not a MIME module type for
AsciiArmouring ?

Personally, I agree that it is something that was added at a time when
there were no real standards (though UUENCODE could have been used)
and PGP was a command-line standalone.

However I also suspect that recognition of the type and provision for
reduction to binary as a single pass would take so little code as to be
negligible (easy for me to say since have not tried to do it 8*).

However I do not understand what the controversy is about since it
seems to be a simple matter of yet another code form.

					Warmly,
						Padgett

Date: Thu, 20 Nov 1997 10:26:56 +0000
From: Ian Brown <[email-masked]>
To: Jeremey Barrett <[email-masked]>
CC: Dave Crocker / IMC <[email-masked]>, [email-masked]
Subject: Re: The case against redundancy and isolation
Sender: [email-masked]

Jeremey Barrett wrote:
 
> Let me clarify my position a bit. I think MIME is great, and PGP/MIME
> is great. Both are necessary and I even use them from time to time.
> However, I _don't_ use them for most email, by choice, because it
> simply isn't useful.

I think several people have already given good reasons why they are
useful to *them*. Their utility will improve in time, as Dave Crocker
has already said. We *certainly* don't want to have to keep developing
armour in parallel to MIME every time a new feature (e.g. Unicode) is
needed.

> There is an awful lot of utility in ASCII armoring, and it would be
> unfortunate to "standardize" it out of future PGP implementations.
> Especially considering how bloody easy it is to implement, relative
> to PGP/MIME.

Really, you shouldn't have to do much work at all to implement MIME. The
mailer should be able to handle 99% of the encoding. You should be able
to say "Here is some binary data; its MIME type is x" - and that's all
there would be to it.

As Dave said:

> One argument for retaining the separate, PGP-specific mechanisms is that
> they aren't very expensive.  This shows a misunderstanding of the cost of
> having multiple solutions to the same problem.  Each can be incrementally
> cheap, but the combination is a pain and, more importantly, is frequently
> the source of software errors.  Besides that, a single-implementation cost
> that is small is made considerable more expensive when replicated across
> many products.

I occasionally send GIF files to people by e-mail. The only way to do
this is to use a MIME attachment. There aren't specifications for "GIF
armour" anywhere.

> I want to be able to send secure email to people who don't use MIME,
> that is a very useful feature of PGP in the context of email, and I 
> don't see any reason at all to not include ASCII armoring in the draft.
 
I agree. In the appendix is fine.

> Yes, PGP is about security, and requiring PGP users to use MIME mail
> readers does not result in an increase in security. Quite the
> opposite.

Could you please describe to us the security holes in MIME, and why they
are not present in Armour?

Ian

From: [email-masked]
To: "William H. Geiger III" <[email-masked]>
cc: Ian Brown <[email-masked]>, Thomas Roessler <[email-masked]>, IETF OpenPGP <[email-masked]>
Subject: Re: The Case Against MIME
Date: Thu, 20 Nov 1997 06:10:25 +0100
Sender: [email-masked]

>For the majority of e-mail messages that are currently generated there is
>no reason to use MIME formatting including PGP formated messages!

For the majority of e-mail messages generated in English,
failing to use any text formatting function apart from CR LF,
failing to have the characters "From " at the start of a line,
and failing to include any attachment whatsoever, your statement
is true, but irrelevant.

Come on!!!!! THINK!!!!!!!!

           Harald T. Alvestrand
       the guy with a son named Torbj=F8rn

Date: Thu, 20 Nov 1997 00:58:15 -0500
To: [email-masked]
From: Robert Guerra <[email-masked]>
Subject: CTC-PGP5 - Interoperability
Cc: [email-masked]
Sender: [email-masked]

--=-=---=-====--==----=-==---=-====--=-==-===--===
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

I'm not sure if this is the right place for this....but as it is related to
pgp and a non-pgp.com implementation of PGP perhaps it is...

regards

robert

CTC-PGP5 - Interoperability

If you have PGP5 working and can send me so specimen output please e-mail.

When we embarked on this, we had no documentation of the formats, and have
been working largely on our own
analysis of samples and the released source.

However there are now a number of documents available from the OpenPGP
Working Group in the IETF. These
include:-

       PGP Inc.'s initial documentation of PGP Message Exchange Formats
       RFC 1991, PGP Message Exchange Formats
       RFC 2015, MIME Security with Pretty Good Privacy (PGP)

We view achieving maximum interoperability with all other PGP-format
encryption software very important. PGP5.0
is currently very important.

CTC Approach

This out-lines how we intend to handle these changes and the facilities we
intend including:-

General

We are far more concerned with inter-site interoperatibility than with
individuals being able to use more than one
program on the same files on a single machine. In the short term at least,
we will be primarily interested in formats
routinely transmitted between sites (normally encrypted files, public keys
and signatures) than formats that normally
stay on the site of origin (conventional encrypted files and secret keys).

We are also far more interested in reading all formats than writing all
formats. All PGP-compatible variants in use will
read Version 3 (PGP2.6) formats. However in some cases, notably storing new
format keys in key-rings, writing
packets is also necessary for effective interoperability.

Progress

We now have all the basic operations necessary for inter-operability coded
and to at least some extent working. We
cannot claim that any of these are really "tested". The main problem is a
lack of software to test it against.

CTB format

We have implemented:-

       the correct reading of new-style CTB.

We ultimately intend to implement:-

       the writing of new-style CTBs for record types greater than 15 only.

Version 4 packets

We have implemented:-

       Reading version 4 public key certificates
       Reading sub-key certificates
       Reading version 4 signature (SKE) packets
       Writing all of the above packets

There are no immediate plans to provide for generating, reading, writing or
using DSA/D-H secret keys.

Operations

We have implemented the following operations:-

       3-DES encryption/decryption
       DSA signature verification
       D-H encryption
       New style (SHA-1 fingerprint based) calculation of key Id.s.

Difficulties

       We don't have a CAST implementation.
       We need people with working version of PGP5 to help us with testing.

[email-masked]

"They say that we are yesterday's men. They say that we represent
yesterday's ideas and values. All I can say is that perhaps it is
better than today's men, who have no ideas, and no values."
-- Pierre E. Trudeau.

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

--=-=---=-====--==----=-==---=-====--=-==-===--===
Content-Type: application/pgp-signature

--=-=---=-====--==----=-==---=-====--=-==-===--===--

Date: Wed, 19 Nov 1997 23:02:04 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: The case against redundancy and isolation
Sender: [email-masked]

Dave Crocker / IMC <[email-masked]> writes:
> PGP is about security.  All of the wrapping and encoding mechanisms in PGP
> were developed because none were available at the time it was first
> developed.  Things have changed.  There are now standards to cover these
> requirements.  This means that PGP can focus on doing what it needs to do,
> namely security, and it need no longer be burdened with assorted baggage
> for segmenting and labeling the data or for protecting it against the
> vagaries of transport.
> 
> MIME does all that.

The only remaining problem is cut and paste situations... encrypt to
clipboard, etc.  I guess you could MIME those too.

Thinking about clear text signatures (pgp -sat) does MIME have a way
to do text without putting = on the end of each line, and similarly
breaking other symbols?  (I found that most irksome, and generally
skip MIME munged articles to majordomo lists.)

> Why would you want to perpetuate unique, non-standard ways of doing
> something that is both already covered in existing standards which are in
> real use and getting more used?

I agree.

People are focussing on backwards compatibility with ascii armor.

Backwards compatibility is already broken in the MUST section.  So
armor can be another SHOULD or MAY, or simply an appendix as
suggested.

This does not mean that vendors won't implement armor; just that they
won't _have_ to implement it.  Doesn't sound that controversial to me.
William Geiger is free to implement it.  Systemics implements it
already.  PGP will probably keep it too.

> ps. I have the same line of argument against S/MIME's use of ASN.1,
> and am intrigued to see whether this group is similarly
> uncooperative towards true integration with Internet mail and web
> standards...

Ugh, please not!  ASN.1 truly does suck.  Let's keep things away from
ASN.1.  I would have thought one of the main advantages OpenPGP has
over S/MIME is that it doesn't currently go overboard on ASN.1.  Faced
with implementing one of the two -- I know I would plump for the one
which avoids ASN.1 other things being equal. 

Any ASN.1 crapola should be in an appendix.  Include the hex for magic
strings which go inside PKE packets.

Adam

Date: Wed, 19 Nov 1997 15:13:47 -0800
To: Dave Crocker / IMC <[email-masked]>
Cc: [email-masked]
Subject: Re: The case against redundancy and isolation
From: Jeremey Barrett <[email-masked]>
Organization: BlueMoney Software Corp.
Sender: [email-masked]

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

Let me clarify my position a bit. I think MIME is great, and PGP/MIME
is great. Both are necessary and I even use them from time to time.
However, I _don't_ use them for most email, by choice, because it
simply isn't useful. Instead, I clearsign everything (and occasionally
encrypt).

With ASCII armored messages, it is immediately obvious to the
recipient that the message was signed or encrypted, whether or not
they have a MIME-capable mail reader. It is also trivial, with few
exceptions, to invoke pgp and decrypt or verify the message, or to
use an sdk and do it internally. Futher, ASCII armored messages can
be shipped off to things that don't understand MIME at all.

I want to be able to send secure email to people who don't use MIME,
that is a very useful feature of PGP in the context of email, and I 
don't see any reason at all to not include ASCII armoring in the draft.

There is an awful lot of utility in ASCII armoring, and it would be
unfortunate to "standardize" it out of future PGP implementations.
Especially considering how bloody easy it is to implement, relative
to PGP/MIME.

Dave Crocker / IMC writes:
 > 
 > PGP is about security.  All of the wrapping and encoding mechanisms in PGP
 > were developed because none were available at the time it was first
 > developed.  Things have changed.  There are now standards to cover these
 > requirements.  This means that PGP can focus on doing what it needs to do,
 > namely security, and it need no longer be burdened with assorted baggage
 > for segmenting and labeling the data or for protecting it against the
 > vagaries of transport.

Yes, PGP is about security, and requiring PGP users to use MIME mail
readers does not result in an increase in security. Quite the
opposite.

 > 
 > MIME does all that. 
 > 
 > Why would you want to perpetuate unique, non-standard ways of doing
 > something that is both already covered in existing standards which are in
 > real use and getting more used?

IMO ASCII-armored PGP is not a competing standard on encoding
techniques, rather it is an integral part of PGP and security.

Regards,
Jeremey.
- -- 
Jeremey Barrett                                BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems               http://www.bluemoney.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64

Date: Wed, 19 Nov 1997 14:16:55 -0800
To: "John  W. Noerenberg" <[email-masked]>
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: Armour
Cc: Ian Brown <[email-masked]>, Jon Callas <[email-masked]>, Bill Stewart <[email-masked]>, Adam Back <[email-masked]>, [email-masked]
Sender: [email-masked]

At 01:29 PM 11/15/97 -0800, John  W. Noerenberg wrote:
>>I'm not arguing that we should totally do away with armour - just that I
>>don't think it should be a MUST, so that people who want to use OpenPGP
...
>This is probably closest to my own point of view, Ian.  The ability to
>generate and accept ascii armor must be preserved for backwards
>compatibility.  However, successfully encoding and decoding a message
>should not mandate translation through ascii armor.

Let me suggest that the cleanest way to handle this is by including its
specification in an appendix, with a note explaining that is has been used
in the past and that the capabilities defined in the appendix are needed
for processing data from these earlier (pre-standards) systems.  

This puts the old armouring mechanism outside of the formal standard but
keeps people informed about its existance and details, and the reason it
might be useful.

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

Date: Wed, 19 Nov 1997 14:11:31 -0800
To: [email-masked]
From: Dave Crocker / IMC <[email-masked]>
Subject: The case against redundancy and isolation
Sender: [email-masked]

Folks,

All of this discussion about MIME and amouring is facinating.

The fundamental question about MIME vs. non-MIME and, in general, about
behaving like an independent activity, versus integrating with existing
Internet standards, is the question of participation.

Does this group want to participate in the suite of Internet technology
standards or does it want to act in isolation and require that it provide
all its own tools?  

One comment was that MIME sucks.  While not the most professional language,
it is and entirely accurate technical assessment, in my opinion.  What that
assessment lacks is an understanding that MIME mostly sucks due to very
careful (and, I believe, necessary) engineering.  More importantly, sucky
little MIME has become the lingua franca for object labeling and
aggregation on the Internet.  It is used by email and it is used by the
Web.  There ain't much else.

Observations that you don't "need" MIME in various circumstances or that
MIME is not used all the time are entirely true, but they again miss the
point.  MIME is a relatively new standard and it is being adopted.  "Being
adopted" means that its use in not total but that it is increasing.
Arguing that some people don't use it now is no argument against having it
as a basis for a new standards effort.

Paying attention to the installed based is very important.  (It's even one
of the reasons that MIME sucks.)  But "paying attention" does not mean
doggedly shooting oneself in the foot.  As noted by others, you already
have other incompatibilities.  This is either a problem or an opportunity.

PGP is about security.  All of the wrapping and encoding mechanisms in PGP
were developed because none were available at the time it was first
developed.  Things have changed.  There are now standards to cover these
requirements.  This means that PGP can focus on doing what it needs to do,
namely security, and it need no longer be burdened with assorted baggage
for segmenting and labeling the data or for protecting it against the
vagaries of transport.  

MIME does all that. 

Why would you want to perpetuate unique, non-standard ways of doing
something that is both already covered in existing standards which are in
real use and getting more used?

One argument for retaining the separate, PGP-specific mechanisms is that
they aren't very expensive.  This shows a misunderstanding of the cost of
having multiple solutions to the same problem.  Each can be incrementally
cheap, but the combination is a pain and, more importantly, is frequently
the source of software errors.  Besides that, a single-implementation cost
that is small is made considerable more expensive when replicated across
many products.

Why not, instead, use the standards-based mechanisms for doing the
ancillary work, and then enjoy the opportunity to focus on the real
requirement, namely security? 

d/

ps. I have the same line of argument against S/MIME's use of ASN.1, and am
intrigued to see whether this group is similarly uncooperative towards true
integration with Internet mail and web standards...

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

Date: Wed, 19 Nov 1997 21:08:56 +0000
From: Ian Brown <[email-masked]>
To: Jeremey Barrett <[email-masked]>
CC: "William H. Geiger III" <[email-masked]>, [email-masked]
Subject: Re: The Case Against MIME
Sender: [email-masked]

Jeremey Barret wrote:

> Plain old non-MIME ASCII-armored PGP is one of the most 
> useful crypto tools out there, not to mention the sole basis of PGP
> integration into most mail readers that support it.

This actually misses one of the main benefits of MIME. In almost all
cases, a MIME-compliant mailer will do the decoding for you. If PGP/MIME
had a specific pgp-data type bodypart, *any* MIME-compliant mailer would
be configurable, upon receiving such a bodypart, to:

a) Remove the base64 (or whatever) encoding and
b) present the resulting binary data to any OP/PGP program

William Geiger wrote:

> As far as KISS what can be more simpler than rfc822 with a PGP Ascii
> Armor Block?

Binary data handed straight to your program?

This has further benefits:

Greg Vaudreuil wrote:

> One of the strongest reasons to use MIME encoding, even for plain text 
> messages is MIME's ability to support multiple languages and character 
> sets. While I am new to PGP, I do not believe that multi-lingual 
> support is part of PGP 2.6.X.

There is some support for using different codepages for text. But Greg
points to the main problem with continued use of armour - we have to
continue solving exactly the same problems as the MIME people. Different
character sets (Unicode would be very useful, for instance), multi-part
messages, and so on are issues armour and MIME both have to deal with.
Why not just leverage the work the MIME people are doing?

> Multilingual support is an IESG requirement for all IETF protocols 
> going forward.  At a minimum this requires identification of the 
> selected character set, and in the mail context, a way to encooding 
> these 8 or 16 bit characters into a 7 bit transfer format such as 
> Quoted Printable.

I don't think PGP has an easy method of encoding 16-bit systems such as
Unicode.

Ian.

From: [email-masked]
Date: Wed, 19 Nov 1997 11:39:50 -0800
To: Thomas Roessler <[email-masked]>, Ian Brown <[email-masked]>
Cc: IETF OpenPGP <[email-masked]>
Subject: Re[2]: The Case Against MIME
Sender: [email-masked]

--IMA.Boundary.647369978
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     One of the strongest reasons to use MIME encoding, even for plain text 
     messages is MIME's ability to support multiple languages and character 
     sets. While I am new to PGP, I do not believe that multi-lingual 
     support is part of PGP 2.6.X.  Plain text email which makes up most 
     domestic US email is not MIME encoded and uses the defined default 
     USASCII character set and the English language.  This probably is not 
     a valid assumption for the Internet as a whole.
     
     Multilingual support is an IESG requirement for all IETF protocols 
     going forward.  At a minimum this requires identification of the 
     selected character set, and in the mail context, a way to encooding 
     these 8 or 16 bit characters into a 7 bit transfer format such as 
     Quoted Printable.

     Greg V.
     
--IMA.Boundary.647369978
Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers"
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Content-Disposition: inline; filename="RFC822 message headers"

Date: Wed, 19 Nov 1997 16:19:49 +0000
From: Ian Brown <[email-masked]>
To: Thomas Roessler <[email-masked]>
CC: IETF OpenPGP <[email-masked]>
Subject: Re: The Case Against MIME
<[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

--IMA.Boundary.647369978--

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 19 Nov 97 12:08:58 -0600
To: [email-masked] (Lutz Donnerhacke)
Cc: [email-masked]
Subject: Re: Ascii Armor solution?
Sender: [email-masked]

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

In <[email-masked]>, on 11/19/97 
   at 05:50 PM, [email-masked] (Lutz Donnerhacke) said:

>* William H. Geiger III wrote:
>>I will release my subroutines w/source for ascii-armor encoding/decoding
>>into the public domain. That way everyone will have them available to use
>>as they wish free of charge.
>>
>>Will this be an acceptable solution to the "problem"??

>No. The problem is not programming efforts (which is quite simple to
>handle), the problem is the KISS principle. Ascii Armor is simply
>outdated.

Well I don't believe that the case has been made that Ascii Armor is
outdated.

As far as KISS what can be more simpler than rfc822 with a PGP Ascii Armor
Block? Not to mention the fact that everyone currently using PGP can read
it.

Sorry but those wishing to drop Ascii-Armor have not made a cost/benefit
case (ie the cost of droping ascii armor out weigh the benefits of doing
so).

- -- 
- ---------------------------------------------------------------
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, 19 Nov 1997 10:15:05 -0800
To: "William H. Geiger III" <[email-masked]>
Cc: [email-masked]
Subject: Re: The Case Against MIME
From: Jeremey Barrett <[email-masked]>
Organization: BlueMoney Software Corp.
Sender: [email-masked]

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

William H. Geiger III writes:
 > 
 > There seems to be several members that are in favor of dropping Ascii
 > Armour, and MIME formatting all PGP messages. 
 > 
 > I would like to present the case that this is not necessary nor even
 > recommended!
 > 
 > The majority of PGP users are using 2.6.x and will be for a long time to
 > come. This is fact regardless of wether one likes it or not. Switching
 > formats for the sake of some MIME "purity" at the expense of compatibility
 > is a foolhardy gesture.

Absolutely. Plain old non-MIME ASCII-armored PGP is one of the most 
useful crypto tools out there, not to mention the sole basis of PGP
integration into most mail readers that support it.

Frankly, MIME sucks. PGP/MIME is needed for those (very) rare
occasions when one needs to encrypt MIME attachments, etc, but it 
is not useful in 90% of email. Making it the only way to send PGP
email is just plain dumb IMHO.

Regards,
Jeremey.
- -- 
Jeremey Barrett                                BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems               http://www.bluemoney.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 19 Nov 97 11:50:17 -0600
To: Ian Brown <[email-masked]>
Cc: "William H. Geiger III" <[email-masked]>, [email-masked]
Subject: Re: Ascii Armor solution?
Sender: [email-masked]

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

In <[email-masked]>, on 11/19/97 
   at 12:38 PM, Ian Brown <[email-masked]> said:

>> I have a proposal for the group in a effort to put the Ascii-Armor
>> question to rest.
>> 
>> I will release my subroutines w/source for ascii-armor encoding/decoding
>> into the public domain. That way everyone will have them available to use
>> as they wish free of charge.
>> 
>> Will this be an acceptable solution to the "problem"??

>Such freely available toolkits already exist (see, for example,
>http://www.systemics.com/software/cryptix-java/)

>This does not alter the fact that implementors would need to download,
>understand, and adapt such code to work in their subsequently bloated
>application.

This has to be the silliest of excuses for not incorporating Ascii-Armour.
Exactly how many extra lines of code do you think it will take to
implement?? Compare that to the size of any Open-PGP implementation and
anyone can see this is a non-issue.

BTW: I did get a chuckle of you using a Java lib as an example. Anyone
writting a Java based app has bigger bloat problems than a couple of
ascii-armour routines to worry about. :)

- -- 
- ---------------------------------------------------------------
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]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Ascii Armor solution?
Date: 19 Nov 1997 17:50:12 GMT
Organization: IKS GmbH Jena
Lines: 9
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* William H. Geiger III wrote:
>I will release my subroutines w/source for ascii-armor encoding/decoding
>into the public domain. That way everyone will have them available to use
>as they wish free of charge.
>
>Will this be an acceptable solution to the "problem"??

No. The problem is not programming efforts (which is quite simple to
handle), the problem is the KISS principle. Ascii Armor is simply outdated.

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 19 Nov 97 11:40:49 -0600
To: Ian Brown <[email-masked]>
Cc: Thomas Roessler <[email-masked]>, IETF OpenPGP <[email-masked]>
Subject: Re: The Case Against MIME
Sender: [email-masked]

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

In <[email-masked]>, on 11/19/97 
   at 11:19 AM, Ian Brown <[email-masked]> said:

>> > It isn't for "purity"; it is to make it easier for new
>> > implementors to create compatible versions without
>> > unnecessary impediments. They can obtain MIME toolkits
>> > more easily than Armour ones. Or even just let mail
>> > programs handle the encoding of the binary data.
>> 
>> Partdon me, this is not true.  The only difference between
>> ASCII Armor and MIME's base64 are the armor header and the
>> CRC.

>I do know this. So a MIME toolkit writes armour headers and CRCs?

>> To make 2.6 understand MIME encoded PGP messages,
>> just use mmencode -u -b | pgp -f - it will work on unix
>> systems; porting mmencode to other OS'es will be quite
>> trivial.

>An excellent reason for saying we *don't* need armour.

>The difficulty is not in reading it but in *writing* it. We don't want
>new implementations to have to mess around with armour headers and CRCs.

>mmencode shows a way that even PGP 2.6 could be made to work with MIME
>rather than armour.

What you are assuming is that all Open-PGP implementations will be using
MIME. Not only do I think that this will not be the case more improtantly
it SHOULD NOT be the case.

For the majority of e-mail messages that are currently generated there is
no reason to use MIME formatting including PGP formated messages!

- -- 
- ---------------------------------------------------------------
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, 19 Nov 1997 17:38:03 +0000
From: Ian Brown <[email-masked]>
To: "William H. Geiger III" <[email-masked]>
CC: [email-masked]
Subject: Re: Ascii Armor solution?
Sender: [email-masked]

> I have a proposal for the group in a effort to put the Ascii-Armor
> question to rest.
> 
> I will release my subroutines w/source for ascii-armor encoding/decoding
> into the public domain. That way everyone will have them available to use
> as they wish free of charge.
> 
> Will this be an acceptable solution to the "problem"??

Such freely available toolkits already exist (see, for example,
http://www.systemics.com/software/cryptix-java/)

This does not alter the fact that implementors would need to download,
understand, and adapt such code to work in their subsequently bloated
application.

Paul Hoffman wrote, quoting you:

> >This is silly, I really can't see anyone saying "I'm not going to support
> >PGP because it uses ASCII armor encoding".
> 
> By itself, no. But if we require lots of other things that make it that
> much harder for people to implement (such as requiring them being able to
> handle all the earlier packet formats), they will probably have the same
> attitude as they have had up to now: "I won't bother". That hurts all of
> us, and is one of the driving forces for us to make a simple and useful spec.

Ian.

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 19 Nov 97 11:16:11 -0600
To: [email-masked]
Subject: Ascii Armor solution?
Sender: [email-masked]

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

I have a proposal for the group in a effort to put the Ascii-Armor
question to rest.

I will release my subroutines w/source for ascii-armor encoding/decoding
into the public domain. That way everyone will have them available to use
as they wish free of charge.

Will this be an acceptable solution to the "problem"??

- -- 
- ---------------------------------------------------------------
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, 19 Nov 1997 16:19:49 +0000
From: Ian Brown <[email-masked]>
To: Thomas Roessler <[email-masked]>
CC: IETF OpenPGP <[email-masked]>
Subject: Re: The Case Against MIME
Sender: [email-masked]

> > It isn't for "purity"; it is to make it easier for new
> > implementors to create compatible versions without
> > unnecessary impediments. They can obtain MIME toolkits
> > more easily than Armour ones. Or even just let mail
> > programs handle the encoding of the binary data.
> 
> Partdon me, this is not true.  The only difference between
> ASCII Armor and MIME's base64 are the armor header and the
> CRC.

I do know this. So a MIME toolkit writes armour headers and CRCs?

> To make 2.6 understand MIME encoded PGP messages,
> just use mmencode -u -b | pgp -f - it will work on unix
> systems; porting mmencode to other OS'es will be quite
> trivial.

An excellent reason for saying we *don't* need armour.

The difficulty is not in reading it but in *writing* it. We don't want
new implementations to have to mess around with armour headers and CRCs.

mmencode shows a way that even PGP 2.6 could be made to work with MIME
rather than armour.

Ian.

Date: Wed, 19 Nov 1997 17:03:20 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: The Case Against MIME
Sender: [email-masked]

Ian Brown wrote:

> It isn't for "purity"; it is to make it easier for new
> implementors to create compatible versions without
> unnecessary impediments. They can obtain MIME toolkits
> more easily than Armour ones. Or even just let mail
> programs handle the encoding of the binary data.

Partdon me, this is not true.  The only difference between
ASCII Armor and MIME's base64 are the armor header and the
CRC.  To make 2.6 understand MIME encoded PGP messages,
just use mmencode -u -b | pgp -f - it will work on unix
systems; porting mmencode to other OS'es will be quite
trivial.

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

Date: Wed, 19 Nov 1997 15:53:27 +0000
From: Ian Brown <[email-masked]>
To: "William H. Geiger III" <[email-masked]>
CC: [email-masked]
Subject: Re: The Case Against MIME
Sender: [email-masked]

> The majority of PGP users are using 2.6.x and will be for a long time to
> come. This is fact regardless of wether one likes it or not.

There is a lot of stuff in OP which just will not work with PGP 2.6.x.
Strictly speaking, a MUST-only implementation would be totally
incompatible with PGP 2.6 as it won't do IDEA or RSA. Armour is the
least of our worries there.

> Switching formats for the sake of some MIME "purity" at the expense of
> compatibility is a foolhardy gesture.

It isn't for "purity"; it is to make it easier for new implementors to
create compatible versions without unnecessary impediments. They can
obtain MIME toolkits more easily than Armour ones. Or even just let mail
programs handle the encoding of the binary data.

> > BEGIN PGP MESSAGE, PART X/Y used for multi-part messages, where the
> > armor is split amongst Y parts, and this is the Xth part out of Y.
> 
> > BEGIN PGP MESSAGE, PART X used for multi-part messages, where this is
> > the Xth part of an unspecified number of parts. Requires the MESSAGE-ID
> > Armor Header to be used.
> 
> These formats for multi-part messages are not re-inventing the wheel, they
> are the wheels that all current versions of PGP ride on.

The second, PART X, is a new invention in PGP 5 and thus not relevant to
"the majority of PGP users [that] are using 2.6.x".

> I highly doubt that the MIME Message/Partial subtype is widely implemented
> among the current crop of MIME "compliant" Mua's (considering that Mua's
> like Netscape & Eudora do not make use of multipart/alternative it is
> doubtful that few if any make use of Message/Partial).

So they're even less likely to implement yet another multipart message
scheme.

> I am also STRONGLY against using Base64 encoding of PGP packets. IMNSHO it
> should be allowed for special case implementations but SHOULD NOT be used
> in general e-mail applications. All this servers to do is break all
> existsing PGP implementations without any added benefit.

I'm not sure what you mean by this.

Ian.

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 19 Nov 97 08:26:47 -0600
To: [email-masked]
Subject: The Case Against MIME
Sender: [email-masked]

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

Hi,

There seems to be several members that are in favor of dropping Ascii
Armour, and MIME formatting all PGP messages. 

I would like to present the case that this is not necessary nor even
recommended!

The majority of PGP users are using 2.6.x and will be for a long time to
come. This is fact regardless of wether one likes it or not. Switching
formats for the sake of some MIME "purity" at the expense of compatibility
is a foolhardy gesture.

> BEGIN PGP MESSAGE, PART X/Y used for multi-part messages, where the
> armor is split amongst Y parts, and this is the Xth part out of Y.

> BEGIN PGP MESSAGE, PART X used for multi-part messages, where this is
> the Xth part of an unspecified number of parts. Requires the MESSAGE-ID
> Armor Header to be used.

These formats for multi-part messages are not re-inventing the wheel, they
are the wheels that all current versions of PGP ride on.

I highly doubt that the MIME Message/Partial subtype is widely implemented
among the current crop of MIME "compliant" Mua's (considering that Mua's
like Netscape & Eudora do not make use of multipart/alternative it is
doubtful that few if any make use of Message/Partial).

There are still a large number of users who do not use MIME Mua's at all.
In all reality MIME is quite over-rated and is not needed for the majority
of e-mail messages! Why jump through the hoops of MIME formatting if it's
not needed?? (I still get a laugh when I see a plain text message MIME
formatted).

This is not to say that there is not a place for MIME just that one should
use the right tool for the right job. If a particular situation calls for
MIME formatting of a PGP message then RFC 2015 should be followed but I do
not think that the Open-PGP specs should push the developer in the
direction that ALL messages should be in that format.

In my current 2015 implementation the default action is to only MIME
format PGP messages if the message before signing/encrypting is in MIME
format (the user has 3 settings options Never use MIME, MIME on MIME
messages [default], always use MIME).

I am also STRONGLY against using Base64 encoding of PGP packets. IMNSHO it
should be allowed for special case implementations but SHOULD NOT be used
in general e-mail applications. All this servers to do is break all
existsing PGP implementations without any added benefit.

- -- 
- ---------------------------------------------------------------
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, 19 Nov 1997 13:32:12 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: A first set of comments
Sender: [email-masked]

I'm currently working my way through the draft.  Yesterday
night's results follow:

> BEGIN PGP MESSAGE, PART X/Y used for multi-part messages, where the
> armor is split amongst Y parts, and this is the Xth part out of Y.

> BEGIN PGP MESSAGE, PART X used for multi-part messages, where this is
> the Xth part of an unspecified number of parts. Requires the MESSAGE-ID
> Armor Header to be used.

I don't see any need for this in the specification: In
virtually all situations I can imagine there are more
appropriate ways to accomplish the same result:

· If OP is used for local data storage, splitting stored
  data will be handled by the traditional methods
  (split(1) ;-) which will work for encrypted data the
  same way they are working for unencrypted data.

· When using OP for data transmission, this will almost
  always be in some kind of PGP/MIME context, thus MIME's
  partial message methods can be used.  No need to
  reinvent the wheel.

> The Armor Headers are pairs of strings that can give the user or the
> receiving OP message block some information about how to decode or use
> the message.  The Armor Headers are a part of the armor, not a part of
> the message, and hence are not protected by any signatures applied to
> the message.

> The format of an Armor Header is that of a key-value pair.  A colon
> (':' 0x38) and a single space (0x20) separate the key and value.  OP
> should consider improperly formatted Armor Headers to be corruption of
> the ASCII Armor.  Unknown keys should be reported to the user, but OP
> should continue to process the message.  Currently defined Armor Header
> Keys include "Version" and "Comment", which define the OP Version used
> to encode the message and a user-defined comment.

One could refer to the e-mail standards' definition of
headers for this part.  It's describing almost the same
format, and it's widely used.

> The MessageID should not appear unless it is in a
> multi-part message. If it appears at all, it should be
> computed from the message in a deterministic fashion,
> rather than contain a purely random value.  This is to
> allow anyone to determine that the MessageID cannot serve
> as a covert means of leaking cryptographic key
> information.

Phrase this as follows: "The MessageID header should not
appear except in multi-part messages.  It MUST be computed
as a deterministic function of the armored message data.
Implementors SHOULD use an SHA1 value of the armored
message data concatenated with a string indicating the
time of the message generation."

Rationale: We should prescribe a method to get things
clear; SHA1(armor + time) gives us the necessary amount of
"randomness".

Anyway, the MessageID header is actually not needed.

For extensibility, we should permit X-something armor
headers which MAY be used by specific implementations for
their own purposes.

The precise specification of the radix64 format is not
needed in the present text - the reader can be referred to
RFC2045.

> Sometimes it is necessary to sign a textual octet stream 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.)

"Whenever possible and applicable, RFC 2015's method
should be preferred over clear signing material."

> If the "Hash" armor header is given, the specified message digest
> algorithm is used for the signature.  If this header is missing, SHA-1
> is assumed.  If more than one message digest is used in the signature,

You mean MD5 here, as that's used in PGP 2 which doesn't
add the Hash header.

> Dash escaped cleartext is the ordinary cleartext where every line
> starting with a dash '-' (0x2D) is prepended by the sequence dash '-'
> (0x2D) and space ' ' (0x20).  This prevents the parser from recognizing
> armor headers of the cleartext itself.  The message digest is computed
> using the cleartext itself, not the dash escaped form.

In 2.6, the same is valid for lines beginning with the
five characters "From ".  I think we should stick with
this convention since clear signing messages will mostly
be used in legacy environments which don't support MIME
(and will mangle From_ lines).

> {{Editor's note: This is very complex, with bizarre things
> like an 8-bit floating point format.  Should we just drop
> it? --jdcc}}

Nope, it may be of some use at some point in the future.
See also /etc/shadow. ;)

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

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Draft comments
Date: 19 Nov 1997 12:23:31 GMT
Organization: IKS GmbH Jena
Lines: 84
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Ian Brown wrote:
>2.4.1	- Just one quibble. Since Armour is largely for backward
>compatibility with the 4 million users of PGP 2.6, do we *really* need
>to add a new header (BEGIN PGP MESSAGE, PART X)? If this went, could
>Message-ID also go? It does say in PGP/MIME that "When the amount of
>data to be transmitted requires that it be sent in many parts, the MIME
>message/partial mechanism should be used rather than the multipart ASCII
>armor PGP format."

Good Idea.

>2.6	- I'm not sure what jdcc means by "Should the armor header line stay
>or go... I think anything that reduces parsing complexity is a Good
>Thing." I agree, but by this do you mean it saves implementations
>parsing the algorithm fields in the actual signature itself?

No. The new line is completely sensless IMHO, because directly after this
header line the armor header follows. There the Hash codes are already
present.

>5.1	- "An implementation should accept, but not generate a version of 2,
>which is equivalent to V3 in all other respects." Is this purely for
>legal (RSAREF) reasons? The international version of PGP 2.6 can
>generate V2 packets for backwards compatibility (LEGAL_KLUDGE=off). Is
>there any *technical* reason why OP implementations should not generate
>version 2 packets?

Public key encrypted session keys are stored in a completely other padding
format. Same goes for hash paddings in signatures. So there es a major
difference between v2 and v3. For backward compatibility you may refer to
1991 or describe it.

>5.2.	- Ditto, "Implementations SHOULD generate V4 signatures, unless
>there is a need to generate a signature that can be verified by PGP
>2.6.x.". Could this not be "Implementations SHOULD generate V3/2
>signatures if possible, for backwards compatibility. Only packets that
>would not be understood by PGP 2.6.x should have a version number of 4"?

Keeping the technical difference above in mind, you have to use exactly the
same format version the public key of the recipient is stored in.

>"Preferred hash algorithms" - you mention "If this subpacket is not
>included, ZIP is preferred." Would it be useful to put a sentence of
>this type in the preferred symmetric and hash algorithms also? We have
>3DES and SHA-1 as MUSTs, so they could be used...

ZIP is not MUST, so: 'If this subpacket is not included, uncompressed is
preferred." Only use MUST values as defaults.

>> {{Editor's note:  While there is a scale of identification signatures
>> in the range 0x10 to 0x13, most of them have never been implemented or
>> used.  Current implementations only use 0x10, the "generic
>> certification." Should the others be removed?  RFC 1991 went to some
>> trouble to explain which ones were defined but not implemented, or read
>> but not generated.  I think we should not do that.  If we define them,
>> they should be MAY features at the very least.  If we're not going to
>> use them, they shouldn't be in the spec. --jdcc}}
>
>They were a good idea, but seem to be obseleted by the trust subpackets.
>In which case, you're right - get rid of them.

Trust packets are not transferable. There are several implementations known
to use these signatures heavily.

>> {{Editor's note:  There is presently no way for a key-signer (a.k.a.
>> certifier) to sign a main key along with a subkey.  There are a number
>> of useful situations for a set of keys (main plus subkeys) to all be
>> signed together... --jdcc}}
>
>Could you give a few examples?

If you try to exchange a whole packet on a keyserver, you must sign all key
material incl. subkeys at once.

>5.4	- Is the one-pass signature packet *really* necessary?

Yes, software knows in advance which hashs are used in the signature below.
This is necessary for one pass implementations. I choosed to calculate all
hashs in my one pass implementation. But this can be messy.

>8.1	- Why not use the BNF-like notation from section 7.2 to describe
>keyring structure also?

Not enough time ;-)

Date: Wed, 19 Nov 1997 11:04:52 +0000
From: Ian Brown <[email-masked]>
To: IETF OpenPGP <[email-masked]>
Subject: Draft comments
Sender: [email-masked]

Took a while to plough through!

It's a pretty good document overall - please don't take the following
comments as quibbling in any way, I'm just trying to contribute ;-)

Sec	Comments

2.4	- Like the description of armour
	- If ithe checksum is remaining, I think jdcc's idea to put a sample
implementation in C in the appendix is good - we don't want people to
have to dig out (possibly out of print) books.

2.4.1	- Just one quibble. Since Armour is largely for backward
compatibility with the 4 million users of PGP 2.6, do we *really* need
to add a new header (BEGIN PGP MESSAGE, PART X)? If this went, could
Message-ID also go? It does say in PGP/MIME that "When the amount of
data to be transmitted requires that it be sent in many parts, the MIME
message/partial mechanism should be used rather than the multipart ASCII
armor PGP format."

2.6	- I'm not sure what jdcc means by "Should the armor header line stay
or go... I think anything that reduces parsing complexity is a Good
Thing." I agree, but by this do you mean it saves implementations
parsing the algorithm fields in the actual signature itself?

3.5	- Are the S2K functions really necessary? Are dictionary attacks on
passphrases in an (at least) 128-bit keyspace likely to be successful?
If so, I still agree with jdcc that the Iterated-Salted algorithm should
be dropped.

5.1	- "An implementation should accept, but not generate a version of 2,
which is equivalent to V3 in all other respects." Is this purely for
legal (RSAREF) reasons? The international version of PGP 2.6 can
generate V2 packets for backwards compatibility (LEGAL_KLUDGE=off). Is
there any *technical* reason why OP implementations should not generate
version 2 packets?

5.2.	- Ditto, "Implementations SHOULD generate V4 signatures, unless
there is a need to generate a signature that can be verified by PGP
2.6.x.". Could this not be "Implementations SHOULD generate V3/2
signatures if possible, for backwards compatibility. Only packets that
would not be understood by PGP 2.6.x should have a version number of 4"?

5.1 + 5.2.1 - You mention ASN.1 and PKCS-1. While it's good to have
everything properly attributed, do we need to get simple implementations
involved in these horrors ;-)

5.2.2.2

"Preferred hash algorithms" - you mention "If this subpacket is not
included, ZIP is preferred." Would it be useful to put a sentence of
this type in the preferred symmetric and hash algorithms also? We have
3DES and SHA-1 as MUSTs, so they could be used...

"Additional request recipients" - as this is still such a controversial
topic, I don't think it should be included in this first version of the
standard.

5.2.3	- Signature types

> {{Editor's note:  While there is a scale of identification signatures
> in the range 0x10 to 0x13, most of them have never been implemented or
> used.  Current implementations only use 0x10, the "generic
> certification." Should the others be removed?  RFC 1991 went to some
> trouble to explain which ones were defined but not implemented, or read
> but not generated.  I think we should not do that.  If we define them,
> they should be MAY features at the very least.  If we're not going to
> use them, they shouldn't be in the spec. --jdcc}}

They were a good idea, but seem to be obseleted by the trust subpackets.
In which case, you're right - get rid of them.

> {{Editor's note:  It would be nice to have a signature that applied to
> the key alone, rather than a key plus a user name... --jdcc}}

What would it mean to have just key material signed by someone else?

> {{Editor's note:  There is presently no way for a key-signer (a.k.a.
> certifier) to sign a main key along with a subkey.  There are a number
> of useful situations for a set of keys (main plus subkeys) to all be
> signed together... --jdcc}}

Could you give a few examples?

5.4	- Is the one-pass signature packet *really* necessary?

5.10	- I think you're right about there being so many problems with
Trust packets, we should forget them. Your idea about them being
implementation dependent is good, except that different OP
implementations may want to use the same keyring. For example, I use PGP
2.6.3i and my mail encrypting program with the same keyring. If they
implement trust packets differently, it would be very confusing. I think
we should just specify that they should be ignored.

6.2	- I know the inclusion of ROT-n started as a joke - but it's in
there! Eeeek! Also, excuse my ignorance, but what is DES/SK?

8.1	- Why not use the BNF-like notation from section 7.2 to describe
keyring structure also?

Ian :D

From: [email-masked]
Date: Tue, 18 Nov 1997 09:40:16 -0800
To: [email-masked]
Original-From: Bill Stewart <[email-masked]>
Subject: I-D ACTION:draft-ietf-openpgp-formats-00.txt
Cc: [email-masked]
Sender: [email-masked]

Forwarded from [email-masked] and [email-masked]
---------------------------------------------------------------
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: OP Formats - OpenPGP Message Format
	Author(s)	: R. Thayer, J. Callas, L. Donnerhacke, H. Finney
	Filename	: draft-ietf-openpgp-formats-00.txt
	Pages		: 40
	Date		: 17-Nov-97
	
This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on the
OP format.  It is not a step-by-step cookbook for writing an
application, it describes only the format and methods needed to read,
check, generate and write conforming packets crossing any network.  It
does not deal with storing and implementation questions albeit it is
necessary to avoid security flaws.
 
OP (Open-PGP) software uses a combination of strong public-key and
conventional cryptography to provide security services for electronic
communications and data storage.  These services include
confidentiality, key management, authentication and digital signatures.
This document specifies the message formats used in OP.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-formats-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-openpgp-formats-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-formats-00.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-formats-00.txt

<ftp://ds.internic.net/internet-drafts/draft-ietf-openpgp-formats-00.txt>

				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Tue, 18 Nov 1997 08:06:24 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-00.txt
Sender: [email-masked]

At 09:45 AM 11/18/97 -0500, [email-masked] wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the An Open Specification for Pretty Good
Privacy Working Group of the IETF.
>
>	Title		: OP Formats - OpenPGP Message Format
>	Author(s)	: R. Thayer, J. Callas, L. Donnerhacke, H. Finney
>	Filename	: draft-ietf-openpgp-formats-00.txt
>	Pages		: 40
>	Date		: 17-Nov-97
>	

This is also available as <http://www.imc.org/draft-ietf-openpgp-formats>.
As the draft gets revised in the future, this URL will always point to the
latest version.

--Paul Hoffman, Director
--Internet Mail Consortium

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-formats-00.txt
Date: Tue, 18 Nov 1997 09:45:05 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: OP Formats - OpenPGP Message Format
	Author(s)	: R. Thayer, J. Callas, L. Donnerhacke, H. Finney
	Filename	: draft-ietf-openpgp-formats-00.txt
	Pages		: 40
	Date		: 17-Nov-97
	
This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on the
OP format.  It is not a step-by-step cookbook for writing an
application, it describes only the format and methods needed to read,
check, generate and write conforming packets crossing any network.  It
does not deal with storing and implementation questions albeit it is
necessary to avoid security flaws.
 
OP (Open-PGP) software uses a combination of strong public-key and
conventional cryptography to provide security services for electronic
communications and data storage.  These services include
confidentiality, key management, authentication and digital signatures.
This document specifies the message formats used in OP.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-formats-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-openpgp-formats-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-formats-00.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-formats-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-formats-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 17 Nov 1997 19:25:28 -0800
To: Ian Brown <[email-masked]>, Jon Callas <[email-masked]>
From: Bill Stewart <[email-masked]>
Subject: Re: Armour
Cc: Adam Back <[email-masked]>, [email-masked]
Sender: [email-masked]

At 02:37 PM 11/15/1997 +0000, Ian Brown wrote:
>I'm not sure what you mean. Do you mean safely holding an object while
>it is transmitted by mail?
>Armour was a very necessary part of PGP. But now we have MIME, which is
>meant for the same purpose - safely transmitting binary data across
>7-bit or less mail systems.

Same primary purpose, and it we were starting from scratch there'd be no need
for two similar but different systems.  But we're not -
all the existing versions of PGP generate and read PGP-armor, 
some parts of even PGP 5.0 don't have a mechanism for inputting MIME or binary,
like the Encrypt/Decrypt/Sign/Verify-From-Clipboard mechanisms,
and you'll lose compatibility with all of them if you drop armor.
MIME, on the other hand, tries to do far more than just armor,
with lots of complexity, registered object types, unregistered object types,
interaction with mail systems that should maybe leave the encrypted part alone,
and a whole lot of other ballast that may not belong in a pocket organizer.
And mail user agents aren't the only places people use PGP.

>I'm not arguing that we should totally do away with armour - just that I
>don't think it should be a MUST, so that people who want to use OpenPGP
>in their program or standard minimally, with no need for backwards
>compatibility, can do it with as little problem as possible.

Losing compatibility may be worthwhile for avoiding patent encumbrances,
but it's a serious mistake for an "OpenPGP" to do so just for aesthetic purity.
If you want S/MIME, use S/MIME.  If you want PGP, you need to interact with PGP.
I agree that there were other choices of armor that PRZ should have used,
like uuencode or maybe btoa, but this is what we've got.
Meanwhile, while ASCII armor may mean adding another MIME type,
the amount of code involved is a small part of the total,
and it's easy for an OpenPGP program to tell which input it's getting.

				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Mon, 17 Nov 1997 09:56:56 -0800
From: Karen Rosenthal <[email-masked]>
Organization: Premenos
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Receipt mechanism(s)
Sender: [email-masked]

Chuck,

Has there ever been any thought/discussion of pulling the signed receipt
section out of the MIME-based Secure EDI draft, and into a working
group/draft of its own?

The MDN based signed receipts address some of the issues coming up in
the S/MIME receipt discussions, are really not EDI specific.  Both the
S/MIME and PGP groups are looking for receipt mechanisms  (the former
obviously more actively), and there has been talk before of trying to
combine efforts between the two groups, where appropriate.

Sure, we can all support Message Disposition Notifications, S/MIME
receipts, some day PGP receipts, AUTACKs, etc, but is there not benefit
in a well developed, centralized and higher-level receipt mechanism?

Regards,
--
Karen Rosenthal               Email: [email-masked]
Premenos                      Tel#:  1-510-688-2928
1000 Burnett Ave              Fax#:  1-510-602-2133
Concord, CA  94520            Visit: http://www.premenos.com

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: extension mechanism needed
Date: 17 Nov 1997 13:24:51 GMT
Organization: IKS GmbH Jena
Lines: 5
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Adam Back wrote:
[Two new extensions]
>What more could we ask for :-)

Interoperability.

Date: Sat, 15 Nov 1997 13:29:06 -0800
To: Ian Brown <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: Armour
Cc: Jon Callas <[email-masked]>, Bill Stewart <[email-masked]>, Adam Back <[email-masked]>, [email-masked]
Sender: [email-masked]

At 2:37 PM +0000 11/15/97, Ian Brown wrote:
>
>I'm not arguing that we should totally do away with armour - just that I
>don't think it should be a MUST, so that people who want to use OpenPGP
>in their program or standard minimally, with no need for backwards
>compatibility, can do it with as little problem as possible.
>

This is probably closest to my own point of view, Ian.  The ability to
generate and accept ascii armor must be preserved for backwards
compatibility.  However, successfully encoding and decoding a message
should not mandate translation through ascii armor.

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: Sat, 15 Nov 1997 13:19:04 -0800
To: [email-masked]
From: "John  W. Noerenberg" <[email-masked]>
Subject: Draft on the way
Sender: [email-masked]

Keep an eye out for an message from Internet-Drafts that it has been
posted.  I've sent it off to the internet-drafts editor.

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: Sat, 15 Nov 1997 14:37:57 +0000
From: Ian Brown <[email-masked]>
To: Jon Callas <[email-masked]>
CC: Bill Stewart <[email-masked]>, Adam Back <[email-masked]>, [email-masked]
Subject: Armour
Sender: [email-masked]

Jon Callas wrote:

> From PRZ's first documents, he labeled
> armoring as an integral piece of PGP. It's too useful as a generalized
> mechanism for holding an object (data, keys, etc.) without having to worry
> about what odd thing something will do to your binary.

I'm not sure what you mean. Do you mean safely holding an object while
it is transmitted by mail?

Armour was a very necessary part of PGP. But now we have MIME, which is
meant for the same purpose - safely transmitting binary data across
7-bit or less mail systems.

Bill Stewart wrote:

> Understanding armour _isn't_ very hard; I'd prefer MUST,
> especially since it's needed for backward compatibility with PGP 5.0
> (in particular, the Encrypt Clipboard doesn't do MIME.)

I agree it isn't too difficult. But as Paul Hoffman said:

> The advantage is that using standard MIME is more easily specified and
> implemented than using ASCII armor. That is, a developer who has a MIME
> toolkit must modify that toolkit in order to use ASCII armor. Forcing ASCII
> armor when it shows no noticable value over standard MIME is one more
> impediment to new developers adopting OpenPGP.
> ...
> If the IETF Calendaring and Scheduling Working Group,
> for example, wants to use OpenPGP for handing around scheduling events in
> an automated environment (that is, without human intervention), there is
> absolutely no reason why the must be able to process older PGP formats. If
> our spec requires that they do so, it is that much harder for them to chose
> it over competing specs.
> 
> OpenPGP can be useful for many types of applications other than humans
> sending email to each other. Many other IETF messaging protocols can use
> the privacy and authentication offered by OpenPGP. They would have
> absolutely no use for backwards compatibility with earlier versions.
> 
> This isn't to say that we shouldn't try to get software to be able to
> process and possibly even emit messages from earlier versions, but there is
> no reason to *force* them to because what we specify will be complete and
> secure by itself. We should make it as easy as possible for some who starts
> with OpenPGP to add support for earlier versions without burdening them
> with implementation issues that aren't relevant to OpenPGP.

Bill again:

> Generating it is a matter of taste - will PGP 5.0 always accept MIME?
> Even in applications like Decrypt/Verify Clipboard?

I agree it could be awkward with the current implementation (PGP 5).
Most mailers these days understand MIME, so even if they don't
understand PGP/MIME objects they can do the conversion from Base64 to
binary data - at which point PGP could take over. If we had a standard
content-type for the PGP data itself - rather than just using
application/octet-stream like PGP/MIME - *any* mailer that understood
MIME could be configured to launch a PGP program upon receipt of such a
body part.

I'm not arguing that we should totally do away with armour - just that I
don't think it should be a MUST, so that people who want to use OpenPGP
in their program or standard minimally, with no need for backwards
compatibility, can do it with as little problem as possible.

Ian >:)

Date: Sat, 15 Nov 1997 01:21:39 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: closedPGP vs openSMIME
To: "John  W. Noerenberg" <[email-masked]>
Cc: Ian Grigg <[email-masked]>, [email-masked]
Sender: [email-masked]

> I'm not going to bed tonight until it is sent to the draft editor.  It
> should be posted to the directory early next week.

John, your efforts, and the efforts of the other authors and editors,
are much appreciated.

I look forward to seeing the draft.

				Ned

Date: Fri, 14 Nov 1997 23:55:25 -0800
To: Ned Freed <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: closedPGP vs openSMIME
Cc: Ian Grigg <[email-masked]>, [email-masked]
Sender: [email-masked]

At 7:30 PM -0800 11/14/97, Ned Freed wrote:
>
>> Mr Chair,
>> would it be at all possible to post the draft on the mailing list in
>> order to minimise delays?
>
>As I said before, some people may object to drafts being posted to
>the list, but I don't.

Thanks, Ned.  I'll bear that in mind.  I suspect your sentiment is shared
by many.

>
>Please note that submitting an Internet Draft is trivially easy -- you send
>mail to [email-masked] with the document in plain text format
>attached. There are no, repeat NO, formatting requirements other than this.

While this is true, the first draft of the format document is already
lengthy, 30+ pages broken into 11 sections.  In order to have some sensible
discussion, it would be useful for people to be able to refer to specific
sections of the document.  So some minimal formatting is useful.

>
>I do object, however, to having drafts posted to the list as a substitute for
>submitting them to the Internet Drafts repository. As far as I'm concerned a
>draft not posted to the Internet Drafts repository doesn't exist in any formal
>sense. And I can assure you that the IESG shares this view.

So that's why for the first one, I'm going by the book.  Before you break
the rules, first prove you understand them.  Later, justifying why you need
to deviate is easier if you've already shown you know how the game is
played.

best,

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: Fri, 14 Nov 1997 23:10:04 -0800
To: Ian Grigg <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: closedPGP vs openSMIME
Cc: [email-masked]
Sender: [email-masked]

At 12:28 AM +0000 11/15/97, Ian Grigg wrote:
>
>Mr Chair,
>would it be at all possible to post the draft on the mailing list in
>order to minimise delays?

I've been scolded in the past for that sort of thing in APPs.  Now I'm a
bit skittish -- cats and stoves, and all that.  Not that it hasn't crossed
my mind.  I might be more flexible in the future, but for the initial
draft, I'm going by the book.  Call me anal-compulsive if you must.

I'm not going to bed tonight until it is sent to the draft editor.  It
should be posted to the directory early next week.

I know you're all eager to see it.  The authors are equally eager for you
to see it, too.  I expect a lot of discussion once its in your hands.

My expectation at this point is we'll use the next weeks running up to the
Dec meeting to read and start commenting on the document.  I plan to have
the authors bring a list of topics they think we can resolve at the meeting
for their agenda.  I'll post my agenda for the whole meeting shortly.

I haven't sent my agenda in yet, so this will be an opportunity for your
suggestions.

Thanks!

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: Fri, 14 Nov 1997 19:30:02 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: closedPGP vs openSMIME
To: Ian Grigg <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Meanwhile, over at IPsec,

> >  At the direction of the working group chairs, we're posting the IPsec
> >  Architecture draft directly to the mailing list to minimize delays.  (It
> >  is also being sent to the secretariat.)  The chairs ask everyone to
> >  please review and comment as quickly as possible.

> Mr Chair,
> would it be at all possible to post the draft on the mailing list in
> order to minimise delays?
 
As I said before, some people may object to drafts being posted to
the list, but I don't.

I do object, however, to having drafts posted to the list as a substitute for
submitting them to the Internet Drafts repository. As far as I'm concerned a
draft not posted to the Internet Drafts repository doesn't exist in any formal
sense. And I can assure you that the IESG shares this view.

So post to the list if you want to, but you _must_ submit the document
as an Internet Draft.

Please note that submitting an Internet Draft is trivially easy -- you send
mail to [email-masked] with the document in plain text format
attached. There are no, repeat NO, formatting requirements other than this.

To say that this mechanism works well understates the case considerably. I have
on occasion posted as many as three revisions to a document in a single day and
gotten prompt and correct turnaround on all of them. When I've screwed up and
gotten the wrong name or revision level on a document the I-D people have
caught it every time.

My experience has been that the draft usually makes it out in less than 24
hours. Of course this is the period just before an IETF, so there may be a bit
more of a backlog than usual.

				Ned

Date: Sat, 15 Nov 1997 00:28:10 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
Subject: Re: closedPGP vs openSMIME
Sender: [email-masked]

> draft is being physically formatted now for delivery to IETF.

Meanwhile, over at IPsec,

> From: Karen Seo <[email-masked]>
> To: [email-masked]
> Subject:  IPsec Architecture -- List of changes
> 
> Folks,
> 
>  At the direction of the working group chairs, we're posting the IPsec
>  Architecture draft directly to the mailing list to minimize delays.  (It
>  is also being sent to the secretariat.)  The chairs ask everyone to
>  please review and comment as quickly as possible.

Mr Chair,
would it be at all possible to post the draft on the mailing list in
order to minimise delays?

> >On ietf-smime there 70 posts in last 3 days, this list only 3!

I'd just like to make the point that whilst Adam and I have been working
hard on crypto all week (yes, we hack for cash) this correlation is
coincidence and not causality :-)

-- 
iang                                      systemics.com

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

Date: Fri, 14 Nov 1997 21:06:12 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: extension mechanism needed
Sender: [email-masked]

Bill Stewart <[email-masked]> writes:
> At 12:15 PM 11/14/1997 GMT, Adam Back wrote:
> >In ESMTP/SMTP there are extension mechanisms.  Clients/Servers can use
> >this mechanism where the other party has it also.  This is a very
> >powerful and simple to add feature.  I think we need such an extension
> >mechanism in OpenPGP.
> 
> Extension mechanisms require a communication mechanism between
> the ends of the connection.  ESMTP is interactive, so it's easy.
> In PGP, the only interaction mechanism from the recipient to the sender
> is the public key record.  There's already an extension mechanism
> for indicating algorithm choices.  There's another extension mechanism
> for indicating additional recipients, but it's apparently controversial :-)

CMR was not defined as an extension, it was proposed for inclusion in
the standard.  Perhaps it would be less controversial if it were also
an extension.  (Now there's an idea.)

> >One example I am thinking of is transparent tunneling of SMTP headers
> >inside the encrytion envelope when both sides are using an encrypting
> >proxy such as Ian Brown's Enigma.  
> 
> This sounds like a problem for the application programs on the ends,
> not a problem for PGP itself?

It is a problem for PGP.

Say I want to be able to tunnel information.

If I can not determine from the recipients public key whether he has
the tunneling extension, I must insert the information into the
plaintext, and this could confuse the recipient, and/or the recipients
software where the software does not support tunneling.

If I know that the recipient does not support this extension I can
avoid this risk by not using it in this case.

> >Another might be opportunistic forward secrecy via sending of new EG
> >keys within each message with relatively short expiry times.
> 
> That sounds like there's a need for the sender of a key to indicate
> that it should be used in preference to a previous key, e.g.
> 	New: Adam Back, 0x22222222, expires 2/2/1998
> 	Old: Adam Back, 0x11111111, expires 1/1/2000

I think probably what you would do is to use the key which is nearest
to it's expiry date of those marked as forward secret.  (You could
mark the keys as forward secret with another extension record).

Also, there is already I think a "valid from" date.  So another way of
avoiding using a long term key which happens to expire before a short
lived one would be to use the "valid from" date to avoid using
relatively long lived keys where still valid shorter lived keys are
available.

I am happy to discuss or put together a proposal for how this might
work out, but the above comment was just arguing for an extension
system which allows things like this to be done as extensions.

The beauty of an extension feature is that the extension implementors
can hash it out in practice, and bring it back to the standards
process as tried and tested technology for next time around.

Also it allows us to move forward in a focussed manner to get
something minimal and workable out _now_.  We could be hear until next
year arguing about Forward secrecy, and politically controversial CMR
extensions, etc.

Extensions are a useful way of focussing the discussion on what is
necessary now.  If anyone brings up a "I want to do X" -- we just say
"fine use an extension" -- end of argument.

> Supporting this automatically isn't straightforward -
> what if the new encryption key expires _before_ the old one?

Use it instead.  You are trying to give the message you are about to
send maximal forward secrecy.  The way to do this is to use of the
available keys marked for forward secret use the one which expires
soonest.

> And does the extension only apply to EG/DSA keys, or to RSA keys as
> well (which has lots of complex interaction with trust models.)?

There is no inherent reason why RSA sign only and RSA encrypt only
keys could not be used.  It would be interesting to have this
functionality expressible within the standard.  (Perhaps it is... I am
not sure).

But yes, the extension I had in mind once we had an extension
mechanism, was to have forward secret EG subkeys.

I wasn't thinking directly about having forward secret signature keys.
But they too are interesting.  To make a signature key forward secret,
you publish the private key :-)

(Then non-timestamped documents signed by you have lost much of their
proof of authorship).

If you wanted to do this it would actually argue that you had a
certification only signing key, as well as a document signing key.
You disclose the private document signing key when it expires.  You
destroy the private forward secret decryption key when it expires.

Interesting stuff.

(Incidentally the Norwegian? standards document that I posted excerpts
from earlier makes this distinction between key uses... they see a
need for separate certification keys.  Also they see a need to time
stamp signatures where the signature is intended to have meaning after
the signature key has expired.  The application they are thinking of I
think is long term contracts.)

> There's an obvious need to deal with the semantics of accepting keys,
> and it sounds like you're proposing that this needs more options?

All I was really proposing was that there be a flexible extension
mechanism so that we can put it in and get on with this iteration of
the standard without having people clamoring for their favourite
feature to go in at this stage.

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

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

Date: Fri, 14 Nov 1997 21:18:26 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: extension mechanism needed
Sender: [email-masked]

Jon Callas <[email-masked]> writes:
> There are two parts of the extension mechanism: a "notation" that is a tag
> and value (16-bit length for each, no encoding assumed) that can be put in
> any signature. This is so it can be used both for extensions, but also for
> human-readable notes. You might, for example, put in a document signature
> "read but not agreed to". 

Sounds cool.  16 bits is lots.

> The second part is a "standalone signature" which is a signature
> that hashes only over its own subpacket contents. This is so you can
> have signatures that encode their own extension pieces so that they
> can act like SPKI certificates (or even *hold* SPKI certificates) or
> any other type of advanced use.

The icing too.

What more could we ask for :-)

Adam
--
Pentium bug program in C, cut and paste to shell:
echo main=0xc8c70ff0\; > t.c; gcc t.c; a.out # boom!

Date: Fri, 14 Nov 1997 10:50:32 -0800
To: Bill Stewart <[email-masked]>, Ian Brown <[email-masked]>, Adam Back <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: extension mechanism needed
Cc: [email-masked]
Sender: [email-masked]

At 10:21 AM 11/14/97 -0800, Bill Stewart wrote:

   Understanding armour _isn't_ very hard; I'd prefer MUST,
   especially since it's needed for backward compatibility with PGP 5.0
   (in particular, the Encrypt Clipboard doesn't do MIME.)
   Generating it is a matter of taste - will PGP 5.0 always accept MIME?
   Even in applications like Decrypt/Verify Clipboard?

Thanks Bill. I agree completely. From PRZ's first documents, he labeled
armoring as an integral piece of PGP. It's too useful as a generalized
mechanism for holding an object (data, keys, etc.) without having to worry
about what odd thing something will do to your binary.

	Jon

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

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 14 Nov 97 12:46:43 -0600
To: [email-masked]
Subject: Re: closedPGP vs openSMIME
Sender: [email-masked]

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

In <[email-masked]>, on 11/14/97 
   at 12:34 PM, [email-masked] (Anonymous) said:

>Subject: closedPGP vs openSMIME

>So PGP Inc and editors are working on standard, can we participate too?

>On ietf-smime there 70 posts in last 3 days, this list only 3!

>Working behind closed doors not good for standard.

Troll be gone!

Go back to RSADSI/Netscape and find somplace else to play.

- -- 
- ---------------------------------------------------------------
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: Fri, 14 Nov 1997 10:48:07 -0800
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: extension mechanism needed
Sender: [email-masked]

At 12:15 PM 11/14/97 GMT, Adam Back wrote:
   
   It would seem that these extensions should be self signed and perhaps
   attachable to userIDs so that different userIDs could be marked for
   different capabilities.  (Perhaps the client you use at your home
   email address has the FS extension, but the one at the office does
   not, etc).
   
   Comments?
   
I couldn't agree more. You got it.

The draft has spent this week with people not giving me comments. :-) We
should have it for you in a day or so.

There are two parts of the extension mechanism: a "notation" that is a tag
and value (16-bit length for each, no encoding assumed) that can be put in
any signature. This is so it can be used both for extensions, but also for
human-readable notes. You might, for example, put in a document signature
"read but not agreed to". The second part is a "standalone signature" which
is a signature that hashes only over its own subpacket contents. This is so
you can have signatures that encode their own extension pieces so that they
can act like SPKI certificates (or even *hold* SPKI certificates) or any
other type of advanced use.

	Jon

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

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 14 Nov 97 12:30:21 -0600
To: Ian Brown <[email-masked]>
Cc: Hal Finney <[email-masked]>, [email-masked], [email-masked]
Subject: Re: clearsigned sigs
Sender: [email-masked]

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

In <[email-masked]>, on 11/14/97 
   at 11:56 AM, Ian Brown <[email-masked]> said:

>Hal Finney wrote:

>> I am considering doing sign-and-encrypt by clearsigning and then
>> encrypting the clearsigned message.  This way you just decrypt and are
>> left with a nice clearsigned message, which you can then verify.

>>From PGP/MIME:

>> 6.2  Combined method
>> 
>> Versions 2.x of PGP also allow data to be signed and encrypted in one
>> operation.  This method is an acceptable shortcut, and has the
>> benefit of less overhead.  The resulting data should be formed as a
>> "multipart/encrypted" object as described above.
>> 
>> Messages which are encrypted and signed in this combined fashion are
>> REQUIRED to follow the same canonicalization rules as for
>> multipart/signed objects.
>> 
>> It is explicitly allowed for an agent to decrypt a combined message
>> and rewrite it as a multipart/signed object using the signature data
>> embedded in the encrypted version.

>Could your MUA could do this automatically and rewrite a
>signed+encrypted message as cleartext plus a signature message part? This
>even hides the PGP data in the mailer, which I like.

Well what I am doing in my MUA is the following:

When a signed+encrypted message comes in:

- -- Decrypt the message
- -- Attach a text/X-PGPDecrypt to the message
    - this displays relevant info about the decryption
- -- Verify the signature
- -- Attach a text/X-PGPVerify to the message
    - this displays relevent info about the verification
- -- Signature Blocks are retained.

So long as the original message is signed then encrypted this works well.
When the origianl message is signed & encrypted (one operation) one runs
into the problmes mentioned earlier.

There are several reasons for the X-PGPVerify text attachment:

- -- gives users sig verification info whenever the message is opened
without having to re-verify the sigblock. The user has the option to
re-verify of course.

- -- move signature verification to the server. In a corporate enviroment it
may be advantageous to have the server verify the signatures on incoming
messages as opposed to the MUA's doing so. Not that the MUA's in such an
enviroment should be restricted from doing so. Of course verification can
not be done on the server if the message is encrypted. :)

- -- 
- ---------------------------------------------------------------
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: Fri, 14 Nov 97 12:17:08 -0600
To: Hal Finney <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: clearsigned sigs
Sender: [email-masked]

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

In <[email-masked]>, on 11/14/97 
   at 10:34 AM, Hal Finney <[email-masked]> said:

>I am considering doing sign-and-encrypt by clearsigning and then
>encrypting the clearsigned message.  This way you just decrypt and are
>left with a nice clearsigned message, which you can then verify.

This is the default behavior for my PGP implementations.

In addition to the sig block being retained for future reference after
decryption you have the implementation of sign and forward systems where
you would wish to retain multiple signatures.

Take the following example:

Message X needs to be distributed and signed off by several people:

Originator of X signs the message and encrypts it to user 1.

User 1 decrypts the messages and then parallel signs the message. He then
encrypts it to user 2.

This process continues until the originator receives the message with all
the signatures from the distribution list.

- -- 
- ---------------------------------------------------------------
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: Fri, 14 Nov 1997 10:10:09 -0800
To: Adam Back <[email-masked]>, [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: extension mechanism needed
Sender: [email-masked]

At 12:15 PM 11/14/1997 GMT, Adam Back wrote:
>In ESMTP/SMTP there are extension mechanisms.  Clients/Servers can use
>this mechanism where the other party has it also.  This is a very
>powerful and simple to add feature.  I think we need such an extension
>mechanism in OpenPGP.

Extension mechanisms require a communication mechanism between
the ends of the connection.  ESMTP is interactive, so it's easy.
In PGP, the only interaction mechanism from the recipient to the sender
is the public key record.  There's already an extension mechanism
for indicating algorithm choices.  There's another extension mechanism
for indicating additional recipients, but it's apparently controversial :-)

>One example I am thinking of is transparent tunneling of SMTP headers
>inside the encrytion envelope when both sides are using an encrypting
>proxy such as Ian Brown's Enigma.  

This sounds like a problem for the application programs on the ends,
not a problem for PGP itself?

>Another might be opportunistic forward secrecy via sending of new EG
>keys within each message with relatively short expiry times.

That sounds like there's a need for the sender of a key to indicate
that it should be used in preference to a previous key, e.g.
	New: Adam Back, 0x22222222, expires 2/2/1998
	Old: Adam Back, 0x11111111, expires 1/1/2000
Supporting this automatically isn't straightforward -
what if the new encryption key expires _before_ the old one?
And does the extension only apply to EG/DSA keys, or to
RSA keys as well (which has lots of complex interaction with trust models.)?

There's an obvious need to deal with the semantics of accepting keys,
and it sounds like you're proposing that this needs more options?
				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Fri, 14 Nov 1997 10:21:57 -0800
To: Ian Brown <[email-masked]>, Adam Back <[email-masked]>
From: Bill Stewart <[email-masked]>
Subject: Re: extension mechanism needed
Cc: [email-masked]
Sender: [email-masked]

At 02:55 PM 11/14/1997 +0000, Ian Brown wrote:
>Adam Back wrote:
>"Implementations MAY understand Armour (see RFC 1991/corrected) for
>backward compatibility. They SHOULD use PGP/MIME2 for transport of
>OpenPGP messages using mail."
>
>This allows all other mention of armour to be excised.

Understanding armour _isn't_ very hard; I'd prefer MUST,
especially since it's needed for backward compatibility with PGP 5.0
(in particular, the Encrypt Clipboard doesn't do MIME.)
Generating it is a matter of taste - will PGP 5.0 always accept MIME?
Even in applications like Decrypt/Verify Clipboard?
				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Fri, 14 Nov 1997 10:07:53 -0500
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: closedPGP vs openSMIME
Sender: [email-masked]

draft is being physically formatted now for delivery to IETF.

If you don't like the process, please leave.

>Date: Fri, 14 Nov 1997 18:34:57 +0100 (MET)
>Subject: closedPGP vs openSMIME
>To: [email-masked]
>From: [email-masked] (Anonymous)
>Organization: Replay and Company UnLimited
>X-001: Replay may or may not approve of the content of this posting
>X-002: Report misuse of this automated service to <[email-masked]>
>X-URL: http://www.replay.com/remailer/
>Sender: [email-masked]
>
>
>Subject: closedPGP vs openSMIME
>
>So PGP Inc and editors are working on standard, can we participate
>too?
>
>On ietf-smime there 70 posts in last 3 days, this list only 3!
>
>Working behind closed doors not good for standard.
>
>-someone
>
>

Date: Fri, 14 Nov 1997 17:43:07 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
CC: Hal Finney <[email-masked]>
Subject: Re: clearsigned sigs
Sender: [email-masked]

Hal Finney wrote:

> Unfortunately the text mode signature is done slightly differently than
> the cleartext signature.  The difference is that cleartext signatures
> remove trailing whitespace on each line when calculating the hash.
> I believe this was added because some mailers and gateways munged mail
> which had trailing whitespace.  This is not a problem with signed/encrypted
> messages since the cleartext is protected from munging.

Aha, I always wondered about this.  I had much the same problem with the
e$pam mailing lists (an ecommerce thing run by Bob Hettinga).  In this
case, there is leading spaces rather than trailing spaces, and the sigs
don't get picked up.  Worse, the spaces start at line 2, so we have one
space inserted in every line after the '-----BEGIN' so there is no
simple algorithm like "ignore the same spaces before the '-----BEGIN.' 
Generally, you would have to ignore all the spaces...

This is also not the first time that I have seen this munge feature
break PGP-style messages.  When we send SOX payments around the place,
we generally mail them.  The user knows to C&P them from the MUA to the
SOX agent.  However, the leading spaces tend to creep in from either the
original C&P or the extraction C&P.  This can be very difficult to track
down and rectify, and it is much more of a pain when you are dealing
with money.  A sig that doesn't work can be ignored, broken cash means
the loss of a customer.

So I would have thought that these packets, when in text-signed or ascii
armoured mode, should be readable with both leading or trailing
whitespace.  I don't know whether I'd make it a SHOULD, but a gentle MAY
would at least indicate to programmers of the potential problems.

Problem is of course, what happens when I send my signed balance sheet:

-----BEGIN MUNGE------
Credits       Debits
100
              100
-----BEGIN MUNGE SIG-----
I promise to pay the bearer the Credits minus the Debits...
-----END MUNGE SIG------

> If the message you are signing has no trailing whitespace, you could convert
> a signed-and-encrypted message into a clearsigned one by decrypting,
> wrapping it in the appropriate headers, and appending the signature in
> ascii armor form.  The sender could remove any trailing whitespace before
> sending it to allow this to happen.

A gentle suggestion in the text then.  I suppose there will be some
software (Hollerith conversions?) that insists on blank padding, so it
should not be a SHOULD.

> I am considering doing sign-and-encrypt by clearsigning and then
> encrypting the clearsigned message.  This way you just decrypt and are
> left with a nice clearsigned message, which you can then verify.

That should be there, yes.  One doesn't want to preserve the ascii
armouring, but one does want to preserve the sig, and (I would have
thought that) one should preserve the clear sig because it is visible,
and won't get lost.  This makes more sense when you are talking about
serious contracts, as people only want to see text and signatures.
-- 
iang                                      systemics.com

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

Date: Fri, 14 Nov 1997 18:34:57 +0100 (MET)
Subject: closedPGP vs openSMIME
To: [email-masked]
From: [email-masked] (Anonymous)
Organization: Replay and Company UnLimited
Sender: [email-masked]

Subject: closedPGP vs openSMIME

So PGP Inc and editors are working on standard, can we participate
too?

On ietf-smime there 70 posts in last 3 days, this list only 3!

Working behind closed doors not good for standard.

-someone

Date: Fri, 14 Nov 1997 16:56:03 +0000
From: Ian Brown <[email-masked]>
To: Hal Finney <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: clearsigned sigs
Sender: [email-masked]

Hal Finney wrote:

> I am considering doing sign-and-encrypt by clearsigning and then
> encrypting the clearsigned message.  This way you just decrypt and are
> left with a nice clearsigned message, which you can then verify.

>From PGP/MIME:

> 6.2  Combined method
> 
> Versions 2.x of PGP also allow data to be signed and encrypted in one
> operation.  This method is an acceptable shortcut, and has the
> benefit of less overhead.  The resulting data should be formed as a
> "multipart/encrypted" object as described above.
> 
> Messages which are encrypted and signed in this combined fashion are
> REQUIRED to follow the same canonicalization rules as for
> multipart/signed objects.
> 
> It is explicitly allowed for an agent to decrypt a combined message
> and rewrite it as a multipart/signed object using the signature data
> embedded in the encrypted version.

Could your MUA could do this automatically and rewrite a
signed+encrypted message as cleartext plus a signature message part?
This even hides the PGP data in the mailer, which I like.

Ian.

Date: Fri, 14 Nov 1997 07:34:37 -0800
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: clearsigned sigs
Sender: [email-masked]

[email-masked] writes:
> Ian Grigg [[email-masked]] wrote:
> >I suggest we clarify this in the standard by saying that clearsigned
> >messages SHOULD be signed with sig type of 01, and that readers MAY
> >assume that cleartext messages are so signed.
>
> It's a long time since I implemented the clearsigning code so I don't
> remember the details very well, but one feature that I would have liked 
> to put into my PGP-aware email program was to take the signature from a 
> signed, encrypted message and use it to create a clearsigned message for archiving. Presumably if normal encrypted messages have binary sigs and clearsigned messages have text sigs, this will be impossible? I think
> this was the situation with the PGP version (2.3a?) I was testing for 
> compatibility.

Signed-and-encrypted messages can sign in either text mode or binary mode.
If they are done in text mode then it will often work to convert to
a cleartext signature.

Unfortunately the text mode signature is done slightly differently than
the cleartext signature.  The difference is that cleartext signatures
remove trailing whitespace on each line when calculating the hash.
I believe this was added because some mailers and gateways munged mail
which had trailing whitespace.  This is not a problem with signed/encrypted
messages since the cleartext is protected from munging.

If the message you are signing has no trailing whitespace, you could convert
a signed-and-encrypted message into a clearsigned one by decrypting,
wrapping it in the appropriate headers, and appending the signature in
ascii armor form.  The sender could remove any trailing whitespace before
sending it to allow this to happen.

I am considering doing sign-and-encrypt by clearsigning and then
encrypting the clearsigned message.  This way you just decrypt and are
left with a nice clearsigned message, which you can then verify.

Hal

Date: Fri, 14 Nov 1997 15:46:17 +0000
From: Ian Brown <[email-masked]>
To: Adam Back <[email-masked]>
CC: [email-masked]
Subject: Re: extension mechanism needed
Sender: [email-masked]

It would actually be *very* simple to do opportunistic forward secrecy
with the protocols we have *now*.

PGP/MIME defines an application/pgp-keys type. If you sent an FS
encryption key with a short expiry time in every n messages, signed with
your long term signature key, compatible clients would simply add the
key to the user's keyring. Others would ignore it. PGP 2.6 uses the
last-added key for any user to encrypt messages, so we could just codify
that behaviour in the standard. You wouldn't even need to send out key
revocations as the expiry date would be set. You could then securely
wipe/archive/whatever the corresponding private key some time after that
date.

Ian :D

Date: Fri, 14 Nov 1997 14:55:46 +0000
From: Ian Brown <[email-masked]>
To: Adam Back <[email-masked]>
CC: [email-masked]
Subject: Re: extension mechanism needed
Sender: [email-masked]

Adam Back wrote:

> In ESMTP/SMTP there are extension mechanisms.  Clients/Servers can use
> this mechanism where the other party has it also.  This is a very
> powerful and simple to add feature.  I think we need such an extension
> mechanism in OpenPGP.

Exactly what I've been thinking of over the last few days, although from
a different angle. I agree with Paul Hoffman (IMC) that OpenPGP MUSTs
should be absolutely as simple as possible, to allow other
standards/programs to incorporate it with minimal effort. We have
already abandoned MUST backwards-capability with PGP 2.6 (RSA and IDEA
can't be MUSTs) so we could have some paring down of MUSTs to a minimum.
PGP backward compatibility could then be just an option for
implementations.

At a first glance, ALL that would seem to be needed in a minimal
implementation would be (using the first draft at the IMC):

> PGP provides four services related to the format of messages
> and data files: 
>       -digital signature
>       -encryption 
>       -compression
>       -radix-64 conversion

Only the first two are MUSTs. The second two are specified in RFCs
elsewhere, {c/sh}ould be optional, and could even be largely absent from
the document - just refer to Zip and MIME RFCs.

I've also been looking at PGP/MIME. It REQUIRES Armour use, which was
appropriate for backward compatibility but is now not as important.
ietf-open-pgp is chartered to replace RFC1991 AND RFC2015 (PGP/MIME) so
we could define a version 2 of PGP/MIME which simply encodes binary
OpenPGP
data like all other MIME data.

"Implementations MAY understand Armour (see RFC 1991/corrected) for
backward compatibility. They SHOULD use PGP/MIME2 for transport of
OpenPGP messages using mail."

This allows all other mention of armour to be excised.

The current packet types are as follows:

> 0  -- Reserved. A packet must not have a tag with this value.
> 1  -- Encrypted Session Key Packet
> 2  -- Signature Packet
> 3  -- Conventionally Encrypted Session Key Packet
> 4  -- One-Pass Signature Packet
> 5  -- Secret Key Packet
> 6  -- Public Key Packet
> 7  -- Secret Subkey Packet
> 8  -- Compressed Data Packet
> 9  -- Symmetrically Encrypted Data Packet
> 10 -- Obsolete Literal Packet
> 11 -- Literal Data Packet
> 12 -- Trust Packet
> 13 -- Name Packet
> 
> 14 -- Subkey Packet
> 15 -- Reserved
> 16 -- Comment Packet

Packet headers contain a length, so it is simple for us to specify that
packets that are not understood by an implementation should simply be
ignored. All vital packets which an implementation MUST understand will
be specified in openPGP. At first glance, these would be 1, 2, 5, 6, 9
and 11
(and maybe 3).

Keyring management programs would also need to understand 12 and 13. As
Peter Gutmann suggested, this need not be part of the base
specification. Applications may wish to use a public key without needing
to
know anything about a userID/email address for it. Public keys should
also
be securely obtainable from Secure DNS (when it finally rolls out)
without an absolute need for signatures.

Someone like the IANA could then act as a registry for other, optional
packet types. Something Raif Naffah wrote on another list recently:

> Assuming you already have the classes to
> handle each specific PGP packet, it's easy to process a public or secret
> keyring or even a PGP message as a structured sequence of packets. In the
> mentioned cases, the structure is well defined by current implementations
> of PGP and by proposed standards.
> 
> The tool/bean I'm thinking of would allow the user to define and process
> other types of PGP packet sequence(s). Ultimately it can also allow users
> to define their own packets. With such a tool, communities can agree and
> use their own PGP-based 'structures.' An additional layer of code or data
> may allow the encoding of the structure and its elements totally
> dissociating the data (the packets contents) from their structure (sequence
> of a public keyring, secret keyring, etc...).

Finally, the only MUST symmetric encryption algorithm would be 3DES; the
only MUST asymmetric encryption algorithm Elgamal; the only MUST
signature algorithm DSA.

This would allow a very minimal implementation indeed of OpenPGP. All
other features would be MAYs.

Ian :D

Date: Fri, 14 Nov 1997 06:22:55 -0800 (PST)
From: [email-masked]
To: [email-masked]
Subject: Re: clearsigned sigs
Sender: [email-masked]

Ian Grigg [[email-masked]] wrote:
>I suggest we clarify this in the standard by saying that clearsigned
>messages SHOULD be signed with sig type of 01, and that readers MAY
>assume that cleartext messages are so signed.

It's a long time since I implemented the clearsigning code so I don't
remember the details very well, but one feature that I would have liked 
to put into my PGP-aware email program was to take the signature from a 
signed, encrypted message and use it to create a clearsigned message for archiving. Presumably if normal encrypted messages have binary sigs and clearsigned messages have text sigs, this will be impossible? I think
this was the situation with the PGP version (2.3a?) I was testing for 
compatibility.

    Mark

Date: Fri, 14 Nov 1997 12:15:10 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
Subject: extension mechanism needed
Sender: [email-masked]

In ESMTP/SMTP there are extension mechanisms.  Clients/Servers can use
this mechanism where the other party has it also.  This is a very
powerful and simple to add feature.  I think we need such an extension
mechanism in OpenPGP.

One example I am thinking of is transparent tunneling of SMTP headers
inside the encrytion envelope when both sides are using an encrypting
proxy such as Ian Brown's Enigma.  

(This allows mutliple recipients to be broken up into separately
delivered single recipient messages and the Cc fields reconstructed by
the decryption agent for the MUA.  Useful also for mixmaster delivery,
which such a proxy agent can automatically manage.)

Another might be opportunistic forward secrecy via sending of new EG
keys within each message with relatively short expiry times.

Both of these would be hacky if one had no formal way to determine the
extensions the recipient's software could handle, as one would be
forced to hack or tweak various values in the existing spec in ways
which would hopefully not break other implementations.

I want to be able to encode:

Extension: Forward-secrecy, SMTP-header-tunneling

In such a way that implementations without these extensions will
know to ignore those it does not understand.

It would seem that these extensions should be self signed and perhaps
attachable to userIDs so that different userIDs could be marked for
different capabilities.  (Perhaps the client you use at your home
email address has the FS extension, but the one at the office does
not, etc).

Comments?

(btw I am now manually using the FS extension... use key below for
Nov, on 2nd Dec the private key gets burnt).

Adam

Type Bits/KeyID    Date       User ID
pub  2048/CA2A006D 1997/11/06 Adam Back <[email-masked]> (FS key, Nov 97)

Date: Thu, 13 Nov 1997 21:29:12 -0800
To: Ian Grigg <[email-masked]>, [email-masked]
From: Bill Frantz <[email-masked]>
Subject: Re: clearsigned sigs
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 5:43 PM -0800 11/13/97, Ian Grigg wrote:
>I suggest we clarify this in the standard by saying that clearsigned
>messages SHOULD be signed with sig type of 01, and that readers MAY
>assume that cleartext messages are so signed.
>
>Or some such language.  The intent should be clear: there is validity in
>assuming that clear-signed is sig type of text.

Detached signatures for clearsigned binary executables are still useful.
It seems reasonable for this use to jump thru special hoops while the more
common text use is the default.

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

Date: Fri, 14 Nov 1997 01:43:41 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: clearsigned sigs
Sender: [email-masked]

A week or two ago I was trying to debug messages that were encrypted by
Cryptix and undecryptable by pgp5.x.

The problem turned out to be a confusion surrounding how pgp2.6 treated
clearsigned messages.

In the signature packet there is a signature type byte with values 00
and 01.  This refers to the way in which the has is calculated over the
preceding text:

    00 data is binary
    01 data is text, treat as ISO Latin-1
       with <CR><LF> endings (adding those
       <CR> characters if necessary.

pgp 2.6 didn't mind if you did a 00 sig over a clear signed message. 
Cryptix produced a binary sig over clear text (for some reason), and
everyone was happy until pgp5.x came along and assumed that clear signed
messages must be text.

I suggest we clarify this in the standard by saying that clearsigned
messages SHOULD be signed with sig type of 01, and that readers MAY
assume that cleartext messages are so signed.

Or some such language.  The intent should be clear: there is validity in
assuming that clear-signed is sig type of text.

My thanks to Hal Finney and Colin Plumb for assisting in this.
-- 
iang                                      systemics.com

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

Date: Mon, 10 Nov 1997 20:45:55 -0800
To: "William H. Geiger III" <[email-masked]>, "Alain Zahm" <[email-masked]>
From: Bill Frantz <[email-masked]>
Subject: Re: IETF process
Cc: "David P. Kemp" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 11:28 AM -0800 11/10/97, William H. Geiger III wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>In <[email-masked]>, on 11/10/97
>   at 12:42 PM, "Alain Zahm" <[email-masked]> said:
>
>>One (more) silly question: what about MOSS? Isn(t it THE INTERNET
>>standard for secured email?
>
>Heh, Is anyone useing it?? :)

Since IETF standards must achieve market acceptance, this answer is more
relevant than it appears at first.  As far as I can tell:

(1) There is no such thing as THE internet standard.  There are usually
several to chose from.  Although those who wish to communicate tend to use
IP.  :-)

(2) Even when there are well established standards, people are free to
start a working group to make a new standard.  SPKI is an example.

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

Date: Mon, 10 Nov 1997 12:05:00 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: IETF process
To: Alain Zahm <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, [email-masked]
Sender: [email-masked]

> One (more) silly question: what about MOSS? Isn(t it THE INTERNET standard
> for secured email?

Nope. MOSS is currently a proposed standard. Due to lack of implementation
(something the IETF process requires) it is unlikely to ever move to draft
standard. My expectation is that it will be moved to historic once one or more
other protocols are on the standards track that replace it and are clearly 
seeing widespread deployment and interoperable use.

				Ned

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 10 Nov 97 13:28:39 -0600
To: "Alain Zahm" <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: IETF process
Sender: [email-masked]

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

In <[email-masked]>, on 11/10/97 
   at 12:42 PM, "Alain Zahm" <[email-masked]> said:

>One (more) silly question: what about MOSS? Isn(t it THE INTERNET
>standard for secured email?

Heh, Is anyone useing it?? :)

- -- 
- ---------------------------------------------------------------
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: Mon, 10 Nov 1997 10:57:32 -0800
To: Ian Grigg <[email-masked]>, Bill Stewart <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: CART before the HORSE
Cc: [email-masked]
Sender: [email-masked]

At 10:37 AM 11/10/97 +0000, Ian Grigg wrote:

   I thought that actually pgp5.x does use ElGamal, Jon posted that the
   reason it was called Diffie Hellman was the name recognition.
   
   I would hope that the Open PGP standard does not incorporate this
   confusion and uses the appropriate technical name for the algorithm.
   
Yes, in the draft, Elgamal is called Elgamal.

	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: Mon, 10 Nov 1997 10:58:54 -0800
To: Robert Guerra <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: specifying 
Sender: [email-masked]

At 03:20 PM 11/8/97 -0500, Robert Guerra wrote:
   I'd like to know if the new draft includes a provision that which allows
   the creator of a key to specify which algorythym he prefers senders to use.
   
   For example, will there be a way to specify that the users using (public)
   key A encrypt messages using algo. X?
   
   Perhaps this might be included in the self-signature section?
   
Yes, that is there, and in the self-signature, just like you suggest. There
are also preferences for other things, too, like what your preferred
compression is (particularly if you want things uncompressed). Some of the
preferences are controversial, and I have some notes describing the
controversy.

	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: "Alain Zahm" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: IETF process
Date: Mon, 10 Nov 1997 18:42:47 +0100
Sender: [email-masked]

One (more) silly question: what about MOSS? Isn(t it THE INTERNET standard
for secured email?

----------
> De : David P. Kemp <[email-masked]>
> A : [email-masked]
> Objet : Re: IETF process
> Date : lundi 10 novembre 1997 16:27
> 
> > From: Ned Freed <[email-masked]>
> > 
> > This then means that there will be no less than four S/MIMEs:
> > 
> > (1) The original RSADSI S/MIME.
> > (2) The one that's coming out as a set of informational RFCs.
> > (3) The one the WG will standardize.
> > (4) The one that will result from the PKCS rewrite that RSADSI is
supposedly
> >     doing.
> > 
> > Wow! That's a lot of S/MIMEs! Mind you, there may be a high degree of
> > compatibility between all of them -- I wouldn't know about that. But
let's hope
> > that we don't have quite so many PGPs...
> 
> 
> Wow, that would be a lot of S/MIMEs, if they were truly different. 
But...
> (1) and (2) are supposed to describe the identical (not just compatible)
> protocol - it's just a matter of writing down S/MIME v2 as Informational
> RFCs, perhaps making technical corrections, clarifications, and
collecting
> dispersed information into a single document.  This would be analogous to
> publishing an Informational RFC on PGP 2.6.
> 
> There is discussion regarding (3) and (4); IETF S/MIME was originally
> supposed to be based on the PKCS#7 v2 message syntax, but the Internet
> Drafts for IETF S/MIME are now based on PKCS#7 v1.5, with the minimum
> changes required to accommodate algorithm flexibility, signed receipts,
> and a couple of other flaws.  This syntax might have been called PKCS#7
> v1.7 (v1.6 included mods to accommodate the SET credit card
> protocol), but it is not - the PKCS#7 name will no longer be used - it
> is now called the S/MIME Cryptographic Message Syntax (CMS).
> 
> The evolution of CMS will be determined entirely by the IETF S/MIME
> working group - it may incorporate features from the
independently-evolving
> PKCS#7 v2 or it may not.  But in no case will there be two IETF
(Standard)
> S/MIMEs; there will be only one, and it will be based on CMS.
> 
> To summarize, there will be only two S/MIMEs: v2 described by original
> RSA documents and Informational RFCs, and v3 described by whatever
> Standard RFCs are produced by the working group.  There is the intent
> that v3 will *allow* backwards interoperability with v2, but there is
> no MUST requirement for implementations to support backwards-compatible
> algorithms and message formats.
> 
> Sorry to burden the PGP list with this level of detail on the
competition,
> but accurate information is in everyone's best interest.

Date: Mon, 10 Nov 1997 10:27:15 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: IETF process
Sender: [email-masked]

> From: Ned Freed <[email-masked]>
> 
> This then means that there will be no less than four S/MIMEs:
> 
> (1) The original RSADSI S/MIME.
> (2) The one that's coming out as a set of informational RFCs.
> (3) The one the WG will standardize.
> (4) The one that will result from the PKCS rewrite that RSADSI is supposedly
>     doing.
> 
> Wow! That's a lot of S/MIMEs! Mind you, there may be a high degree of
> compatibility between all of them -- I wouldn't know about that. But let's hope
> that we don't have quite so many PGPs...

Wow, that would be a lot of S/MIMEs, if they were truly different.  But...
(1) and (2) are supposed to describe the identical (not just compatible)
protocol - it's just a matter of writing down S/MIME v2 as Informational
RFCs, perhaps making technical corrections, clarifications, and collecting
dispersed information into a single document.  This would be analogous to
publishing an Informational RFC on PGP 2.6.

There is discussion regarding (3) and (4); IETF S/MIME was originally
supposed to be based on the PKCS#7 v2 message syntax, but the Internet
Drafts for IETF S/MIME are now based on PKCS#7 v1.5, with the minimum
changes required to accommodate algorithm flexibility, signed receipts,
and a couple of other flaws.  This syntax might have been called PKCS#7
v1.7 (v1.6 included mods to accommodate the SET credit card
protocol), but it is not - the PKCS#7 name will no longer be used - it
is now called the S/MIME Cryptographic Message Syntax (CMS).

The evolution of CMS will be determined entirely by the IETF S/MIME
working group - it may incorporate features from the independently-evolving
PKCS#7 v2 or it may not.  But in no case will there be two IETF (Standard)
S/MIMEs; there will be only one, and it will be based on CMS.

To summarize, there will be only two S/MIMEs: v2 described by original
RSA documents and Informational RFCs, and v3 described by whatever
Standard RFCs are produced by the working group.  There is the intent
that v3 will *allow* backwards interoperability with v2, but there is
no MUST requirement for implementations to support backwards-compatible
algorithms and message formats.

Sorry to burden the PGP list with this level of detail on the competition,
but accurate information is in everyone's best interest.

Date: Mon, 10 Nov 1997 10:37:48 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Bill Stewart <[email-masked]>
CC: [email-masked]
Subject: Re: CART before the HORSE
Sender: [email-masked]

Bill Stewart wrote:
> 
> On the other hand, Diffie-Hellman is generally used in interactive
> applications, such as SSL, not batch applications like email encryption -
> it's clearly the right choice for those applications.
> Open-PGP is probably better off using ElGamal, but it's not a no-brainer.

I thought that actually pgp5.x does use ElGamal, Jon posted that the
reason it was called Diffie Hellman was the name recognition.

I would hope that the Open PGP standard does not incorporate this
confusion and uses the appropriate technical name for the algorithm.

-- 
iang                                      systemics.com

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

Date: Sun, 09 Nov 1997 21:42:31 -0800
To: [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do today?)
Sender: [email-masked]

>>   Anyway, I agree with the people who are arguing for MUST for 3DES,
>>   DSA, Elgamal; and SHOULD for RSA, IDEA, MD5, and MAY for the rest.

Presumably SHA-1 also belongs in MUST?

>A very basic reason: SHOULD is only for things that are strongly desired
>by all implementations. If we have a strong algorithm for a MUST and
>another strong algorithm for a SHOULD, I see no point to tossing another
>SHOULD in. Many developers try to implement all SHOULD-level specs, and
>this would cause needless software bloat with little definable benefit.

3DES is MUST, because everybody trusts it, but nobody really likes it :-)  
IDEA is fine, and fast enough to use, but encumbered.

Adding CAST5 as a SHOULD sets a direction that we want a fast free
algorithm to be the primary operating mode, which I think is good,
and says that enough people trust CAST5 that it's the best choice -
is that realistic?
				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Sun, 09 Nov 1997 17:51:00 -0800
To: [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: Conflicts and Options...
Sender: [email-masked]

>* Peter Gutmann wrote:
>>running PGP on pocket calculators and the like) is that it'd be a good idea to 
>>finally split the key management off into a seperate program, especially with 
>>the extra bloat added by the new algorithms and key packets.  About 99% of the 

PGP 5.0 mostly does that, at least on Win95 - there's a PGPkeys program
that does the fancy key management, and the main PGPtray program that
does encryption, decryption, signatures, and verification,
though it also does "Add Key From Clipboard".
				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Sun, 09 Nov 1997 17:28:42 -0800
To: [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: CART before the HORSE
Sender: [email-masked]

On the other hand, Diffie-Hellman is generally used in interactive
applications, such as SSL, not batch applications like email encryption -
it's clearly the right choice for those applications.
Open-PGP is probably better off using ElGamal, but it's not a no-brainer.

>On Fri, 31 Oct 1997, David P. Kemp wrote:
>> > If compatibility with pgp2.6, etc, is a MUST, then RSA is a MUST.  Is
>> > this acceptable?  Have we already made a decision on RSA, or has the
>> > IETF already pronounced (via the S/MIME group) a leaning on this?
>>  
>> The TLS group has decided that there is only one MUST algorithm,
>> DSA/DH/3DES, despite the fact that nearly 100% of the installed base
>> of SSL currently uses RSA/RC4.

At 04:43 PM 10/31/1997 +0200, Markku-Juhani Saarinen wrote:
>  We have chosen the exactly same MUST algorithms in IETF-SecSh work
>  (see draft-ietf-secsh-transport-02.txt).

				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: specifying
Date: 10 Nov 1997 08:28:21 GMT
Organization: IKS GmbH Jena
Lines: 10
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Robert Guerra wrote:
>I'd like to know if the new draft includes a provision that which allows
>the creator of a key to specify which algorythym he prefers senders to use.
>
>For example, will there be a way to specify that the users using (public)
>key A encrypt messages using algo. X?
>
>Perhaps this might be included in the self-signature section?

It is included.

To: [email-masked]
From: [email-masked] (Christopher Creutzig)
Path: bionic.zerberus.de!nescio.foebud.org!christopher
Subject: Re: Symmetric Algorithm
Date: Sun, 9 Nov 1997 13:44:12 +0100 (MET)
Lines: 22
Sender: [email-masked]

On Tue, 28 Oct 1997, Jon Callas wrote:

-> (4) What other algorithm(s) do you want to see as MAY algorithms?

 I'd like something similar to the ssh-specs, where you can introduce new
ciphers "on the fly", if you wish to, by just giving them a string as a name
which needs to be unique, so they suggest "[email-masked]" for that
purpose, e.g. "[email-masked]" or something like that. I
think introducing a magic number which says "there's a packet with a string
following which specifies the algorithm" shouldn't be too hard. The same
applies for the public key algorithm, btw, there's at least RSA, McEliece,
ElGamal and Chor-Rivest and variants of these (especially elliptic curves
come to mind) for encryption and a whole bunch of others for signatures. I
think an "open" standard should allow implementing new algorithms easily.

-- 
Christopher Creutzig # Im Samtfelde 19 # D-33098 Paderborn # V+49-5251-71873
  # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
    "Das kann doch nicht so schwer sein, so ein paar Header zu erzeugen!"
                                             (Eike Rathke auf der Gatebau'97)

Date: Sun, 09 Nov 1997 22:49:18 -0500
To: Ian Grigg <[email-masked]>, [email-masked]
From: "Jeffrey I. Schiller" <[email-masked]>
Subject: Re: patent freedom & compatibility
Cc: [email-masked]
Sender: [email-masked]

At 09:30 PM 11/6/97 +0000, Ian Grigg wrote:
>OK, I'll ask directly, and we'll put this to bed.
>
>Jeff, do you accept Ned Freed's post of today to Open PGP under "Re:
>IETF process" as accurately describing the "Munich doctrine" and its
>effect on this WG?

Its a good first approximation. Also remember Ned's comment about the IETF 
Process being dynamic.

                          -Jeff

From: "Adam Hoier" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Orthogonality and Disaster Recovery
Date: Sun, 09 Nov 1997 09:24:59 PST
Sender: [email-masked]

Could some1 pleez send me PGP in an Email Attachment PLEEZ

ID REALLY APPRECIATE IT!!!!

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Sat, 8 Nov 1997 15:20:19 -0500
To: [email-masked]
From: Robert Guerra <[email-masked]>
Subject: specifying 
Sender: [email-masked]

I'd like to know if the new draft includes a provision that which allows
the creator of a key to specify which algorythym he prefers senders to use.

For example, will there be a way to specify that the users using (public)
key A encrypt messages using algo. X?

Perhaps this might be included in the self-signature section?

regards

robert

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

Date: Sat, 08 Nov 1997 11:20:24 -0800
To: Ned Freed <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: IETF process
Sender: [email-masked]

The ietf-open-pgp mailing list isn't the most appropriate place for
discussing S/MIME, is it? :-) I'd like to point people over to the mailing
list for the just-formed S/MIME Working Group at [email-masked].
However, since there is a bit of confusion still here, I'd like to clear it
up so it doesn't get in the way of the decisions being made here about
OpenPGP.

At 10:26 AM 11/8/97 -0800, Ned Freed wrote:
>This then means that there will be no less than four S/MIMEs:
>
>(1) The original RSADSI S/MIME.
>(2) The one that's coming out as a set of informational RFCs.
>(3) The one the WG will standardize.
>(4) The one that will result from the PKCS rewrite that RSADSI is supposedly
>    doing.

Nope, sorry. The number will be two.
- It's not clear that anyone ever implemented (1)
- (2) is what is out there today
- (3) is what will be out there if the S/MIME WG does its job
- (4) will not be created
For (4), there are no plans for the S/MIME spec to use the revised PKCS #7
format if it ever comes out. All desired changes for S/MIME that might be
made in PKCS #7 should be made to the CMS that will be used in S/MIME v3.
At the last S/MIME developer's meeting, there was a very definite choice to
support (3) and not to try to do (4). Further, (4) is *not* on the charter
for the S/MIME WG. There's a good chance the S/MIME WG will have dissolved
before the PKCS revision is even finished.

Thus, we'll be left with two versions of S/MIME (v2 and v3), just like
there will be two versions of PGP/MIME (RFC 1991/2015 and OpenPGP). The
reasons for having two versions of each protocol are almost identical:
earlier use of encumbered algorithms, later use of unencumbered algorithms
plus fixes and extensions.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sat, 08 Nov 1997 10:26:02 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: IETF process
To: Ian Grigg <[email-masked]>
Cc: Ned Freed <[email-masked]>, Rodney Thayer <[email-masked]>, [email-masked]
Sender: [email-masked]

> > I now call this the "Munich doctrine". It joins the "Danvers doctrine", which
> > was the decision to refuse to cater to export requirements in regards to
> > security issues in IETF protocols. Neither of these are written down in an RFC
> > as far as I know, but both are very real nevertheless.

> OK.  A slight point of clarification: encumbered algorithms as a MUST
> should not be permitted if there are alternatives, presumably.  MAY or
> SHOULD is ok?

I don't think there's any problem with SHOULD and I cannot see how there would
be any problem with MAY.

> > The DNSsec people have taken this to heart, that's for sure. They have made
> > arrangements with RSADSI for royalty free use of RSA in the DNS. (Unfortunately
> > I doubt this is a possibility with RSA.)

> Ah.  I don't understand your last "possibility with RSA" unless you mean
> "possibility with Open PGP."

My mistake. I meant to say "Open PGP", just as you interpreted it.

> Yes, RSADSI are most unlikely to give this forum that license, given the
> opposing standard.  I wonder if IETF would take that to heart and insist
> that if RSADSI were to give royalty-free license to S/MIME, they should
> also give it to competitors?  Probably, if the algorithm is to be useful
> in an unencumbered way, then this must be the case!

Actually what seems to be happening is that S/MIME will be changed to use
unemcumbered algorithms and only those algorithms will be MUSTs in the
standard. (If I were in RSADSI's shoes I wouldn't do this, but then again your
point about there being an issue if they did a special deal for S/MIME and not
for PGP is well taken.)

This then means that there will be no less than four S/MIMEs:

(1) The original RSADSI S/MIME.
(2) The one that's coming out as a set of informational RFCs.
(3) The one the WG will standardize.
(4) The one that will result from the PKCS rewrite that RSADSI is supposedly
    doing.

Wow! That's a lot of S/MIMEs! Mind you, there may be a high degree of
compatibility between all of them -- I wouldn't know about that. But let's hope
that we don't have quite so many PGPs...

> But, yes, I see this as unlikely.

Mind you, I'm not especially happy about any of this. I'm describing the
situation as I see it, not endorsing it. I understand the reasons the IESG and
the IETF have taken this course of action, but I sure wish it could have been
handled differently.

In case anyone cares, I trace all this back to the last iteration of the POISED
process (this is where the IETF develops its procedural and process
requirements). The IETF used to have a rule that basically said you had to make
a good case for using encumbered technologies, especially if unencumbered
alternatives were available. However, this rule caused some trouble in cases
where there encumbered technology existed that was believed by some to be
clearly superior to unemcumbered alternatives. The long and short of it is that
the rule was changed so that use of encumbered technology couldn't be an issue.
(I objected at the time but was overruled.) But this, if anything, proved to be
a worse situation, and now the pendulum has swung to the opposite extreme.

I think it would be better all around to avoid these extremes, even if that
meant not reaching closure on some of the things that caused the initial
swing, but that's just my personal opinion on the matter.

> > I now take it as a given that requiring encumbered technologies when
> > alternatives exist is a nonstarter in the IETF.

> That leaves me with the sad feeling that the Open PGP standard will
> suffer from slow takeup outside the US.  I guess that's the lookout that
> this forum has accepted from the start.

Pretty much. I think the problem exists in part because of the encumbered
technology situation and in part because of the export restriction situation,
but picking apart the causal relationships doesn't change the situation
any.

> ( It would appear that the IESG assumes that encumbered within the US is
> equivalent to encumbered within the IESG, whereas encumbered within
> France is not.  I also agree with these Internet politics :-)

I think the view is that given that the situation in France (and elsewhere)
won't admit any reasonable solution, it might as well be ignored.

> On a related issue, that of an unencumbered reference implementation.  I
> have heard it said that this was required.  Is this the case, as it
> would seem to be in your careful use of the word "technologies" above?

There is no such requirement as far as I know. However, as a practical matter
protocols for which unencumbered implementations are available tend to do
better in the long run.

Back in the days when MIME was developed we took steps to make very sure that
two unemcumbered implementations were available almost immediately. I think
this helped immensely in winning acceptance for MIME. By contrast, unemcumbered
implementations of PEM and MOSS weren't possible, and speaking as someone who
would have cheerfully shipped product including such things if they were
available (and for that matter would have been willing to accept reasonable
licensing terms), I think this contributed significantly to the failure of
these protocols.

> And if so, was pgp5.0 proposed and accepted as the reference
> implementation at the Munich BOF?

Not that I'm aware of. In fact I know of no formal process for designating a
"reference implementation", other than possibly citing the existance of such a
thing in an RFC.

Again, on the practical front I'm a strong supporter of unencumbered reference
implementations regardless of what the process says (or doesn't say) about
them. In fact in the SASL API work that Innosoft is contributing to we've gone
so far as to include unencumbered source code for a reference implementation in
the specification itself. (Of course this isn't practical for Open PGP given
its size and complexity.)

				Ned

From: "William H. Geiger III" <[email-masked]>
Date: Sat, 08 Nov 97 07:08:10 -0600
To: Ben Escoto <[email-masked]>
Cc: [email-masked]
Subject: Re: base64 signature test
Sender: [email-masked]

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

In <[email-masked]>, on 11/07/97 
   at 10:15 PM, Ben Escoto <[email-masked]> said:

>	The draft seemed relatively clear, but I thought I would post this
>message just to make sure I was implementing things correctly.  I would
>also like some input from people whose software doesn't support base64
>encoding, so I know how badly messages like these are handled. Thanks.

Well my system craped out on it. :(

- -- 
- ---------------------------------------------------------------
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]
Cc: [email-masked]
Subject: Re: base64 signature test
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Sat, 08 Nov 1997 13:16:19 +0900
Lines: 37
Sender: [email-masked]

----Security_Multipart(Sat_Nov__8_13:15:59_1997_945)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Just for your information,

From: Ben Escoto <[email-masked]>
Subject: base64 signature test
Date: Fri, 07 Nov 1997 19:15:36 -0800

> 	The draft seemed relatively clear, but I thought I would post
> this message just to make sure I was implementing things correctly.  I
> would also like some input from people whose software doesn't support
> base64 encoding, so I know how badly messages like these are handled.
> Thanks.

Your message was correctly verified by my mail reader, Mew.

X-Mew: <all> Good PGP sign "Ben Escoto <[email-masked]>" COMPLETE

--Kazu

----Security_Multipart(Sat_Nov__8_13:15:59_1997_945)--
Content-Type: Application/Pgp-Signature
Content-Transfer-Encoding: 7bit

----Security_Multipart(Sat_Nov__8_13:15:59_1997_945)----

From: Ben Escoto <[email-masked]>
To: [email-masked]
Subject: base64 signature test
Date: Fri, 07 Nov 1997 19:15:36 -0800
Sender: [email-masked]

--=_Mapil-0.2a_848824537

	The draft seemed relatively clear, but I thought I would post
this message just to make sure I was implementing things correctly.  I
would also like some input from people whose software doesn't support
base64 encoding, so I know how badly messages like these are handled.
Thanks.

--
Ben Escoto
PGP/MIME mail welcome - finger [email-masked] for key

--=_Mapil-0.2a_848824537
Content-Type: application/pgp-signature
Content-Transfer-Encoding: base64

iQCVAwUBNGPZR1PyP+bsWtNdAQGsdQP/QLxwCZkI3IX+js8llrrzZSST65b+9ATtUxkP5QI2Bjw+
mntLxrOBL3qoAhFPnRWNVqTRVfeqmiJeWliMzpRiXb5BSMO3pe+QdjHPxL7VdjTAE+Xho3nzN7uD
41o1C7TO67XZtRYtPyyC+woMuxA2sj1rEvhyhwCcadIVxEUFgbg=

--=_Mapil-0.2a_848824537--

Date: Fri, 07 Nov 1997 12:52:08 -0600
To: Jon Callas <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
From: David Hayes <[email-masked]>
Subject: Re: Management by Committee ...
Sender: [email-masked]

Thank you for your effort, and the generous gift that PGP is to the world.

I know you get lots of heat here on this list, with some of it from me. :-)
We disagree over the issue of defining CMR in the standard. We'll probably
continue to disagree. But I don't want to let that get it the way of
expressing my gratitude for the large body of work you have contributed.

So, a time-out from the CMR debate, while I just say "thank you."

--
David Hayes                                       [email-masked]
Switch Systems Engineering                        voice: 972-918-7236
MCI Communications, Inc.                               VNET: 777-7236
--If these thoughts were MCI's official opinions, the line above would
--read "MCI - Law & Public Policy Department".

Date: 7 Nov 1997 13:45:15 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: patent freedom & compatibility
To: Paul Hoffman / IMC <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

Just replying to the subject, rather than the specific message.

With regards to pgp 2.6 compatibility, I believe that only a MAY reference in
the spec (with appendices/references for formats), is required for it to be
widely implemented, user demand and market pressure will take care of that.
If there are really 4 million pgp 2.6 users out there, then most email
developers will be eager to service that market niche. 

If we leave it a MAY then issues of copyright & patents are upto the
implementors in their various countries, as it should be. And that would
leave us free to *quickly* draft a unencumbered clearly documented spec
with ONE MUST and ONE SHOULD. As a developer I dream of that, at the moment
implementing email security is a nightmare.

Too much time is being wasted on political issues & debates, for what I
thought was meant to be a purely technical spec.

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

Date: Fri, 7 Nov 1997 08:19:54 +1100 (EST)
From: ? the Platypus {aka David Formosa} <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: IETF process
Sender: [email-masked]

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

On Thu, 6 Nov 1997, Paul Hoffman / IMC wrote:

> Last we heard, MAY and SHOULD is OK. (I'm still lobbying against "MAY"
> because that implies that everything not listed is "MAY NOT", and I think
> that's a bad protocol.)

I would suggest that wonderful phrase "including but not limmited to".
We are going to need a MAY list if just for the cypher identerfires.

- -- 
Please excuse my spelling as I suffer from agraphia see the url in my header. 
Never trust a country with more peaple then sheep.  ex-net.scum and proud
You Say To People "Throw Off Your Chains" And They Make New Chains For
Themselves? --Terry Pratchett

Date: Thu, 06 Nov 1997 21:30:48 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked], [email-masked]
CC: [email-masked]
Subject: Re: patent freedom & compatibility
Sender: [email-masked]

Jeff and Paul,

Paul Hoffman / IMC wrote:
> The announcement of the new thinking was made at the plenary session at the
> last IETF meeting (the one in Munich). Many people on this mailing list
> were there. Some even cheered when the announcement was made. :-)

( To be honest, I probably would have cheered and voted such too.  Only
on reflection of the market (which tends to ignore programmers views)
did I question this. )

> >  It
> >would raise many questions, and given the circumstances of the
> >competition for mail standards, these are questions that we'd rather the
> >other standards proponents could not raise.
> 
> I'm not sure what you mean here.

To clarify, I suspect that RSADSI are not above challenging the results
of this forum in court if they thought they could show it was
non-rigourous.

> >( I think I know what the answer to this might be: there is no
> >supporting material and it should be taken up with the Area Director.
> >OK, I'll start drafting a note.  Not knowing the guy and how familiar he
> >is with the situation, this'll keep me quite for a few days. :-)
> 
> He's quite familiar with the situation, and he's also on this mailing list.

OK, I'll ask directly, and we'll put this to bed.

Jeff, do you accept Ned Freed's post of today to Open PGP under "Re:
IETF process" as accurately describing the "Munich doctrine" and its
effect on this WG?

-- 
iang                                      systemics.com

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

Date: Thu, 06 Nov 1997 12:20:37 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: IETF process
Sender: [email-masked]

At 08:04 PM 11/6/97 +0000, Ian Grigg wrote:
>OK.  A slight point of clarification: encumbered algorithms as a MUST
>should not be permitted if there are alternatives, presumably.  MAY or
>SHOULD is ok?

Last we heard, MAY and SHOULD is OK. (I'm still lobbying against "MAY"
because that implies that everything not listed is "MAY NOT", and I think
that's a bad protocol.)

>I wonder if IETF would take that to heart and insist
>that if RSADSI were to give royalty-free license to S/MIME, they should
>also give it to competitors?

Just to be very clear here, in my extensive dealings with RSA over S/MIME,
they have never suggested that they wanted to give a royalty-free license
to S/MIME developers. The might in the future, of course, but that' not
come up yet with me in private, and never in public.

>On a related issue, that of an unencumbered reference implementation.  I
>have heard it said that this was required.

Not at all. To move from Proposed to Draft standard, we must prove that
there are two independent interoperable implementations of each required
feature. A "reference implementation" has never been required and is
certainly not available for most of the popular IETF protocols.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 6 Nov 1997 12:04:46 -0800
To: <[email-masked]>
From: Lance Cottrell <[email-masked]>
Subject: Re: Bravo!
Sender: [email-masked]

>Instead, let's leave message recovery up to the implementors of individual
>applications, as an added feature not part of the official open-pgp
>standard.  Those who sell into markets where such features are desired can
>add them.  The rest of the world will not have to be forced to go along.

* Uncloak *

While imperfect, this seems like the only solution likely to result in
consensus. A government willing to require a GMR key would not hesitate to
outlaw PGP completely. Like the range of criminals smart enough to use
crypto but dumb enough to use GAK, the range of government anti-crypto
hostility which would require GMR but would stop short of outlawing non-GMR
PGP is very narrow.

* Cloak *

	-Lance

----------------------------------------------------------
Lance Cottrell   [email-masked]
PGP 2.6 key available by finger or server.
http://www.infonex.com/~loki/

"Love is a snowmobile racing across the tundra.  Suddenly
it flips over, pinning you underneath.  At night the ice
weasels come."
                        --Nietzsche
----------------------------------------------------------

Date: Thu, 06 Nov 1997 12:05:24 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: patent freedom & compatibility
Sender: [email-masked]

At 07:05 PM 11/6/97 +0000, Ian Grigg wrote:
>Is there any reference material of a non-formal nature that would
>support the notion that this WG should use unencumbered crypto for its
>MUST algorithms?

The announcement of the new thinking was made at the plenary session at the
last IETF meeting (the one in Munich). Many people on this mailing list
were there. Some even cheered when the announcement was made. :-)

>If there is no supporting material at all, and the policy is based on
>verbal or emailed conversations, then I would be most uncomfortable.

You are not alone in this!

>  It
>would raise many questions, and given the circumstances of the
>competition for mail standards, these are questions that we'd rather the
>other standards proponents could not raise.

I'm not sure what you mean here. The rules for OpenPGP are certainly the
same rules as must be followed for all security protocols. This is one of
the motivating factors for the S/MIME v3 work: to be able to produce
something that can get on standards track, which S/MIME v2 probably could
not (because it requires RSA signatures, like PGP 2.6 does).

>( I think I know what the answer to this might be: there is no
>supporting material and it should be taken up with the Area Director. 
>OK, I'll start drafting a note.  Not knowing the guy and how familiar he
>is with the situation, this'll keep me quite for a few days. :-)

He's quite familiar with the situation, and he's also on this mailing list.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 06 Nov 1997 20:04:36 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Ned Freed <[email-masked]>
CC: Rodney Thayer <[email-masked]>, [email-masked]
Subject: Re: IETF process
Sender: [email-masked]

Ned,
this is quality information, Thanks.

Ned Freed wrote:

> The problem with TLS was that it didn't specify a mandatory-to-implement
> ciphersuite.  Without one it is impossible to meet IETF interoperability
> requirements. This caused it to be bounced back to the WG for further work. In
> other words, it wasn't the choice of a mandatory ciphersuite that mattered, it
> was the lack of one. (I thought I'd mention this in case someone advocates
> not having any mandatory-to-implement algorithms in OpenPGP.)

( Indeed, I have advocated that as a potential solution. )

> Having said that, the WG was also clearly unable to go with RC4, since RC4 is
> considered to be a trade secret and IETF rules absolutely forbid standardizing
> on material with confidentiality constraints.

( OK, interesting point.  Not immediately applicable as RC4 does not
enter into the Open PGP debate. )

> And given that backwards
> compatibility was a nonstarter, the WG elected to go with the least encumbered
> alternatives it could find.

( OK, so on the basis that RC4 was out *becuase* it was a trade secret,
backwards compatibility was dropped.  That however does not apply here.
)

Here's the good bits:

> However, regardless of what happened to TLS, the fact of the matter is that the
> rules are now in a state of flux. We all know what RFC 2026 says. But things
> have changed since it was written.
> 
> For one thing, the IESG in general and the security AD in particular clearly
> feel in light of past bad experiences with encumbered technologies that
> embracing standards that require them is not a good idea. This is especially
> true when perfectly viable alternatives are available.
> 
> For another, there's the matter of the plenary session in Munich. A straw poll
> was taken there and a clear consensus emerged that use of encumbered
> technologies should not be allowed when alternatives are available.
> 
> Far more than anything else, the IETF is ruled by rough consensus. So a straw
> poll taken under such circumstances carries real weight, especially when it
> tightens the rules rather than loosening them.
> 
> I now call this the "Munich doctrine". It joins the "Danvers doctrine", which
> was the decision to refuse to cater to export requirements in regards to
> security issues in IETF protocols. Neither of these are written down in an RFC
> as far as I know, but both are very real nevertheless.

OK.  A slight point of clarification: encumbered algorithms as a MUST
should not be permitted if there are alternatives, presumably.  MAY or
SHOULD is ok?

> Remember that all it takes is two IESG members voting "NO" and the document
> goes back to the WG. (The IESG, BTW, is the one place where voting is
> sanctioned in the IETF.) My read of the situation is that there are at least
> three and probably more IESG members who will vote against any specification
> that requires use of encumbered technology where alternatives are available.
> 
> The DNSsec people have taken this to heart, that's for sure. They have made
> arrangements with RSADSI for royalty free use of RSA in the DNS. (Unfortunately
> I doubt this is a possibility with RSA.)

Ah.  I don't understand your last "possibility with RSA" unless you mean
"possibility with Open PGP."

Yes, RSADSI are most unlikely to give this forum that license, given the
opposing standard.  I wonder if IETF would take that to heart and insist
that if RSADSI were to give royalty-free license to S/MIME, they should
also give it to competitors?  Probably, if the algorithm is to be useful
in an unencumbered way, then this must be the case!

But, yes, I see this as unlikely.

> I now take it as a given that requiring encumbered technologies when
> alternatives exist is a nonstarter in the IETF.

OK, I concur.  Your explanation has convinced me of that:  IETF will not
permit Open PGP to use unencumbered technologies because alternatives
are around.

That leaves me with the sad feeling that the Open PGP standard will
suffer from slow takeup outside the US.  I guess that's the lookout that
this forum has accepted from the start.

( It would appear that the IESG assumes that encumbered within the US is
equivalent to encumbered within the IESG, whereas encumbered within
France is not.  I also agree with these Internet politics :-)

> > Analyzing the document rather than studying the context is not necessarily
> > the way to look at things when dealing with the IETF standards process.
> 
> Exactly right. This is a dynamic process. There's always more to it than what
> is said on paper. So while I do recommend that people read what's on paper, it
> should only be taken as a starting point.

Your explanation provides the middle and ending as well.  Thanks again.

On a related issue, that of an unencumbered reference implementation.  I
have heard it said that this was required.  Is this the case, as it
would seem to be in your careful use of the word "technologies" above?

And if so, was pgp5.0 proposed and accepted as the reference
implementation at the Munich BOF?

-- 
iang                                      systemics.com

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

Date: Thu, 06 Nov 1997 10:22:05 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: IETF process
To: Rodney Thayer <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> If you look at what has been happening in the IETF lately you'd see that
> TLS, IPSec, and PKIX have all run into this issue.

I'm not sure about the examples, but I think the basic idea here is pretty
close to the mark.

The problem with TLS was that it didn't specify a mandatory-to-implement
ciphersuite.  Without one it is impossible to meet IETF interoperability
requirements. This caused it to be bounced back to the WG for further work. In
other words, it wasn't the choice of a mandatory ciphersuite that mattered, it
was the lack of one. (I thought I'd mention this in case someone advocates
not having any mandatory-to-implement algorithms in OpenPGP.)

Having said that, the WG was also clearly unable to go with RC4, since RC4 is
considered to be a trade secret and IETF rules absolutely forbid standardizing
on material with confidentiality constraints. And given that backwards
compatibility was a nonstarter, the WG elected to go with the least encumbered
alternatives it could find.

I'm not familiar with the IPSec or PKIX situation so I cannot comment on them.

However, regardless of what happened to TLS, the fact of the matter is that the
rules are now in a state of flux. We all know what RFC 2026 says. But things
have changed since it was written.

For one thing, the IESG in general and the security AD in particular clearly
feel in light of past bad experiences with encumbered technologies that
embracing standards that require them is not a good idea. This is especially
true when perfectly viable alternatives are available.

For another, there's the matter of the plenary session in Munich. A straw poll
was taken there and a clear consensus emerged that use of encumbered
technologies should not be allowed when alternatives are available.

Far more than anything else, the IETF is ruled by rough consensus. So a straw
poll taken under such circumstances carries real weight, especially when it
tightens the rules rather than loosening them.

I now call this the "Munich doctrine". It joins the "Danvers doctrine", which
was the decision to refuse to cater to export requirements in regards to
security issues in IETF protocols. Neither of these are written down in an RFC
as far as I know, but both are very real nevertheless.

Remember that all it takes is two IESG members voting "NO" and the document
goes back to the WG. (The IESG, BTW, is the one place where voting is
sanctioned in the IETF.) My read of the situation is that there are at least
three and probably more IESG members who will vote against any specification
that requires use of encumbered technology where alternatives are available.

The DNSsec people have taken this to heart, that's for sure. They have made
arrangements with RSADSI for royalty free use of RSA in the DNS. (Unfortunately
I doubt this is a possibility with RSA.)

I now take it as a given that requiring encumbered technologies when
alternatives exist is a nonstarter in the IETF.

> Analyzing the document rather than studying the context is not necessarily
> the way to look at things when dealing with the IETF standards process.

Exactly right. This is a dynamic process. There's always more to it than what
is said on paper. So while I do recommend that people read what's on paper, it
should only be taken as a starting point.

				Ned

Date: Thu, 06 Nov 1997 19:05:22 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Rodney Thayer <[email-masked]>
CC: Adam Back <[email-masked]>, [email-masked]
Subject: Re: patent freedom & compatibility
Sender: [email-masked]

Rodney Thayer wrote:
> 
> My point is that TLS was ordered to use DSS/DH and 3DES rather than RSA and
> RC4 as the MUST.

"ordered" is an interesting word.

> Analyzing 2026 to death rather than finding out what the IETF really does
> is why I started this comment.

OK, I admit to a flaw in my research.  I was assuming that the IETF
documented its processes and decisions, and that such process and
decision-making was robust enough to be analysed or even audited at some
future time.  I think the term for this might be transparency or
accountability.

You are suggesting, and suggesting strongly even, that this is not the
case.  OK, I completely accept that, as I am new to the process, and
there is no reason to believe that the IETF would have adopted these
viewpoints.

Is there any reference material of a non-formal nature that would
support the notion that this WG should use unencumbered crypto for its
MUST algorithms?

If there is no supporting material at all, and the policy is based on
verbal or emailed conversations, then I would be most uncomfortable.  It
would raise many questions, and given the circumstances of the
competition for mail standards, these are questions that we'd rather the
other standards proponents could not raise.

( I think I know what the answer to this might be: there is no
supporting material and it should be taken up with the Area Director. 
OK, I'll start drafting a note.  Not knowing the guy and how familiar he
is with the situation, this'll keep me quite for a few days. :-)

-- 
iang                                      systemics.com

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

Date: Thu, 06 Nov 1997 10:43:23 -0800
To: Rodney Thayer <[email-masked]>, Adam Back <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: patent freedom & compatibility
Cc: [email-masked]
Sender: [email-masked]

At 11:18 AM 11/6/97 -0500, Rodney Thayer wrote:
>My point is that TLS was ordered to use DSS/DH and 3DES rather than RSA and
>RC4 as the MUST.

Quite true. The latest (and hopefully final) version of TLS has DSS/DH a
MUST and 3DES a MUST. Because there is no direct interoperability with
earlier versions of SSL, there are no SHOULDs, but there is a long list of
IDs so people will know the algorithm identifiers for other commonly used
algorithms like RSA.

>Using encumbered algorithms as non-MUST algorithms is fine.

This is my understanding of the IESG's current thinking as well.

>Analyzing 2026 to death rather than finding out what the IETF really does
>is why I started this comment.

And it's quite right. The IESG has offered verbal guidance about how they
currently interpret RFC 2026, and that guidance boils down to (I think) "if
there is an unencumbered alternative, you may not require an encumbered
algorithm, but you may list it as a suggested one, particularly for
compatibilty with earlier work."

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 06 Nov 1997 11:18:27 -0500
To: Adam Back <[email-masked]>
From: Rodney Thayer <[email-masked]>
Subject: Re: patent freedom & compatibility
Cc: [email-masked]
Sender: [email-masked]

My point is that TLS was ordered to use DSS/DH and 3DES rather than RSA and
RC4 as the MUST.

Using encumbered algorithms as non-MUST algorithms is fine.

Analyzing 2026 to death rather than finding out what the IETF really does
is why I started this comment.

At 03:20 PM 11/6/97 GMT, you wrote:
>
>Rodney Thayer <[email-masked]> writes:
>> If you look at what has been happening in the IETF lately you'd see that
>> TLS, IPSec, and PKIX have all run into this issue.
>
>Here's SSL3.02 draft (TLS) comments on this:
>
>G. Patent Statement
>
>   This version of the SSL protocol relies on the use of patented
>   public key encryption technology for authentication and encryption.
>   The Internet Standards Process as defined in RFC 1310 requires a
>   written statement from the Patent holder that a license will be
>   made available to applicants under reasonable terms and conditions
>   prior to approving a specification as a Proposed, Draft or Internet
>   Standard.  The Massachusetts Institute of Technology has granted
>   RSA Data Security, Inc., exclusive sub-licensing rights to the
>   following patent issued in the United States:
>
>        Cryptographic Communications System and Method ("RSA"),
>   No. 4,405,829
>
>   The Board of Trustees of the Leland Stanford Junior University have
>   granted Caro-Kann Corporation, a wholly owned subsidiary
>   corporation, exclusive sub-licensing rights to the following
>   patents issued in the United States, and all of their corresponding
>   foreign patents:
>
>         Cryptographic Apparatus and Method ("Diffie-Hellman"),
>   No. 4,200,770
>
>        Public Key Cryptographic Apparatus and Method ("Hellman-
>   Merkle"), No. 4,218,582
>
>   The Internet Society, Internet Architecture Board, Internet
>   Engineering Steering Group and the Corporation for National
>   Research Initiatives take no position on the validity or scope of
>   the patents and patent applications, nor on the appropriateness of
>   the terms of the assurance.  The Internet Society and other groups
>   mentioned above have not made any determination as to any other
>   intellectual property rights which may apply to the practice of
>   this standard.  Any further consideration of these matters is the
>   user's own responsibility.
>
>> Analyzing the document rather than studying the context is not
>> necessarily the way to look at things when dealing with the IETF
>> standards process.
>
>Could you clarify that comment?
>
>Personally I think a patent free MUST cipher set is great, and very
>desirable.
>
>However I can also see that it would be nice to have backwards
>compatibility, and to provide a way for automatic backwards
>compatibility to be implemented within the documentation.
>
>An analogy for what Ian is arguing for might be perhaps SSL2.0
>fallback mode for SSL3.0 to retain backwards compatibility.
>
>Could we not do this at the same time as having patented algorithms as
>SHOULDs or even MAYs.  People don't have to implement SHOULD/MAY, but
>they can if they want, and presumably some vendors would to please
>users.
>
>Having more seamless backwards compatibility than pgp5.0 currently has
>might paradoxically speed the move to pgp5.x / OpenPGP algorithms and
>security improvements -- people may be holding back for various
>perceived compatibility reasons.  (Personally my only hold up is MUA
>software (unix person), I'm quite happy with being able to cope with
>two key pairs and using appropriately.)
>
>Note that I am not saying you can't be interoperable with pgp5.0,
>clearly you can, as you can add both your old RSA keys if you have
>some, or generate both RSA and DSA/EG keys and manually select key
>types to use.  I understand pgp5.0 windows client will warn you if you
>try to do things like sign with DSA key a document headed for someone
>with an RSA key.  This kind of thing could be made seamless, so the
>user wouldn't even notice.  So what is being suggested here is that
>there is some value to working through the process when the draft
>comes out to ensure that it would be possible to build such a system
>with the message and key formats allowing software to auto-detect what
>is the right thing to do.
>
>One trick SSL3.0 does is to diddle with some random value/value which
>is ignored which would not be noticeable to a 2.0 client, but which
>could be used by a 3.0 client to detect that it was talking to a 3.0
>capable client.  Building in more formalised upgrade paths in OpenPGP
>1.0 version such as this, will ease the way for less hassles later.
>It is probably possible to do things like this with 2.x, but I'm not
>sure how pretty the result would be :-( (Hide EG/DSA key in pgp2.x
>comment field, or other place?  Ugh.  Yuck.)
>
>Adam
>-- 
>Now officially an EAR violation...
>Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/
>
>print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
>)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
>
>

Date: Thu, 6 Nov 1997 15:20:03 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: patent freedom & compatibility
Sender: [email-masked]

Rodney Thayer <[email-masked]> writes:
> If you look at what has been happening in the IETF lately you'd see that
> TLS, IPSec, and PKIX have all run into this issue.

Here's SSL3.02 draft (TLS) comments on this:

G. Patent Statement

   This version of the SSL protocol relies on the use of patented
   public key encryption technology for authentication and encryption.
   The Internet Standards Process as defined in RFC 1310 requires a
   written statement from the Patent holder that a license will be
   made available to applicants under reasonable terms and conditions
   prior to approving a specification as a Proposed, Draft or Internet
   Standard.  The Massachusetts Institute of Technology has granted
   RSA Data Security, Inc., exclusive sub-licensing rights to the
   following patent issued in the United States:

        Cryptographic Communications System and Method ("RSA"),
   No. 4,405,829

   The Board of Trustees of the Leland Stanford Junior University have
   granted Caro-Kann Corporation, a wholly owned subsidiary
   corporation, exclusive sub-licensing rights to the following
   patents issued in the United States, and all of their corresponding
   foreign patents:

         Cryptographic Apparatus and Method ("Diffie-Hellman"),
   No. 4,200,770

        Public Key Cryptographic Apparatus and Method ("Hellman-
   Merkle"), No. 4,218,582

   The Internet Society, Internet Architecture Board, Internet
   Engineering Steering Group and the Corporation for National
   Research Initiatives take no position on the validity or scope of
   the patents and patent applications, nor on the appropriateness of
   the terms of the assurance.  The Internet Society and other groups
   mentioned above have not made any determination as to any other
   intellectual property rights which may apply to the practice of
   this standard.  Any further consideration of these matters is the
   user's own responsibility.

> Analyzing the document rather than studying the context is not
> necessarily the way to look at things when dealing with the IETF
> standards process.

Could you clarify that comment?

Personally I think a patent free MUST cipher set is great, and very
desirable.

However I can also see that it would be nice to have backwards
compatibility, and to provide a way for automatic backwards
compatibility to be implemented within the documentation.

An analogy for what Ian is arguing for might be perhaps SSL2.0
fallback mode for SSL3.0 to retain backwards compatibility.

Could we not do this at the same time as having patented algorithms as
SHOULDs or even MAYs.  People don't have to implement SHOULD/MAY, but
they can if they want, and presumably some vendors would to please
users.

Having more seamless backwards compatibility than pgp5.0 currently has
might paradoxically speed the move to pgp5.x / OpenPGP algorithms and
security improvements -- people may be holding back for various
perceived compatibility reasons.  (Personally my only hold up is MUA
software (unix person), I'm quite happy with being able to cope with
two key pairs and using appropriately.)

Note that I am not saying you can't be interoperable with pgp5.0,
clearly you can, as you can add both your old RSA keys if you have
some, or generate both RSA and DSA/EG keys and manually select key
types to use.  I understand pgp5.0 windows client will warn you if you
try to do things like sign with DSA key a document headed for someone
with an RSA key.  This kind of thing could be made seamless, so the
user wouldn't even notice.  So what is being suggested here is that
there is some value to working through the process when the draft
comes out to ensure that it would be possible to build such a system
with the message and key formats allowing software to auto-detect what
is the right thing to do.

One trick SSL3.0 does is to diddle with some random value/value which
is ignored which would not be noticeable to a 2.0 client, but which
could be used by a 3.0 client to detect that it was talking to a 3.0
capable client.  Building in more formalised upgrade paths in OpenPGP
1.0 version such as this, will ease the way for less hassles later.
It is probably possible to do things like this with 2.x, but I'm not
sure how pretty the result would be :-( (Hide EG/DSA key in pgp2.x
comment field, or other place?  Ugh.  Yuck.)

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

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

Date: Thu, 06 Nov 1997 07:42:36 -0500
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Re: IETF process 
Cc: [email-masked]
Sender: [email-masked]

If you look at what has been happening in the IETF lately you'd see that
TLS, IPSec, and PKIX have all run into this issue.

Analyzing the document rather than studying the context is not necessarily
the way to look at things when dealing with the IETF standards process.

>Date: Wed, 05 Nov 1997 23:58:12 +0000
>From: Ian Grigg <[email-masked]>
>Organization: Systemics
>X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386)
>To: Raph Levien <[email-masked]>
>CC: [email-masked], Gene Hoffman <[email-masked]>
>Subject: Re: IETF process (was How many 2.6 users?)
>Sender: [email-masked]
>
>Raph Levien wrote:
>> I believe that the most relevant document explaining IETF process is RFC
>> 2026. Quoting section 10.3.2(c), which is relevant for standards track
>> documents:
>> 
>>    (C)  Where the IESG knows of rights, or claimed rights under (A), the
>>       IETF Executive Director shall attempt to obtain from the claimant
>>       of such rights, a written assurance that upon approval by the IESG
>>       of the relevant Internet standards track specification(s), any
>>       party will be able to obtain the right to implement, use and
>>       distribute the technology or works when implementing, using or
>>       distributing technology based upon the specific specification(s)
>>       under openly specified, reasonable, non-discriminatory terms.
>>       The Working Group proposing the use of the technology with respect
>>       to which the proprietary rights are claimed may assist the IETF
>>       Executive Director in this effort.  The results of this procedure
>>       shall not affect advancement of a specification along the
>>       standards track, except that the IESG may defer approval where a
>>       delay may facilitate the obtaining of such assurances.  The
>>       results will, however, be recorded by the IETF Executive Director,
>>       and made available.  The IESG may also direct that a summary of
>>       the results be included in any RFC published containing the
>>       specification.
>> 
>>    So the existence of patented technology (such as RSA or IDEA) would
>> seem to be not necessarily a problem, as long as the patent is licensed
>> under appropriately "open" terms.
>
>Wow.  Let's look at this.  IDEA first.
>
>IDEA is licensed by Ascom and their licensing page is at [1].  Their
>schedule is at [2] and includes more prices than you can poke a stick
>at.  What is more interesting is that you can purchase the license over
>the Internet at [3] (although you are forced to read the license to get
>there).  It's especially open in the hackers sense that you do not have
>to use their source.
>
>I would therefore conclude that IDEA is: available to any party,
>distributable, purchasable under open, "reasonable" and
>non-discriminatory terms.  Reasonable is of course a value judgement.
>
>As an administrative burden, the IETF ExecDirector should get a letter
>that confirms this.  My reading of the site and Ascom's reputation do
>not indicate an issue here.
>
>> Whether RSA meets this standard is open
>> to question - certainly they have been accused by their detractors of
>> non-openness in their licensing process.
>
>OK, now RSA.
>
>I agree that RSADSI have a bad reputation on this issue.  I had a look
>at their web site and it is appallingly closed.  Note however that the
>above comment does not say that an assurance of openness is necessary:
>
>      "The results of this procedure
>      shall not affect advancement of a specification along the
>      standards track, except that the IESG may defer approval where a
>      delay may facilitate the obtaining of such assurances.  The
>      results will, however, be recorded by the IETF Executive Director,
>      and made available.  The IESG may also direct that a summary of
>      the results be included in any RFC published containing the
>      specification."
>
>"shall not affect advancement" is quite specific, which leaves open the
>question as to why the IESG supposedly rejected the S/MIME and SSL V3
>standards.  Perhaps they were simply deferred instead, as this deferral
>might be a bargaining chip in the hands of IETF.
>
>Can you comment in the S/MIME case as to why the above was considered to
>be a rejection?
>
>I would think that having the RSA algorithm listed in the standard,
>along with an IESG comment that said that this algorithm may not be
>available under open, non-discriminatory and reasonable guidelines to
>all parties would be quite a useful bargaining point.
>
>We could go even further.  You could say that the RSA algorithm is to be
>used, except where algorithm is not available under open,
>non-discriminatory and reasonable guidelines.  If we need a definition
>of this, I would suggest
>
>   * prices not in excess of other comparables (is ElGamal comparable?
>:-),
>   * purchasable over the web with no possibility of a human
>     being interposing some "conditions."
>   * no restrictions on code use (i.e., roll-your-own is ok, as is use
>     somebody else's)
>
>All of which seems obvious of course, based on the snippet above.  Are
>there any counter-views?
>
>
>
>>    Hope this helps.
>
>It's excellent, thanks.  Clears the FUD right out.
>
>
>
>[1] http://www.ascom.ch/Web/systec/policy/main.html
>[2] http://www.ascom.ch/Web/systec/policy/normal/exhibit3.html
>[3] http://www.ascom.ch/Web/systec/policy/normal/orderform.html
>
>-- 
>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: Conflicts and Options...
Date: 6 Nov 1997 12:23:02 GMT
Organization: IKS GmbH Jena
Lines: 6
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Peter Gutmann wrote:
>running PGP on pocket calculators and the like) is that it'd be a good idea to 
>finally split the key management off into a seperate program, especially with 
>the extra bloat added by the new algorithms and key packets.  About 99% of the 

I use modules. ;-)

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Conflicts and Options...
Cc: [email-masked]
Reply-To: [email-masked]
Date: Fri, 7 Nov 1997 00:30:49 (NZDT)
Sender: [email-masked]

>I believe that most users would be willing to migrate from their 
>current 2.x version to a new version (say 2.6.5, to include the magic 
>"5") which had 
> (1) a DOS-like interface identical to 2.6.3in, but with support for 
>the additional algorithms of 5.x (SHA1 and DSA, EG, CAST5, 3DES);
> (2) with key generation extended by optional additional parameters 
>to specify these algorithms (somewhat like PGP 5.5's choices); 
> (3) with defaults for these additional parameters set in pgp.ini for 
>existing programs which shell to PGP to generate keys.
 
A fourth point (which you've already touched on with your mention of people 
running PGP on pocket calculators and the like) is that it'd be a good idea to 
finally split the key management off into a seperate program, especially with 
the extra bloat added by the new algorithms and key packets.  About 99% of the 
time you never need to use the key management features, and you could probably 
halve the size of the program by moving the code into a seperate executable.  
If people really want to be able to run it under a single name, you could add 
a wrapper which invokes pgpcrypt or pgpkey depending on whether any of the 
args begin with -k.
 
Peter.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Conflicts and Options...
Date: 6 Nov 1997 08:33:30 GMT
Organization: IKS GmbH Jena
Lines: 24
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Tom Phinney wrote:
>If I were going to do create this 2.6.5 version, I would start with 
>Lutz' 2.6.3in as the base, and add the necessary algorithms and key 
>flags and pgp.ini parameters.  In addition to the source, I would 

Don't do that. I tried and failed. PGP 2.6.x code is not free for
development (exept 2.6.3ui). The major problem is, that PGP 2.6.x is a bunch
of patches you can't work with. So I restarted from stratch. Hope to finish
this year.

We (http://www.in-ca.individual.net/) have to get a licence for your
software from the BSI (German NSA, but much smaller and inco.*oops*). The
licence we need is called E4 (== B2 orange book) / high (strongest
algorithms known) for the whole system incl. software.

PGP 2.6.x will not get the licence, because E3 and higher requires a source
code check these patches will not survive.

The new development combined with a new enhanched(!) OpenPGP specification
may allow even a E6 (== A1) classification. <eg>

The sources for this PGPin will be published (as work progess snapshots)
under GPL and LGPL (especially allow to link the lib statically into
proprietary programms w/o source). Import into USA is not limited.

From: "Tom Phinney" <[email-masked]>
To: <[email-masked]>
Subject: Re: Conflicts and Options...
Date: Wed, 5 Nov 1997 23:00:24 -0000
Sender: [email-masked]

Ian Grigg <[email-masked]> wrote:

> Options have been on my mind lately.  More than anything else, 
> sparked by the 2.6 versus 5.x issue.

> 3.  A compatible 2.6 / 5.x method arises, so all product can handle 
> all comms.  This would migrate people over to the new methods more 
> quickly, perhaps within 2 years.

> 4.  Two separate standards opposed around some axis ... 
> (I am beginning to wonder myself whether this is inevitable, due to 
> the slow upgrade represented by the pure 5.x line ...

> We should remember that standards might be written by WGs and 
> authorised by quango-like administrators, but they are accepted by 
> users.  The success of any standard that this WG produces will not 
> be known for many years, and will be dictated by market reactions 
> to it and other factors.

I believe that most users would be willing to migrate from their 
current 2.x version to a new version (say 2.6.5, to include the magic 
"5") which had 
 (1) a DOS-like interface identical to 2.6.3in, but with support for 
the additional algorithms of 5.x (SHA1 and DSA, EG, CAST5, 3DES);
 (2) with key generation extended by optional additional parameters 
to specify these algorithms (somewhat like PGP 5.5's choices); 
 (3) with defaults for these additional parameters set in pgp.ini for 
existing programs which shell to PGP to generate keys.

The major problem with migration to PGP 5.x is not the additional 
algorithms; it is the limited integration of the PGP 5.x clients with 
existing platforms and tools.  PGP 2.x works on 80286s and up, on 
palmtops, and on virtually any other machine's DOS emulator.  It 
works with the remailers and nymservers and steganography tools and 
everything else which people use today to protect themselves from 
prying eyes.  It integrates into a wide variety of mail and news 
clients through PGPclick and many other support tools.

If I were going to do create this 2.6.5 version, I would start with 
Lutz' 2.6.3in as the base, and add the necessary algorithms and key 
flags and pgp.ini parameters.  In addition to the source, I would 
produce both RSAREF-based and non-US/Canada executables for DOS PCs, 
so that the majority of users (who don't have the necessary 
compilation tools) could do a simple download to upgrade.  But I 
don't have the toolset necessary to this task; perhaps those of you 
who do could tackle the job.

Tom Phinney
PGP: pub 1024 RSA:0xFA7148F1 DSS/EG:0x8A297007 on keyservers

From: "Darryl L. Rowe" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Bravo!
Date: Wed, 5 Nov 1997 22:18:57 -0500
Sender: [email-masked]

Works for me.

-----Original Message-----
From:	Richard Johnson [SMTP:[email-masked]]
Sent:	Wednesday, November 05, 1997 17:33 PM
To:	Jon Callas; [email-masked]; [email-masked]
Subject:	Re: Just say NO to key escrow or CMR/ARR revisited

Instead, let's leave message recovery up to the implementors of individual
applications, as an added feature not part of the official open-pgp
standard.  Those who sell into markets where such features are desired can
add them.  The rest of the world will not have to be forced to go along.

Date: Wed, 5 Nov 1997 19:43:10 -0700
To: "William H. Geiger III" <[email-masked]>, [email-masked]
From: "Richard Johnson" <[email-masked]>
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

At 15:49 -0700 on 11/05/1997, William H. Geiger III wrote:
> In <[email-masked]>, on 11/05/97
>    at 03:32 PM, "Richard Johnson" <[email-masked]> said:
>
> >It is not fear-mongering to request that the tags not even be defined
> >because they unnecessarily weaken the security of the standard.
>
> How does having a request tag in the key weaken security?? The tag can be
> used or ignored as the implementors see fit. No one is saying that you
> MUST respect the request tag and no one is saying that you MUST generate
> keys that contain such flags.
>

If only it were just a request tag.  PGP Inc's SMTP policy enforcer turns
the "request" into more of a demand.  It says, in its most strict
incarnation, 'encrypt to a 3rd party key we specify, or else your message
will not be allowed to reach the intended recipients.'  (Given the tags in
the messages, if PGP didn't write such an enforcer, someone else would
have.)

> >Please, let's not place hooks that can easily be abused to require
> >encryption to 3rd party keys into the standard.  Enforcement of such
> >requirements by software such as PGP's SMTP agent are all too real
> >possibilities (er, that exists already, doesn't it).
>
> <sigh> the biggest "hook" for the type of abuse you are so fearfull of is
> the ability to encrypt to multiple keys. The CMR tag is quite trivial
> compaired to this. So are you willing to continue with your logic that
> such "hooks" are to be avoided and call for a complete re-write of PGP so
> this can be advoided??
>

The problem I'm worried about is _forced_ encryption to 3rd party keys by
senders who don't need or desire to encrypt to those keys, but acquiese
because their messages won't get through if they don't.

Here, we just differ by a matter of degree.  Taking your point about
encryption to multiple keys being a "hook" a (large) step further, the
ability to encrypt to even a single key is a "hook" that should probably be
avoided if we want to keep attackers from having any chance of decrypting
the message.

Humor aside, I think capabilities that can easily be abused (and are being
abused?) to _require_ encryption to 3rd party keys do not belong in the
open-pgp specification.

Such features offer a many orders of magnitude reduction of effort and
storage needs to a drift-net attacker who wants to decrypt a large number
of messages.  Instead of having to obtain, sort and use thousands of
individual keys, the attacker will only need to steal (or legislatively
require access to) a single high value, long term recovery key.

Also, in a worst-case attack scenario where the adversary is a national
government (not necessarily your government...), it will certainly be
politically easier for them to require access to recovery keys, as a wedge,
than it will be to require access to all individual keys.  Granted, either
could be achieved by a government, but the high value recovery keys will be
easier for them to both obtain and manage.

In other attack scenarios with fewer overtones of big brother (or big
French uncle), a high value, long term recovery key still reduces the work
that needs to be done by an attacker seeking to perform corporate espionage.

Message recovery, as implemented in PGP 5.5 with forceable encryption to
3rd party keys, is an unnecessary weakness in the message format that
scales too well for the attacker.

> >Instead, let's leave message recovery up to the implementors of
> >individual applications, as an added feature not part of the official
> >open-pgp standard.  Those who sell into markets where such features are
> >desired can add them.  The rest of the world will not have to be forced
> >to go along.
>
> No one is forceing anyone to do anything here. No one is calling for MUST
> CMR key generation, no one is calling for MUST CMR implementation, all
> that is being requested in the spec is the definition of the CMR tag in
> the key. If you don't like it don't use it!! I think this falls in line
> with letting those who wish to implement message recovery to do so and
> those who do not don't.
>

PGP Inc.'s SMTP policy enforcer shows quite clearly how use of the CMR keys
can be (and is being?) required.  The tags should thus not be defined as
part of the official standard, as this leaves a wide opening (already being
exploited?) for forcing encryption of messages to 3rd party keys.

This unnecessarily weakens the security of the standard.  Message recovery
can and should be done only for those markets that need it, in the clients
they run, to avoid forcing the rest of the world to share the increased
risk.  Message recovery features thus need to be outside the open-pgp
standard.

Richard

Date: Wed, 05 Nov 1997 18:40:11 -0800
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Management by Committee ...
Sender: [email-masked]

At 09:45 AM 11/5/97 -0500, Darryl L. Rowe wrote:
   
   IMO, Phil/PGP should simply present the standard to IETF for 
   review, make any modifications, resubmit and so on a couple more 
   times and present a finished product.
   
   This group simply illustrates to me the fundamental rule that to 
   really screw things up requires a committee. Though W. Geiger, 
   Jon and a couple others are signalling quite well, others have 
   an enhanced noise level which seems to be subverting any 
   progress while others (i.e. RSA) manage to get their PR licks in 
   on other fronts. (Wonder if any posters are RSA stooges ...?)
   
Thanks for the vote of confidence, but I disagree comepletely about just
"presenting" something to the IETF.

Before we at PGP Inc. started this working group, we informally discussed
something that we called "unencumbered PGP." This was PGP with no
encumbered algorithms. PGP 5.0 was the first stab at it. Actually, PGP 3
was the first stab at it, from even before the formation of PGP Inc. All we
did at PGP Inc. was to put a name to what had already been happening. (PGP
5.0 was the first release of the long-awaited "PGP 3" code. It got its
number bumped to 5 because of the Viacrypt products numbered "PGP 4.x" that
were actually modifications to 2.6.x.)

There were also a number of other things that were happening related to
that. Most importantly, we did not document the new key formats adequately.
We put out a newsletter (called The Zimmermann Telegram) this spring that
had notes on the new key and signature formats. When we did that, I sat
down with a copy of RFC 1991 and the Zimmermann Telegram article and
started writing some PGP-compatible utilities. I ended up with a long list
of deficiencies, exceptions, and oh-by-the-ways that made it impossible to
use those as specs.

This concerned me, because there are a number of people who make
PGP-compatible software who weren't going to have an easy time making it
work with the new stuff. I started lobbying to get this done. In those
days, we believed that the EAR provisions about providing "technical
support" being an export precluded us from documenting the packet format
except with ink on paper, too.

I also wanted to revise the packet format. I dislike the "hand
huffman-coding" in the PGP formats. There are other idiosyncratic things in
the way PGP works that I have no opinion about, but other people don't
like. I thought that housecleaning was in order. There are of course
problems with doing a housecleaning, particularly in migrating old software
forward, but that doesn't mean I don't want to houseclean, only that I
understand I'm not likely to see that desire fulfilled.

I don't know who exactly came up with the idea for an OP working group. It
was some combination of Charles Breed and me, sometime in late June. We
discussed the possibility with people in the IETF and people at PGP. We
warned people at PGP that making something be an IETF standard means change
control is released to the IETF, encumbered algorithms are disallowed
(which we were doing anyway), and so on. I warned people that PGP 5.x would
probably not be OP-compliant. Everyone agreed this was okay. (By the bye,
according to the spec I'm now finishing up, it isn't.) We agreed to all the
requirements that other people who want to make IETF standards have to.
This includes the SECSH people, the TLS people, and anyone else who starts
from proprietary technology.

We got a BOF for Munich. We called it OpenPGP so that everyone would know
what it meant. We also started working on an OpenPGP draft for Munich.
Everyone who worked on that draft worked very hard, but it was only less
woefully inadequate than what had gone before.

At the BOF in Munich, we put everything on the table. I said, "everything
is negotiable." At Munich, we were told that we've followed the procedures
more closely than most working groups do. We were also given the advice,
"stop being so nice." As the team of us formed the working group, we
settled a number of the questions left open at the BOF. One was that there
is to be no new format, we'd start OP from PGP 5.x because PGP 2.6 can't be
an IETF standard, the PGP 5 formats solve those problems, solve the
security weaknesses of the PGP 2.6, and they predate PGP Inc., too. If you
want to propose new formats once OP 1.0 is finished, that's fine with me!

I'm the editor for OP-FORMAT 1.0. My personal goal for the OP working group
is to get OP done ASAP, in such a form that anyone -- PGP Inc., Systemics,
Bill Geiger, and so on can build interoperable, expandable products from
it. And then I want to leave. I'm an engineer, not a spec maven.

By the bye, I want to say now that I've been grumpy about the October date
for the OP-FORMAT draft. When the WG was formed, I said I wasn't going to
make it, but I could make a Thanksgiving date. I am someone who thinks
schedules are there to be met, not broken. I loathe being forced to play
for down one, if you'll pardon the bridge metaphor. I'm pretty sure I can
get the draft to John, Lutz, and Rodney by Friday so that it can be on an
FTP site after they are done with it, but it's not a foregone conclusion.

Like I said before, OP-FORMAT is not just a documentation of PGP 5.x. It's
based on PGP 5.x, but it has changes in it to make it a good IETF standard,
and PGP will have to catch up to that.

	Jon

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

From: "Chris Bartram" <[email-masked]>
Organization: 3k Associates
Reply-To: [email-masked]
Date: Wed,  5 Nov 1997 20:51:55 -0500
Subject: Re[2]: IETF process (was How many 2.6 users?)
To: [email-masked]
Sender: [email-masked]

 In <[email-masked]> [email-masked] writes:

[snip]

> >    So the existence of patented technology (such as RSA or IDEA) would
> > seem to be not necessarily a problem, as long as the patent is licensed
> > under appropriately "open" terms.

[snip]

> > Whether RSA meets this standard is open
> > to question - certainly they have been accused by their detractors of
> > non-openness in their licensing process.

[snip]

> I would think that having the RSA algorithm listed in the standard,
> along with an IESG comment that said that this algorithm may not be
> available under open, non-discriminatory and reasonable guidelines to
> all parties would be quite a useful bargaining point.
>
> We could go even further.  You could say that the RSA algorithm is to be
> used, except where algorithm is not available under open,
> non-discriminatory and reasonable guidelines.  If we need a definition
> of this, I would suggest

[snip]

> All of which seems obvious of course, based on the snippet above.  Are
> there any counter-views?

As someone that develops for a platform not officially "blessed" by RSA, I
would strongly object to RSA technology being referenced in an encryption
standard. We have approached RSA multiple times, and cannot even *get* a
license for their technology (even if we volunteer to port it ourselves)
at any cost. We dropped out of monitoring the S/MIME standards a while back
when it looked like it was going to require RSA technology-- so we took up
monitoring OpenPGP as an alternative. We develop an e-mail system for HP3000
computers and fully intend to implement and support OpenPGP on this platform.

Recommendation (or requirement) of a technology not available to *all*
implementors should not be allowed in an IETF standard.

Note; pgp and the rsalib code *do* work fine on our platform [hp 3000
computers running the MPE/iX OS] but we still cannot get a license for the
technology to "legally" use it. Not very *open*.

                -Chris Bartram
                 3k Associates, Inc.

______________________/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_
  Chris Bartram        Sales (US):   800 Net-Mail    Fax:+1 703 451-3720
   ______                         +1 703 569-9189    mailto:[email-masked]
  /__ |  \__________   Sales (Europe):+44(1480)414131 Fax:+44(1480)414134
 /  / | / ________     Sales (Pacific):+61 3 9489 8216 Fax:+61 3 9482 5124
|  /_ |<  ______       Tech Support:+1 703 569-9189  Fax:+1 703 451-3720
 \ __)| \ ___          mailto:support at 3k.com       Me: rcb at 3k.com
  \______/Associates,  6901 Old Keene Mill Rd Suite 500 Springfield VA 22150
_________________Inc._/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_
Gopher: gopher.3k.com   Anon-FTP: ftp.3k.com  WWW: http://www.3k.com/

From: "Ron Craswell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Conflicts and Options...
Date: Wed, 5 Nov 1997 17:10:29 -0800
Sender: [email-masked]

On Wednesday, November 05, 1997 4:33 PM, Ian Grigg
[SMTP:[email-masked]] wrote:
> 
> > You may also
> > note that this new spec has no MUST requirement for any RSADSI
> > technology.
> 
> What is the proposal, and how does it cope with the existing user base?

Please see
ftp://ietf.org/internet-drafts/draft-ramsdell-smime-msg-00.txt

Date: Thu, 06 Nov 1997 00:33:14 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Ron Craswell <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Conflicts and Options...
Sender: [email-masked]

Ron Craswell wrote:

> Please note that none of the authors are RSADSI employees.

Accepted.

> You may also
> note that this new spec has no MUST requirement for any RSADSI
> technology.

What is the proposal, and how does it cope with the existing user base?

-- 
iang                                      systemics.com

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

Date: Wed, 05 Nov 1997 23:58:12 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Raph Levien <[email-masked]>
CC: [email-masked], Gene Hoffman <[email-masked]>
Subject: Re: IETF process (was How many 2.6 users?)
Sender: [email-masked]

Raph Levien wrote:
> I believe that the most relevant document explaining IETF process is RFC
> 2026. Quoting section 10.3.2(c), which is relevant for standards track
> documents:
> 
>    (C)  Where the IESG knows of rights, or claimed rights under (A), the
>       IETF Executive Director shall attempt to obtain from the claimant
>       of such rights, a written assurance that upon approval by the IESG
>       of the relevant Internet standards track specification(s), any
>       party will be able to obtain the right to implement, use and
>       distribute the technology or works when implementing, using or
>       distributing technology based upon the specific specification(s)
>       under openly specified, reasonable, non-discriminatory terms.
>       The Working Group proposing the use of the technology with respect
>       to which the proprietary rights are claimed may assist the IETF
>       Executive Director in this effort.  The results of this procedure
>       shall not affect advancement of a specification along the
>       standards track, except that the IESG may defer approval where a
>       delay may facilitate the obtaining of such assurances.  The
>       results will, however, be recorded by the IETF Executive Director,
>       and made available.  The IESG may also direct that a summary of
>       the results be included in any RFC published containing the
>       specification.
> 
>    So the existence of patented technology (such as RSA or IDEA) would
> seem to be not necessarily a problem, as long as the patent is licensed
> under appropriately "open" terms.

Wow.  Let's look at this.  IDEA first.

IDEA is licensed by Ascom and their licensing page is at [1].  Their
schedule is at [2] and includes more prices than you can poke a stick
at.  What is more interesting is that you can purchase the license over
the Internet at [3] (although you are forced to read the license to get
there).  It's especially open in the hackers sense that you do not have
to use their source.

I would therefore conclude that IDEA is: available to any party,
distributable, purchasable under open, "reasonable" and
non-discriminatory terms.  Reasonable is of course a value judgement.

As an administrative burden, the IETF ExecDirector should get a letter
that confirms this.  My reading of the site and Ascom's reputation do
not indicate an issue here.

> Whether RSA meets this standard is open
> to question - certainly they have been accused by their detractors of
> non-openness in their licensing process.

OK, now RSA.

I agree that RSADSI have a bad reputation on this issue.  I had a look
at their web site and it is appallingly closed.  Note however that the
above comment does not say that an assurance of openness is necessary:

      "The results of this procedure
      shall not affect advancement of a specification along the
      standards track, except that the IESG may defer approval where a
      delay may facilitate the obtaining of such assurances.  The
      results will, however, be recorded by the IETF Executive Director,
      and made available.  The IESG may also direct that a summary of
      the results be included in any RFC published containing the
      specification."

"shall not affect advancement" is quite specific, which leaves open the
question as to why the IESG supposedly rejected the S/MIME and SSL V3
standards.  Perhaps they were simply deferred instead, as this deferral
might be a bargaining chip in the hands of IETF.

Can you comment in the S/MIME case as to why the above was considered to
be a rejection?

I would think that having the RSA algorithm listed in the standard,
along with an IESG comment that said that this algorithm may not be
available under open, non-discriminatory and reasonable guidelines to
all parties would be quite a useful bargaining point.

We could go even further.  You could say that the RSA algorithm is to be
used, except where algorithm is not available under open,
non-discriminatory and reasonable guidelines.  If we need a definition
of this, I would suggest

   * prices not in excess of other comparables (is ElGamal comparable?
:-),
   * purchasable over the web with no possibility of a human
     being interposing some "conditions."
   * no restrictions on code use (i.e., roll-your-own is ok, as is use
     somebody else's)

All of which seems obvious of course, based on the snippet above.  Are
there any counter-views?

>    Hope this helps.

It's excellent, thanks.  Clears the FUD right out.

[1] http://www.ascom.ch/Web/systec/policy/main.html
[2] http://www.ascom.ch/Web/systec/policy/normal/exhibit3.html
[3] http://www.ascom.ch/Web/systec/policy/normal/orderform.html

-- 
iang                                      systemics.com

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

From: "Ron Craswell" <[email-masked]>
To: "'Ian Grigg'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Conflicts and Options...
Date: Wed, 5 Nov 1997 15:06:43 -0800
Sender: [email-masked]

On Wed, Nov 05, 1997 2:12 PM, "Ian Grigg" <[email-masked]> wrote:
> 
> Whether you believe that PGP Inc would do such a thing or not, I doubt
> if you would disagree that there is a clear conflict in interest in PGP
> Inc writing the draft around PGP Inc product.  The same conflict of
> interest exists around RSADSI, for example.
> 

Point of accuracy -- the current S/MIME spec is being written by:

Section 1: Cryptographic Message Syntax
Russ Housley
SPYRUS

Section 2: Enhanced Security Services for S/MIME
Paul Hoffman
Internet Mail Consortium

Section 3: S/MIME Version 3 Message Specification
Blake Ramsdell
Worldtalk

Please note that none of the authors are RSADSI employees.  You may also
note that this new spec has no MUST requirement for any RSADSI
technology.

--
Ron Craswell
Worldtalk Corp.

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 05 Nov 97 16:49:56 -0600
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
To: [email-masked]
Sender: [email-masked]

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

In <[email-masked]>, on 11/05/97 
   at 03:32 PM, "Richard Johnson" <[email-masked]> said:

>At 13:25 -0700 on 11/5/97, Jon Callas wrote:
>> At 08:04 AM 11/5/97 -0800, [email-masked] wrote:
>>    I have no great problem with defining the neccesary flags and tags
>>    as 'implementation defined' so that non-CMR applications won't barf
>>    when they see them, but I certainly do not want to have to build
>>    snoopware into my applications in order to comply with the standard.
>>
>> This is *PRECISELY* what my original suggestion was. I think this is why
>> some people talk about "fear mongering." No one has ever suggested anything
>> by just defining the tags, and leaving treatment up to the application,
>> except the fear mongers.
>>

>It is not fear-mongering to request that the tags not even be defined
>because they unnecessarily weaken the security of the standard.

How does having a request tag in the key weaken security?? The tag can be
used or ignored as the implementors see fit. No one is saying that you
MUST respect the request tag and no one is saying that you MUST generate
keys that contain such flags.

>Please, let's not place hooks that can easily be abused to require
>encryption to 3rd party keys into the standard.  Enforcement of such
>requirements by software such as PGP's SMTP agent are all too real
>possibilities (er, that exists already, doesn't it).

<sigh> the biggest "hook" for the type of abuse you are so fearfull of is
the ability to encrypt to multiple keys. The CMR tag is quite trivial
compaired to this. So are you willing to continue with your logic that
such "hooks" are to be avoided and call for a complete re-write of PGP so
this can be advoided??

>Also, use of "recovery" keys to which a large amount of traffic is
>encrypted merely provides a high value key as a target for attack, by any
>adversary, government or not.

Well then don't implement it. No one is calling for CMR to be maditory in
the specs. You don't like it don't use it.

>Instead, let's leave message recovery up to the implementors of
>individual applications, as an added feature not part of the official
>open-pgp standard.  Those who sell into markets where such features are
>desired can add them.  The rest of the world will not have to be forced
>to go along.

No one is forceing anyone to do anything here. No one is calling for MUST
CMR key generation, no one is calling for MUST CMR implementation, all
that is being requested in the spec is the definition of the CMR tag in
the key. If you don't like it don't use it!! I think this falls in line
with letting those who wish to implement message recovery to do so and
those who do not don't.

- -- 
- ---------------------------------------------------------------
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, 5 Nov 1997 14:51:19 -0800 (PST)
From: Raph Levien <[email-masked]>
To: Ian Grigg <[email-masked]>
cc: [email-masked], Gene Hoffman <[email-masked]>
Subject: IETF process (was How many 2.6 users?)
Sender: [email-masked]

On Wed, 5 Nov 1997, Ian Grigg wrote:
> Can someone please post or point me at an authoritive reference to the
> IETF policy that has been mentioned, to whit, will not accept encumbered
> algorithms.
> 
> ( While we're at it, it has been mentioned that there is an IETF policy
> that there be an unencumbered implementation - does anybody have an
> authoritive reference on that as well?)

Sorry for jumping into the fray here. I'm no expert on IETF process, but 
I did look into this issue a couple of months ago when there was a 
similar debate on the S/MIME list.

I believe that the most relevant document explaining IETF process is RFC 
2026. Quoting section 10.3.2(c), which is relevant for standards track 
documents:

   (C)  Where the IESG knows of rights, or claimed rights under (A), the
      IETF Executive Director shall attempt to obtain from the claimant
      of such rights, a written assurance that upon approval by the IESG
      of the relevant Internet standards track specification(s), any
      party will be able to obtain the right to implement, use and
      distribute the technology or works when implementing, using or
      distributing technology based upon the specific specification(s)
      under openly specified, reasonable, non-discriminatory terms.
      The Working Group proposing the use of the technology with respect
      to which the proprietary rights are claimed may assist the IETF
      Executive Director in this effort.  The results of this procedure
      shall not affect advancement of a specification along the
      standards track, except that the IESG may defer approval where a
      delay may facilitate the obtaining of such assurances.  The
      results will, however, be recorded by the IETF Executive Director,
      and made available.  The IESG may also direct that a summary of
      the results be included in any RFC published containing the
      specification.

   So the existence of patented technology (such as RSA or IDEA) would 
seem to be not necessarily a problem, as long as the patent is licensed 
under appropriately "open" terms. Whether RSA meets this standard is open 
to question - certainly they have been accused by their detractors of 
non-openness in their licensing process.

   Hope this helps.

Raph

Date: Wed, 5 Nov 1997 15:32:32 -0700
To: Jon Callas <[email-masked]>, [email-masked], [email-masked]
From: "Richard Johnson" <[email-masked]>
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

At 13:25 -0700 on 11/5/97, Jon Callas wrote:
> At 08:04 AM 11/5/97 -0800, [email-masked] wrote:
>    I have no great problem with defining the neccesary flags and tags
>    as 'implementation defined' so that non-CMR applications won't barf
>    when they see them, but I certainly do not want to have to build
>    snoopware into my applications in order to comply with the standard.
>
> This is *PRECISELY* what my original suggestion was. I think this is why
> some people talk about "fear mongering." No one has ever suggested anything
> by just defining the tags, and leaving treatment up to the application,
> except the fear mongers.
>

It is not fear-mongering to request that the tags not even be defined
because they unnecessarily weaken the security of the standard.

Please, let's not place hooks that can easily be abused to require
encryption to 3rd party keys into the standard.  Enforcement of such
requirements by software such as PGP's SMTP agent are all too real
possibilities (er, that exists already, doesn't it).

Also, use of "recovery" keys to which a large amount of traffic is
encrypted merely provides a high value key as a target for attack, by any
adversary, government or not.

Instead, let's leave message recovery up to the implementors of individual
applications, as an added feature not part of the official open-pgp
standard.  Those who sell into markets where such features are desired can
add them.  The rest of the world will not have to be forced to go along.

Richard

Date: Wed, 05 Nov 1997 22:18:30 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
CC: Gene Hoffman <[email-masked]>
Subject: Re: How many 2.6 users?
Sender: [email-masked]

Ian Grigg wrote:
> Gene Hoffman wrote:
> > I think that comparing what is in use today (90K DSA/ElGamal keys versus
> > 20K RSA keys) with how many total copies of an old piece of software
> > were distributed is a logical flaw.
> 
> I must admit that I don't know how the 4 million was calculated,

Now I remember where the figure of 4 million users of PGP software comes
from.  Check out the latest PGP Inc publicity release [[email-masked]:

    PGP APPROVED TO EXPORT STRONG ENCRYPTION TO
    BANKS WORLDWIDE TO PROTECT FINANCIAL
    COMMUNICATIONS AND TRANSACTIONS

    [snip]
    About PGP
    .... With over four million users in 50 countries ...

> But the issue keeps getting raised, so in order to clarify this
> situation, let's find out.  How can we work out how many pgp2.6 users
> are out there?  I've got one suggestion: post to cypherpunks these
> questions:

( To cap off my recent survey, I got a smattering of responses that
combined gave 0, 0, and 10-25% usage by pgp5.x keys.  Not statistically
significant, but zero support for any notion that pgp5.x keys are of a
worthwhile percentage. )

Having established that we all agree that the user base of PGP software
is in the order of four millions, and the user base for PGP Inc's 5.x
products is also in the order of 100k, can we put the shaggy dog tales
to bed and accept that the community is using legacy software?

Now we just need to come up with a suitable proposal that seeks not to
disenfranchise the four million in order to meet the IETF policy.

Can someone please post or point me at an authoritive reference to the
IETF policy that has been mentioned, to whit, will not accept encumbered
algorithms.

( While we're at it, it has been mentioned that there is an IETF policy
that there be an unencumbered implementation - does anybody have an
authoritive reference on that as well?)

-- 
iang                                      systemics.com

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

Date: Wed, 05 Nov 1997 22:11:50 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: "[email-masked]" <[email-masked]>
CC: "'Anonymous'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Conflicts and Options...
Sender: [email-masked]

Darryl L. Rowe wrote:
> 
> I _did_ say: "...for review, ... modify, ... resubmit and so on
> a couple (times)."
> 
> That's _not_ a "rubber stamp."

The danger is that even though it is reviewed, PGP Inc can attempt to
keep changes to a minimum.  As editor (or, employing the editor), PGP
Inc are effectively in the driving seat.

Whether you believe that PGP Inc would do such a thing or not, I doubt
if you would disagree that there is a clear conflict in interest in PGP
Inc writing the draft around PGP Inc product.  The same conflict of
interest exists around RSADSI, for example.

One way to counterbalance that conflict is to write the draft in public
(the Lutz method).  Another way is to not put so much of the
responsibility into PGP Inc's hands (which may not be practical if they
are the only ones prepared to pay the editor's salary).

Whatever your politics, it can't be fun being editor in that position.

> No one is getting _anywhere_ with this more-or-less "off topic"
> issue .... maybe this should be a _moderated_ list, eh?

This might not be a good idea.  It would kill it stone dead.

Think of it this way.  With the absence of a draft to discuss, and a
moderated list being kept "on topic" we could also save on uneccessary
words such as "Open."

> ... Even a "rubber-stamped" PGP standard and CMR would
> be preferable to _anything_ involving RSA IMO....

Options have been on my mind lately.  More than anything else, sparked
by the 2.6 versus 5.x issue.

There are more options than you mention above:

1.  The null case:

  * the pgp2.x de facto standard remains in place
    for 4 million users.  (PGP Inc advertise this
    user base as their starting market.)

  * pgp5.x makes inroads into corporate America.
    and competes with S/MIME.

  * S/MIME remains in place as a de facto standard
    for large company mailers.  I don't know how
    effective this is, whilst it is widespread in
    browsers (I gather) I have never heard of anyone
    using it.

This is the do nothing case, which is synonymous with the WG folding
without a result.

2.  5.x becomes the IETF standard.  This is the "rubber-stamp."  In this
case, the 2.6 de facto standard will be around for a lot longer, due to
the barriers.  Hence, 4. below.

3.  A compatible 2.6 / 5.x method arises, so all product can handle all
comms.  This would migrate people over to the new methods more quickly,
perhaps within 2 years.

4.  Two separate standards opposed around some axis of commercial/noncom
or US/International.  The difficulties we have experienced in this group
are concentrated in the US/commercial area, so having a separate
standard for one segment might work.  (I am beginning to wonder myself
whether this is inevitable, due to the slow upgrade represented by the
pure 5.x line, as proposed in 2. above.)

5.  S/MIME becomes the standard - I can't see this being the case, but
RSADSI could always sweet-talk the IETF.  In which case, it might gain
currency in commercial markets, but I suspect pgp2.x will be around for
a long time too.

We should remember that standards might be written by WGs and authorised
by quango-like administrators, but they are accepted by users.  The
success of any standard that this WG produces will not be known for many
years, and will be dictated by market reactions to it and other factors.
-- 
iang                                      systemics.com

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

Date: Wed, 05 Nov 1997 12:25:14 -0800
To: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

At 08:04 AM 11/5/97 -0800, [email-masked] wrote:
   
   This is precisely the point we're making. If CMR goes into the Open
   PGP spec then this will happen *automatically* with any compliant
   application which receives a GMR key from abroad. 
   
How do you know?

>From my very first post on the subject to the OP list on CMR, I said that I
opposed what you're suggesting above. If CMR were mandatory, PGP products
would not comply, because it isn't mandatory in any PGP product.

   I have no great problem with defining the neccesary flags and tags 
   as 'implementation defined' so that non-CMR applications won't barf 
   when they see them, but I certainly do not want to have to build 
   snoopware into my applications in order to comply with the standard.

This is *PRECISELY* what my original suggestion was. I think this is why
some people talk about "fear mongering." No one has ever suggested anything
by just defining the tags, and leaving treatment up to the application,
except the fear mongers.

	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, 05 Nov 1997 12:07:44 -0800
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 03:35 PM 11/5/97 GMT, Adam Back wrote:
   
   Because it is PGP Inc is trying CMR people's reasoning abilities kick
   out "It can't be bad... PGP Inc are doing it".  "You don't understand
   it's very privacy respecting".  Sheesh.

Excuse me. We are doing no such thing. 
   
	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, 05 Nov 1997 20:23:40 +0100
To: IETF Open-PGP List <[email-masked]>
From: "Anthony E. Greene" <[email-masked]>
Subject: CMR & Open-PGP
Sender: [email-masked]

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

At 08:04 1997-11-05 -0800, [email-masked] wrote:
>I have no great problem with defining the neccesary flags and tags 
>as 'implementation defined' so that non-CMR applications won't barf 
>when they see them, but I certainly do not want to have to build 
>snoopware into my applications in order to comply with the standard.

Mark's idea is a good one. It makes Open-PGP compatible with current 
implementations and does not add any dangers. It also leaves the door 
open for developers who need to implement CMR for their markets. PGP 5.0 
does not choke on keys with ARR fields. This is the behavior we need to 
document. Whether or not an Open-PGP compliant application responds to 
ARR requests should be an implementation decision.

Writing a completely new messaging security standard, even if one is 
needed, is not part of the charter. I recommend we stay within the 
charter and move forward with open issues.

Tony

To: [email-masked]
cc: [email-masked] (Ned Freed), [email-masked]
Subject: published Internet Drafts (was Re: Ballot result: Element vs Packet)
From: "C. Harald Koch" <[email-masked]>
Date: Wed, 5 Nov 1997 14:21:56 -0500
Sender: [email-masked]

In message <[email-masked]>, Uri Blumenthal writes:
> 
> Ned, I take exception to this. In my NSH opinion, it is poerfectly OK to
> circulate the drafts on the list until they're ready to be submitted to
> the RFC editor (and that indeed is how several WGs do their job).

The point of Internet Drafts is to get review of a document *before* it
becomes an RFC. IDs usually go through several iterations before being
submitted to the RFC Editor. 

This *includes* review by people who are interested in a particular area,
but don't necessarily have time to wade through the WG mailing list (which
is particularly verbose and off-topic in the PGP WG).

Then there's the issue that E-Mail is not a good tool for distributing large
documents. Some people still run e-mail clients on small machines, like
palmtop computers, and don't like receiving internet-draft size messages.

Get the drafts *published* and into the I-D FTP sites, so that we have a
target to discuss, and we can get some rational discourse going.

-- 
Harald

From: "Darryl L. Rowe" <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'Anonymous'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: To Captain A. Duncel ... 
Date: Wed, 5 Nov 1997 14:08:28 -0500
Organization: Vocational Economics, Inc.
Sender: [email-masked]

I _did_ say: "...for review, ... modify, ... resubmit and so on
a couple (times)."

That's _not_ a "rubber stamp."

I can effectively do CMR using 2.6.2 and batch files and server
file/dir rights, but it's a pain.

CMR is irrelevant. Set up the standard so it won't choke on
anyone's app that uses it and/or some other implementation
"add-ins" and move on.

No one is getting _anywhere_ with this more-or-less "off topic"
issue .... maybe this should be a _moderated_ list, eh? Get
something done and moving before RSA gets their foot in the
door? (Even a "rubber-stamped" PGP standard and CMR would
be preferable to _anything_ involving RSA IMO.)

I may use PGP's crypto API in a couple of our apps to protect
client confidentiality ... or I may use something else. I've used
PGP 4/BE with corporate keys (CMR) before it (CMR) became
such an overstated issue. When we use PGP here at work the
PGP key's passphrase is known _both_ to the user and, if I look
it up, to me and the COO (if he looks it up). We're NOT using our
own dime here at the office. At home we (and I,) do what we want
and keep our own personal/private keys to ourselves. At work we
"speak for the company" and encrypting files is a no-no. Though
we've played with Norton's YEO a little. YEO and SecurePC both
have some nice ideas that PGP should, perhaps, look at and
implement in some manner, if they can.

If your company PGP uses CMR, don't use CMR at home. The vast
majority of the time we only use PGP to "sign" plaintext emails, so
CMR is _not_ an issue.

I would be all for having 3 people required to access a user's key
and decrypt their messages, or (gasp) recover their password or
merely _reset_ it so they could get back in themselves. Norton
has such a feature in the Admin kit (a 1-time-only password, I 
think).
But then, Norton is a file/directory encryption product, not email.

Matter of fact, this would do away with the whole CMR idea - have
an Admin Kit for business users where the Admin/Supervisor can
just "reset" the password to "password" so they can get back in
and change it ... or the boss can if the employee is dead or in
prison/Mexico.

How many of you expire your keys routinely? How many "normal"
users generate keys with expiration dates? Hmm.

Some of us keep a personal email address/key and a company email
address/key and never the twain meet.

And no, I'm _not_ kidding.

And I, too, am increasingly frustrated by the canine tail-chasing 
going on.
But at least I'm not posting anonymously.

Last word on the subject.

On Wednesday, November 05, 1997 11:31 AM, Anonymous 
[SMTP:[email-masked]] wrote:
>
> Darryl Rowe getting with the spirit of Open Standards writes:
> >
> > IMO, Phil/PGP should simply present the standard to IETF for
> > review, make any modifications, resubmit and so on a couple more
> > times and present a finished product.
>
> Yeah, right on!  They write it, we rubber stamp it without 
question.
>
> > Though W. Geiger, Jon and a couple others are signalling quite
> > well,
>
> On the topic of CMR?  You're kidding, right?
>
> > others have an enhanced noise level which seems to be subverting
> > progress while others (i.e. RSA) manage to get their PR licks in
>
> - An OpenPGP list member who is getting increasingly pissed off
> with certain "PGP only is allowed to speak" attitudes around here

Date: Wed, 05 Nov 1997 10:35:48 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Ballot result: Element vs Packet
To: Uri Blumenthal <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> > ........I see what appears to be a modified version of this posted by
> > Lutz to the list (which isn't the correct thing to do with drafts, BTW)...

> Ned, I take exception to this. In my NSH opinion, it is poerfectly OK to
> circulate the drafts on the list until they're ready to be submitted to
> the RFC editor (and that indeed is how several WGs do their job).

Frankly, I also could care less about drafts being posted to the list. However,
some people do care about this, and sometimes say so vociferously. And
this list always has enough vociferous contributions, if you know what I mean.

> No disagreement with the rest though.

Good.

				Ned

Date: Wed, 5 Nov 1997 10:07:36 -0800
To: Paul Hoffman / IMC <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: Ballot result: Element vs Packet
Cc: [email-masked] (Lutz Donnerhacke), [email-masked]
Sender: [email-masked]

At 11:06 AM -0800 11/4/97, Paul Hoffman / IMC wrote:
>I find this wholly offensive. This is an IETF Working Group, not a informal
>gang of developers making a spec by brute force.

Actually, Paul, by publishing the results, Lutz has done us all a favor.
The few number of voters is a much more vivid demonstration than my words
of how inconclusive such polls frequently are in an IETF mailing list.  As
Harald observed, the number of contributors to the mailing list far
exceeded the number of participants in the poll.

Lutz, once again, thank you for taking the time to do this.  Unfortunately,
this time the results are not particularly helpful.  Polls may have their
place, but we will put this aside for now.

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, 5 Nov 1997 17:33:29 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

David Hayes <[email-masked]> writes:
> 
> At 06:53 AM 11/5/97 -0600, William H. Geiger III wrote:
> >Plain and simple with or without CMR if the government is going to pass
> >laws requiring that all messages be encrypted with a government key then
> >you are f**ked, plain and simple. 
> 
> Your statement supposes that _the_ (singular) government will do this. In
> fact, there are many governments in the world. Some of them already have
> draconian laws, some have rejected them, and many are still sitting on the
> fence.

Absolutely.  William's statement over-simplifies the logistic problems
for governments in installing GAK.

The interoperability issues (many governments with different political
stances) and ease of software migration path are important.  With a
mail encryption standard, and implementations which aid the user in
complying with French (SCSSI) additional recipient requests, and with
Israel (mossad) requests the job is made considerably easier for
governments.

Let governments build their own infrastructure, let governments work
out their own software migration plans, and let governments deploy
their own software.

Clipper failed, let's not help them build clipper VI aka OpenPGP with
CMR.

> PGP is supposed to protect our information from adversaries, even
> democratically elected adversaries.

Right.  Security risks aren't fussy about the politics of the people
who exploit them.

> It would be better NOT to have features which are easily abusable by
> adversaries, even if those features have some legitimate use. Certainly
> such features should not be REQUIRED elements of a standard. 

Fortunately the CMR approach fails for security reasons alone, so we
can dismiss it for that reason.  (Though I do agree with the above
statement).

> Thus, using GAK means cutting one's self off from the rest of the
> non-GAK world. 

This is exactly what I argue we should be engineering in open
standards: extra GAK resistance.  If the international standards
purposely make it difficult to install GAK we have half won the
battle.  The IPSEC IETF standards people grok that argument, Ian Brown
posted a URL a while back on this list explaining this strategy.

To take an example SSL is forward secret.  This means that it is hard
to install `corporate/government web traffic recovery' because there
is no software available to do it, and because it would cut those
governments which tried it off from the rest of the world.

This is why some of us have been arguing for forward secret transport
level security for mail delivery.

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

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

Date: Wed, 5 Nov 1997 17:20:08 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: CMR semantics
Sender: [email-masked]

Mark Grant <[email-masked]> writes:
> I have no great problem with defining the neccesary flags and tags 
> as 'implementation defined' so that non-CMR applications won't barf 
> when they see them, but I certainly do not want to have to build 
> snoopware into my applications in order to comply with the standard.

Another option is to define in the standard correct behaviour for
personal use software on receipt of ARR requests is to fill them in
with random numbers as Bodo Moeller described.

I can't see this worrying PGP Inc as they like to describe how easy it
is to bypass anyway.

This just makes the semantics that ARR is a `request' as the name
suggests.

And that the sender has the choice either to comply or not with that
request.

(Where not complying is filling random numbers in the requested
extra crypto recipient.)

> >The purpose of this group is to provide a strong message encryption
> >standard.
> 
> Good; so let's create that standard and leave snoopware, message 
> recovery and key escrow to individual implementors.

Sounds good to me.

I think that having multiple long term keys (up to 4 with pgp5.5!)
able to decrypt messages transmitted over open communications channels
is an unnecessary security risk.

William stated that the discussion should be kept apolitical -- the
CMR security risk is apolitical to the extent that the parties who
might try to exploit the added CMR risks could be anyone: corporate
espionage, disgruntled ex-employee, French secret service (long
history of corporate espionage giving info to French competitors to US
and other companies), etc.

The point is why bother incurring the security risks, when there are
simpler and more secure alternatives?

I repeat: I'd like to see those who want CMR justify why they think it
is necessary that it should go in the standard.

Adam

Date: Wed, 05 Nov 1997 16:52:03 +0000
From: Ian Brown <[email-masked]>
Organization: University College London
To: "William H. Geiger III" <[email-masked]>
CC: [email-masked]
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

I have *tried* and *tried* to remain entirely non-abusive and stick to
the facts here. But since you are determined to attack this position -
your choice.

> Oh please, this is just more bad logic on top of bad logic.

Oh please, this is entirely non-substantiated irrelevant abuse. Save it
for somewhere else.

> Having a CMR flag in some public keys does not mean that everyone
> is using CMR

It does if a government mandates it. May I remind you what Barbara
Simons of the ACM's US Public Policy Committee said (since it seems to
have gone RIGHT over your head):

> 4. The NSA states that key recovery is doable and will not jeopardize
> national security. And there is an existence proof for key recovery
> software in the new PGP release.

> No that is not the purpose of this group. The purpose of this group is to
> provide a strong message encryption standard.

Well, why don't we just go with S/MIME then? That provides a strong
encryption standard within the US. DOH! It allows 40-bit encryption as
well. Oh well.

> Debate on the technical
> merits of any part of the spec is warranted, political fearmongering is
> not.

So, what would you describe Phil Zimmerman's speeches about human rights
and encryption as?

> Lets see here, you take a quote of a quote from a competitor of PGP Inc.
> as a factual statement and the basis of support for your position. Sorry
> you will have to do better than that.

Oh sorry, I didn't realise that a direct quote from Phil by a
'competitor' of PGP's was less valid than anyone else's. And Bruce
Schneier - what kind of clueless snake-oil purveyor is he? (IRONY
ALERT).

Let me quote Phil directly, from pgpdoc1. Is that OK?

> Most alarming of all is the White House's bold new encryption policy
> initiative, under development at NSA since the start of the Bush
> administration, and unveiled April 16th, 1993. The centerpiece of this
> initiative is a Government-built encryption device, called the Clipper
> chip, containing a new classified NSA encryption algorithm. The Government
> is encouraging private industry to design it into all their secure
> communication products, like secure phones, secure FAX,
> etc. AT&T is now putting the Clipper into their secure voice products.
> The catch: At the time of manufacture, each Clipper chip will be loaded with
> its own unique key, and the Government gets to keep a copy, placed in escrow.
> Not to worry, though -- the Government promises that they will use these keys
> to read your traffic only when duly authorized by law. Of course, to make
> Clipper completely effective, the next logical step would be to outlaw other
> forms of cryptography. 

Oh I'm sorry. Was that political fearmongering?

Ian.

Date: Wed, 05 Nov 1997 16:52:17 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Lutz Donnerhacke <[email-masked]>
CC: [email-masked]
Subject: Re: Next draft
Sender: [email-masked]

Lutz Donnerhacke wrote:

> Next draft may be come out by the end of this week. Thx Jon.

I think that we all would agree that the current lack of an open draft
on which to work on is debilitating to the group, to the extent of
dysfunctionality.  I would commend Lutz for efforts to bring the draft
to the open forum.

If indeed it is the intention of the editor to release the draft by the
end of the week, then perhaps we could call a truce in hostilities until
it is presented.  Then, we could resume group activity on the basis of
working on the draft.

-- 
iang                                      systemics.com

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

Date: Wed, 5 Nov 1997 08:49:23 -0800
From: Kent Crispin <[email-masked]>
To: IETF OpenPGP <[email-masked]>
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

On Wed, Nov 05, 1997 at 09:47:42AM +0000, Ian Brown wrote:

> > A completely bogus crux.  In *both cases* we are talking about
> > encrypted email.  Therefore, in both cases we are talking about data
> > sent across an insecure network.  Therefore, in both cases the FBI has
> > access to the ciphertext.  In either case, data that doesn't get sent 
> > across an insecure network is not the issue.
> > 
> > Forward secrecy in email is an orthogonal issue to CMR/key escrow.
> 
> Forward secrecy in email is orthogonal to this post.

> 
> In a CMR scheme, with a mandated government recipient, the ciphertext is
> sent across an insecure network. There it can be intercepted and read by
> any interested TLA.
> 
> In an escrow scheme - with escrow of either decryption keys or
> ciphertext encrypted to a company/FBI key *inside an organisation* -
> ciphertext *outside* the organisation is not encrypted to anyone except
> the recipient. It can be intercepted but not read.
> 
> > You are not making any sense here.  CMR doesn't automatically give 
> > keys to anyone.
> 
> No, I didn't say that. With a mandated government recipient, no keys
> need to be handed over. The ciphertext can be read as is.

The usual rule of thumb is that you should compare oranges and
oranges. 

With mandated escrow of all keys to the FBI the ciphertext can be 
read as is, just as well.

Neither CMR nor CKE say anything about "mandated government access". 
Either of them can be perverted by requiring it.  And either such
perversion would require a huge infrastructure of some sort or
another.

Personally, I prefer CKE to CMR, because after you filter out all the
FUD there actually is a serious and real problem here: organizational
management of large numbers of keys.  CKE more directly addresses 
this problem.  CMR merely puts off the problem a while.

It is my belief that *any* solution to this problem can be perverted
by governments, as well.  That's unfortunate, but it doesn't make the
problem go away.  As being online becomes more and more important and
common, large organizations need to use encryption for organizational
security. 

-- 
Kent Crispin				"No reason to get excited",
[email-masked]			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Everything discussed?
Date: 5 Nov 1997 16:40:57 GMT
Organization: IKS GmbH Jena
Lines: 10
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Adam Back wrote:
>Perhaps our IETF chairperson could help conduct a civilised discussion
>of this question whilst we are waiting for the draft.  There seems to
>be agreement on the MUST/SHOULD/MAY status of various ciphers, and
>nothing much else to discuss in the interim.

I don't believe this. There are several open questions. I.e. what's with the
empty line of an armor header, if armor headers do not exist at all? Other
open questions (for me) are: Key usage, Group keys, UserID expiration vs.
Key expiration.... (you all know my list).

Date: Wed, 5 Nov 1997 17:31:14 +0100 (MET)
To: [email-masked]
From: [email-masked] (Anonymous)
Organization: Replay and Company UnLimited
Sender: [email-masked]

Darryl Rowe getting with the spirit of Open Standards writes:
>
> IMO, Phil/PGP should simply present the standard to IETF for 
> review, make any modifications, resubmit and so on a couple more 
> times and present a finished product.

Yeah, right on!  They write it, we rubber stamp it without question.
Then they can advertise it as "IETF approved standard".

Sheesh.

Come to think of it why even bother with IETF standards, that would
dispense with inconveniences like having security flaws like CMR
exposed for what they are.

> Though W. Geiger, Jon and a couple others are signalling quite well,

On the topic of CMR?  You're kidding, right?

> others have an enhanced noise level which seems to be subverting any
> progress while others (i.e. RSA) manage to get their PR licks in on
> other fronts. (Wonder if any posters are RSA stooges ...?)

Not that I noticed... but one wonders about PGP stooges... are you a
PGP stooge?

- An OpenPGP list member who is getting increasingly pissed off with
certain "PGP only is allowed to speak" attitudes around here

Date: Wed, 05 Nov 1997 09:10:40 -0600
To: "William H. Geiger III" <[email-masked]>, [email-masked]
From: David Hayes <[email-masked]>
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

At 06:53 AM 11/5/97 -0600, William H. Geiger III wrote:
>Plain and simple with or without CMR if the government is going to pass
>laws requiring that all messages be encrypted with a government key then
>you are f**ked, plain and simple. 

Your statement supposes that _the_ (singular) government will do this. In
fact, there are many governments in the world. Some of them already have
draconian laws, some have rejected them, and many are still sitting on the
fence.

>Debating what should or should not be in the Open-PGP specs based on what
>law some government may or may not pass in the future does not have a
>place here. 

But it does. The world's governments must be lumped together as
"adversaries". From the point of view of a message sender, a government is
a well-funded, determined, but unauthorized recipient. PGP is supposed to
protect our information from adversaries, even democratically elected
adversaries. 

It would be better NOT to have features which are easily abusable by
adversaries, even if those features have some legitimate use. Certainly
such features should not be REQUIRED elements of a standard. 

That's where I think the OpenPGP standard, a protocol document, ends. The
rest is implementation choice.

My implementation choice is that GAK/GMR should be a high-profile feature.
I would prefer that other non-GAK/GMR implementations actively refuse to
cooperate with a GAK program. Thus, using GAK means cutting one's self off
from the rest of the non-GAK world. If the US government wants to require
GAK or GMR, they will. But it should be very painful to crypto's users, so
they can't just let it slip by unnoticed. 

--
David Hayes                                       [email-masked]
Switch Systems Engineering                        voice: 972-918-7236
MCI Communications, Inc.                               VNET: 777-7236
--If these thoughts were MCI's official opinions, the line above would
--read "MCI - Law & Public Policy Department".

Date: Wed, 5 Nov 1997 08:04:30 -0800 (PST)
From: [email-masked]
To: [email-masked]
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

William H. Geiger III [[email-masked]] wrote:

>well you are missing a step or two here:
>1st everyone overseas must be using CMR.
>2nd that software must force the user to encrypt to the GMR key.

This is precisely the point we're making. If CMR goes into the Open
PGP spec then this will happen *automatically* with any compliant
application which receives a GMR key from abroad. 

I have no great problem with defining the neccesary flags and tags 
as 'implementation defined' so that non-CMR applications won't barf 
when they see them, but I certainly do not want to have to build 
snoopware into my applications in order to comply with the standard.

>The purpose of this group is to
>provide a strong message encryption standard. 

Good; so let's create that standard and leave snoopware, message 
recovery and key escrow to individual implementors.

    Mark

Date: Wed, 5 Nov 1997 15:35:10 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

Ian Brown <[email-masked]> writes:
> > Debating what should or should not be in the Open-PGP specs based on what
> > law some government may or may not pass in the future does not have a
> > place here.

!!

> Au contraire. The overall aim of this exercise is (at least, I used to
> think) to improve everyone's privacy and prevent Big Brother taking
> over. To quote Phil Zimmerman:
> 
> > "It's poor civic hygene to install technologies that may someday
> > facilitate a police state."
> 
> [Source: Bruce Schneier]
> 
> I would say a central principle of Open PGP design should be that we do
> not do this.

Perhaps people would get the picture better if the NSA or NIST were to
join in this standardisation process, and ask for support for Lotus
notes like backdoors.  (Some of message key bits sent to CMR/GMR key
belonging to NSA resulting in 40 bits for NSA to break, and more bits
for everyone else to break)

If the NSA tried to put this in the standard there would be uproar.
If IBM, or TIS tried it also.

Because it is PGP Inc is trying CMR people's reasoning abilities kick
out "It can't be bad... PGP Inc are doing it".  "You don't understand
it's very privacy respecting".  Sheesh.

To the people who will jump in and say this post is off topic, it is
_not_ off topic.  CMR is poor design, and we are presenting the case
for why it should be either removed out right, or at least phased
out...

Security-wise: CMR is crap.  It is a security risk.  We've gone over
and over the risks of CMR and of simple obvious ways to reduce those
risks.  PGP Inc are having situations where 2, 3, 4 or even more long
term keys will be able to decrypt traffic for all time.  Attackers can
easily archive email as it goes over the Internet.

Ergonomics-wise: CMR is crap.  You can't recover from forgotten
passwords gracefully -- you've got to re-encrypt everything with the
employees new key.  I predict companies will use local escrow AND CMR
if this persists, and this is doubly dangerous because they'll escrow
the signature keys, and personal use keys too.

Politically: The brand name "PGP" has certain reputation behind it.
Lots of people have helped to give that brand name value.  We don't
want it associated with CMR/GMR techniques.

Those who want CMR in the standard had better start making a good case
for why that is necessary, and what advantages it has.  I can't see
that it has _any_.

Perhaps our IETF chairperson could help conduct a civilised discussion
of this question whilst we are waiting for the draft.  There seems to
be agreement on the MUST/SHOULD/MAY status of various ciphers, and
nothing much else to discuss in the interim.

Adam

From: Uri Blumenthal <[email-masked]>
Subject: Re: Ballot result: Element vs Packet
To: [email-masked] (Ned Freed)
Date: Wed, 5 Nov 1997 10:34:53 -0500 (EST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Ned Freed says:
> ........I see what appears to be a modified version of this posted by
> Lutz to the list (which isn't the correct thing to do with drafts, BTW)...

Ned, I take exception to this. In my NSH opinion, it is poerfectly OK to
circulate the drafts on the list until they're ready to be submitted to
the RFC editor (and that indeed is how several WGs do their job).

No disagreement with the rest though.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Next draft
Date: 5 Nov 1997 15:12:18 GMT
Organization: IKS GmbH Jena
Lines: 6
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* William H. Geiger III wrote:
>Well I will wait until the official draft is made available and then make
>my judgement on the technical merits of the proposal. The political
>fearmongering can be left for other lists.

Next draft may be come out by the end of this week. Thx Jon.

From: "Darryl L. Rowe" <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Management by Committee ...
Date: Wed, 5 Nov 1997 09:45:32 -0500
Organization: Vocational Economics, Inc.
Sender: [email-masked]

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

IMO, Phil/PGP should simply present the standard to IETF for 
review, make any modifications, resubmit and so on a couple more 
times and present a finished product.

This group simply illustrates to me the fundamental rule that to 
really screw things up requires a committee. Though W. Geiger, 
Jon and a couple others are signalling quite well, others have 
an enhanced noise level which seems to be subverting any 
progress while others (i.e. RSA) manage to get their PR licks in 
on other fronts. (Wonder if any posters are RSA stooges ...?)

On Wednesday, November 05, 1997 7:54 AM, William H. Geiger III 
[SMTP:[email-masked]] wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> In <[email-masked]>, on 11/05/97 
>    at 04:47 AM, Ian Brown <[email-masked]> said:
> 
> >-----BEGIN PGP SIGNED MESSAGE-----
> 
> >> A completely bogus crux.  In *both cases* we are talking 
about
> >> encrypted email.  Therefore, in both cases we are talking 
about
> >> data
> >> sent across an insecure network.  Therefore, in both cases 
the
> >> FBI has
> >> access to the ciphertext.  In either case, data that 
doesn't get
> >> sent 
> >> across an insecure network is not the issue.
> >> 
> >> Forward secrecy in email is an orthogonal issue to CMR/key
> >> escrow.
> 
> >Forward secrecy in email is orthogonal to this post.
> 
> >In a CMR scheme, with a mandated government recipient, the
> >ciphertext is
> >sent across an insecure network. There it can be intercepted 
and
> >read by
> >any interested TLA.
> 
> >In an escrow scheme - with escrow of either decryption keys 
or
> >ciphertext
> >encrypted to a company/FBI key *inside an organisation* -
> >ciphertext *outside* the organisation is not encrypted to 
anyone
> >except
> >the recipient. It can be intercepted but not read.
> 
> >> You are not making any sense here.  CMR doesn't 
automatically
> >> give 
> >> keys to anyone.
> 
> >No, I didn't say that. With a mandated government recipient, 
no
> >keys need
> >to be handed over. The ciphertext can be read as is.
> 
> 
> This argument against CMR is getting old and is as flawed as 
when it
> was
> first brought up. :(
> 
> Plain and simple with or without CMR if the government is 
going to
> pass
> laws requiring that all messages be encrypted with a 
government key
> then
> you are f**ked, plain and simple. CMR is not required for them 
to do
> it,
> plain old PGP 2.6 will work just as well. If they are going to
> start
> passing draconian laws in regards to encryption nothing done 
here
> will be
> of any importance as they will outlaw anything that does not
> conform
> (volentary GAK will never work and they know it).
> 
> Debating what should or should not be in the Open-PGP specs 
based on
> what
> law some government may or may not pass in the future does not 
have
> a
> place here. I propose that the FBI/CIA/NSA ...et al will get 
laws
> passed
> banning the use of all crypto therefore we should drop 
everything
> pack our
> bags and go on home.
> 
> - -- 
> - -------------------------------------------------------------
- --
> 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
>                        
> - -------------------------------------------------------------
- --
> 
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3a
> Charset: cp850
> Comment: Registered_User_E-Secure_v1.1b1_ES000000
> 
> 
iQCVAwUBNGBvYY9Co1n+aLhhAQHCOQP+MP2lwXtizpaPcg2N5nxMx8qO4WvjILIR
> 
LOS28FasDwTkT3dkgSUYP971m6BcwsdUmWr13P7aKDMb7E6UUC3rC9ax24qzeCFf
> 
obadn0TrqWiCw9/VfKR9FvuxhxeYUF+KkiTE5JybVh1P4GQTyJXNmWtmLyBI/L

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 05 Nov 97 08:20:09 -0600
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
To: [email-masked]
Sender: [email-masked]

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

In <[email-masked]>, on 11/05/97 
   at 08:20 AM, Ian Brown <[email-masked]> said:

>> Plain and simple with or without CMR if the government is going to pass
>> laws requiring that all messages be encrypted with a government key then
>> you are f**ked, plain and simple. CMR is not required for them to do it,
>> plain old PGP 2.6 will work just as well. If they are going to start
>> passing draconian laws in regards to encryption nothing done here will be
>> of any importance as they will outlaw anything that does not conform
>> (volentary GAK will never work and they know it).

>The WHOLE POINT is that we don't want to make it any easier for any
>government to impose such laws. If CMR becomes widespread, it is very
>easy for a government to pass a law saying "This GMR key must be used as
>a recipient on all messages". If everyone is using CMR already, few
>people will see this as particularly controversial. 

Oh please, this is just more bad logic on top of bad logic.

Having a CMR flag in some public keys does not mean that everyone is using
CMR let alone support your position that this somehow conditions the
public to support GMR.

You have failed to show that having a CMR flag leads to everyone using CMR
which leads to the government mandating GMR which leads to everyone
accepting GMR. The only leg you have to stand on is the fearmongering the
the government somehow someway might in the future pass some law to abuse
CMR. My point is that if they are going down this route they don't need
CMR to do it and CMR does not in any significant way aid them in this
effort. 

>Even worse, it allows
>governments to force such schemes on other countries without such laws.
>If the US passed such a law, all US citizens' keys would have an ARR for
>the GMR key. So if someone living in a country with more sensible
>legislation sent the US citizen a message, it would still be snoopable by
>the NSA. Is this what you want?

well you are missing a step or two here:

1st everyone overseas must be using CMR.
2nd that software must force the user to encrypt to the GMR key.

>> Debating what should or should not be in the Open-PGP specs based on what
>> law some government may or may not pass in the future does not have a
>> place here.

>Au contraire. The overall aim of this exercise is (at least, I used to
>think) to improve everyone's privacy and prevent Big Brother taking over.

No that is not the purpose of this group. The purpose of this group is to
provide a strong message encryption standard. Debate on the technical
merits of any part of the spec is warranted, political fearmongering is
not.

>To quote Phil Zimmerman:

>> "It's poor civic hygene to install technologies that may someday
>> facilitate a police state."

>[Source: Bruce Schneier]

Lets see here, you take a quote of a quote from a competitor of PGP Inc.
as a factual statement and the basis of support for your position. Sorry
you will have to do better than that.

>I would say a central principle of Open PGP design should be that we do
>not do this.

Well I will wait until the official draft is made available and then make
my judgement on the technical merits of the proposal. The political
fearmongering can be left for other lists.

- -- 
- ---------------------------------------------------------------
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, 05 Nov 1997 13:20:59 +0000
From: Ian Brown <[email-masked]>
Organization: University College London
To: "William H. Geiger III" <[email-masked]>, IETF OpenPGP <[email-masked]>
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

> Plain and simple with or without CMR if the government is going to pass
> laws requiring that all messages be encrypted with a government key then
> you are f**ked, plain and simple. CMR is not required for them to do it,
> plain old PGP 2.6 will work just as well. If they are going to start
> passing draconian laws in regards to encryption nothing done here will be
> of any importance as they will outlaw anything that does not conform
> (volentary GAK will never work and they know it).

The WHOLE POINT is that we don't want to make it any easier for any
government to impose such laws. If CMR becomes widespread, it is very
easy for a government to pass a law saying "This GMR key must be used as
a recipient on all messages". If everyone is using CMR already, few
people will see this as particularly controversial. Even worse, it
allows governments to force such schemes on other countries without such
laws. If the US passed such a law, all US citizens' keys would have an
ARR for the GMR key. So if someone living in a country with more
sensible legislation sent the US citizen a message, it would still be
snoopable by the NSA. Is this what you want?

> Debating what should or should not be in the Open-PGP specs based on what
> law some government may or may not pass in the future does not have a
> place here.

Au contraire. The overall aim of this exercise is (at least, I used to
think) to improve everyone's privacy and prevent Big Brother taking
over. To quote Phil Zimmerman:

> "It's poor civic hygene to install technologies that may someday
> facilitate a police state."

[Source: Bruce Schneier]

I would say a central principle of Open PGP design should be that we do
not do this.

Ian.

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 05 Nov 97 06:53:35 -0600
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
To: [email-masked]
Sender: [email-masked]

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

In <[email-masked]>, on 11/05/97 
   at 04:47 AM, Ian Brown <[email-masked]> said:

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

>> A completely bogus crux.  In *both cases* we are talking about
>> encrypted email.  Therefore, in both cases we are talking about data
>> sent across an insecure network.  Therefore, in both cases the FBI has
>> access to the ciphertext.  In either case, data that doesn't get sent 
>> across an insecure network is not the issue.
>> 
>> Forward secrecy in email is an orthogonal issue to CMR/key escrow.

>Forward secrecy in email is orthogonal to this post.

>In a CMR scheme, with a mandated government recipient, the ciphertext is
>sent across an insecure network. There it can be intercepted and read by
>any interested TLA.

>In an escrow scheme - with escrow of either decryption keys or ciphertext
>encrypted to a company/FBI key *inside an organisation* -
>ciphertext *outside* the organisation is not encrypted to anyone except
>the recipient. It can be intercepted but not read.

>> You are not making any sense here.  CMR doesn't automatically give 
>> keys to anyone.

>No, I didn't say that. With a mandated government recipient, no keys need
>to be handed over. The ciphertext can be read as is.

This argument against CMR is getting old and is as flawed as when it was
first brought up. :(

Plain and simple with or without CMR if the government is going to pass
laws requiring that all messages be encrypted with a government key then
you are f**ked, plain and simple. CMR is not required for them to do it,
plain old PGP 2.6 will work just as well. If they are going to start
passing draconian laws in regards to encryption nothing done here will be
of any importance as they will outlaw anything that does not conform
(volentary GAK will never work and they know it).

Debating what should or should not be in the Open-PGP specs based on what
law some government may or may not pass in the future does not have a
place here. I propose that the FBI/CIA/NSA ...et al will get laws passed
banning the use of all crypto therefore we should drop everything pack our
bags and go on home.

- -- 
- ---------------------------------------------------------------
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, 05 Nov 1997 09:47:42 +0000
From: Ian Brown <[email-masked]>
Organization: University College London
To: Kent Crispin <[email-masked]>, IETF OpenPGP <[email-masked]>
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

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

> A completely bogus crux.  In *both cases* we are talking about
> encrypted email.  Therefore, in both cases we are talking about data
> sent across an insecure network.  Therefore, in both cases the FBI has
> access to the ciphertext.  In either case, data that doesn't get sent 
> across an insecure network is not the issue.
> 
> Forward secrecy in email is an orthogonal issue to CMR/key escrow.

Forward secrecy in email is orthogonal to this post.

In a CMR scheme, with a mandated government recipient, the ciphertext is
sent across an insecure network. There it can be intercepted and read by
any interested TLA.

In an escrow scheme - with escrow of either decryption keys or
ciphertext encrypted to a company/FBI key *inside an organisation* -
ciphertext *outside* the organisation is not encrypted to anyone except
the recipient. It can be intercepted but not read.

> You are not making any sense here.  CMR doesn't automatically give 
> keys to anyone.

No, I didn't say that. With a mandated government recipient, no keys
need to be handed over. The ciphertext can be read as is.

Ian.

Date: Wed, 5 Nov 1997 00:02:55 -0700
To: Gene Hoffman <[email-masked]>, [email-masked]
From: "Richard Johnson" <[email-masked]>
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Cc: [email-masked]
Sender: [email-masked]

At 12:16 -0700 on 11/04/1997, Gene Hoffman wrote:
> On Tue, 4 Nov 1997 [email-masked] wrote:
>
> > At the same time, it builds a 'feature' into every copy
> > of PGP which could at some point in the future be used to provide
> > government access to messages by forcing users to encrypt to a government
> > key. This, to Adam and others (including me), is so great a risk that
> > we'd much prefer key escrow or an alternate system.
>
> ...
> It would take the same amount of government intervention to corrupt a
> corporate key escrow system as CMR.
>

Requiring access to plaintext via a system using either CMR (easier) or
corporate key escrow (slightly harder) would probably be well within the
capabilities of your average government to arrange.

However, there is one crucial difference between CMR and corporate key
escrow.  This difference leads me strongly _away_ from any kind of system
that requires (or could be abused to require) encryption of messages to 3rd
party keys.

Think of what the adversary who wants to abuse CMR on a large scale would
have to do, vs the task facing the adversary who wants to abuse a corporate
key escrow system.

Compare and contrast workload:

With CMR (encryption to 3rd party keys), in a likely implementation
scenario, the attacker only has to require encryption of all messages to a
corporate/ISP/city/county key, which they also hold or can steal, for
decryption at will.

With corporate key escrow, to achieve the same effect, the attacker will
need to require access to or steal copies of each key.

At an average of only 10,000 users per corporate/ISP/city/county "recovery"
key, CMR reduces the workload and storage needs of the attacker by 4 orders
of magnitude.  Throw in a province-wide or regional government recovery
key, and you reduce the storage needs of the attacker (not necessarily the
government) by 10 orders of magnitude or more.

This is a serious bottom-level security flaw with the basic CMR idea as
implemented in PGP 5.5.  It is too scalable, to the benefit of an attacker.

Implement message recovery outside open-pgp:

To achieve message recovery when necessary, corporate key escrow
implemented _outside_ the open-pgp standard (on a per-application basis) is
the more secure and reasonable alternative.

I would thus greatly prefer that the open-pgp standard not specify any kind
of encryption to 3rd party keys.

Of course, there is also no need for it to specify how any kind of key
escrow might be done.

Let's keep open-pgp simple, and leave message recovery to each application
developer who sells into markets where such features are desired.

Richard

Date: Tue, 04 Nov 1997 20:19:15 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Ballot result: Element vs Packet
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> I find this wholly offensive. This is an IETF Working Group, not a informal
> gang of developers making a spec by brute force.

> Lutz, you have previously claimed ignorance of IETF rules, and it appears
> that you have not done anything to fix that ignorance. I'd like to repeat
> what the WG chairperson said weeks ago:

> > Lutz, let me speak more plainly.  The chair will not hear further
> > discussion on this issue.  The chair did not call for a straw poll.  There
> > will be no vote on this.

> Which part of that did you not understand?

Paul, I agree 100%.

Folks, in case you haven't figured it out, this WG is in trouble. Discussion is
wandering all over the map rather than focusing on the deliverables this WG is
supposed to produce. Discussions of, say, RSA press releases, is _entirely_ out
of order.

I am also concerned that when I look at the IETF Web page for this WG for
Internet Drafts I find ... nothing. I see one formats draft from July on the
IMC Web site, I see what appears to be a modified version of this posted by
Lutz to the list (which isn't the correct thing to do with drafts, BTW), I have
a messasge from the chair saying that he's asked the various authors to work
together to get a combined draft out, and I have a message from Jon Callas
saying that he's going to merge all this stuff and have a draft out RSN. 

This is all quite confusing. Internet drafts are an essential part of a WG's
operation. Not having produced any at this point would be fine. Missing the Oct
97 schedule for a draft is of no real consequence. Having all these documents
lying around in lieu of legitimate drafts, however, is not fine.

This group needs to get drafts out in the proper way, develop a list of open
issues in those drafts, and hammer away at the issues on the list until they
are all resolved.

				Ned

Date: Tue, 4 Nov 1997 19:28:14 -0800
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

On Tue, Nov 04, 1997 at 09:02:31PM +0000, Ian Brown wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> > Building a key escrow system would do exactly the same thing. Putting in
> > place the infrastructure for automated enterprise wide key escrow to a
> > corporate key would mean building a technology infrastructure at exactly
> > the same risk. A government could just as easily say, "Thou shalt escrow
> > to the FBI key and send it to central storage" as they could corrupt CMR
> > to say "Thou shalt encrypt to the FBI key."
>  
> I'm not sure what you mean by 'central storage'. If you mean a backup
> server within an organisation, this means the FBI still has to gain
> physical access to the encrypted data. With CMR, the data is likely to
> be sent across an insecure network so the FBI could access it easily.
> 
> This is the crux of the argument.

A completely bogus crux.  In *both cases* we are talking about
encrypted email.  Therefore, in both cases we are talking about data
sent across an insecure network.  Therefore, in both cases the FBI has
access to the ciphertext.  In either case, data that doesn't get sent 
across an insecure network is not the issue.

Forward secrecy in email is an orthogonal issue to CMR/key escrow.

[...]

> A properly designed escrow system
> would require the keys to be physically handed over by the organisation
> to the NSA. Regardless of how easy this step may be, it would hinder
> fishing and leave some kind of audit trail - unlike CMR.

You are not making any sense here.  CMR doesn't automatically give 
keys to anyone.

-- 
Kent Crispin				"No reason to get excited",
[email-masked]			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

Date: Tue, 04 Nov 1997 18:03:32 -0500 (EST)
From: Jeffrey Gold <[email-masked]>
Subject: Regulation: Self-Imposed or Goverment Mandated
To: pgp-users <[email-masked]>, ietf-open-pgp <[email-masked]>
Sender: [email-masked]

I have no doubt that the following is meant to apply to PGP and other 
crypto-methods, both inside and eventually outside the United States.
Any suggestions?  Or, should it be ignored until it is mandated?
___________________________________________________________

CYBERSPACE REGULATION:  DO IT YOURSELF OR HAVE IT DONE TO YOU  

In a speech to advertisers, Ira Magaziner, the Clinton 
administration's advisor on Internet issues, said:  "The 
tremendous economic benefits of the Internet will not work 
if we don't get efficient industry self-regulation on issues 
like privacy and content, especially in the children's area.  
If you fail, we will have to go the legislative route.  That 
gets caught up in the political process and will be less 
rational and efficient."  

(New York Times Cybertimes 4 Nov 97)
___________________________________________________________

Unfortunately, access to the New York Times Cybertimes outside
the United States requires a paid-subscription.  Reference:
http://www.nytimes.com/library/cyber/week/110497magaziner.html

Date: Tue, 04 Nov 1997 13:38:11 -0800
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 08:50 PM 11/4/97 GMT, Adam Back wrote:
   
   Jon Callas stated earlier that some pgp 5.0 for business customers
   were already escrowing keys (signature keys included ouch!)  All that
   needs to be done to fix this is to provide a menu option to copy
   backups of only company use encryption keys to floppy (presumably
   encrypted to a selected company escrow key).
   
Just for the record, I didn't say what version they're using. They are
pre-V5 customers. Probably 4.0 or 4.5, but I can't remember.

	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: Tue, 4 Nov 1997 20:50:21 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

Gene Hoffman <[email-masked]> writes:
> On Tue, 4 Nov 1997 [email-masked] wrote:
> 
> > At the same time, it builds a 'feature' into every copy 
> > of PGP which could at some point in the future be used to provide
> > government access to messages by forcing users to encrypt to a government
> > key. This, to Adam and others (including me), is so great a risk that 
> > we'd much prefer key escrow or an alternate system. 
> 
> Building a key escrow system would do exactly the same thing. Putting in
> place the infrastructure for automated enterprise wide key escrow to a
> corporate key would mean building a technology infrastructure at exactly
> the same risk. 

Jon Callas stated earlier that some pgp 5.0 for business customers
were already escrowing keys (signature keys included ouch!)  All that
needs to be done to fix this is to provide a menu option to copy
backups of only company use encryption keys to floppy (presumably
encrypted to a selected company escrow key).

This could be implemented by PGP Inc or other vendors outside of the
OpenPGP standard.

An international standard which includes support for message recovery
(CMR) is dangerous.  All you would have done with the local recovery
system I discuss above is to minimize the risks of forgery inherent in
escrowing signature keys.  All you would be doing is building support
for what companies will do anyway.  You can minimise privacy risks by
providing a personal use encryption subkey which is not escrowed by
this operation.

Even with CMR companies will probably escrow keys because the
ergonomics of recovering from lost passwords with CMR are poor
(re-encrypt all encrypted files on disk, floppy, backup tapes, etc).
Users frequently forget passwords (as unix sysadmins will confirm).  I
suspect CMR will get you many tech support calls at PGP -- user's
forgotten password, are you seriously telling us we've got to
re-encryt all this data (megabytes scattered over write once CDs,
tapes, harddisk, floppies, inside .ZIP archives etc).  Not pretty.

> A government could just as easily say, "Thou shalt escrow to the FBI
> key and send it to central storage" as they could corrupt CMR to say
> "Thou shalt encrypt to the FBI key."

They could indeed do this.  However local escrow is harder to abuse
than CMR because:

- it is logistically harder to organise collection of millions of keys
  than it is to publish one NSA owned key

- especially when companies use different techniques locally

Mark's point that CMR builds a feature which can be used for escrow
into every copy of PGP is also good.  He's referring to the fact that
all versions of pgp5.x to date (pgp5.0, and pgp5.5 for both personal
and company use) include support to make it easy for users to comply
with demands for escrow.  

For example, say you are using pgp5.0 for personal use in the US, and
you get a message from a French user where the French government have
installed mandatory CMR (I suppose that would be GMR), with the master
CMR key held by SCSSI.  pgp5.0 helps you to comply with that request,
and the CMR design simplifies the French governments task.  If the
French government wants to escrow user keys, let them work out the
logistics of collecting all their citizens keys themselves without any
help from PGP, or the OpenPGP standard.  If you want bonus
crypto-anarchic brownie points build forward secret transport level
security -- that'll slow down governments.

> Corporations are going to want central, encrypted escrow if PGP, Inc. 
> were to go that way.

If that is the corporations mentality I suspect they will have one
single master CMR key also, and that they will turn on the strict
policy enforcer flag.  I also suspect they will escrow the user
private keys just to ease recovery -- users forgetting passwords is
common, and CMR does not allow easy recovery from this.

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

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

Date: Tue, 04 Nov 1997 21:02:31 +0000
From: Ian Brown <[email-masked]>
Organization: University College London
To: Gene Hoffman <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

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

> Building a key escrow system would do exactly the same thing. Putting in
> place the infrastructure for automated enterprise wide key escrow to a
> corporate key would mean building a technology infrastructure at exactly
> the same risk. A government could just as easily say, "Thou shalt escrow
> to the FBI key and send it to central storage" as they could corrupt CMR
> to say "Thou shalt encrypt to the FBI key."
 
I'm not sure what you mean by 'central storage'. If you mean a backup
server within an organisation, this means the FBI still has to gain
physical access to the encrypted data. With CMR, the data is likely to
be sent across an insecure network so the FBI could access it easily.

This is the crux of the argument. CMR could enable widespread fishing by
surveillance agencies; they already have access to the ciphertext (which
would also be encrypted to their key). A properly designed escrow system
would require the keys to be physically handed over by the organisation
to the NSA. Regardless of how easy this step may be, it would hinder
fishing and leave some kind of audit trail - unlike CMR.

Ian.

Date: Tue, 4 Nov 97 13:35 GMT+0100
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Subject: Re: What this WG is doing
Organization: =?ISO-8859-1?B?SW5zdGl0dXQgPT9JU08tODg1OS0xP1E/Zj1GQ3JfdmVyc2Nodz1GNnJ1bmdzdGhlb3JldGlzY2hlPz0gSW5mb3JtYXRpaw==?=
Sender: [email-masked]

Bill Stewart <[email-masked]>:

> A program receiving a CMRK can do several things
> 0) Be confused and crash when receiving public key records
>       containing CMRKs :-)
> 1) Reject public key records containing CMRKs and complain to the user
> 2) Ignore the CMRK and process the main key, though you need to record
> 	the CMRK in the public key database since it's part of the signatures.
> 3) Ask the user whether to encrypt a copy to the CMRK, if there's a user
> 4) Ask the user, who's not there to respond to a dialog box, and hang
> 5) Cooperate with the request, doing something appropriate if you
> 	need to fetch the key matching the CMRK KeyID.
> 6) Implement some totally different functionality using that field
> 7) Obey Blindly

There is one more option.  For every public key encryption, the sender
also has the option of sending garbage (in the case of RSA, a random
number in the interval 1 .. N_key - 1; in the case of ElGamal, two
random numbers in the interval 1 .. p_key - 1) instead of real data.
Only with the appropriate private key is it possible to find out that
the "encrypted data" does not make any sense.

This feature is (AFAIK) not available in any version of PGP, up so
far.  But I always thought the user should have the possibility to

 1. add recipients to public key encrypted messages (provided that he
    can decrypt the message himself),
 2. add "fake recipients" in the sense explained above,
 3. delete recipients.

Usually, these features would have been pretty useless (although this
obviously changed with the advent of PGP's e-mail filtering gateway).
However, their existence would educate every PGP user that

 * PGP's message claiming that "This message can only be read by <list
   of user keys>" does not really guarantee that all those users are
   in fact able to decrypt the message, and

 * that it also does not guarantee that the original sender chose the
   same list of recipients that is present in the received message.

Note that options 2. and 3. above do not require the posession of a
private key; i.e., they can be done by an attacker while the message
is in transit.  I am sure that many PGP users assume that, when PGP
informs them that a message "can only be read by ...", the sender is
responsible for the decision who can (apparently) read the message --
while in fact there is no authentication for that.  Having features 1.,
2. and 3. implemented in PGP could help to prevent that unjustified
assumption.

Bodo M"oller
<[email-masked]>

From: [email-masked]
To: [email-masked] (Lutz Donnerhacke)
cc: [email-masked]
Subject: Re: Ballot result: Element vs Packet
Date: Tue, 04 Nov 1997 21:00:38 +0100
Sender: [email-masked]

In IETF terms, a 6:9 split is usually called "no consensus".

In a group with > 80 different people posting over the last few
weeks, a "vote" with a turnout of 17 is called a failure.

                            Harald A

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Ballot result: Element vs Packet
Date: 4 Nov 1997 19:29:01 GMT
Organization: IKS GmbH Jena
Lines: 4
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Paul Hoffman / IMC wrote:
>Which part of that did you not understand?

That's a result. Plain and simple. I do not urge any actions based on this.

Date: Tue, 04 Nov 1997 11:19:01 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do today?)
Sender: [email-masked]

At 01:37 PM 11/2/97 GMT, Adam Back wrote:
   
   It may not be necessary to have CAST5 to be interoperable with pgp5.x
   -- the symmetric cipher capability flags which are attached to public
   keys would allow people not implementing "MAY/or just OID listed"
   CAST5 to warn pgp5.x that they can't handle CAST5.
   
   Or stated the other way around, if CAST5 is not to be listed as a
   SHOULD, there better be a way to tell pgp5.x not to send email
   encrypted with CAST5 which reliably ensures you don't get CAST5 in
   your mailbox.  By reliably I mean even with Cc combinations of people
   with different combinations where multiple recipient encryption is
   used.
   
   Perhaps someone from PGP Inc with a better understanding of how this
   works (as the draft is not out yet) could explain how this would work
   out.
   
   There may even be that there is a case for CAST5 to be a SHOULD for
   compatibility with pgp5.x.  PGP Inc clarifications please!

The whole reason I originally suggested that CAST5 be a SHOULD algorithm
was my principle that any algorithm needed for compatibility ought to be a
SHOULD algorithm. Since then, though, Hal told me that PGP 5.x does not
need CAST5 to be a SHOULD algorithm. In other words, given that Triple-DES
is the MUST algorithm, a MUST-only implementation can interoperate with PGP
5.x. This is why I'm leaning away from making it a SHOULD. If Triple-DES is
the MUST, and IDEA is a SHOULD, everything else can be a MAY and you still
have maximal backwards compatiblilty. (Again, the most RSA or IDEA can be
are SHOULD algorithms.) 

If you have a message that is encrypted to more than one recipient, and
they all have their preferences, you quickly get to the MUST algorithm
being the lowest common denominator. The painful rub for our current
situation is that the MUST algorithm can't be the one for backwards
compatibility.
   
   > My understanding is that CAST5 is the default algorithm in 5.x, if
   > it is not a MUST or SHOULD there still should be some mention that
   > it is the default in PGP and those wishing to be able to communicate
   > with 5.x users will need to implement it. Simmilar documentation
   > should be provide in regards to 2.6.x and the RSA/IDEA/MD5
   > algortihms.
   
   I agree with the need to document cipher mode as well as OID -- for
   instance the IDEA mode is particularly odd: a non-standard CFB and it
   has particular checksum requirements.  (8 byte random junk is
   encrypted to act as IV, and then 2 bytes of checksum repeating the
   last 2 bytes of the random junk.  In addition something weird is done
   to the feedback at semantic boundaries in the message.  Personally I
   find this quirky mode annoying, but we've got it now for backwards
   compatibility.  Is this quirky semantic context variable length
   feedback CFB used with CAST5 and 3DES?)
   
Hal can speak most clearly on this, but my understanding is that all the
cyphers do the same thing.

	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: Tue, 4 Nov 1997 11:16:41 -0800 (PST)
From: Gene Hoffman <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

On Tue, 4 Nov 1997 [email-masked] wrote:

> At the same time, it builds a 'feature' into every copy 
> of PGP which could at some point in the future be used to provide
> government access to messages by forcing users to encrypt to a government
> key. This, to Adam and others (including me), is so great a risk that 
> we'd much prefer key escrow or an alternate system. 

Building a key escrow system would do exactly the same thing. Putting in
place the infrastructure for automated enterprise wide key escrow to a
corporate key would mean building a technology infrastructure at exactly
the same risk. A government could just as easily say, "Thou shalt escrow
to the FBI key and send it to central storage" as they could corrupt CMR
to say "Thou shalt encrypt to the FBI key."

Corporations are going to want central, encrypted escrow if PGP, Inc. 
were to go that way.

It would take the same amount of government intervention to corrupt a
corporate key escrow system as CMR.

-Gene Hoffman
PGP, Inc.

Date: Tue, 04 Nov 1997 11:06:53 -0800
To: [email-masked] (Lutz Donnerhacke), [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Ballot result: Element vs Packet
Sender: [email-masked]

I find this wholly offensive. This is an IETF Working Group, not a informal
gang of developers making a spec by brute force.

Lutz, you have previously claimed ignorance of IETF rules, and it appears
that you have not done anything to fix that ignorance. I'd like to repeat
what the WG chairperson said weeks ago:

>Lutz, let me speak more plainly.  The chair will not hear further
>discussion on this issue.  The chair did not call for a straw poll.  There
>will be no vote on this.

Which part of that did you not understand?

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 4 Nov 1997 11:01:24 -0800 (PST)
From: [email-masked]
To: [email-masked]
Subject: Re: Just say NO to key escrow or CMR/ARR revisited
Sender: [email-masked]

Since this probably is the wrong place for this discussion, I'll simply 
point out that every supposed advantage you give for CMR could equally 
apply to a properly designed key escrow system. Both provide access to 
data for those who have access to the recovery keys, and any system 
controlling access to CMR recovery keys could be used to control access 
to escrowed keys.

The only advantage that PGP Inc have suggested for CMR over key escrow is
that you can write your own version of PGP which puts garbage in the
CMR key field. At the same time, it builds a 'feature' into every copy 
of PGP which could at some point in the future be used to provide
government access to messages by forcing users to encrypt to a government
key. This, to Adam and others (including me), is so great a risk that 
we'd much prefer key escrow or an alternate system. In fact, key
escrow does not have to be built into PGP at all; it can be implemented
by an external secret-sharing program.

I for one do not want to see any such system included in the Open PGP
spec, but strongly suspect that PGP Inc will push it, since CMR cannot 
work properly unless every implementation of PGP supports it.

    Mark

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Ballot result: Element vs Packet
Date: 4 Nov 1997 18:38:17 GMT
Organization: IKS GmbH Jena
Lines: 19
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

                                                           Packet   Element
[email-masked]             Ian Grigg                   ABSTAIN  ABSTAIN
[email-masked]       Lutz Donnerhacke            ABSTAIN  ABSTAIN
[email-masked]              Anthony E. Greene           NO       YES
[email-masked]            David Hayes                 NO       YES
[email-masked]  David Formosa               NO       YES
[email-masked]               Jason Dufair                NO       YES
[email-masked]              Kent Crispin                NO       YES
[email-masked]       Tony Mione                  NO       YES
[email-masked]             Gary Williams               NO       YES
[email-masked]            Tom Phinney                 NO       YES
[email-masked]                 Gerald Young                NO       YES
[email-masked]           Ian Brown                   YES      NO
[email-masked]               Adam Back                   YES      NO
[email-masked]               Stefan Kelm                 YES      NO
[email-masked]         Mike Wynn                   YES      NO
[email-masked]              WengFatt Fong               YES      NO
[email-masked]              William H. Geiger III       YES      NO

Date: Tue, 04 Nov 1997 11:13:38 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Sounds like the only MUST should be a standard means of adding plug-in 
algoritms. That way id someone wanted IDEA, they could license the module
and link to the local engine.
					Warmly,
						Padgett

Date: Tue, 04 Nov 1997 09:10:13 -0800
To: Adam Back <[email-masked]>, [email-masked]
From: Andrea <[email-masked]>
Subject: Just say NO to key escrow or CMR/ARR revisited
Cc: [email-masked]
Sender: [email-masked]

Would someone please post the name of the correct mailing list for discussing 
this, as I do not believe that what I am about to say is appropriate for this 
forum.
   
At 11:38 PM 11/3/97 GMT, Adam wrote:
>
>Jon Callas suggests that CMR has been discussed vigorously.  What was
>the outcome?
>
>Here's a short summary of a more secure and less politically
>controversial alternative to CMR:
>
>1. Escrow employee company use encryption keys.
>2. Don't escrow employee personal use encryption keys.
>3. Don't escrow employee company use signature keys.

Who do you work for Adam, the CIA, FBI, Interpol?  Escrowing company keys 
creates a target for abuse.  If security and privacy is the goal there is no 
room for ANY key escrow except that copy of the private key that the 
individual maintains for their own backup. 

Message recovery, when used properly, enhances security and privacy as 
follows:
	1) There should never be only one message recovery key that can access all 
organizational information.  It creates a security risk. In the event that 
such a key is compromised all previously secured intellectual property would 
be at risk.
	2) Message recovery is to be configured at the client for small 
organizational units.
  	3) The unit's "TMR", trusted message recovery key, is to be accessed by 
trusted members of the group under the following conditions:
		a) The holder of the private key cannot decrypt the message/file. (forgot 
passphrase, on vacation, dropped dead, went to jail, etc.)
		b) TMR requires cooperative access by two or more individules within the 
organizational unit. (Won't get into my "shared/split split/shared secret" 
scheme at this point.)
	4) Compromise of the TMR key would require collusion. In the event that such 
compromise occurred, its impact would be limited to the single organizational 
unit and uncovering the weak link would be a fairly simple process.

TMR gives honest people the ability to protect their privacy and to secure 
their work from their own memory loss as well as unknown spies. 

>As pgp5 packet format already supports multiple encryption sub keys
>attached to signature keys, all that has to be done to support the
>above is to put comments in the userID to say what purpose the keys
>are for:
>
>Jon Callas <[email-masked]> (personal use)
>Jon Callas <[email-masked]> (company use)
>

99.9% (at least) of corporate users of encryption are not cryptographers. 
Understanding the difference between public and private keys, what 
encryption, decryption, digital signatures, and signature verification means 
is enough of a challenge without adding the complexity of multiple keys to be 
used for different purposes.

>Provide support in the business verion of the software to escrow the
>company use key.  Provide support for both company use and personal
>use keys.  If some companies want to disallow personal use, you might
>consider adding this feature.
>

This approach would only be appropriate if you were creating a surveillence 
system or a burdensome corporate control structure designed to invite 
corruption.  

>The above is already provided for without CMR/ARR.
>
>CMR/ARR fields add political and security risks, so why bother?
>
>
>So what is PGP Inc's position on the future of CMR?
>
>Is it going to be phased out?
>

I hope not. It solves the problem of multi-dimensional trust when 
communicating on behalf of yourself and the organization of which you are 
part.

>Is it going in the OpenPGP standard?
>
>Are there any security, privacy or political objections to local
>escrow?

Yes to all of the above. The rule of thumb here is..

Just say NO to key escrow.

Andrea

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Armor Header Optional?
Date: 4 Nov 1997 14:09:09 GMT
Organization: IKS GmbH Jena
Lines: 6
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

My draft points out, that the armor header may be missing. In this case the
empty line closing the armor header MUST NOT appear. My very first draft
said, that this line MAY occur anyway. It was changed to strong requests
from list members.

Unfortunly, this is not true for PGP 2.xx. The empty line MUST appear.

Date: Mon, 3 Nov 1997 23:38:05 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: CMR/ARR revisited
Sender: [email-masked]

Jon Callas suggests that CMR has been discussed vigorously.  What was
the outcome?

Here's a short summary of a more secure and less politically
controversial alternative to CMR:

1. Escrow employee company use encryption keys.
2. Don't escrow employee personal use encryption keys.
3. Don't escrow employee company use signature keys.

As pgp5 packet format already supports multiple encryption sub keys
attached to signature keys, all that has to be done to support the
above is to put comments in the userID to say what purpose the keys
are for:

Jon Callas <[email-masked]> (personal use)
Jon Callas <[email-masked]> (company use)

Provide support in the business verion of the software to escrow the
company use key.  Provide support for both company use and personal
use keys.  If some companies want to disallow personal use, you might
consider adding this feature.

The above is already provided for without CMR/ARR.

CMR/ARR fields add political and security risks, so why bother?

So what is PGP Inc's position on the future of CMR?

Is it going to be phased out?

Is it going in the OpenPGP standard?

Are there any security, privacy or political objections to local
escrow?

Enciphering minds want to know...

Adam

Date: Mon, 03 Nov 1997 15:13:23 -0800
To: Paul Hoffman / IMC <[email-masked]>, Rodney Thayer <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: how to discuss 2.6.2 compatability in OP...
Sender: [email-masked]

At 01:58 PM 11/3/97 -0800, Paul Hoffman / IMC wrote:
   
   Actually, I'd like it in the OpenPGP document, probably as an appendix. It
   is certainly acceptable to have the main document say how to have backward
   compatibility with pre-standards PGP, as long as compatibility that
   violates IETF rules isn't required. Backward compatibility that doesn't
   violate IETF rules could be required, although it probably should be
   optional if it's duplicated overhead.

Noted. It probably won't get in immediately -- I want to get out a draft to
everyone at the end of the week, but it makes a lot of sense to make such
an appendix.

It seems to me that it makes sense for such a thing to be in OP-FORMAT (my
document), but if it should be in another one, someone suggest which one.
   
   This is a very good reason for using the word SHOULD. You MUST do it this
   way, but you also SHOULD allow the user to do it this way to be compatible
   with earlier versions if they want to.
   
   I've also heard that there are errors and omissions in RFC 1991. If this is
   true, it would be very good if someone either rewrote RFC 1991 with them
   fixed or at least created a separate document that lists the fixes.
   However, that's separate from the OpenPGP work.
   
There are. When I came to PGP, I sat down and wrote some PGP-compatible
software using only RFC 1991 and our original ZT article that described the
V5 formats. I'm intimately familiar with what all is left out, and
documenting those was the original purpose of OP.

OP-FORMAT is the replacement for RFC 1991. When I started, the WG chairs
wanted a reorganization of the document from 1991 and The July Draft. I was
working on that, but have dropped that. The next draft takes Lutz's trunk
and grafts on text from The July Draft, your armoring work, and a lot of
stuff from Hal Finney. That's four merged docs. 

	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: Uri Blumenthal <[email-masked]>
Subject: Re: how to discuss 2.6.2 compatability in OP...
To: [email-masked]
Date: Mon, 3 Nov 1997 17:50:24 -0500 (EST)
Reply-To: [email-masked]
Sender: [email-masked]

Let me remind what those magic words are:

  MUST - unless you have it, you cannot claim conformance,
	period.

  SHOULD - you can claim conformance even without this feature, 
	but you have to be able to explain to your customers
	why you omitted the named feature from your product.
	If they don't buy your excuse, tough luck for you.

  MAY - entirely up to you, "no questions asked".
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

From: Uri Blumenthal <[email-masked]>
Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do
To: [email-masked] (Jon Callas)
Date: Mon, 3 Nov 1997 17:37:56 -0500 (EST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Jon Callas says:
>    So IDEA as SHOULD would guarantee backward compatibility? Fine. I'd prefer
>    MUST, but I see the problem.
> 
> Alas, it doesn't. The only thing that guarantees interoperability is MUST,
> and you can't have a MUST algorithm that's got intellectual property
> constraints, if there is an alternative.

Wel, nobody asks to GUARANTEE backward compatibility in ALGORITHMS.
On the other hand, nobody prohibits one from purchasing IDEA and
RSA license and building a backward-compatible product, if this
is what one thinks his customers want.

To accomplish it, "MAY" would be sufficient. "SHOULD" is actively
encouraging the interoperability with the obsoleted de-facto 
standard and is certainly more than enough.

> When we started the BOF in Munich, we had as one of the OP goals "limited
> backwards compatibility." What we meant by this was that we wouldn't even
> consider backwards compatibility with anything before 2.6, we even think
> that 2.6 should eventually be migrated/upgraded/phased out for security
> reasons, and we knew that even 2.6 compatibility is not possible given IETF
> because 2.6 used *only* encumbered algorithms. Thus, we put in the
> weasel-words "limited backwards compatibility."

Speaking PGP Inc. - I wish you ensured full backward compatibility
wrt. the INTERFACE: for example, since I have no time to modify
Mailcrypt-3.4 package that serves me nicely, I'd appreciate
if you could make PGP-6 (or whatever version it is going
to have :-) a perfect drop-in replacement for PGP-2.6.x
having the default algorithm suit specified, let's
say, in ~/.pgp/config.txt. 

> The bottom line is that we cannot be both an IETF standard and have
> guaranteed backward compatibility with 2.6.

Sure. How possibly can this be any different?
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Mon, 03 Nov 1997 13:58:38 -0800
To: Rodney Thayer <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: how to discuss 2.6.2 compatability in OP...
Sender: [email-masked]

At 04:31 PM 11/3/97 -0500, Rodney Thayer wrote:
>I believe the proper thing to do in this situation is for some interested
>party to write an informational draft that describes how, within the
>context of the OP framework, one would build something that is backwards
>compatible with 2.6.2.

Actually, I'd like it in the OpenPGP document, probably as an appendix. It
is certainly acceptable to have the main document say how to have backward
compatibility with pre-standards PGP, as long as compatibility that
violates IETF rules isn't required. Backward compatibility that doesn't
violate IETF rules could be required, although it probably should be
optional if it's duplicated overhead.

This is a very good reason for using the word SHOULD. You MUST do it this
way, but you also SHOULD allow the user to do it this way to be compatible
with earlier versions if they want to.

I've also heard that there are errors and omissions in RFC 1991. If this is
true, it would be very good if someone either rewrote RFC 1991 with them
fixed or at least created a separate document that lists the fixes.
However, that's separate from the OpenPGP work.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 03 Nov 1997 16:31:22 -0500
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: how to discuss 2.6.2 compatability in OP...
Sender: [email-masked]

I believe the proper thing to do in this situation is for some interested
party to write an informational draft that describes how, within the
context of the OP framework, one would build something that is backwards
compatible with 2.6.2.  In other words, write a draft that says:

  to be compatible with 2.6.2, use RSA and IDEA.  Their identifiers are <xxx>
  and <yyy>.

It gets the information documented.  It's Informational so it doesn't
violate the IETF guidelines.  It can be referenced by the main document.
It even gives you a place to write a nice speech in the Security
Considerations section about how you wish people would migrate.

>   So IDEA as SHOULD would guarantee backward compatibility? Fine. I'd prefer
>   MUST, but I see the problem.
>
>Alas, it doesn't. The only thing that guarantees interoperability is MUST,
>and you can't have a MUST algorithm that's got intellectual property
>constraints, if there is an alternative.

Date: Mon, 03 Nov 1997 12:31:17 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do
Sender: [email-masked]

At 12:11 PM 11/3/97 GMT, Lutz Donnerhacke wrote:
   
   So IDEA as SHOULD would guarantee backward compatibility? Fine. I'd prefer
   MUST, but I see the problem.

Alas, it doesn't. The only thing that guarantees interoperability is MUST,
and you can't have a MUST algorithm that's got intellectual property
constraints, if there is an alternative.

When we started the BOF in Munich, we had as one of the OP goals "limited
backwards compatibility." What we meant by this was that we wouldn't even
consider backwards compatibility with anything before 2.6, we even think
that 2.6 should eventually be migrated/upgraded/phased out for security
reasons, and we knew that even 2.6 compatibility is not possible given IETF
because 2.6 used *only* encumbered algorithms. Thus, we put in the
weasel-words "limited backwards compatibility."

The bottom line is that we cannot be both an IETF standard and have
guaranteed backward compatibility with 2.6.

	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: Mon, 03 Nov 1997 11:51:59 -0800
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: RSA Blows Smoke
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 01:53 PM 11/2/97 GMT, Adam Back wrote:
   
   Unfortunately PGP Inc have closed off dialogue on the topic --
   apparent blanket ban on employee discussion of CMR.
   
Horsefeathers, Adam. We've been talking about this with you a lot and you
know it. We set up a mailing list to discuss it, you've received personal
phone calls, and lots of people have bent over backwards for you.

If you think you're being ignored, perhaps you should re-examine the
signal-to-noise ratio of your posts.

	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)

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do
Date: 3 Nov 1997 12:11:41 GMT
Organization: IKS GmbH Jena
Lines: 14
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Paul Hoffman / IMC wrote:
>A very basic reason: SHOULD is only for things that are strongly desired by
>all implementations. If we have a strong algorithm for a MUST and another
>strong algorithm for a SHOULD, I see no point to tossing another SHOULD in.
>Many developers try to implement all SHOULD-level specs, and this would
>cause needless software bloat with little definable benefit.

So IDEA as SHOULD would guarantee backward compatibility? Fine. I'd prefer
MUST, but I see the problem.

>And, again, I would strongly lobby against any MAY list. A list of IDs for
>all known algorithms identifiers is enough.

That's a MAY list.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: expectation of privacy (Re: Symmetric Algorithm)
Date: 3 Nov 1997 12:07:34 GMT
Organization: IKS GmbH Jena
Lines: 6
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Jon Callas wrote:
>Your request for an algorithm identifier for ROT-13 has been duly noted. It
>might be better if I generalized it in the spec to ROT-N, where N is a
>128-bit number.

Don't include it. It is too easy to break.

Date: Sun, 02 Nov 1997 10:27:59 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Could We PLEASE stay on-topic here?
Sender: [email-masked]

At 09:39 AM 11/2/97 -0500, Rodney Thayer wrote:
>I don't think RSA-bashing is on-topic for this IETF WORKING GROUP 
>mailing list. 

I completely agree. The last thing OpenPGP needs to be is sidetracked by
the political machinations going on in the S/MIME world. RSADSI is who they
have always been, and this is part of the need for OpenPGP to come out
well, and soon.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sun, 02 Nov 1997 09:39:13 -0500
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Could We PLEASE stay on-topic here?
Sender: [email-masked]

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

I don't think RSA-bashing is on-topic for this IETF WORKING GROUP 
mailing list. 

Could we please stick to the subject?

If you want to bitch about RSA, do it on cypherpunks or something.

Cross-posting is also somewhat offensive.

Date: Sun, 2 Nov 1997 13:37:42 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do today?)
Sender: [email-masked]

William Geiger <[email-masked]> writes:
> >>[MUST = DSA/EG/3DES
> >> SHOULD = RSA/IDEA/MD5]
> >
> >A very basic reason: SHOULD is only for things that are strongly desired
> >by all implementations. If we have a strong algorithm for a MUST and
> >another strong algorithm for a SHOULD, I see no point to tossing another
> >SHOULD in. Many developers try to implement all SHOULD-level specs, and
> >this would cause needless software bloat with little definable benefit.
> >
> >And, again, I would strongly lobby against any MAY list. A list of IDs
> >for all known algorithms identifiers is enough.
> 
> Well FWIW I don't have a problem with only having one MUST and one SHOULD
> but if we are going that route there should be some documentation on what
> algorithms PGP 2.6.x & PGP 5.x are using and what the default operations
> are so implementors can insure that they have compatability with the
> current software available. 

It may not be necessary to have CAST5 to be interoperable with pgp5.x
-- the symmetric cipher capability flags which are attached to public
keys would allow people not implementing "MAY/or just OID listed"
CAST5 to warn pgp5.x that they can't handle CAST5.

Or stated the other way around, if CAST5 is not to be listed as a
SHOULD, there better be a way to tell pgp5.x not to send email
encrypted with CAST5 which reliably ensures you don't get CAST5 in
your mailbox.  By reliably I mean even with Cc combinations of people
with different combinations where multiple recipient encryption is
used.

Perhaps someone from PGP Inc with a better understanding of how this
works (as the draft is not out yet) could explain how this would work
out.

There may even be that there is a case for CAST5 to be a SHOULD for
compatibility with pgp5.x.  PGP Inc clarifications please!

> My understanding is that CAST5 is the default algorithm in 5.x, if
> it is not a MUST or SHOULD there still should be some mention that
> it is the default in PGP and those wishing to be able to communicate
> with 5.x users will need to implement it. Simmilar documentation
> should be provide in regards to 2.6.x and the RSA/IDEA/MD5
> algortihms.

I agree with the need to document cipher mode as well as OID -- for
instance the IDEA mode is particularly odd: a non-standard CFB and it
has particular checksum requirements.  (8 byte random junk is
encrypted to act as IV, and then 2 bytes of checksum repeating the
last 2 bytes of the random junk.  In addition something weird is done
to the feedback at semantic boundaries in the message.  Personally I
find this quirky mode annoying, but we've got it now for backwards
compatibility.  Is this quirky semantic context variable length
feedback CFB used with CAST5 and 3DES?)

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

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

Date: Sun, 2 Nov 1997 13:53:15 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: RSA Blows Smoke
Sender: [email-masked]

William Geiger <[email-masked]> forwards article:
> The Internet standards process is lengthy and complicated at
> best. The sticking point in RSA's efforts to date is that the task
> force will only consider non-proprietary technologies for the
> standards track. But S/MIME 2, the protocol at the heart of the
> effort, includes core RSA technologies that must be licensed.

No hope then, cool :-)

> RSA, in fact, is only one of five groups that have worked on S/MIME 2,
> which is about to be submitted by the Internet Mail Coalition to the IETF
> as an informational request for comments. Now, in order to retain its hold
> on the S/MIME technology, RSA is taking sole credit for submitting it to
> the task force, some observers claim.

Who worked on S/MIME 2?  How comes it's the same "Internet Mail
Coalition" that is "submitting S/MIME 2 to the IETF" as the one which
Paul Hoffman is slagging off RSA and S/MIME 2?

What version of S/MIME does netscape support?

> Hoffman reiterated that S/MIME 2 won't be an Internet standard
> because it relies on proprietary security technology and weak
> encryption. The Internet Mail Coalition is about to begin work on
> S/MIME 3, which will use stronger encryption and true open
> standards.

What's the point?  Why have two competing standards OpenPGP and S/MIME
3 -- does RSA hope that they will get some value from it?

Does S/MIME 3 have key escrow or CMR snooping support?

> "I hope [the announcement] hasn't sunk their chances because there
> are still a lot of people who want to do S/MIME," said
> Hoffman. "RSA's greediness could sink this, but I really hope it
> doesn't."

Before I heard about CMR additions to pgp5.x I would have said I do
sincerely hope RSA's greed sinks this.  (40 bit RC2/40 feh!)

I think I still do hope RSA's greed sinks S/MIME on average, but I
would be much more certain if this pgp5.x CMR thing could be resolved
satisfactorily.

Unfortunately PGP Inc have closed off dialogue on the topic --
apparent blanket ban on employee discussion of CMR.

So will the OpenPGP draft which Jon Callas dubbed "non political"
include CMR?

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

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

From: "William H. Geiger III" <[email-masked]>
Date: Sun, 02 Nov 97 06:53:09 -0600
To: Paul Hoffman / IMC <[email-masked]>
Cc: Jon Callas <[email-masked]>, Adam Back <[email-masked]>, [email-masked], [email-masked]
Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do today?)
Sender: [email-masked]

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

In <[email-masked]>, on 11/01/97 
   at 02:20 PM, Paul Hoffman / IMC <[email-masked]> said:

>>   Anyway, I agree with the people who are arguing for MUST for 3DES,
>>   DSA, Elgamal; and SHOULD for RSA, IDEA, MD5, and MAY for the rest.
>>   
>>This is my plan. I'm still open toward making CAST5 a SHOULD (in fact, that
>>is my personal preference), but I hear more reasons for MAY than SHOULD.

>A very basic reason: SHOULD is only for things that are strongly desired
>by all implementations. If we have a strong algorithm for a MUST and
>another strong algorithm for a SHOULD, I see no point to tossing another
>SHOULD in. Many developers try to implement all SHOULD-level specs, and
>this would cause needless software bloat with little definable benefit.

>And, again, I would strongly lobby against any MAY list. A list of IDs
>for all known algorithms identifiers is enough.

Well FWIW I don't have a problem with only having one MUST and one SHOULD
but if we are going that route there should be some documentation on what
algorithms PGP 2.6.x & PGP 5.x are using and what the default operations
are so implementors can insure that they have compatability with the
current software available. My understanding is that CAST5 is the default
algorithm in 5.x, if it is not a MUST or SHOULD there still should be some
mention that it is the default in PGP and those wishing to be able to
communicate with 5.x users will need to implement it. Simmilar
documentation should be provide in regards to 2.6.x and the RSA/IDEA/MD5
algortihms.

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

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

From: "William H. Geiger III" <[email-masked]>
Date: Sun, 02 Nov 97 06:37:59 -0600
To: [email-masked]
Cc: [email-masked]
Subject: RSA Blows Smoke
Sender: [email-masked]

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

Wierd News
RSA Blows Standards Smoke
James Glave [email-masked]"
6:16pm 31.Oct.97.PST
http://www.wired.com/news/news/business/story/8196.html

Today's announcement "http://www.rsa.com/smimelive/html/9710311.html" by
RSA Data Security stating that the company has formally applied to the
Internet Engineering Task Force to establish an email security standard is
a blatant lie rooted in greed, allege sources close to the process.

"RSA is lying, and I am really livid," said Paul Hoffman of the Internet
Mail Coalition. "RSA has not submitted anything."

The flap centers around the company's ongoing efforts to get its
proprietary S/MIME email encryption technology endorsed as a standard by
the task force. Such an endorsement would give the company credibility,
and potentially, an increased market share over rival Pretty Good Privacy.
PGP submitted a competing protocol for standards consideration last month.

The Internet standards process is lengthy and complicated at best. The
sticking point in RSA's efforts to date is that the task force will only
consider non-proprietary technologies for the standards track. But S/MIME
2, the protocol at the heart of the effort, includes core RSA technologies
that must be licensed.

To be considered for standardization, RSA must relinquish "change
control," or the ability to modify the technology, to the task force. And
the portion the task force is most interested in altering is the portion
that requires RSA technology. As a result, getting change control "has
been like pulling teeth," claims Jeff Schiller, the organization's
security director. 

"Their goal has always been get this into the IETF but don't really give
up control," said Schiller. "[They want to] make sure that when the
standard comes down, if an anyone wants to implement it then they have to
be a licensee."

Schiller says that until change control is secured, RSA has no hope of
coming near a formal application - as they had claimed to have already
done this morning. RSA, however, claims that it has granted change
control.

"They are trying to get more market share by claiming that the IETF is
endorsing their commercial product," alleged Schiller.

RSA, in fact, is only one of five groups that have worked on S/MIME 2,
which is about to be submitted by the Internet Mail Coalition to the IETF
as an informational request for comments. Now, in order to retain its hold
on the S/MIME technology, RSA is taking sole credit for submitting it to
the task force, some observers claim.

"It's totally disacknowledging the work of a lot of other people," said
Hoffman. A request for comments is one of the initial steps in the
certification process, and Hoffman says that the Internet Mail Coalition
has yet to put S/MIME 2 forward.

Further, Schiller says, "When we do, it is not trying to get it as an
Internet standard. It won't go - and therefore we are not going to try."

Hoffman reiterated that S/MIME 2 won't be an Internet standard because it
relies on proprietary security technology and weak encryption. The
Internet Mail Coalition is about to begin work on S/MIME 3, which will use
stronger encryption and true open standards.

Tim Matthews, product manager for RSA, acknowledged that the announcement
may be open to misinterpretation. "It's basically a summation of all the
work we've been doing over the past month," he said.

Instead of helping its own cause, and gaining public mindshare, RSA's
announcement may end up flying back in its face.

"If it fragments the S/MIME camp it could help PGP a bit," said Charles
Breed, director of technology for competitor PGP.

"I hope [the announcement] hasn't sunk their chances because there are
still a lot of people who want to do S/MIME," said Hoffman. "RSA's
greediness could sink this, but I really hope it doesn't."

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

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

Date: Sat, 01 Nov 1997 11:20:20 -0800
To: Jon Callas <[email-masked]>, Adam Back <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do today?)
Cc: [email-masked]
Sender: [email-masked]

>   Anyway, I agree with the people who are arguing for MUST for 3DES,
>   DSA, Elgamal; and SHOULD for RSA, IDEA, MD5, and MAY for the rest.
>   
>This is my plan. I'm still open toward making CAST5 a SHOULD (in fact, that
>is my personal preference), but I hear more reasons for MAY than SHOULD.

A very basic reason: SHOULD is only for things that are strongly desired by
all implementations. If we have a strong algorithm for a MUST and another
strong algorithm for a SHOULD, I see no point to tossing another SHOULD in.
Many developers try to implement all SHOULD-level specs, and this would
cause needless software bloat with little definable benefit.

And, again, I would strongly lobby against any MAY list. A list of IDs for
all known algorithms identifiers is enough.

--Paul Hoffman, Director
--Internet Mail Consortium