Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do today?)
From: Jon Callas <[email-masked]>
To: Adam Back <[email-masked]>, [email-masked]
Cc: [email-masked]
Date: Fri, 31 Oct 1997 15:47:54 -0800

At 08:43 PM 10/31/97 GMT, Adam Back wrote:
   
   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.

	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, 31 Oct 1997 20:43:32 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: IDEA licensing vs RSA licensing (Re: What do we have to do today?)
Sender: [email-masked]

Gene Hoffman <[email-masked]> writes:
> I find it interesting that everyone is ignoring the IDEA patent. I'm
> actually much more concerned about that encumberance as it is almost
> worldwide.

Perhaps it is that Ascom are easy to do business with: they have fixed
reasonable licensing rates, and bulk discounts for those who want to
pay more money up front.

RSA on the other hand have a history of being hard to do business with
stories about rates being based on "how much money do you have."  PRZ
knows all about RSADSI -- in fact some of the rumors are that PRZ's
investigation was instigated by RSA causing trouble.  Also the more
recent legal threat from RSA.

Can you license RSA from Cylink now?  What are they like?

Also with RSA something which seems to be missing from the discussion
is that they allow use of RSA under various circumstances provided you
use their RSAREF library.

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.

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, 31 Oct 1997 12:34:08 -0800
To: Lutz Donnerhacke <[email-masked]>, Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: What do we have to do today?
Cc: [email-masked]
Sender: [email-masked]

Thank you for sending me your notes, Lutz.

I'd like to note, however, that at the BOF in Munich, I agreed to be the
editor of this document, and the BOF agreed. Referring to me as the "new
editor to be" is incorrect. As far as the working group is concerned, I've
always been the editor.

Right now, I'm merging your work, the July draft, and other text from Hal
Finney, Paul Hoffman, Rodney Thayer, and others. I expect to have
everything merged by the end of next week, at which time I'll send it out,
and then we can have another editing pass on it.

The document I'm working on is the "Format" document, as opposed to the
Trust Model document (which also includes key server protocols). I can't
find my final list of what all the documents are. At one time, we were
talking about a handful of them, but a number of them got lumped together.
For example, I proposed originally that there be a document for packet
format, one for tehniques and algorithms, one for how packets are lumped
into messages and keys, one for the trust model, etc. John and Charles,
following the advice of Jeff Schiller (our Area Director), preferred a
small number of larger documents.

I really appreciate the work you've done -- I am taking all the other
sources I have and putting them into your document, and using its base
framework. My original plan had been to make a new framework that built up
messages from their constituant parts, and to rework a lot of the language
in the document. For example, getting rid of terms like "CTB," "Packet
Structure Field," and "Packet" itself (I was going to call them "Records").
I started this in my portion of the July draft, and I'm doing some, but not
the rest. For example, there's text now that says that a message "is
constructed from a number of records that are traditionally called packets"
and then uses the word "packet" everywhere else.

The one I'm editing now doesn't have trust models, politics, or anything
like that in it. It's a format document. Also, timestamps are specifically
out-of-scope for the working group.

	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, 31 Oct 1997 19:38:30 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: non-US acceptance of RSA (Re: What do we have to do today?)
Sender: [email-masked]

Uri Blumenthal <[email-masked]> writes:
> > I agree with Ian that RSA should be left in for non-US implementors
> > who don't have to worry about patents.  For us the concern is
> > getting people to use the implementation, people have heard of, and
> > trust, RSA, people can sometimes be persuaded to use DSA, but noone
> > outside the crypto/security community has ever heard of Elgamal, and
> > it's going to be a tough job going to someone who barely knows how
> > to spell RSA and convincing them to use a different algorithm
> > they've never heard of before.
> 
> I disagree with Peter grossly here.
> 
> Somebody who trusts RSA because he understands how it works, will
> trust El-Gamal for the same reason. Somebody who trusts RSA
> because the vendor who he believes, told him RSA is good,
> will trust El-Gamal for the same reason.

You are missing possibly the largest group -- they have heard of RSA,
and want it.  This is what Peter was saying, and it reflects my
experience also.  RSA is a digital signature standard I think for some
European standardisation efforts.  I think there are CEN standards on
using RSA as a digital signature algorithm for medics.  Certainly the
standards stuff I've been involved with has stuck to RSA, PKCS#7, and
X.509.

An argument against the CESGs attempted foisting of (DH based) CASM
(or new PR name CLOUD COVER) put forward was that it was contrary to
European standardisation which the medics were bound by European
law/agreement to use.  (Course the real reason they didn't like CASM
was because it was a key escrow system, and the medics couldn't see
the case for "national security" back door access to medical
information -- that and that it was packaged up with top sikrit CESG
(UK spook agency) designed algorithm Red Pike (also commonly known
amongst detractors as `red herring;.)

> > USA developers won't care after the autumn of 2000.  Then people can go
> > back to worrying about advances in factoring as well as attacks on random
> > numbers.
> 
> Still, I'd prefer El-Gamal over Elliptic Curve if I can have my say.
> In addition, I'd rather carry 300-bit key for ECC, that 2024-bit for
> RSA... 'nuff...

If you want tried and tested (re your comments about 3DES, with which
I agree), that's RSA or EG, but _not_ EC.

Anyway I'm not arguing... seems to be that what others suggested is
good:

MUST: 3DES, EG, DSA, SHA1
SHOULD/MAY: IDEA, CAST5, RSA, MD5, MD2

Unencumbered is important.  So is backwards compatibility, which rates
a SHOULD for those algorithms necessary for backwards compatibility
(IDEA, RSA, MD5) in my opinion.

MD2, CAST5, Blowfish perhaps as MAYs.

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, 31 Oct 1997 11:38:14 -0800 (PST)
From: Gene Hoffman <[email-masked]>
To: Bill Frantz <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: What do we have to do today?
Sender: [email-masked]

I find it interesting that everyone is ignoring the IDEA patent. I'm
actually much more concerned about that encumberance as it is almost
worldwide.

Gene Hoffman
PGP, Inc.

On Fri, 31 Oct 1997, Bill Frantz wrote:

> At 9:00 AM -0800 10/31/97, Peter Gutmann wrote:
> >I agree with Ian that RSA should be left in for non-US implementors who don't
> >have to worry about patents.  For us the concern is getting people to use the
> >implementation, people have heard of, and trust, RSA, people can sometimes be
> >persuaded to use DSA, but noone outside the crypto/security community has
> >ever
> >heard of Elgamal, and it's going to be a tough job going to someone who
> >barely
> >knows how to spell RSA and convincing them to use a different algorithm
> >they've never heard of before.
> 
> USA developers won't care after the autumn of 2000.  Then people can go
> back to worrying about advances in factoring as well as attacks on random
> numbers.
> 
> 
> -------------------------------------------------------------------------
> Bill Frantz       | Internal surveillance      | Periwinkle -- Consulting
> (408)356-8506     | helped make the USSR the   | 16345 Englewood Ave.
> [email-masked] | nation it is today.        | Los Gatos, CA 95032, USA
> 
> 

From: Uri Blumenthal <[email-masked]>
Subject: Re: What do we have to do today?
To: [email-masked] (Bill Frantz)
Date: Fri, 31 Oct 1997 13:14:40 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Bill Frantz says:
> >I agree with Ian that RSA should be left in for non-US implementors who don't
> >have to worry about patents.  For us the concern is getting people to use the
> >implementation, people have heard of, and trust, RSA, people can sometimes be
> >persuaded to use DSA, but noone outside the crypto/security community has
> >ever heard of Elgamal, and it's going to be a tough job going to someone who
> >barely knows how to spell RSA and convincing them to use a different
> >algorithm they've never heard of before.

I disagree with Peter grossly here.

Somebody who trusts RSA because he understands how it works, will
trust El-Gamal for the same reason. Somebody who trusts RSA
because the vendor who he believes, told him RSA is good,
will trust El-Gamal for the same reason.

> USA developers won't care after the autumn of 2000.  Then people can go
> back to worrying about advances in factoring as well as attacks on random
> numbers.

Still, I'd prefer El-Gamal over Elliptic Curve if I can have my say.
In addition, I'd rather carry 300-bit key for ECC, that 2024-bit for
RSA... 'nuff...
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Fri, 31 Oct 1997 09:18:47 -0800
To: [email-masked], [email-masked]
From: Bill Frantz <[email-masked]>
Subject: Re: What do we have to do today?
Cc: [email-masked]
Sender: [email-masked]

At 9:00 AM -0800 10/31/97, Peter Gutmann wrote:
>I agree with Ian that RSA should be left in for non-US implementors who don't
>have to worry about patents.  For us the concern is getting people to use the
>implementation, people have heard of, and trust, RSA, people can sometimes be
>persuaded to use DSA, but noone outside the crypto/security community has
>ever
>heard of Elgamal, and it's going to be a tough job going to someone who
>barely
>knows how to spell RSA and convincing them to use a different algorithm
>they've never heard of before.

USA developers won't care after the autumn of 2000.  Then people can go
back to worrying about advances in factoring as well as attacks on random
numbers.

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

From: Uri Blumenthal <[email-masked]>
Subject: Re: CART before the HORSE
To: [email-masked] (David P. Kemp)
Date: Fri, 31 Oct 1997 11:47:40 -0500 (EST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

David P. Kemp says:
> 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.

Hear, hear!  (:-)

> This decision was supported by the users, the small vendors, the large
> vendors, and the IESG.  

I personally am not surprised at all.

> This was
> not even controversial - the large controversy was whether there should
> be even one MUST algorithm suite.

But since all the *current* compliant implementation ought to interoperate,
at least *one* algorithm suite indeed is a-must.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Fri, 31 Oct 1997 16:43:07 +0200 (EET)
From: Markku-Juhani Saarinen <[email-masked]>
To: [email-masked]
Subject: Re: CART before the HORSE
Sender: [email-masked]

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.

  We have chosen the exactly same MUST algorithms in IETF-SecSh work
  (see draft-ietf-secsh-transport-02.txt).

- mj

Markku-Juhani O. Saarinen <[email-masked]>, SSH Communications Security Ltd

Date: Fri, 31 Oct 1997 08:42:58 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: CART before the HORSE
Sender: [email-masked]

> 
> 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.  This decision was supported by the
users, the small vendors, the large vendors, and the IESG.  This was
not even controversial - the large controversy was whether there should
be even one MUST algorithm suite.  Several minds were changed on that
issue, and most now agree that there should be.

Date: Fri, 31 Oct 1997 08:49:53 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: the security case against CMR (Re: rough consensus)
Sender: [email-masked]

Kent Crispin <[email-masked]> writes:
> > but there is a good security
> > case arguing against use of CMR for either of it's argued purposes.
> 
> There is a minor security case, IMO.  Given that PGP2.6 uses long-term
> communication keys the argument that 5.x should support forward
> secrecy is specious.  

Fact is pgp5.x _does_ support one form of forward secrecy already.

> Furthermore, forward secrecy in the existing email infrastructure is
> a known difficult problem, is it not?

No, if you're willing to have delayed forward secrecy, perhaps once
every 6 months, it's pretty easy.  pgp5.0 provides everything you need
to interoperate with such key usage.

> So, taking PGP to task for not providing forward secrecy is just hot
> air.

They have provided a form of forward secrecy: separate expiry times on
encryption keys.  All that needs to be done about that approach to
forward secrecy is to explain it in the security recommendations.

> Any scheme that doesn't provide forward secrecy is going to 
> leave gobs of ciphertext exposed under the same key for some time, by 
> definition.  

This is why pgp5.x has key expiry facilities; this part of the
argument is simple enough -- explain what key expiry can be used for:

- to reduce value of one key to an attacker
- or to delete private half some time after expiry

> This is just as true for Key Escrow schemes as it is for Multiple
> Encryption schemes.  Despite the FUD, the risks are very
> similar. (*)

It's potentially more dangerous for message recovery schemes because
the company is likley to use one long term key to provide backdoors
into many messages.  It is also more dangerous because there are now
TWO long term keys instead of one.

However much you want to downplay the danger, the fact is it is simply
an unnecessary security risk; there are much simpler, and safer
message recovery techniques, PGP Inc employees tell us their customers
were already using such techniques on an ad-hoc basis (floppies in
safe).  Implementors of commercial use OpenPGP software can improve
upon their customers existing practice of escrowing floppies (and
passphrases one presumes) by providing support to avoid escrowing of
signature keys.

Simple, requires no CMR definitions in the standard, meets all message
recovery user requirements, and is more secure too boot.

> (*) Your analysis avoids the problem of key management.  In both
> scenarios (Individual Key Escrow vs Dual Encryption (CMR)) the real
> issue is the mechanism for protecting the keys.  In the IKE case you
> have a repository for the escrowed keys -- the "keysafe" model I
> discussed some time ago.  The "keysafe" is a database in a
> cryptographic safe, and has a key of its own.

Implementors can build keysafes without CMR.  It is more secure to do
so than to use CMR.

> CMR actually requires a keysafe as well -- good practice would
> dictate that an organization segment their data across several
> recovery keys, and that they expire fairly quickly.  [When keys
> expire, you have three choices -- reencrypt everything to a new key
> (stupid), 

There are two kinds of key "expiry"; key reaches expiry date; and user
forgets passphrase.

Re-encrypting everything to a new key is PGP Inc's current practice,
which I agree isn't very ergonomic -- in fact I don't think they
provide any software to automate this problematic task.

> throw away the data (not likely),

> or keep a database of expired keys (the only realistic solution).]

You seem to be talking about storage.  For storage you wouldn't expire
the keys until you did want to throw away the data.  Several people
have expressed that they actually want to _destroy_ data after certain
periods for some applications.  (Where the data expiry period is
determined by their legal departments, based on record storage
requirements, and limitation of risks of lawsuits involving discovery
processes to retain data which would be better burnt from companies
point of view.)

For messages it is good security practice to throw away the key after
usage.  You seem to be jumping to conclusions about short expiry
times.  In an earlier example I gave a key expiry of 6 months.  Say
that you discard communications only keys a further 6 months after
expiry.  I can't see you losing many emails in transit over that one.
All the support to cope with such usage is built right into pgp5.0 and
pgp5.5; automated fetching of new keys from key servers when the user
attempts to use an expired key, and checking of certification on new
keys.

Separate storage keys are obviously a good idea, the difference in
use, and different security risks demand this.

> In both cases, you end up with a big pot of encrypted data encrypted
> by different keys, and no single key can decrypt more than a certain
> fraction of the total data.  With IKE the granularity is finer,
> probably, but it is adjustable in either case. 

If you're talking about storage it seems to me that you'd want to keep
the keys as long as you keep the data.  There might be some value in
expiring and more securely storing keys for very old backups which you
aren't intending to use much.  Perhaps you could write a few
paragraphs describing this kind of tradeoff for inclusion in the
security recommendations of the draft.  One suspects it might be a bit
advanced at this stage; most people are have enough work getting
implementations out at all.  It is a nice thought though, and probably
worth documenting in my view.

> [...]
> > 
> > When we start talking about key lengths, you get fairly clear
> > consensus -- much opposition is displayed to the notion of allowing
> > politics to weaken security.  (Sure Kent, 40 bits, or 56 bits might
> > arguably enough for some applications, if one uses your argument.)
> [...]
> > This doesn't sound in line with IPSEC stuff I
> > followed where political weakening of security standards has
> > specifically been rejected.
> 
> >From the IETF perspective, there is a vast difference between a
> protocol issue, like keylength, and an operational issue, like key
> management.  Operational issues are of a different character.  You
> can't say "The user MUST change his key every week", for example. 
> Realistically, you can't even say "Conforming implementations MUST
> generate a new key automatically after 30 days."

Sure, but you could say: "implementations SHOULD generate new keys
periodically".  Or implementations are recommended to in security
recommendations.  Even a 6 month expiry and 12 month key desctruction
period has great value.

> > What is worse though is that long term communications keys are being
> > encouraged by PGP Inc.  This is definately less secure.  Much less
> > secure.
> 
> As noted, the long term communication keys are a problem of 
> infrastructure, not PGP.

With pgp5.x the infrastructure is here.  Updating keys once per month,
or once every 6 months should present no problem.  You would delay
deleting the key for some kludge factor after the key expiry to still
be able to decrypt emails in transit.  Be generous, double the expiry
period before you delete the key, if you're suspicious of losing
messages.

> > Most who have voiced their opinion on the topic have expressed
> > negative opinions of CMR.  Perhaps this says something about the
> > technical and political demerits of CMR?
> 
> Perhaps it rather says something about who is vocal and who isn't.

Yes, but not the way you mean it.  PGP Inc has some investment in CMR,
therefore they will naturally want to protect that investment.  The
rest of participants mostly seem to agree that there are better ways
to do message recovery, which can be acheived outside the packet
standard even, with current pgp5.x packet sets.

My only interest in CMR is to see it phased out; mentions in the draft
if any should be in terms of being a feature retained for backwards
compatibility only.

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: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: What do we have to do today?
Cc: [email-masked]
Reply-To: [email-masked]
Date: Fri, 31 Oct 1997 17:00:17 (NZDT)
Sender: [email-masked]

>I don't know of any other pgp developers that have even started on the
>ElGamal side, I have asked on pgp-dev.
 
I have Elgamal in cryptlib (modulo keygen at the moment), but as you say, 
nobody outside the US cares about it.  I added Elgamal mainly because some 
people I know in the US asked for it and it wasn't that much work (again, 
modulo the keygen which is a real bastard to do quickly and efficiently).  In 
NZ and Australia neither RSA nor IDEA are patented, so everyone just sticks 
with that they know from PGP 2.x.  
 
I agree with Ian that RSA should be left in for non-US implementors who don't 
have to worry about patents.  For us the concern is getting people to use the 
implementation, people have heard of, and trust, RSA, people can sometimes be 
persuaded to use DSA, but noone outside the crypto/security community has ever 
heard of Elgamal, and it's going to be a tough job going to someone who barely 
knows how to spell RSA and convincing them to use a different algorithm 
they've never heard of before.
 
Peter.

Date: Fri, 31 Oct 1997 03:57:10 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Gene Hoffman <[email-masked]>
CC: [email-masked]
Subject: How many 2.6 users?
Sender: [email-masked]

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

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, and I
agree that it is not a rigourous comparison.  I would like to see some
rigourous numbers, but I wonder how to calculate numbers on a product
that was fundamentally distributed through informal means.  I say this
seriously because a lot of Systemics' product is like that - I simply
don't know how much is out there.

> I grant that I am making an
> assumption, but it would seem that the majority of keys in use would be
> on the public keyring. Of these its clear that there is most likely a
> majority of users with DSS/EG keys.

Well, let's assume not a majority, but half, because it makes the
numbers easy.  Also, of the 20k old keys up there, let's guess that
*all* them are from old software, and not new software.

That makes 40k copies of pgp2.6 out there in use today.  As in, double
the 20k.  I don't think that has any bearing with reality, nor the
figure of 4 million.  If the number was that low, why did PGP Inc bother
to keep the old algorithms in pgp5.0?

I happen to think the existing pgp2.6 user base is important, and I
address at long ranting length below.  Apologies to all for the length,
skip this mail if you are unconcerned.

A few observations:

1. Maybe not representative, but my own experiences over 4 or so years
of usage:  I don't know anyone (amongst those users I regularly
communicate with using pgp) that gets keys from servers, and who puts
keys on servers as a useful exercise.  I have indeed put my key up there
(and have done in the past) but I cannot recall anyone who has got it
off the server and sent me some encrypted email.  People just mail me
and ask me for the key.  That they do a lot.

( Perhaps we could ask the server sysadms:  of the keys on the servers,
what is the spread of 'gets' on those keys.  I.e., what percentage have
one get, what for 2, 3, ....  Wouldn't work if there were some automatic
key getters in operation, but I don't know of any. )

2. I suspect that the US cypherpunks use servers more than the people
that I communicate with regularly.  But not so as it has ever come up in
conversation that I can remember.

3. I suspect that server use has gone up dramatically because newer
mailers (Ian's Enigma and PGP Inc's pgp5.0 for example) will manage the
server interface for you.  That is, I wouldn't be surprised if the
reason that servers have many pgp5.0 keys is simply because pgp5.0 makes
it easy to put the keys up (and pgp5.x is sold without RSA, its an
extra).  Which means of course that one cannot conclude anything about
pgp2.6 user bases, but you might be able to conclude that pgp5.0 bases
is related to keys on servers.

4. Server use is sort of contradictory to the web of trust and key
signing ethos of PGP.  People meet to exchange keys and signatures.  The
culture of trust meant that you wouldn't use a key that you didn't
trust, and getting it from a keyserver without a sig was clearly
questionable in the strict diet of no-compromises security.

OTOH, professional pgpers exchange pieces of paper with fingerprints and
server references, and if you got a broad enough circle, you would find
that you could get a key off the server and find it signed by someone
you already knew.  That's only happened to me once though (and it wasn't
from a server), and hence, 2. above, I suspect it only really happens
with the cypherpunk crowd.  Which is to say, this is an idea for the
future, not indicative of the past.

I am beginning to wonder why there is such a divergence of opinion in
the importance and size of the pgp2.6 user base.  Are the business types
amongst us perhaps extrapolating the current sales data into an
understanding of the user community?

Focusing on the people you are selling your current product to, hell,
that's great, it sounds dumb not to focus on customers.  The problem is,
you are not ever likely to sell a copy to the majority of current
users.  That's because, like all freeware markets, most won't pay for
something they already have for free.  (Some will, which is what makes
it worthwhile to spread software via the freeware distibution method). 
We should also remember that there are a lot of users outside the US,
and I guess that doesn't really get analysed either due to the local
difficulties.

Unlike a sales-oriented organisation, the IETF process supports all
users, or at least the one I dial into every day does.  Those that don't
pay for product are just as valuable as the ones that do, and whilst we
sometimes pay lip-service to this notion, fobbing it off won't work on
the Internet.  The net was built by the non-paying kind of user - it
couldn't have been built by the paying kind, and those newbie companies
that want to make money on the net would do well to realise this early
on.

The base of users that exists today really is the pgp2.6 crowd, IMNSHO,
and the challenge facing those in the freeware area at least is how to
convert these people over to the new format.  If this user base wasn't a
significant number, then there would simply have been no reason to
bother having the old keys in pgp5.0.  If there was any possibility of
creating a majority market within 6 months of use, then it makes more
sense to drop the old algorithms and get on with the job.  Building a
pgp product with a single X/Y/Z suite of algorithms would have saved
some significant lump of the time, as well as cutting down the support
nightmare (and each bug report leading to a new sale :-)

Of course, this foolishness didn't happen, pgp5.0 went out there with
full compatibility (albeit via an optional paid extra).

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:

    * what proportion of the people you use
      pgp with have started using ElGamal
      (or DH) keys ?

    * what proportions of the above are in
      cypherpunks, and what proportion are
      not in cypherpunks ?

This is a simple 2 by 2 matrix - done this way to show and skew of
cypherpunks talking to each other and being counted twice.

Any other suggestions?  We could all look at our key rings and count the
mix.  My own numbers: 1 versus 27 (all used within the last month). 
This of course would be biased given the group but my own experience
reflects one biased key only :-)  Feel free to send me privately the
result and I will count them and report.

As an absolute lower limit:  count this ratio within PGP Inc, and we can
be sure there arn't less than that proportion.

This standards body must take that on board who the current user base
is, notwithstanding that the majority us want to sell software.  If we
are to make a case that this body of users is to be disenfranchised in
any way, it must be on very strong grounds, by unbiased analysis. 
Elsewise, this is not a standards organisation for users, but one for
some other interested parties.  Not in the IETF spirit of things at all.

- -- 
iang                                      systemics.com

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

Date: Fri, 31 Oct 1997 03:30:07 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Gene Hoffman <[email-masked]>
CC: [email-masked]
Subject: Re: What do we have to do today?
Sender: [email-masked]

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

Gene Hoffman wrote:
...
> ... there is most likely a
> majority of users with DSS/EG keys.

I'll address this separately.

> Ignoring that and moving to a couple of more important points, I believe
> that the charter had or has a goal of creating a standard to which
> implementors anywhere can implement without concern for intellectual
> property rights. DSA, SHA-1, ElGamal, 3DES, and CAST5 are all
> un-encumbered alogorithims. DSS/ElGamal with either 3DES or CAST should be
> the standard MUSTs. If you as an applications developer wish to support
> the "legacy" mode of PGP and can get the licenses to do so, please feel
> free to implement a SHOULD of RSA/MD5/IDEA as well as
> DSS/EG/(???3DES/CAST5????).

I accept the RSA patent as a strong consideration.  However, I find
myself taking the devil's advocate.

Outside the US (and perhaps Canada), nobody much cares about the RSA
thing.  In fact, nobody much wants to implement ElGamal because it is
slower, messier, not as well proven, and harder to implement.  RSA is a
nice algorithm, and we have happily communicated with US people up until
now - why do we need to change?

You might find this odd, but when I talk to European companies, they
actually prefer RSA.  Getting them onto something else will be a
problem, especially for the big ones.  Let's put it another way: in
Europe there is demand for RSA and no demand for ElGamal.

So which algorithm is a MUST might depend on which side of the Atlantic
the editor is sitting.

For half the market, RSA is good but ElGamal is bad.  For the other
half, ElGamal is cool but RSA is out.  This argues, in an
*international* standard, for two MUSTs, or two SHOULDs.  In an
*international* standard, is there a case for one over the other?

An RSA MUST might be out if IETF can't deliver unencumbered algorithms
to part of the market.  What remains is two SHOULDs.  (To repeat an
earlier post, could somebody summarise the IETF experiences or feelings
specifically regarding RSA?)

Two SHOULDs would work, although it appears clumsy on the surface. 
Let's work through it.

Half the market (US) goes with ElGamal, and the other half (non-US)
stays with RSA.  Remember, this is how it is now (being loose on the
definition of "half"):

   * In the short term, those in the US half of
     the connection will simply buy the plugin
     (say for the next year).

   * In the medium term, the unincentivised Europeans
     (and Australians and Japanese and ...) will get
     around to doing ElGamal.  Maybe faster if we can
     find some US customers to pay for it.

   * In the longer term (4 years time) the RSA patent
     expires and we can all go back to using RSA,
     which is what we wanted to do in the first place.

But to rush this process simply to get one international unencumbered
standard that not everyone wants will cause a rift that need not
happen.  The Eastern half simply don't need to do this.  (Odd that -
perhaps the Westerners should be paying for the development of
Euro-crypto :-)

It's not so simple.  Regardless of my arguments above, I do not find
that there is a clear and obvious case here either way, and would hope
that we can develop these arguments without biases getting in the way.

> Joe has got to get a license from Security Dynamics....
> More crypto will get deployed if ANYONE can build it and sell it. Also, it
> seems like "the interoperability problem"  decreases linearly with time.
> Once this proposal is done, I would hope that people like Ian will be
> making available OpenPGP compliant software and toolkits that implement
> both RSA/MD5/IDEA and DSS/EG/?3DES-CAST5?

To confirm, the Cryptix Development Team do have an ElGamal
implementation.  It is close enough to delivery that it will beat this
standard out (I hope) but it's not as if we have any customers asking
for it so there's no hurry.  Our US users aren't allowed to ask of
course ;-)

I don't know of any other pgp developers that have even started on the
ElGamal side, I have asked on pgp-dev.

> On the symmetric front, I'd like to suggest that all software MUST Decrypt
> CAST5 and 3DES, but only MUST encrypt 3DES. In this way, those application
> developers/ end users who wish to use CAST5 as their default can be
> assured that someone out there can read what they generate. If they find a
> key from an application that does not "prefer" CAST5, then they will know
> how to encrypt 3DES so as to conform to spec...

I know of no practical, technical or business scenario where it makes
sense to deploy decryption but not encryption (with symmetric ciphers). 
If you have the algorithm to decrypt, you can use it to encrypt.

USG/NIST did spend an awful lot of money deploying a system that could
sign and not encrypt (DSS), but that's politics.

- -- 
iang                                      systemics.com

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

Date: Thu, 30 Oct 1997 18:42:54 -0800
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: the security case against CMR (Re: rough consensus)
Sender: [email-masked]

On Thu, Oct 30, 1997 at 10:45:48PM +0000, Adam Back wrote:
> 
> Kent Crispin <[email-masked]> writes:
> > On Thu, Oct 30, 1997 at 04:11:20PM +0100, Ulf M=F6ller wrote:
> > > Several WG members and other recognized crypto experts consider any
> > > form of message recovery dangerous, others do not agree with the way
> > > it is implemented in PGP in particular.
> > 
> > However, these are primarily political considerations.  
> 
> There are certainly political considerations.
> 
> There are also very good security considerations.
> 
> I'm sure we went through all this before,

Oh, indeed.

> but there is a good security
> case arguing against use of CMR for either of it's argued purposes.

There is a minor security case, IMO.  Given that PGP2.6 uses long-term
communication keys the argument that 5.x should support forward
secrecy is specious.  Furthermore, forward secrecy in the existing
email infrastructure is a known difficult problem, is it not? And
despit your aggressive early innuendo to the contrary, I don't see a
solution from you.

Instead, what I see from you are waving hands spelling out KEY ESCROW
in big letters.  There is nothing very original in that. 

So, taking PGP to task for not providing forward secrecy is just hot
air.  Any scheme that doesn't provide forward secrecy is going to 
leave gobs of ciphertext exposed under the same key for some time, by 
definition.  This is just as true for Key Escrow schemes as it is for 
Multiple Encryption schemes.  Despite the FUD, the risks are very 
similar. (*)

As far as Corporate Data Recovery is concerned, you have blown a
stream of bubbly ideas -- yes, I have read http://..., no, I am not
impressed -- there isn't anything more than slightly elaborated KEY
ESCROW again. 

To summarize.  PGP didn't solve the forward secrecy problem; neither 
do you.  Key Escrow is a slightly better solution, IMO, but the 
tradeoffs are complex.

(*) Your analysis avoids the problem of key management.  In both
scenarios (Individual Key Escrow vs Dual Encryption (CMR)) the real
issue is the mechanism for protecting the keys.  In the IKE case you
have a repository for the escrowed keys -- the "keysafe" model I
discussed some time ago.  The "keysafe" is a database in a
cryptographic safe, and has a key of its own.  [The Keysafe key is a
weakness.] CMR actually requires a keysafe as well -- good practice
would dictate that an organization segment their data across several
recovery keys, and that they expire fairly quickly.  [When keys expire,
you have three choices -- reencrypt everything to a new key (stupid),
throw away the data (not likely), or keep a database of expired keys
(the only realistic solution).]

In both cases, you end up with a big pot of encrypted data encrypted
by different keys, and no single key can decrypt more than a certain
fraction of the total data.  With IKE the granularity is finer,
probably, but it is adjustable in either case. 

So, in sum, the advantage you claim for key escrow is real, but 
relatively minor.

Note that there may be other models for managing large numbers of keys
besides a "keysafe" -- someone could make a lot of money by designing
and coding a good one -- but I believe the problems are generic.

[...]
> 
> When we start talking about key lengths, you get fairly clear
> consensus -- much opposition is displayed to the notion of allowing
> politics to weaken security.  (Sure Kent, 40 bits, or 56 bits might
> arguably enough for some applications, if one uses your argument.)
[...]
> This doesn't sound in line with IPSEC stuff I
> followed where political weakening of security standards has
> specifically been rejected.

>From the IETF perspective, there is a vast difference between a
protocol issue, like keylength, and an operational issue, like key
management.  Operational issues are of a different character.  You
can't say "The user MUST change his key every week", for example. 
Realistically, you can't even say "Conforming implementations MUST
generate a new key automatically after 30 days."

> > And certainly, with care, CMR as implemented by PGP can be *very*
> > secure.
> 
> It is demonstrably less secure.

You say tomahto, I say tomayto.

> What is worse though is that long term communications keys are being
> encouraged by PGP Inc.  This is definately less secure.  Much less
> secure.

As noted, the long term communication keys are a problem of 
infrastructure, not PGP.

> In real applications this may make more difference to security than
> the difference between 56 bit DES and 128 bit IDEA -- the weakest link
> in a public key crypto system is likely to be the long term decryption
> keys.  Protecting them more carefully (by destroying them after
> expiry) arguably adds more extra real-life security than the extra 72
> bits of keyspace when combined with bad key management practice as it
> is now.
> 
> Having two long term keys exacerbates this problem.  Having a CMR key
> which is used to recover many employees messages is even worse.

This is all true.  However, "worse" is a relative term.  

> > > So, if the IESG gives its WG chairs the power to decide whatever they
> > > consider appropriate, fine, but please save ourselves the Newspeak of
> > > calling that "rough consensus".
> > 
> > Perhaps, then, you would rather have no standard at all, than a
> > standard that refers to PGP's CMR implementation?
> 
> Most who have voiced their opinion on the topic have expressed
> negative opinions of CMR.  Perhaps this says something about the
> technical and political demerits of CMR?

Perhaps it rather says something about who is vocal and who isn't.

>  Perhaps what is said should
> be reflected in the standard?

To some extent, yes.  My opinion is that a PGP "packet" standard would
be a big win, and that the CMR debate is really just breaking waves in
shallow water. 

-- 
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: Thu, 30 Oct 1997 18:03:15 -0800
To: [email-masked]
From: "John  W. Noerenberg" <[email-masked]>
Subject: OpenPGP WG meeting at 40th IETF in Washington DC
Sender: [email-masked]

For those who want to consider this in their travel plans, our WG meeting
is scheduled for:

        Monday, December 8 at 1300-1500
                (opposite uswg, svrloc, radius, http, idmr)

I'll be working up an agenda over the next couple of days.  I'll be drawing
the agenda from the discussions on the mailing list.  However, if there are
other topics you think should be included, now would be a good time to send
them to me.

Thanks!

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: Thu, 30 Oct 1997 18:00:42 -0800
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: expectation of privacy (Re: Symmetric Algorithm)
Cc: [email-masked]
Sender: [email-masked]

At 12:40 AM 10/31/97 GMT, Adam Back wrote:
      
   ROT13 demonstrates almost no expectation of privacy :-)
   
   Personally I would find 128+ bit symmetric ciphers to be much better
   for _enforcing_ expectation of privacy.
   
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.

	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, 31 Oct 1997 00:40:28 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: expectation of privacy (Re: Symmetric Algorithm)
Sender: [email-masked]

Padgett Peterson <[email-masked]> writes:
> >Paul Hoffman said more forcefully what I meant about IDEA being a MUST
> >algorithm. It's also my understanding that if any encumbered algorithm is a
> >MUST, the spec will be spiked.
> 
> Same-same: proprietary mechanisms always seem to fail. So let's just
> say "only algorithms in the public domain *everywhere* may be
> 'musts'".

Sounds reasonable.

> Agree with "no weak crypto" per se but a standard might want to be as broad
> as possible. Am thinking of the possibility that the purpose of an algorithm
> might be to enforce the *expectation of privacy* without being strong
> crypto. In that case ROT13 or XOR55 might suffice.

ROT13 demonstrates almost no expectation of privacy :-)

Personally I would find 128+ bit symmetric ciphers to be much better
for _enforcing_ expectation of privacy.

What's wrong with real crypto?  I'd guess even CAST128 can't compete
with XOR55 for megabytes per second, but it sure beats it for adding a
bit of extra privacy.  If you're thinking of export regs, I think this
is not a good reason.  Performance I don't think is the issue either?

> Am also thinking of the concept of an exportable product with plug-in 
> capability. Would like to see the ability to plug-in new crypto modules 
> in any case. Know this is more product oriented but would like to see
> a standard support this.

Historically this has not always helped exports, re "crypto with a
hole" and a few cases where this kind of idiocy was enforced, or where
developers were leaned up on to remove the hole.

No idea how this one has translated into the EARs.

Plug-in crypto modules is a nice feature though.

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, 30 Oct 1997 18:41:40 -0600
To: Adam Back <[email-masked]>
From: Rick Smith <[email-masked]>
Subject: Re: do security recommendations belong in standard?
Cc: [email-masked]
Sender: [email-masked]

I think it's an excellent idea to include a list of recommendations in the
RFC. I made similar lists of requirements for various technical features
and products in my book "Internet Cryptography." Those lists aren't
appropriate in their current form since they were meant to guide software
buyers rather than developers, but they might provide a useful point of
comparison. If someone has a draft list of recommendations for the RFC, I'd
be happy to review it and make suggestions based on the lists I published.

Regarding Adam Back's comment:

>So long as the importance of adherence to security recommendations is
>clear; ignoring them entirely could lead to some bizarrely insecure
>implementations which could legitimately claim to be OpenPGP
>compliant.

I doubt we can produce any lists that will prevent someone from
implementing "bizarrely insecure" implementations. There is always a "low
end" in the marketplace, even for security products. Someone will use
rand() to generate secret keys and seed it with the clock. Take it as a
given. People will probably even pay money for it. Even if we could prevent
such foolishness, it would require a very large crystal ball to forsee all
the different ways people will use a product, especially something this
new. If crypto becomes a tool of common folk, then people will develop
various habits and traditions that will affect the operating security more
than even the choice of bit length. Nobody, not even the NSA, can predict
how such systems will hold up under use by a giant population of untrained,
casual users.

I can't wait to see what happens.

Rick.
[email-masked]               Secure Computing Corporation
"Internet Cryptography" in bookstores or http://www.visi.com/crypto/

Date: Thu, 30 Oct 1997 14:40:37 -0800
To: [email-masked], [email-masked]
From: Jonathan Wienke <[email-masked]>
Subject: Re: Looking for test LDAP PGP keyserver
Sender: [email-masked]

--==-=--=---=-==--=--==-==-=--===-=--===-=--=-=-==
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 07:14 PM 10/30/97, Peter Gutmann wrote:

>Are there any LDAP PGP keyservers which can be used for testing (ie to grab 
>PGP keys and upload sample keys)?  For that matter, are there any LDAP PGP 
>keyservers online at all?  I'd like to be able to test some keyserver access 
>code against a real server rather than just a copy of slapd running on a
local 
>machine.

Try ldap://certserver.pgp.com.  It worked the last time I tried it.

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

--==-=--=---=-==--=--==-==-=--===-=--===-=--=-=-==--

From: Uri Blumenthal <[email-masked]>
Subject: Re: What do we have to do today?
To: [email-masked]
Date: Thu, 30 Oct 1997 18:35:36 -0500 (EST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Gene Hoffman says:
> ......I grant that I am making an
> assumption, but it would seem that the majority of keys in use would be
> on the public keyring. Of these its clear that there is most likely a
> majority of users with DSS/EG keys.

I'd agree with this.

> Ignoring that and moving to a couple of more important points, I believe
> that the charter had or has a goal of creating a standard to which
> implementors anywhere can implement without concern for intellectual
> property rights. DSA, SHA-1, ElGamal, 3DES, and CAST5 are all
> un-encumbered alogorithims. DSS/ElGamal with either 3DES or CAST should be
> the standard MUSTs. If you as an applications developer wish to support
> the "legacy" mode of PGP and can get the licenses to do so, please feel
> free to implement a SHOULD of RSA/MD5/IDEA as well as
> DSS/EG/(???3DES/CAST5????).

Plus - how difficult does one estimate moving from one algorithm
suite to another? In my NSH out-of-hand opinion, the biggest
obstacle is accumulating an equally large amount of equally
respectable signatures on my new public key.

I am sure I will have zero problem convincing my correspondents to
use the algorithms I prefer (especially since my preference has
considerable cryptographic backing :-).

> On the symmetric front, I'd like to suggest that all software MUST Decrypt
> CAST5 and 3DES, but only MUST encrypt 3DES. 

An excellent idea in my view.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Thu, 30 Oct 1997 23:02:41 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: do security recommendations belong in standard?
Sender: [email-masked]

Rick Smith <[email-masked]> writes:
> RFCs traditionally have that special section at the end called "Security."
> Instead of the traditional phrase "This whole RFC is about security"

Well isn't it? :-)

> perhaps that is the right place to put security recommendations. This would
> be more in line with other RFCs, wouldn't it?
> 
> Also, this would reflect a (previously misplaced and sorely missed)
> recognition of the difference between security and security mechanisms.

So long as the importance of adherence to security recommendations is
clear; ignoring them entirely could lead to some bizarrely insecure
implementations which could legitimately claim to be OpenPGP
compliant.

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, 30 Oct 1997 17:53:56 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: Re: Symmetric Algorithm
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

>Paul Hoffman said more forcefully what I meant about IDEA being a MUST
>algorithm. It's also my understanding that if any encumbered algorithm is a
>MUST, the spec will be spiked.

Same-same: proprietary mechanisms always seem to fail. So let's just say "only
algorithms in the public domain *everywhere* may be 'musts'".

>My comment was supposed to be dry humor,
>akin to saying that if you light a match in a powder room, you may
>experience superficial burns.

More likely to get slapped.

>I'd also like to note that the principle of "no weak crypto" is in the
>charter, so I'm not including any weak algorithms, period.

Agree with "no weak crypto" per se but a standard might want to be as broad
as possible. Am thinking of the possibility that the purpose of an algorithm
might be to enforce the *expectation of privacy* without being strong
crypto. In that case ROT13 or XOR55 might suffice. Possibly is something that
would only concern US lawyers and we already have UUENCODE and BASE64 to
do the same thing but is something I have been thinking about for a while.

Am also thinking of the concept of an exportable product with plug-in 
capability. Would like to see the ability to plug-in new crypto modules 
in any case. Know this is more product oriented but would like to see
a standard support this.

						Warmly,
							Padgett

Date: Thu, 30 Oct 1997 22:45:48 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: the security case against CMR (Re: rough consensus)
Sender: [email-masked]

Kent Crispin <[email-masked]> writes:
> On Thu, Oct 30, 1997 at 04:11:20PM +0100, Ulf M=F6ller wrote:
> > Several WG members and other recognized crypto experts consider any
> > form of message recovery dangerous, others do not agree with the way
> > it is implemented in PGP in particular.
> 
> However, these are primarily political considerations.  

There are certainly political considerations.

There are also very good security considerations.

I'm sure we went through all this before, but there is a good security
case arguing against use of CMR for either of it's argued purposes.
(Disaster recovery of stored messages, and corporate snooping of
messages in transit, or company reading of queued waiting for
decryption in employee's absence).

We can go over these again in detail if it would be useful for the
standardisation process.

When we start talking about key lengths, you get fairly clear
consensus -- much opposition is displayed to the notion of allowing
politics to weaken security.  (Sure Kent, 40 bits, or 56 bits might
arguably enough for some applications, if one uses your argument.)

Let's make this quite clear.

There are more secure ways to achieve the following:

- recovery of encrypted archived emails
- ability for companies to decrypt email in transit

I am quite happy to go over these again.

> Certainly, there are security implications as far as message
> recovery is concerned, but security considerations are
> application-specific -- that is, most commercial applications don't
> require anything approaching military-grade secrecy.  

This is true.  Should we add single DES (56 bit key space) because of
this?  I didn't notice anybody argue for this (except for WengFatt
Fong <[email-masked]> -- if that wasn't a troll).  Should we have
DES because it is possible to export it if you are in the US and your
company agrees to plan for GAK on a 2 year time-schedule?  Should we
then add in the facilities for that GAK?  (Eeek, no need we've already
got that: CMR).  This doesn't sound in line with IPSEC stuff I
followed where political weakening of security standards has
specifically been rejected.

> And certainly, with care, CMR as implemented by PGP can be *very*
> secure.

It is demonstrably less secure.

What is worse though is that long term communications keys are being
encouraged by PGP Inc.  This is definately less secure.  Much less
secure.

In real applications this may make more difference to security than
the difference between 56 bit DES and 128 bit IDEA -- the weakest link
in a public key crypto system is likely to be the long term decryption
keys.  Protecting them more carefully (by destroying them after
expiry) arguably adds more extra real-life security than the extra 72
bits of keyspace when combined with bad key management practice as it
is now.

Having two long term keys exacerbates this problem.  Having a CMR key
which is used to recover many employees messages is even worse.

> > So, if the IESG gives its WG chairs the power to decide whatever they
> > consider appropriate, fine, but please save ourselves the Newspeak of
> > calling that "rough consensus".
> 
> Perhaps, then, you would rather have no standard at all, than a
> standard that refers to PGP's CMR implementation?

Most who have voiced their opinion on the topic have expressed
negative opinions of CMR.  Perhaps this says something about the
technical and political demerits of CMR?  Perhaps what is said should
be reflected in the standard?

> To put it a bit more baldly, the question is are you willing to
> disrupt the process if you don't get things your way?

I don't see it as disruptive to make a security case against a
proposed feature.  I see that as very constructive, similarly to the
constructiveness of discussions rejecting 56 bit key lengths which
might otherwise be argued for on political grounds.

> And, given that some people will answer that in the affirmative, how
> would you expect the WG chair to handle it?

I have some hope left that a sensible outcome can be acheived.  

One outcome could be this.  The CMR approach is defined for backwards
compatibility with the brand new pgp5.5 (how many copies of pgp5.5 for
business sold?  Is it shipping in non-beta yet?)  (I argue against
this outcome, btw).

A privacy respecting definition of CMR functionality could be defined.

ie. Arrange that the sender has two choices when sending to a CMR key,
reflecting two types of messages, "official company business"
messages, and "personal" messages.

1. official company business, fill in the correct key in the second recipient
2. personal messages, fill in garbage in the second recipient

Language in the security recommendations stating that new CMR usage is
discouraged (SHOULD NOT) and only supported for backwards
compatibility reasons.  More secure alternatives given.

Personally I would hope that CMR could be simply removed altogether
however, and that pgp5.5 is modified to be inline with the standard on
this point.

PGP Inc could have coped with migrating to new methods outside of the
standard without introducing compatibility problems if they had used
an extension mechanism.  For example if systems capable of responding
to ARR requests had been defined to use a version number, or extension
flag in a message header.

As they didn't depending on how important pgp5.5 for business
compatibility is we may have to live with something like the above.

I would encourage a formalised extension mechanism to avoid further
such problems.

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, 30 Oct 1997 14:05:05 -0800 (PST)
From: Gene Hoffman <[email-masked]>
Reply-To: Gene Hoffman <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: What do we have to do today?
Sender: [email-masked]

On 30 Oct 1997 [email-masked] wrote:

> To which Gene Hoffman kindly provided some numbers:
> 
> > Some quick rough numbers. On the MIT keyservers there are now about 95,000
> > new public keys since 5/20. Of them 85% are DSS/DH(El Gamal) keys. Before
> > that I believe that there were ~20K RSA keys...
> 
> Now, the number bandied about in documents I have seen indicates that 4
> million users of 2.6 and similar exist.  In 6 months of time, PGP Inc
> appear to have sold 80k worth of keys.  These are good numbers, I
> congratulate them, but at 2% of the user base, they have a long way to
> go. 
> 

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 grant that I am making an
assumption, but it would seem that the majority of keys in use would be
on the public keyring. Of these its clear that there is most likely a
majority of users with DSS/EG keys.

Ignoring that and moving to a couple of more important points, I believe
that the charter had or has a goal of creating a standard to which
implementors anywhere can implement without concern for intellectual
property rights. DSA, SHA-1, ElGamal, 3DES, and CAST5 are all
un-encumbered alogorithims. DSS/ElGamal with either 3DES or CAST should be
the standard MUSTs. If you as an applications developer wish to support
the "legacy" mode of PGP and can get the licenses to do so, please feel
free to implement a SHOULD of RSA/MD5/IDEA as well as
DSS/EG/(???3DES/CAST5????).

In this way Joe Schmoe in New Mexico and Fred Doe in Thailand can create a
conforming and useful application with "Applied Cryptography" and a C
compiler. Requiring RSA or IDEA means that both of them at least have to
go to Ascom Tech. Joe has got to get a license from Security Dynamics....
More crypto will get deployed if ANYONE can build it and sell it. Also, it
seems like "the interoperability problem"  decreases linearly with time.
Once this proposal is done, I would hope that people like Ian will be
making available OpenPGP compliant software and toolkits that implement
both RSA/MD5/IDEA and DSS/EG/?3DES-CAST5? I certainly hope that no one is
expecting people to use DOS (well, other than [email-masked]) for the
next 10 years...

On the symmetric front, I'd like to suggest that all software MUST Decrypt
CAST5 and 3DES, but only MUST encrypt 3DES. In this way, those application
developers/ end users who wish to use CAST5 as their default can be
assured that someone out there can read what they generate. If they find a
key from an application that does not "prefer" CAST5, then they will know
how to encrypt 3DES so as to conform to spec... 

Gene Hoffman
PGP, Inc.

Date: Thu, 30 Oct 1997 19:21:03 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: CMR/ARR and OpenPGP (Re: What this WG is doing)
Sender: [email-masked]

I wrote:
> Bill Stewart <[email-masked]> writes:
> > Unfortunately, it does look like the new format uses 64-bit KeyIDs
> > for these fields, and a 0xdeaddeaddeadbeef attack is a few billion
> > times harder than a 0xdeadbeef attack, which could otherwise fool it :-)
> 
> I think it's much harder to fool than you're thinking -- 
                    ^^^^^^

Above sentence is in error, I meant much _easier_ to fool; probably
obvious from the following text anyway...

> it doesn't
> decrypt the data, and so it can't attempt in anyway to verify the
> contents of the PKE.  (It could somewhat with binding cryptography,
> but I understand this is not currently used).
> 
> So I think if you get an ARR request for 64 bit key (or 128 bit key,
> or whatever) 0x12345781234578 well you just create the second
> recipient PKE field like so:
> 
> [ARR key-id][length-header][garbage]
> 
> and it will go flying through, right?  No 0xdeadbeef or longer cousin
> attacks required.
> 
> (Suggestions for human readable ASCII to put in the garbage field
> accepted on a postcard:-)

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`

Subject: Re: rough consensus
To: [email-masked] (Kent Crispin)
Date: Thu, 30 Oct 1997 22:36:09 +0100 (NFT)
Cc: [email-masked]
From: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?=)
Sender: [email-masked]

> Perhaps, then, you would rather have no standard at all, than a
> standard that refers to PGP's CMR implementation?  

Or, perhaps, a standard that describes the "rough consensus"? Of
course, that would not keep PGP from documenting their CMR in an
informational RFC.

> To put it a bit more baldly, the question is are you willing to
> disrupt the process if you don't get things your way?

Is PGP if they don't get things their way?

From: [email-masked]
Date: 30 Oct 1997 21:14:16 -0000
To: [email-masked]
Subject: Re: What do we have to do today?
Sender: [email-masked]

Uri Blumenthal wrote:
> 
> I raise the question of whether it is wise to allow backward compatibility
> to force us to implement algorithms we wouldn't otherwise.

To which I posited some time in the past:

> We only theoretically have the option to not require it.  The number of
> people using anything other than 2.6 or thereabouts is minute compared
> to the installed base of "classic" PGP.  Any clues on how many copies of
> 5.* have been sold?

To which Gene Hoffman kindly provided some numbers:

> Some quick rough numbers. On the MIT keyservers there are now about 95,000
> new public keys since 5/20. Of them 85% are DSS/DH(El Gamal) keys. Before
> that I beleive that there were ~20K RSA keys...

Now, the number bandied about in documents I have seen indicates that 4
million users of 2.6 and similar exist.  In 6 months of time, PGP Inc
appear to have sold 80k worth of keys.  These are good numbers, I
congratulate them, but at 2% of the user base, they have a long way to
go. 

I know that this group is concentrating on new users, because they are
the only ones who pay for software.  However, I am not sure what
rational there is for a standard that does not take the installed base
as its target audience.  After all, what is standardisation if it is not
taking existing work and hard-won lessons from existing product?

> Lutz Donnerhacke says:........................
...
> >       MD5 is must, because it is the default and backward compatible.
> >       IDEA is must, because it is the default and backward compatible.
> 
> It *was* the default. Do we have to keep the outdated defaults?

I do not see any basis for declaring that default is "outdated" although
my own misgivings on  the whole RSA/IDEA/MD5 thing - see my previous
post - are slowly clarifying, and it took writing this post to get
there.  Ta muchly :-)

-- 
iang                                      systemics.com

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

Date: Thu, 30 Oct 1997 20:54:24 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
Subject: CART before the HORSE
Sender: [email-masked]

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

I must admit that I am troubled by making RSA/IDEA/MD5 a MUST when 2/3s
of those algorithms present patent and license issues.

In fact, it occurs to me that we have the issues back to front.  Perhaps
we should decide what the MUST/SHOULD/MAYs are for the public key
algorithms first.  If we decide something about RSA, be it one or other
of the choices, then as a tougher nut to crack, wouldn't it then have a
fairly serious bearing on IDEA?

For example, there is no point in IDEA being a MUST if RSA is a SHOULD. 
And if RSA is a MUST, I would have thought that whatever the state of
IDEA, it would not indeed be the biggest of issues facing us.

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?
- -- 
iang                                      systemics.com

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

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 30 Oct 97 14:03:09 -0600
To: Uri Blumenthal <[email-masked]>
Cc: [email-masked] (Lutz Donnerhacke), [email-masked]
Subject: Re: What do we have to do today?
Sender: [email-masked]

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

Well if you don't provide backward compatibility whom do you plan on
communicating with?? I think throwing away the current user base and
starting from scratch is a foolhardy thing to do.

In <[email-masked]>, on 10/30/97 
   at 02:47 PM, Uri Blumenthal <[email-masked]> said:

>I raise the question of whether it is wise to allow backward
>compatibility to force us to implement algorithms we wouldn't otherwise.

>Lutz Donnerhacke says:........................
>>       EDE-DES(SHOULD), IDEA(MUST), Cast5(MAY), ....
>>       MD5(MUST), SHA1(SHOULD), MD2(MAY), ...
>> 	MD5 is must, because it is the default and backward compatible.
>> 	IDEA is must, because it is the default and backward compatible.

>It *was* the default. Do we have to keep the outdated defaults? -- 
>Regards,
>Uri		[email-masked]
>-=-=-=-=-=-=-
><Disclaimer>

- -- 
- ---------------------------------------------------------------
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: Uri Blumenthal <[email-masked]>
Subject: Re: What do we have to do today?
To: [email-masked] (Lutz Donnerhacke)
Date: Thu, 30 Oct 1997 14:47:43 -0500 (EST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

I raise the question of whether it is wise to allow backward compatibility
to force us to implement algorithms we wouldn't otherwise.

Lutz Donnerhacke says:........................
>       EDE-DES(SHOULD), IDEA(MUST), Cast5(MAY), ....
>       MD5(MUST), SHA1(SHOULD), MD2(MAY), ...
> 	MD5 is must, because it is the default and backward compatible.
> 	IDEA is must, because it is the default and backward compatible.

It *was* the default. Do we have to keep the outdated defaults?
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Thu, 30 Oct 1997 13:12:59 -0600
To: Adam Back <[email-masked]>, [email-masked]
From: Rick Smith <[email-masked]>
Subject: Re: do security recommendations belong in standard?
Cc: [email-masked]
Sender: [email-masked]

RFCs traditionally have that special section at the end called "Security."
Instead of the traditional phrase "This whole RFC is about security"
perhaps that is the right place to put security recommendations. This would
be more in line with other RFCs, wouldn't it?

Also, this would reflect a (previously misplaced and sorely missed)
recognition of the difference between security and security mechanisms.

Rick.
[email-masked]

Date: Thu, 30 Oct 1997 17:54:36 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: CMR/ARR and OpenPGP (Re: What this WG is doing)
Sender: [email-masked]

Bill Stewart <[email-masked]> writes:
> At 11:50 AM 10/29/1997 GMT, Adam Back wrote:
> >This approach to extensions leads to compatibility problems -- you
> >send to [email-masked] and it will bounce your mail if it is set up
> >strictly.
> 
> The PGP Inc. SMTP filter offers a medium-wide range of options;
> it can be set to reject unencrypted mail, or reject encrypted mail,
> or reject unsigned mail (of course it can't decrypt, so it can only
> tell whether unencrypted mail is also unsigned), etc.
> If the administrator doesn't write adequately explanatory bouncegrams,
> unlucky senders are going to get hosed anyway.

Yes.

> In particular, one of the postings I read on this list said that if
> the sender's PGP public key ring doesn't already have the CMRK key,
> it will ignore the CMRK KeyID request, so you'll get hit with this anyway.

I'm not sure but I think this may be limited to pgp5.0.

> >To guarantee compatibility, your choices as implementor are:
> >- send garbage in second recipient field
> >- send valid second recipient
> Unfortunately, it does look like the new format uses 64-bit KeyIDs
> for these fields, and a 0xdeaddeaddeadbeef attack is a few billion
> times harder than a 0xdeadbeef attack, which could otherwise fool it :-)

I think it's much harder to fool than you're thinking -- it doesn't
decrypt the data, and so it can't attempt in anyway to verify the
contents of the PKE.  (It could somewhat with binding cryptography,
but I understand this is not currently used).

So I think if you get an ARR request for 64 bit key (or 128 bit key,
or whatever) 0x12345781234578 well you just create the second
recipient PKE field like so:

[ARR key-id][length-header][garbage]

and it will go flying through, right?  No 0xdeadbeef or longer cousin
attacks required.

(Suggestions for human readable ASCII to put in the garbage field
accepted on a postcard:-)

> >- ignore additional recipient request (it does say "request"), and
> >  have confused users who can't interoperate even though both using
> >  OpenPGP compliant appliactions.
> >doesn't seem very good from an interoperability point of view, unless the
> >standard says that pgp5.5 should not bounce mail.
> 
> PGP5.5 doesn't handle mail, so it can't bounce it.  SMTP filters do,
> and they're outside the scope of OpenPGP.  Mail User Agents may
> call PGP, but by then it's delivered, though I suppose the MUA could
> bounce it if PGP returns an appropriate failure code, like "Can't decrypt".
> (Returning predictable and useful failure/success indicators _is_
> part of OpenPGP's scope.)

The CMRK enforcement could be moved in to the MUA -- not as usefully
though, because then the recipient must manually send the bounce
message.

> >The correct way to implement extensions I think is to detect extension
> >capability based on public key, and only use it where it is available.
> >(Such as SMTP extensions, browser capability negotiation, SSL
> >algorithm negotiation, etc).  Same as symmetric cipher capability
> >flags in public keys (which are already defined -- I think?)
> 
> Do you mean look up the extension information in some keyserver?
> Or do you mean what it sounds like you mean, which is determine
> whether to use a given extension based on flags in the public keys records?
> If the latter, that's _precisely_ what the CMR feature _does_...

Almost, but not quite.  The enforcer, I attempted to argue, could
determine from the public key of the sender, or from the version
number of the message whether the sender was able to comply with the
ARR request.  If the sender was unable to comply, there is no point
bouncing messages because the sender has _no way to_ comply (short of
downgrading his software to some CMR enabled software).

What you are talking about is the CMR flag in the recipients key.  It
is the sender who's mail will be bounced if his software silently
ignores the ARR request.

> >This approach to extensions would dictate that pgp5.5 policy enforcer
> >SMTP agent would only ever bounce mail where the keys indicated they
> >were generated by software which advertises being capable of
> >understanding ARRs.
> 
> The PGP5.5 message format doesn't differentiate between recipients
> who were included because the sender wanted them or because of ARRs,
> and the PGP Inc. implementation of the SMTP incoming enforcer can't tell.

Yes.  The multiple recipients all look the same regardless of whether
they got there because they are on the Cc: line, or because the
recipients key was created by PGP 5.5 for business.

> On the other hand, the only people who would install such a silly thing (:-)
> are companies whose users have been told to use PGP Business Version>=5.5,
> and if you _want_ to enhance the filter to check each KeyID, it'll find
> their CMRK recipient KeyIDs and be happy.

That's what I was suggesting above, yes.  Probably easier to define a
flag in the message, or a version number, or extension mechanism which
allows the policy enforcer to notice that the sender has no way to
comply with ARRs because his software has no idea what to do with
them.

> I guess there's still the outgoing email policy enforcer, which 
> _could_ hang on to each outgoing encrypted message while it tries to find
> the KeyID on some keyserver that may not even be accessible to it
> to make sure the recipient doesn't mind that the sender's company
> kept a copy of the outgoing mail, but it sounds impractical to implement.

Different problem.  The recipient can tell this after he's received
the mail if there are statement of intent of sender plaintext handling
flags attached to the senders key, or to the message.

Note I didn't say leave the CMR field in -- that's a security flaw,
CMR is dumb to start with, but it's even dumber to leave the CMR field
in after passing through an enforcer, it should strip it out for
security reasons.

> I'm mostly surprised, because you seem to have agreed with 2/3 - 4/5 of
> what PGP5.5 CMR does, and I thought you were more vehemently against it
> than I am....

I am against it.  It is a security design flaw, and it is basically
clipper implemented in software, with all the inherent risks of
government abuse.

However, if certain people on this list proceed to ignore these risks,
and can't be talked out of including the LEAF-like field at least we want
to ensure that software can interoperate in ways which ensure that
people who don't want to send to corporate keys can just fill in that
field with a nice big `FUCK YOU' in reply to the ARR request.  I argue
for defining this in the standard as the correct behaviour.  That
takes a lot of the sting out of CMR dangers -- if all the software
provides you with an option to bypass it for personal messages.

Note pgp5.0 and pgp5.5 for business and for personal use do not
currently do this (against strict settign SMTP enforcers).  It would
be far friendlier to provide a "personal mail" or "official company
business mail" button which filled garbage into the requested
additional recipient field.  It would also make the bouncing enforcers
kind of pointless...

Also interesting would be to include recommendations in the standard
for good security practice:

- use separate storage and encryption keys
- have short lived communication-only keys
- use forward secret transport level security where available
- use opportunistic forward secrecy (and show how to use existing
  packets to support this)

PGP Inc do not currently seem to be interested in providing increased
security, nor in following good security principles, nor in adding
increased resistance to unauthorised third party snoopers (be they
industrial espionage, or rogue governments, or rogue government
agents.)

I think that the standard should do what it can to encourage good
security practice.  I hope someone won't tell me this is outside the
charter!  (Surely it's pointless defining a security standard which
encourages sloppy security practice.)

> >It might be worth documenting, or making suggestions in the standard
> >on a method to implement extensions, so that we don't get more
> >problems like this.
> 
> Yep.  I'm especially annoyed at this one, since we _had_ the source
> and basically nobody noticed these features were there until PGP 
> announced what PGP 5.5 did with them, and I'm not sure if anybody
> even noticed the more blatant ViaCrypt GAK features until then.
> (But I did send you my copy of the source using cheap slow-mail :-)

Sorry -- that's the problem with 1 foot of source code -- people run
out of energy reading it :-)

> >Then people who don't want ARR for security and political reasons can
> >interoperate.
> 
> OpenPGP definitely shouldn't encrypt to ARRKs without some indication from
> the sender that it's OK, whether it's a command-line flag or checkbox
> or failing to drag the red blinking icon out of the dialog box
> or config file / preferences setting or something.  

That's not generally possible for reasons you gave below (batch
processing, etc.).

Simpler, either:

- allow the sender to interogate the recipient key to find out ahead
  of time and give instructions with the encryption request

- define a choice as an extra flag to the encryption process -- is
  this a personal message (say `FUCK YOU' to ARR requests) or a
  corporate message (put up with security risk to help company deal
  with your request promptly even though company is using software
  with poorly designed message snooping software)

So for personal messages, if there is an ARR request, define the
action to be to fill the field with garbage (you could actually say
"ADDITIONAL RECIPIENT REQUEST DENIED" in the PKE place-holder, or less
polite variants :-)

For official company messages define the action to be to fill the
field with the encrypted message key.

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, 30 Oct 1997 18:10:50 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: do security recommendations belong in standard? (Re: CAN'T Re: MUST versus SHOULD in application decisions)
Sender: [email-masked]

Bill Stewart <[email-masked]> writes:
> > Storage Keys vs. Communication Keys; SHOULD/SHOULD NOT/MUST/MUST NOT
> > CMR vs. CDR vs. GACK vs. CMRK.
> 
> I don't think we'll be able to find a satisfactory answer to this,
> or at least not that's useful for a standard like OpenPGP.
> The problem is that PGP doesn't _do_ Storage or Communication;
> it takes a batch of input data, does crypto, and produces output data.

It is simpler to proceed on the basis that the standard says nothing
about storage or communication -- however I'm not sure this safe.
Also I'm not sure this is valid.

I think much more useful security, and proper use recommendations can
be made if the standard, or at least security recommendations in the
standard or related document acknowledges the difference between
storage and communication -- there is a huge difference in security
implications and proper usage.

For starters there is not really much point using public key
encryption for storage for your own use.

Communications keys are much more sensitive than storage keys (with
communications your attacker has easy access to the ciphertext this
means if you use long term keys for communications, the passive
attacker can snoop a years worth of traffic, and then bribe, or coerce
a key from one of your employees).  For storage on the other hand,
access to the data is needed, as well as obtaining the key.

> Since PGP doesn't know what other programs do with its output data,
> it can't implement DO/DONT/SHOULD/MUST; they're out of its scope.

No, I disagree.  At the very least how keys are treated, the security
risks of using the same comms keys for extended periods are inside
it's scope surely?

This has implications for output data handling which you declare above
is outside scope.  If the output data is transferred over an insecure
medium (effectively broadcast over the Internet), this is what creates
the need for short lived keys.

For storage on the other hand, you have less risk, and there is less
value to frequently updating keys.

> PGPdisk does storage.  SMTP does communication, and could add crypto.
> The old PGP2.6.2 did most of its crypto on files, but still generated
> output files from input files rather than directly doing storage,
> and it didn't do any communication at all.

What pgp2.6.x does is also highly dangerous -- no key expiry
mechanism, common practice of having long term keys, no forward
secrecy over the link.

pgp5.x message formats allow for better than this -- there are expiry
fields on keys, and encryption keys can have different expiry fields
than signature key expiry fields.  pgp5.0 (at least linux version) can
also encrypt with symmetric storage keys.

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`

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: What this WG is doing
Date: 30 Oct 1997 17:43:00 GMT
Organization: IKS GmbH Jena
Lines: 7
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Bill Stewart wrote:
>I'd say 3, 5, and 9 are permissible actions, but shouldn't be in the spec
>except perhaps under "Security Conditions" or some similar appendix.  
>2 and 8 are at least SHOULD, and 6 and 10 probably SHOULD NOT BUT MAY.

;-) Completely political discussion. I'd move it to security considerations
but who is the current editor? I don't know.

Date: Thu, 30 Oct 1997 09:33:20 -0800
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: rough consensus
Sender: [email-masked]

On Thu, Oct 30, 1997 at 04:11:20PM +0100, Ulf Möller wrote:
> Several WG members and other recognized crypto experts consider any
> form of message recovery dangerous, others do not agree with the way
> it is implemented in PGP in particular.

However, these are primarily political considerations.  Certainly, 
there are security implications as far as message recovery is 
concerned, but security considerations are application-specific -- 
that is, most commercial applications don't require anything 
approaching military-grade secrecy.  And certainly, with care, CMR as 
implemented by PGP can be *very* secure.

> So, if the IESG gives its WG chairs the power to decide whatever they
> consider appropriate, fine, but please save ourselves the Newspeak of
> calling that "rough consensus".

Perhaps, then, you would rather have no standard at all, than a
standard that refers to PGP's CMR implementation?  

To put it a bit more baldly, the question is are you willing to
disrupt the process if you don't get things your way?  And, given 
that some people will answer that in the affirmative, how would you 
expect the WG chair to handle it?

-- 
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: Thu, 30 Oct 1997 03:42:50 -0800
To: [email-masked] (Lutz Donnerhacke), [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: What this WG is doing
Sender: [email-masked]

At 01:03 PM 10/29/1997 GMT, Lutz Donnerhacke wrote:
>* Ian Grigg wrote:
>>In the current understanding of the community, the only plausible
>>alternative is to simply omit all mention of the CMRK subpacket from the
>>standard.
>
>No. It is possible to document is and point out the security consequences in
>chapter 'Security Considerations'.
>It is only undefined, who edit the draft to move forward.

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

A program generating a public key record can do several things
8) Don't generate a CMRK field
9) Generate a CMRK field if asked to, either for eavesdropping
	or as a mechanism for implementing group keys.
10) Use the CMRK field for something else functional
11) Use the CMRK field to store bogus records to trap PGP Business 5.5 users :-)

I'd recommend strongly against 0, 4, and 7, just in general, and 
weakly against 1 and 11.  
I'd say 3, 5, and 9 are permissible actions, but shouldn't be in the spec
except perhaps under "Security Conditions" or some similar appendix.  
2 and 8 are at least SHOULD, and 6 and 10 probably SHOULD NOT BUT MAY.
				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: Symmetric Algorithm
Date: 30 Oct 1997 17:01:37 GMT
Organization: IKS GmbH Jena
Lines: 10
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* David Hayes wrote:
>I would prefer that the standard explicitly state that a compliant
>implementation MAY NOT support any encryption with less than "n" bits of key. 

Please calm down, guys!

Currently the draft specifies algorithms strong enough. There is no need for
political discussion here.

We have several problems to discuss, so please stop fighting!

Date: Thu, 30 Oct 1997 09:48:56 -0600
To: Jon Callas <[email-masked]>, [email-masked]
From: David Hayes <[email-masked]>
Subject: Re: Symmetric Algorithm
Sender: [email-masked]

At 03:16 PM 10/29/97 -0800, Jon Callas wrote:
>I'd also like to note that the principle of "no weak crypto" is in the
>charter, so I'm not including any weak algorithms, period.

There is a difference between not _including_ weak crypto in the standard,
and specifically _prohibiting_ weak crypto.

I would prefer that the standard explicitly state that a compliant
implementation MAY NOT support any encryption with less than "n" bits of key. 

I'm open to discussion of the appropriate value of "n", but 40 certainly
isn't it. Sorry, Dr. Freeh.

--
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: Thu, 30 Oct 1997 15:13:50 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Bill Stewart <[email-masked]>
CC: [email-masked]
Subject: Re: Symmetric Algorithm
Sender: [email-masked]

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

Bill Stewart wrote:

> >(1) MUST Triple-DES (because it's been more studied than CAST5).
> 
> Yeah, it wins.  Dog-slow, but everybody's comfortable with it.
> What about the 2-Key 3DES vs. 3-Key 3DES problem?
> 
> (There's also the minor annoyance that 3-Key 3DES needs
> 168 bits of key, and SHA-1 only gives you 160,
> and if the standard was going to insist on something that
> required 168 real bits I'd recommend changing it...)

Interesting points.  I would recommend, in the interests of getting on,
to "do whatever pgp5.0 with Triple-DES" does, and leave alternates for
later modes.  I think the importance of the MUST algorithm is in
interoperability.  If someone wants more performance or security,
chances are they will go for another algorithm, rather than fiddle
around with Triple-DES.

- -- 
iang                                      systemics.com

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

Subject: rough consensus
To: [email-masked]
Date: Thu, 30 Oct 1997 16:11:20 +0100 (NFT)
From: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?=)
Sender: [email-masked]

Several WG members and other recognized crypto experts consider any
form of message recovery dangerous, others do not agree with the way
it is implemented in PGP in particular.

So, if the IESG gives its WG chairs the power to decide whatever they
consider appropriate, fine, but please save ourselves the Newspeak of
calling that "rough consensus".

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Symmetric Algorithm
Date: 30 Oct 1997 14:51:44 GMT
Organization: IKS GmbH Jena
Lines: 5
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Peter Gutmann wrote:
>/* Derive an encryption key from a variable-length user key.  This function
>   works as follows:

Great. Thank you.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Symmetric Algorithm
Cc: [email-masked]
Reply-To: [email-masked]
Date: Fri, 31 Oct 1997 02:57:50 (NZDT)
Sender: [email-masked]

>[3DES]
>Yeah, it wins.  Dog-slow, but everybody's comfortable with it.
>What about the 2-Key 3DES vs. 3-Key 3DES problem?
       
Just do what X9.52 does, always use 3 keys but allow the first key to be 
repeated for the third key if you want 2-key triple DES.
 
>(There's also the minor annoyance that 3-Key 3DES needs
>168 bits of key, and SHA-1 only gives you 160, 
>and if the standard was going to insist on something that
>required 168 real bits I'd recommend changing it...)
 
There are a number of algorithms for hashing/distilling passphrases, but many 
of them are either awful and/or don't provide more bits than the output of the 
hash function which is used (which is exactly the problem mentioned above).  
The PKCS #5 method is very limited, the PFX method is awful, HMAC's are 
limited to the hash function output size and also handle passphrases longer 
than 64 bytes in a somewhat kludgy manner, I don't really like the SSLv3 
version (it iterates over the same data and only changes a few input bits for 
each block of output), and the TLS function again has a fixed output size 
based on the underlying hash functions.
 
The one I've been using is the one I posted to sci.crypt about a year ago,
which is:
 
/* Derive an encryption key from a variable-length user key.  This function
   works as follows:
 
   key[] = { 0 };
   state = hash( algorithm, mode, parameters, userKey );
 
   for count = 1 to iterations
     for length = 1 to keyLength
       state = hash( state );
       key[ length ] = hash( state, userKey );
 
   The state acts as an RNG which ensures that the user key hashing is
   serialized (ie that any form of parallelization or precomputation isn't
   possible) */
 
This can produce output of arbitrary size (eg 448 bit Blowfish keys), and also 
addresses various other problems I've seen in existing functions, for example 
if you start with the same parameters and use the resulting hash to key (say) 
DES and IDEA, then anyone who can recover a DES key can also recover 56 bits 
of your IDEA key.  By including the algorithm and parameters into the initial 
state calculation, a DES key derived from a given set of parameters will be 
completely different to an IDEA key coming from the same parameters.
 
Peter.

Date: Thu, 30 Oct 1997 03:54:12 -0800
To: [email-masked] (Lutz Donnerhacke), [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: What this WG is doing
Sender: [email-masked]

>* Lindsay Mathieson wrote:
>>As far as I understand it, it is impossible to guarantee a unique Key ID &
>>fingerprint, as they are hash's of the key material, which implies the
>>possibility of a hash collision, highly unlikely maybe, but still possible.

I'd call 2**-128 impossible, and 2**-64 birthday collisions close to impossible.
But 64-bit KeyIDs lead to birthday collisions with about 2**32 keys,
which _will_ happen, and then there's the problem of the user interfaces
(at least on the key servers) only showing the user 32 bits of key instead of 64
(which is not only susceptible to birthday collisions but 0xdeadbeef attacks,
though they're less useful than they used to be.)  Keyservers especially
need to be able to cope with duplicates.

At 02:35 PM 10/29/1997 GMT, Lutz Donnerhacke wrote:
>That's why my proposal causing this controversy was/is to define it not unique.

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

Subject: Re: Symmetric Algorithm
To: [email-masked] (Bill Stewart)
Date: Thu, 30 Oct 1997 14:11:42 +0100 (NFT)
Cc: [email-masked]
From: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?=)
Sender: [email-masked]

> If so, I'd say CAST5 rates at least a SHOULD; we need something
> fast and unencumbered.

CAST5 *is* patented, and just that it is available royalty-free right
now, doesn't mean the owners can't change their policy once the
algorithm is widely deployed.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: CAN'T Re: MUST versus SHOULD in application decisions
Date: 30 Oct 1997 12:54:04 GMT
Organization: IKS GmbH Jena
Lines: 11
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Bill Stewart wrote:
>The problem is that PGP doesn't _do_ Storage or Communication;
>it takes a batch of input data, does crypto, and produces output data.

*grin* So recovery is not needed in any case.... The surrounding enviroment
has to provide extra storage functions for plaintext.

A simple solution. Thanx.

BTW: Please remove it from all PGP 5.x implementations. This allows us to
remove it from the draft.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: CMR/ARR and OpenPGP
Date: 30 Oct 1997 12:27:49 GMT
Organization: IKS GmbH Jena
Lines: 15
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Bill Stewart wrote:
>Do you know which file it's defined in in 5.0 source?

Of course. ;-)
taranis:src(510)$ find . -name \*c | xargs grep -l SIGSUB_KEY_RECOVERY_KEY
./lib/pgp/keys/pgpRngPub.c
./lib/pgp/pubkey/pgpMakeSig.c

That's the files I derivated the draft from.

>PGP5.5 doesn't handle mail, so it can't bounce it.  SMTP filters do,
>and they're outside the scope of OpenPGP.

OpenPGP implementations should (I wrote MUST) drop keys with ARR. ;)

Date: Thu, 30 Oct 1997 04:18:36 -0800
To: Adam Back <[email-masked]>, [email-masked]
From: Bill Stewart <[email-masked]>
Subject: CAN'T Re: MUST versus SHOULD in application decisions 
Sender: [email-masked]

> Storage Keys vs. Communication Keys; SHOULD/SHOULD NOT/MUST/MUST NOT
> CMR vs. CDR vs. GACK vs. CMRK.

I don't think we'll be able to find a satisfactory answer to this,
or at least not that's useful for a standard like OpenPGP.
The problem is that PGP doesn't _do_ Storage or Communication;
it takes a batch of input data, does crypto, and produces output data.
Since PGP doesn't know what other programs do with its output data,
it can't implement DO/DONT/SHOULD/MUST; they're out of its scope.
PGPdisk does storage.  SMTP does communication, and could add crypto.
The old PGP2.6.2 did most of its crypto on files, but still generated
output files from input files rather than directly doing storage,
and it didn't do any communication at all.

There are some aspects of what PGP does that are relevant -
if you're encrypting a file to a public key for which you don't
hold the private key, you're probably going to use it with a
communication program.  If you're encrypting files using symmetric keys,
especially symmetric keys encrypting a random session key,
you're more likely to be using it for storage.  If a key expires,
and it's an encryption key rather than signature, it's probably not
for storage, but maybe you still want some forward secrecy built in,
and you don't really need public key.  If you're sharing your
storage with a backup-server, though, you may want to reencrypt to
their key.

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

Date: Thu, 30 Oct 1997 02:18:49 -0800
To: Adam Back <[email-masked]>
From: Bill Stewart <[email-masked]>
Subject: Re: CMR/ARR and OpenPGP (Re: What this WG is doing)
Cc: [email-masked]
Sender: [email-masked]

At 11:50 AM 10/29/1997 GMT, Adam Back wrote:
>> Realistically, PGP Inc. does get a bit of extra slack in OpenPGP.
>> In particular, if the field really was defined in 5.0 (not necessarily
>> used, but defined), 
>Yes it's defined in that the software knows what to do with it.  

Do you know which file it's defined in in 5.0 source?
I dredged around in there for a while and didn't see anything
that looked quite like it, but there's a lot of source there.

>This approach to extensions leads to compatibility problems -- you
>send to [email-masked] and it will bounce your mail if it is set up
>strictly.

The PGP Inc. SMTP filter offers a medium-wide range of options;
it can be set to reject unencrypted mail, or reject encrypted mail,
or reject unsigned mail (of course it can't decrypt, so it can only
tell whether unencrypted mail is also unsigned), etc.
If the administrator doesn't write adequately explanatory bouncegrams,
unlucky senders are going to get hosed anyway.
In particular, one of the postings I read on this list said that if
the sender's PGP public key ring doesn't already have the CMRK key,
it will ignore the CMRK KeyID request, so you'll get hit with this anyway.

>To guarantee compatibility, your choices as implementor are:
>- send garbage in second recipient field
>- send valid second recipient
Unfortunately, it does look like the new format uses 64-bit KeyIDs
for these fields, and a 0xdeaddeaddeadbeef attack is a few billion
times harder than a 0xdeadbeef attack, which could otherwise fool it :-)

>- ignore additional recipient request (it does say "request"), and
>  have confused users who can't interoperate even though both using
>  OpenPGP compliant appliactions.
>doesn't seem very good from an interoperability point of view, unless the
>standard says that pgp5.5 should not bounce mail.

PGP5.5 doesn't handle mail, so it can't bounce it.  SMTP filters do,
and they're outside the scope of OpenPGP.  Mail User Agents may
call PGP, but by then it's delivered, though I suppose the MUA could
bounce it if PGP returns an appropriate failure code, like "Can't decrypt".
(Returning predictable and useful failure/success indicators _is_
part of OpenPGP's scope.)

>The correct way to implement extensions I think is to detect extension
>capability based on public key, and only use it where it is available.
>(Such as SMTP extensions, browser capability negotiation, SSL
>algorithm negotiation, etc).  Same as symmetric cipher capability
>flags in public keys (which are already defined -- I think?)

Do you mean look up the extension information in some keyserver?
Or do you mean what it sounds like you mean, which is determine
whether to use a given extension based on flags in the public keys records?
If the latter, that's _precisely_ what the CMR feature _does_...

>This approach to extensions would dictate that pgp5.5 policy enforcer
>SMTP agent would only ever bounce mail where the keys indicated they
>were generated by software which advertises being capable of
>understanding ARRs.

The PGP5.5 message format doesn't differentiate between recipients
who were included because the sender wanted them or because of ARRs,
and the PGP Inc. implementation of the SMTP incoming enforcer can't tell.
On the other hand, the only people who would install such a silly thing (:-)
are companies whose users have been told to use PGP Business Version>=5.5,
and if you _want_ to enhance the filter to check each KeyID, it'll find
their CMRK recipient KeyIDs and be happy.

I guess there's still the outgoing email policy enforcer, which 
_could_ hang on to each outgoing encrypted message while it tries to find
the KeyID on some keyserver that may not even be accessible to it
to make sure the recipient doesn't mind that the sender's company
kept a copy of the outgoing mail, but it sounds impractical to implement.

I'm mostly surprised, because you seem to have agreed with 2/3 - 4/5 of
what PGP5.5 CMR does, and I thought you were more vehemently against it
than I am....

>It might be worth documenting, or making suggestions in the standard
>on a method to implement extensions, so that we don't get more
>problems like this.

Yep.  I'm especially annoyed at this one, since we _had_ the source
and basically nobody noticed these features were there until PGP 
announced what PGP 5.5 did with them, and I'm not sure if anybody
even noticed the more blatant ViaCrypt GAK features until then.
(But I did send you my copy of the source using cheap slow-mail :-)

>Then people who don't want ARR for security and political reasons can
>interoperate.

OpenPGP definitely shouldn't encrypt to ARRKs without some indication from
the sender that it's OK, whether it's a command-line flag or checkbox
or failing to drag the red blinking icon out of the dialog box
or config file / preferences setting or something.  [Yeah, yeah,
in another of my rants I argue that OpenPGP doesn't have a mechanism
for indicating _to_ the user that this is going on, since a GUI
is really out of its scope and it may be running non-interactively,
and putting an indication that it did it into the output file isn't
enough control, but it probably always has some parameter input capability.]

		-----BEGIN PGP ENCRYPTED MESSAGE-----
		Comment: Eavesdropper 0x12024561111 wanted a copy
		Comment: Eavesdropper 0x16503264930 wanted a copy
		Comment: Nosy, aren't they; hope you don't mind.

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

Date: Thu, 30 Oct 1997 03:23:07 -0800
To: [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: Symmetric Algorithm
Sender: [email-masked]

At 06:33 PM 10/28/1997 -0800, Paul Hoffman / IMC wrote:
>At 05:54 PM 10/28/97 -0800, Jon Callas wrote:
>>Please note that arguing for IDEA being a MUST algorithm could lead to the
>>standard getting bogged down.
>I think a better term would be "shot down". The IETF has voiced a strong
>preference for unencumbered algorithms when available, and IDEA is
>encumbered and has other choices, as you mention.

I agree.  And it's not just a US-centric problem, unlike RSA;
the IDEA patent applies in much of Europe.

>(1) MUST Triple-DES (because it's been more studied than CAST5).

Yeah, it wins.  Dog-slow, but everybody's comfortable with it.
What about the 2-Key 3DES vs. 3-Key 3DES problem?

(There's also the minor annoyance that 3-Key 3DES needs
168 bits of key, and SHA-1 only gives you 160, 
and if the standard was going to insist on something that
required 168 real bits I'd recommend changing it...)

>(2) Only one MUST algorithm for simplicity.

If so, I'd say CAST5 rates at least a SHOULD; we need something
fast and unencumbered.

>(3) SHOULD IDEA for compatibility with earlier PGPs (no need to do CAST5
>since there is little implementation history).

I'
I lean toward SHOULD CAST5, 
>(4) Absolutely everything else is a MAY. Under no circumstances should we
>list any MAYs. Implementors should be free to use whatever they want in
>addition to the MUSTs and SHOULDs. We should add algorithm IDs for
>everything that we know might be in use (such as Blowfish and CAST5), but
>not use any words that limit the algorithms to that list.

Or if we do list MAYs, it's only to give them IDs,
not to limit the list.
				Thanks! 
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Thu, 30 Oct 1997 09:10:48 +0100
From: Lutz Donnerhacke <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: What do we have to do today?
Sender: [email-masked]

To the new editor to be (Cc: Jon):

I'd suggest several things:
  - KISS
  - move "political" statments to chapter 'Security Considerations'.
    But leave illegalness statements in place -but move warning policy
    on receiving- especially:
      + MessageID must not generated.
      + UserIDs without self-signature are invalid.
      + Keys without UserIDS are invalid.
      + Keys with different key usage are invalid.
      + Group keys other than communciation encryption are invalid.
      + Other than storage keys with Data Recovery Key extensions are invalid.
      + Everything I alzheimered ;-)
  - Add Adam's anti-gak principles into chapter 'Security Considerations'.
  - introduce a new section in chapter 'generic data types' called
    'algorithm identifier octet' and subdivide it into:
      + 'symmetric algorithms'
        EDE-DES(SHOULD), IDEA(MUST), Cast5(MAY), Blowfish(MAY),
	SAFER128(MAY), ...
	IDEA is must, because it is the default and backward compatible.
	All algorithms use the mode described in Packet 'Symmetrically
	Encrypted Data'. Other modes (OFB, CBC, ...) are not used.
      + 'asymmetric algorithms'
        ElGamal(never mention D-H!, SHOULD), RSA(MUST), DSS(MAY), ...
	RSA is must, because it is backward compatible.
      + 'message digest algorithms'
        MD5(MUST), SHA1(SHOULD), MD2(MAY), ...
	MD5 is must, because it is the default and backward compatible.
      + 'compression algorithms'
        ZIP(MUST), ...
	I'm waiting for a detailed description of a fast algorithm with a
	significant better compression rate for text. This was outsourced to
	the local university last Tu.
  - key server communications describe a protocol of exchanging the hash of
    a level seven octet stream containing the WHOLE public key with user IDs
    and certificates. Define an order for this! I.e: User-IDs: primary
    followed by creation time descending. Certificate order:
    self-certificate followed by creation time ascending. Key revokation
    certificate removes all userIDs and certificates. Self-certificate
    revokation certificate removes all other certificates.
  - LADP keyserver based on draft-ietf-asid-pgp-02.txt by Roland Hedberg.
  - DNS keyserver based on a similar draft for distributed servers.
  - eMail keyserver based on the old (sic!) pgp net keyservers.
  - MIME is recommended as layer six. Ascii Armor MUST be readable and SHOULD
    generatable.
  - Detailed description of the two other trust models in PGP 5.x incl.
    the new Keyring Trust Elements.
  - Use 'Element' or 'Packet' depending on the ballot result published later
    today.
  - Detailed description of the missing algorithms:
      + Armor Checksum.
      + String to Key.
      + Everything I alzheimered.
  - Everything I alzheimered.

Good luck.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Looking for test LDAP PGP keyserver
Reply-To: [email-masked]
Date: Thu, 30 Oct 1997 19:14:21 (NZDT)
Sender: [email-masked]

[This question isn't terribly on-topic but it seems to be the best place to 
 post it]
 
Are there any LDAP PGP keyservers which can be used for testing (ie to grab 
PGP keys and upload sample keys)?  For that matter, are there any LDAP PGP 
keyservers online at all?  I'd like to be able to test some keyserver access 
code against a real server rather than just a copy of slapd running on a local 
machine.
 
Peter.

Date: Wed, 29 Oct 1997 20:08:17 -0800
To: <[email-masked]>
From: Bill Frantz <[email-masked]>
Subject: Re: Symmetric Algorithm
Sender: [email-masked]

I would be in favor of saying that implementations MUST NOT implement any
algorithms with less than 90 bits effective strength against brute force
attack.

81 bit Blowfish might qualify because of its 511 round key schedule.  :-)

-------------------------------------------------------------------------
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: Wed, 29 Oct 1997 15:16:04 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Symmetric Algorithm
Sender: [email-masked]

With regard to a number of questions:

Paul Hoffman said more forcefully what I meant about IDEA being a MUST
algorithm. It's also my understanding that if any encumbered algorithm is a
MUST, the spec will be spiked. My comment was supposed to be dry humor,
akin to saying that if you light a match in a powder room, you may
experience superficial burns.

When I said CAST, I meant CAST5, a.k.a. CAST-128. CAST5 is the default
algorithm with PGP5, which is the reason I proposed it as a SHOULD, rather
than a MAY.

Getting a stronger version of DSA requires our getting a hash algorithm
that is longer than 160 bits. Once we have a better hash algorithm, we can
make a longer signature scheme.

I'd also like to note that the principle of "no weak crypto" is in the
charter, so I'm not including any weak algorithms, period.

I will be sure to note that a list of MAY algorithms does not exclude
algorithms not on the list, but since the algorithms have numeric constants
associated with them, there has to be something akin to a registry for
them. We might as well include a few desirable ones now, as it's the
perfect time.

	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, 29 Oct 1997 14:45:52 -0800
To: [email-masked] (Lutz Donnerhacke), [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Software implementig Hierarchical trust
Sender: [email-masked]

At 04:20 PM 10/29/97 GMT, Lutz Donnerhacke wrote:
   * Salvatore Nesta wrote:
   >Existing software implement the Hierarchical trust? And, if not, why?
   
   Yes, there is such software: X.509 implementations. *grd*
   
   No, there is not such an implementation for PGP keys. The draft only
   describes the trust models in gereral and later the trust model realized.
   There are two other models missing... waiting for an editor.
   
Actually, there is one, it's the meta-introducer system in PGP 5.5.

I'm assembling together my draft of OP-Messaging from the June draft, my
notes, Lutz's work, and Hal Finney's work. I should be done in a few days.

As I remember, there are supposed to be a family of documents, with trust
models, key servers, and so on in a different document from the one I'm
editing. That one contains the packet/record layout, along with the
algorithms. 

Trust models, validity algorithms, and so on belong in the other document.

	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, 29 Oct 1997 13:07:27 -0600
To: Jon Callas <[email-masked]>
From: Black Unicorn <[email-masked]>
Subject: Re: Symmetric Algorithm
Cc: [email-masked]
Sender: [email-masked]

At 05:54 PM 10/28/97 -0800, you wrote:
>Questions:
>
>There are presently three symmetric algorithms used in PGP. They are IDEA,
>Triple-DES, and CAST5.
>
>Ideally, there would be only one MUST algorithm, and the other two are
>SHOULD algorithms -- because you lose some compatibility with PGP 5 if you
>don't do them, but there are reasons not to do IDEA, for example (it's
>patented, and you need a license).
>
>So here are the questions:
>
>(1) Which algorithm is the MUST algorithm?

3DES.

Well understood.  Well reviewed.  Free.  Timeless.

>(2) Should there be more than one MUST algorithm, and if so, which ones?
>Please note that arguing for IDEA being a MUST algorithm could lead to the
>standard getting bogged down.

No.

>(3) Should any remaining algorithms from the original suite be SHOULD or MAY?
>(4) What other algorithm(s) do you want to see as MAY algorithms?

SHOULD:

IDEA, CAST (Let's define WHICH CAST precisely though, yes?), Blowfish.

MAY:

Others.. (SAFER?)

Now, when are we going to see larger than 1024 DSS keys?

Date: Wed, 29 Oct 1997 13:12:43 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: re: Symmetric Algorithm
To: [email-masked]
Sender: [email-masked]

>So here are the questions:
>(1) Which algorithm is the MUST algorithm?

Is there any speed relationships that matter ? Strength being equal, speed of
calculation should be the next discriminator (assume you mean CAST-128).

>(2) Should there be more than one MUST algorithm, and if so, which ones?
>Please note that arguing for IDEA being a MUST algorithm could lead to the
>standard getting bogged down.

Suspect that there might be a way to induce the vendors to allow free
use of decryption and require license for encryption. Problem is that many have
archives. 

(3) Should any remaining algorithms from the original suite be SHOULD or MAY?

I guess it depends on what the purpose is (and might be optional extras).
If the optional module cost was under $5 that should not be a problem 
(particularly if the module could be reused with upgrades). 

This is an interesting thought: since I purchased the Viacrypt product, I would
assume that would mean I have a license for RSA and IDEA. Does that original
license follow through to the later versions ?

>(4) What other algorithm(s) do you want to see as MAY algorithms?

AES (if it ever comes out)

>(1) Triple-DES (because it's less controversial than CAST5).

Agree, think it would be interesting if PGP should qualify under FIPS 140-1

(2) No, only one MUST algorithm.

Not sure if even that is necessary but since D-H and 3-DES are free, would 
start there

>(3) I'd like to see both CAST5 and IDEA as SHOULD algorithms.
>(4) I have no preferences, but ones mentioned to me are Blowfish and SAFER128.

What are really talking about here is interoperability with other products.
Somewhat heretical I know but would like to be able to purchase a single
product that could exchange with PGP freeware, Entrust, Secret Agent, and
even Microsoft EXCHANGE "Advanced Security" (if the last ever meets my minimum
requirements for strength).

(actually would be even happier if Micro$oft ever gives up on its attempts
to provide "secure" nitch products & leaves that to people who know what they are
doing.)

We have plenty of examples (TI 99/4, Sony Beta, PS/2) to show that proprietary
formats *even if superior* do not succeed.

						Warmly,
							Padgett

From: Uri Blumenthal <[email-masked]>
Subject: Re: Symmetric Algorithm
To: [email-masked] (WengFatt Fong)
Date: Wed, 29 Oct 1997 12:29:15 -0500 (EST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

WengFatt Fong says:
> Making Triple-DES a MUST will render this unusable outside of North 
> America. Triple-DES requires a US Export licence.

Now that's a bullsh*t. I'm 99% sure this is a troll, but still
I'll answer.

*ALL* the crypto stuff requires export license, even if it's a
monoalphabetic substitution.  Some algorithms are known to get
the ANSWER (not necesarily a POSITIVE answer - mind you! - but
at least a reply) within 14 business days. Some algorithms are
known to be likely to be license-able "in bulk" - i.e. one
license covers most of your exports rather than having
to get a license to export for every customer, or at
least for every product...

*NO* strong crypto algorithm has that "14 business days reply
guarantee". If you think that IDEA (or SAFER64, or SAFER128)
can be exported from US without a license - there's a nice
cell in a federal facility waiting for you.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 29 Oct 97 11:21:48 -0600
To: Assar Westerlund <[email-masked]>
Cc: WengFatt Fong <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Symmetric Algorithm
Sender: [email-masked]

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

In <[email-masked]>, on 10/29/97 
   at 03:23 PM, Assar Westerlund <[email-masked]> said:

>No.

>It'll make if difficult for US companies to export it.  But that's their
>problem.

>This IETF wg is supposed to make a _specifcation_ that then can be
>implemented in different places.

Absolutely,

*ANY* strong encryption algorithm that we select will run afoul of export
restrictions.

Myself I would like to see a minimum symmetric key size written in to the
specs to avoid people using the OpenPGP name for silly things like RC2/40
and DES/40. This of course would need to be periodically reviewed to keep
up with computer and cryptology advances.

The mandating of RC2/40 was the biggest reason I rejected S/MIME and still
refuse to support it in any of my products.

Key strength, IMNSHO, is the most serious security issue this spec will
face.

- -- 
- ---------------------------------------------------------------
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: Uri Blumenthal <[email-masked]>
Subject: Re: Symmetric Algorithm
To: [email-masked] (Lutz Donnerhacke)
Date: Wed, 29 Oct 1997 12:16:36 -0500 (EST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Lutz Donnerhacke says:
> >(1) MUST Triple-DES (because it's been more studied than CAST5).
> 
> I'd prefer idea or blowfish.

Let's face it: no existing algorithm has been subject to as much
scrutiny as DES. Blowfish is nice (if somewhat slow :-), SAFER
is nice... Still, they don't have as much "field experiense".
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Software implementig Hierarchical trust
Date: 29 Oct 1997 16:20:18 GMT
Organization: IKS GmbH Jena
Lines: 16
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Salvatore Nesta wrote:
>>                      PGP Message Exchange Formats
>>                     <draft-ietf-pgp-formats01.txt>
>>....
>>There are two models of key management: Hierarchical trust and Web of trust.
>>...
>>Existing software implement the Web of trust...
>
>So, the question is:
>Existing software implement the Hierarchical trust? And, if not, why?

Yes, there is such software: X.509 implementations. *grd*

No, there is not such an implementation for PGP keys. The draft only
describes the trust models in gereral and later the trust model realized.
There are two other models missing... waiting for an editor.

Date: Wed, 29 Oct 1997 16:41:58 +0100
From: Salvatore Nesta <[email-masked]>
Subject: Software implementig Hierarchical trust
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Hello,
in the new draft:

>INTERNET-DRAFT                                         Lutz Donnerhacke
>Security                                               IN-Root-CA
>Expires in six months                                  Individual Network e.V.
                                                       October 19 1997

 >                       PGP Message Exchange Formats
 >                     <draft-ietf-pgp-formats01.txt>
Lutz Donnerhacke writes:
>....
>There are two models of key management: Hierarchical trust and Web of trust.
>...
>Existing software implement the Web of trust...

So, the question is:
Existing software implement the Hierarchical trust? And, if not, why?

Thanks

		Salvatore Nesta
		[email-masked]

From: Sam Simpson <[email-masked]>
To: "'WengFatt Fong'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Symmetric Algorithm
Date: Wed, 29 Oct 1997 14:56:56 -0000
Sender: [email-masked]

All algorithms within PGP (CAST,IDEA & 3DES) have keys >40 bits and
are thus unexportable from the US.  What stops people from producing
the programs outside of the US (Hint: nothing!).  This is supposed to
be a standard being defined, not a program hence export issues
shouldn't be considered.

If export restricions were a consideration then the assymetric
algorithms (RSA/DH) will also never get export licenses at their
current lengths.

- -----------------------------------------------------------------
Sam Simpson, Network Administrator & M.Sc. Info Security Student
E-Mail: [email-masked]

Home Tel/Fax: +44 (0)1438 726069     Work Tel: +44 (0)1992 479490

PGP DSS/DH key (1024 DSS/3072 DH):            Key ID:  0x433FDB4F 
  Fingerprint: EC90 207C 6392 3ED0 02A6  7D6C ED2D CBC1 433F DB4F
PGP 2048-bit RSA key:                         Key ID:  0x560D21A9
  Fingerprint: 5230 1896 D999 A4F0  1F31 937E F311 D469
- -----------------------------------------------------------------

On 29 October 1997 13:44, WengFatt Fong [SMTP:[email-masked]]
wrote:
> Making Triple-DES a MUST will render this unusable outside of North
America.
> Triple-DES requires a US Export licence.
> 
> Weng Fatt  Fong
> 
> 
> [email-masked] on 28/10/97 11:58:21 PM
> Please respond to [email-masked] @ internet
> To: [email-masked] @ internet
> cc: [email-masked] @ internet
> Subject: Re: Symmetric Algorithm
> 
> 
> Jon Callas says:
> > There are presently three symmetric algorithms used in PGP. They
are IDEA,
> > Triple-DES, and CAST5..........
> >
> > (1) Which algorithm is the MUST algorithm?
> 
> I say - Triple-DES as the most proved, the most reliable and the
> most "free".
> 
> > (2) Should there be more than one MUST algorithm, and if so, which
ones?
> > Please note that arguing for IDEA being a MUST algorithm could
lead to the
> > standard getting bogged down.
> 
> Due to its patented nature and some other things I strongly urge to
> make IDEA "SHOULD" at most. [Yes, I'm aware of what's the main
> algorithm in PGP-2.x.]
> 
> > (3) Should any remaining algorithms from the original suite be
SHOULD or
> > MAY?
> 
> People apparently like CAST - and it looks promising. I'd make it
SHOULD.
> 
> > (4) What other algorithm(s) do you want to see as MAY algorithms?
> 
> I'd make SEAL and DES/SK "MAY". I realize that there are many nice
> algorithms - but how many can (and should :-) we put in?
> SEAL is the fastest (but patented), and DES/SK gives
> you the benefits of 3DES without the expense of 48 rounds.
> 
> > My votes:
> > (1) Triple-DES (because it's less controversial than CAST5).
> 
> I'm with you.
> 
> > (2) No, only one MUST algorithm.
> 
> I'm with you.
> 
> > (3) I'd like to see both CAST5 and IDEA as SHOULD algorithms.
> 
> I prefer CAST (due to it's free nature).
> 
> > (4) I have no preferences, but ones mentioned to me are Blowfish
and
> > SAFER128.
> 
> Here we differ somewhat... My vote is for DES/SK (and for obvious
reason :-).
> --
> Regards,
> Uri  [email-masked]
> -=-=-=-=-=-=-
> <Disclaimer>
> 
> 

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Documentation of Alternatives (was Re: What this WG is doing)
Date: 29 Oct 1997 14:39:30 GMT
Organization: IKS GmbH Jena
Lines: 10
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Ian Grigg wrote:
>Lack of material is not a problem, but finding an unbiased reporter is a
>problem, and presenting a rational case that is both complete, unbiased
>and brief seems just too much to ask.  Practically, I think we need to
>sacrifice a statement on this issue, because it will be too costly in
>terms of time and contributor energy to produce.

I hope the chairman will decide who edit the draft in the next couple of
days. Jon's solution is known. My solution is known, too.... Which is really
unbiased? I don't know.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: What this WG is doing
Date: 29 Oct 1997 14:35:58 GMT
Organization: IKS GmbH Jena
Lines: 11
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Lindsay Mathieson wrote:
>As far as I understand it, it is impossible to guarantee a unique Key ID &
>fingerprint, as they are hash's of the key material, which implies the
>possibility of a hash collision, highly unlikely maybe, but still possible.

Right.

>I would have thought the only way to guarantee key uniqueness was to have a
>global issuing authority - something I'm not keen on.

That's why my proposal causing this controversy was/is to define it not unique.

Date: Wed, 29 Oct 1997 14:26:27 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Lutz Donnerhacke <[email-masked]>
CC: [email-masked]
Subject: Documentation of Alternatives (was Re: What this WG is doing)
Sender: [email-masked]

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

Lutz Donnerhacke wrote:
> 
> * Ian Grigg wrote:
> >In the current understanding of the community, the only plausible
> >alternative is to simply omit all mention of the CMRK subpacket from the
> >standard.
> 
> No. It is possible to document is and point out the security consequences in
> chapter 'Security Considerations'.

Yes, I jumped a few steps there hastly.  It is certainly possible to
document it.  I was suggesting that within the ambit of the IETF, it
will be impractical of us to do so.

To put this in context, Adam has found explanation difficult enough such
that writing a formal paper is the best way to explain his case.  Some
500 posts on this subject have occured (that I recorded) in the last two
or three weeks.  (PGP Inc has actively presented their viewpoint in
these posts.)

Lack of material is not a problem, but finding an unbiased reporter is a
problem, and presenting a rational case that is both complete, unbiased
and brief seems just too much to ask.  Practically, I think we need to
sacrifice a statement on this issue, because it will be too costly in
terms of time and contributor energy to produce.

- -- 
iang                                      systemics.com

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

To: WengFatt Fong <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Symmetric Algorithm
From: Assar Westerlund <[email-masked]>
Date: 29 Oct 1997 15:23:21 +0100
Lines: 15
Sender: [email-masked]

WengFatt Fong <[email-masked]> writes:
> Making Triple-DES a MUST will render this unusable outside of North America.
> Triple-DES requires a US Export licence.

No.

It'll make if difficult for US companies to export it.  But that's
their problem.

This IETF wg is supposed to make a _specifcation_ that then can be
implemented in different places.

And let's keep export discussions of this list, please.

/assar

From: WengFatt Fong <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Symmetric Algorithm
Date: Wed, 29 Oct 1997 08:43:46 -0500
Sender: [email-masked]

Making Triple-DES a MUST will render this unusable outside of North Ame=
rica.
Triple-DES requires a US Export licence.

Weng Fatt  Fong

[email-masked] on 28/10/97 11:58:21 PM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc: [email-masked] @ internet
Subject: Re: Symmetric Algorithm

Jon Callas says:
> There are presently three symmetric algorithms used in PGP. They are =
IDEA,
> Triple-DES, and CAST5..........
>
> (1) Which algorithm is the MUST algorithm?

I say - Triple-DES as the most proved, the most reliable and the
most "free".

> (2) Should there be more than one MUST algorithm, and if so, which on=
es?
> Please note that arguing for IDEA being a MUST algorithm could lead t=
o the
> standard getting bogged down.

Due to its patented nature and some other things I strongly urge to
make IDEA "SHOULD" at most. [Yes, I'm aware of what's the main
algorithm in PGP-2.x.]

> (3) Should any remaining algorithms from the original suite be SHOULD=
 or MAY?

People apparently like CAST - and it looks promising. I'd make it SHOUL=
D.

> (4) What other algorithm(s) do you want to see as MAY algorithms?

I'd make SEAL and DES/SK "MAY". I realize that there are many nice
algorithms - but how many can (and should :-) we put in?
SEAL is the fastest (but patented), and DES/SK gives
you the benefits of 3DES without the expense of 48 rounds.

> My votes:
> (1) Triple-DES (because it's less controversial than CAST5).

I'm with you.

> (2) No, only one MUST algorithm.

I'm with you.

> (3) I'd like to see both CAST5 and IDEA as SHOULD algorithms.

I prefer CAST (due to it's free nature).

> (4) I have no preferences, but ones mentioned to me are Blowfish and =
SAFER128.

Here we differ somewhat... My vote is for DES/SK (and for obvious reaso=
n :-).
--
Regards,
Uri  [email-masked]
-=3D-=3D-=3D-=3D-=3D-=3D-
<Disclaimer>

=

Date: 29 Oct 1997 13:22:0 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: What this WG is doing
To: [email-masked] (Lutz Donnerhacke), IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>>Exactly what flaws of PGP 5.x that manifest themselves as aspects of 
>the
>>message format are you referring to?
>
> - uniqueness of key ID and fingerprint

As far as I understand it, it is impossible to guarantee a unique Key ID &
fingerprint, as they are hash's of the key material, which implies the
possibility of a hash collision, highly unlikely maybe, but still possible.
I would have thought the only way to guarantee key uniqueness was to have a
global issuing authority - something I'm not keen on.
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Release Vs 2.6.1.1, on October 29, 1997, in Win95
4.0
	http://www.blackpaw.com/

Date: Wed, 29 Oct 1997 12:06:02 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: What this WG is doing
Sender: [email-masked]

John Noerenberg <[email-masked]> writes:
> However, our goal is not to go too far afield with PGP.

Right.

> Clearly CMR is a contentious issue within this group (and
> elsewhere).  Rightly or wrongly, there is a perceived need for it by
> some who nevertheless wish to encourage greater use of cryptography
> to protect their organization's communication from others.

More secure alternatives where presented which achieve the same
functionality.  See: http://www.dcs.ex.ac.uk/~aba/cdr/
Interoperability is important, but so is security.

> My view is that the protocol we produce should never mandate CMR.
> But it would be wise to document a means to implement it for those
> willing to risk potential limitations on their interoperability with
> others.

This is an interoperability issue, I think it is important that
different versions and different vendors implementations which are
compliant with the OpenPGP standard can talk to each other.

PGP Inc's pgp5.5 can be set up to prevent interoperability -- turn on
strict policy enforcer setting -- it will bounce mail without second
recipient.

This compatibility issue needs to be resolved.

> So far, I see arguments on both sides of the issue.

Yes, there are.

> >It is possible to implement functionality extensions interoperably
> >outside the standard in that a proprietary extension can be used only
> >for communications between so enabled software.  The same kind of hack
> >to distinguish recipient type can be used as is currently used to
> >distinguish between things like pgp2.x, cryptix2.2.2 and pgp5.x -- the
> >keys have different version numbers.
> 
> We're not that far apart in our attitude here.

I suggest that the standard should document an extension mechanism to
avoid more of these problems.

For example there is already a symmetric key negotation being
discussed with capabilities or preferences being indicated by flags
attached to public keys.

Could not ARR capability be indicated with such a flag?  Then if the
sender is not advertising the abilitiy to comply with additional
recipient requests, policy enforcers will know to not bounce mail, and
we retain interoperability.

The existing pgp5.5 for business implementation would then be
compliant, so long as the strict policy enforcer option is not used.

Or, an alternative is to define in the standard that implementations
which do not support the ARR request send garbage in the second
recipient field to ensure compatibility with pgp5.5.  (This
immediately guarantees interoperability -- future implementations
(such as pgp6.0) -- can then make use of the ARR extension flag on
public keys).

I think it is important that the standard should document an extension
mechanism to avoid more of these problems.

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, 29 Oct 1997 11:50:46 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: CMR/ARR and OpenPGP (Re: What this WG is doing)
Sender: [email-masked]

Bill Stewart <[email-masked]> writes:
> Adam Back <[email-masked]> writes:
> >I vote this does not go in.
> >If this goes in, everyone will be arguing for their favourite
> >extension of the day to go in, and there will be a messy political
> >argument, so lets please get this draft out without further argument.
> 
> Realistically, PGP Inc. does get a bit of extra slack in OpenPGP.
> In particular, if the field really was defined in 5.0 (not necessarily
> used, but defined), 

Yes it's defined in that the software knows what to do with it.  Ian
Brown experimented and found that pgp5.0 knows how to reply to the
second recipient on a pgp5.5 for business generated key with ARR
(Additional Recipient Request) attached to the userid.  So the
backwards compatibility is there.

However the only software currently which can generate keys with ARRs
so far is pgp5.5 for business.

> and probably even if it only appeared in 5.5, then accepting key
> records containing it should be part of the standard, though I
> strongly agree that any semantics of what to do about it shouldn't
> be in the standard.

This approach to extensions leads to compatibility problems -- you
send to [email-masked] and it will bounce your mail if it is set up
strictly.

To guarantee compatibility, your choices as implementor are:

- send garbage in second recipient field
- send valid second recipient

This:

- ignore additional recipient request (it does say "request"), and
  have confused users who can't interoperate even though both using
  OpenPGP compliant appliactions.

doesn't seem very good from an interoperability point of view, unless the
standard says that pgp5.5 should not bounce mail.

The correct way to implement extensions I think is to detect extension
capability based on public key, and only use it where it is available.
(Such as SMTP extensions, browser capability negotiation, SSL
algorithm negotiation, etc).  Same as symmetric cipher capability
flags in public keys (which are already defined -- I think?)

This approach to extensions would dictate that pgp5.5 policy enforcer
SMTP agent would only ever bounce mail where the keys indicated they
were generated by software which advertises being capable of
understanding ARRs.

It might be worth documenting, or making suggestions in the standard
on a method to implement extensions, so that we don't get more
problems like this.

Another approach may be:

Define an extension structure, and allocate an extension of "ARR/CMR"
for PGP Inc's method.  Perhaps kludge some feature of the current
message format which PGP is using in their pgp5.5 for business keys to
indicate this capability, even.

Then people who don't want ARR for security and political reasons can
interoperate.

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`

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: What this WG is doing
Date: 29 Oct 1997 13:03:47 GMT
Organization: IKS GmbH Jena
Lines: 9
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Ian Grigg wrote:
>In the current understanding of the community, the only plausible
>alternative is to simply omit all mention of the CMRK subpacket from the
>standard.

No. It is possible to document is and point out the security consequences in
chapter 'Security Considerations'.

It is only undefined, who edit the draft to move forward.

Date: Wed, 29 Oct 1997 12:10:55 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked], [email-masked]
CC: [email-masked]
Subject: Re: What this WG is doing
Sender: [email-masked]

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

Bill Stewart wrote:

> Realistically, PGP Inc. does get a bit of extra slack in OpenPGP.

Colin Plumb, Derik Atkins and the nameless others at PGP slaved for some
3 years on this codebase[1].

There are 110,000 lines of C code[2] in pgp5.0.  Now, at 200 working
days and 10 lines per day, that's five and a half man years of effort. 
Or, at valley costs of say 100k per programmer, that's a half a million
(ignoring the support costs, probably have to double that to be
realistic).

PGP Inc is getting a lot of slack cut by having their existing code base
validated.

Remembering that PGP Inc did not release any information about packet
formats until the release of pgp5.0 in paper form (feb this year?), and
then in July this year, the real online code was made available via
Stale's scanning effort.  That means that any competitors, including the
people I work with, have had less than 6 months to catch up [3].

I had always assumed that the IETF had a strictly non-commercial role,
but this standards process, if it succeeds, amounts in economic terms to
an enourmous subsidy to PGP Inc [4].  I personally am prepared to accept
that subsidy on the grounds that the benefit to the community of a
standard RFC on Open PGP is something worth having.

Not being a shareholder in PGP Inc, and thus not a direct beneficiary in
the subsidy, I must contain my enthusiasm to that of being a stakeholder
in Open PGP.  However, as a stakeholder in an open standard, I have yet
to see a convincing reason why any one competitor should receive
preferential treatment.

> In particular, if the field really was defined in 5.0 (not necessarily
> used, but defined), and probably even if it only appeared in 5.5,
> then accepting key records containing it should be part of the standard,
> though I strongly agree that any semantics of what to do about it
> shouldn't be in the standard.

I am prepared to accept, in general, the pgp5.0 code being used as the
basis for this standard.

However, our purpose here is valueless and we would be negligent if we
did not scrutinise the decisions made in that code.  If we make no
changes to the pgp5.0 base this would signal one of two things: that we
have not done our job, or that PGP Inc has done its job perfectly. 
Obviously, the converse (that we make changes and have therefore done
our job) is not likely to hold either.

Changes can be expected.  How PGP Inc wish to treat any changes is of
course up to them.  Given the nature of the IETF subsidy, however, I am
continually surprised by the keenness with which PGP Inc pursues its
commercial agenda.

John W. Noerenberg wrote:

> As much as possible, this discussion must remain apolitical and without
> philosophical rants.  We are here to make decisions about the
> implementation of cryptographic messages.  We must recognize that we may
> disagree with some legitimate uses of cryptography.  But if there is a
> legitimate need, then we must seek to allow it.

This is of course the crux of the argument.  There is a camp that
states, to paraphrase, that there is no legitimate need for this
feature.  Indeed, they assert that there is a serious danger.  I won't
review these arguments here, they are well recorded elsewhere.

The community is split on this issue.  Split violently.  PGP Inc are now
in the interesting position of having to accept the most severe
criticism from their root community.  By severe, I mean, commercially
damaging, which is of course, their choice.

For this standards process to accept *either* viewpoint, by including
any mention of the issue, runs the risk of promoting or accepting some
arguments that the community itself has not accepted as a whole.

> If we fail to do that
> constituencies on which wide acceptance of this protocol depend will not
> accept it, and it will fail to gain standard status.

True.

But to clarify, there will be limited acceptance if we *exclude* valid
or legitimate activity.  By dropping mention of the CMRK subpacket, we
do not exclude its use.  PGP Inc would be free to pursue this as a
commercial choice, just as they are doing now.  In fact it would not
impinge them in their current commercial endevours one iota.  Please
correct me if I have missed something here.  Proponents of this method
or any alternative would also be free to promote an RFC that extends the
current work, which is arguably a more appropriate place for all of this
issue.

On the other hand, to include the CMRK subpacket will signal acceptance
of this.  To avoid any such acceptance by the IETF, one would need to
insert strong verbage listing the dangers of such, and that is
unrealistic from any point of view.

In the current understanding of the community, the only plausible
alternative is to simply omit all mention of the CMRK subpacket from the
standard.

- -- 
iang                                      systemics.com

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

[1] searching the code, there 455 C files.  Plumb and Atkins get credit
in some 160 of those, and the rest were presumably written by the
various programmers at PGP Inc.

[2] I stripped empty lines and empty comments, and only *.[ch]

[3] Yes, we are currently working on the signature bug.  At least if we
had a standard, we could work out who had the bug.

[3] BTW, the subsidy is not 1 million dollars, it is the cash flow
resulting from that investment over time.  A better estimate is a
valuation of the PGP Inc company, but I don't know how much the current
investors value it at.

From: "Tony Mione" <[email-masked]>
Date: Wed, 29 Oct 1997 06:33:05 -0500
To: Jon Callas <[email-masked]>, [email-masked]
Subject: Re: Symmetric Algorithm
Sender: [email-masked]

On Oct 28,  5:54pm, Jon Callas wrote:
> Subject: Symmetric Algorithm
> Questions:
>
> There are presently three symmetric algorithms used in PGP. They are IDEA,
> Triple-DES, and CAST5.
>
> Ideally, there would be only one MUST algorithm, and the other two are
> SHOULD algorithms -- because you lose some compatibility with PGP 5 if you
> don't do them, but there are reasons not to do IDEA, for example (it's
> patented, and you need a license).
>
> So here are the questions:
>
> (1) Which algorithm is the MUST algorithm?
> (2) Should there be more than one MUST algorithm, and if so, which ones?
> Please note that arguing for IDEA being a MUST algorithm could lead to the
> standard getting bogged down.
> (3) Should any remaining algorithms from the original suite be SHOULD or MAY?
> (4) What other algorithm(s) do you want to see as MAY algorithms?
>
> I am presently merging my draft of the spec with Lutz's, and will send that
> out presently.
>
> My votes:
> (1) Triple-DES (because it's less controversial than CAST5).

	Personally, I wouldn't mind seeing both Triple-DES and CAST5 as a MUST.
Question: Why is CAST5 controversial? ... insufficient crytanalysis at this
point in time?

> (2) No, only one MUST algorithm.
> (3) I'd like to see both CAST5 and IDEA as SHOULD algorithms.
> (4) I have no preferences, but ones mentioned to me are Blowfish and
SAFER128.

Ok:

1) Triple-DES and CAST5
2) Yes (see above)
3) SHOULD algorithms : IDEA
4) Blowfish

>
> 	Jon
>...
>-- End of excerpt from Jon Callas

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

Subject: HTTP key lookup request and Host: (was: Re: key server lookup protocol?)
Date: Wed, 29 Oct 97 11:29:07 +0100
From: Gerald Young <[email-masked]>
To: <[email-masked]>
cc: "Pat Richard" <[email-masked]>, "Frank Brueckner" <[email-masked]>, "Jon Callas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 1997-10-28 23:04, Pat Richard [email-masked] wrote:

>Frank Brueckner wrote:
>> 
>> An additional question to that (older) thread:
>> 
>> >    > PGP 5.0 sends the following request:
>> >    > "GET /pks/lookup?op=3Dget&exact=3Don&search=3D<Email Address|Key =
ID> HTTP/1.0"
>> >
>> > Now, with 5.5, we have an ldap server, which will make things a lot =
easier.
>> > We support the old HTTP one, but the ldap one is the way to go.
>> >
>> > Jon Callas                                         [email-masked]
>
>So where is the document describing this and where does it sit within
>the ietf-open-pgp framework. Does this exist ? Will the group accept
>submissions from third parties who already have been storing PGP keys in
>LDAP already, or is this not going to be part of open-pgp ? What is the
>format by which 5.5 does the LDAP queries ?

Sorry to drop in, but I had some problems with most HTTP based client =
software.
It manifests in the ommission of the "Host:" request parameter line, =
which is needed by multi-homed servers (like say Apache) to properly =
detect to which of its served hosts the request was directed.

Is the HTTP based lookup of keys adhering to this?

( Sorry, I dropped the last draft of the document just yesterday due =
to time constraints and found this - naturally - this morning)

-- Gerald Young

-- 
The box said 'Requires Windows 95 or better', so I bought a Macintosh
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| future:       <mailto: "Gerald Young"       [email-masked]>          =
=A1
+ Mac OS rules! - - - - - - - - - - - - - - - - - - - - - - - - - - +

Date: Wed, 29 Oct 1997 00:40:44 -0800
To: Adam Back <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: What this WG is doing
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 10:39 PM +0000 10/28/97, Adam Back wrote:
>Ian Grigg <[email-masked]> writes:
>> Rodney Thayer wrote:
>> > >From: [email-masked] (Lutz Donnerhacke)
>> > >IMHO: We can't document features or bugs made by a company while we are
>> > >working on the draft. We can't document bugs as features. Several
>> > >implementation flaws of PGP 5.x must be cleared in this draft.
>> >
>> > Exactly what flaws of PGP 5.x that manifest themselves as aspects of the
>> > message format are you referring to?
>>
>> Anything to do with CMR.  This issue is well documented elsewhere,
>> elsetime, so I won't repeat it here (let me know if I should summarise).
>
>Seconded -- no CMR.
>
>Experimental new features should be implemented outside the standard.
>IETF is supposed to document current practice, not bleeding edge
>experiments of one vendor -- standards lag behind, and that's the way
>it should be.

In general this is not correct, Adam.  There are numerous examples of
experimental work done within the IETF.  Good current examples include
multicast protocols, and IPv6.

However, our goal is not to go too far afield with PGP.

Clearly CMR is a contentious issue within this group (and elsewhere).
Rightly or wrongly, there is a perceived need for it by some who
nevertheless wish to encourage greater use of cryptography to protect their
organization's communication from others.

My view is that the protocol we produce should never mandate CMR.  But it
would be wise to document a means to implement it for those willing to risk
potential limitations on their interoperability with others.

So far, I see arguments on both sides of the issue.

>
>It is possible to implement functionality extensions interoperably
>outside the standard in that a proprietary extension can be used only
>for communications between so enabled software.  The same kind of hack
>to distinguish recipient type can be used as is currently used to
>distinguish between things like pgp2.x, cryptix2.2.2 and pgp5.x -- the
>keys have different version numbers.

We're not that far apart in our attitude here.

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, 29 Oct 1997 00:27:10 -0800
To: [email-masked] (Lutz Donnerhacke)
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: What this WG is doing
Cc: [email-masked]
Sender: [email-masked]

At 8:58 AM +0000 10/28/97, Lutz Donnerhacke wrote:
>* John  W. Noerenberg wrote:
>[Goal: Document the format]
>>However, adding new ideas that are not in any implementation will slow us
>>down, changing old ideas which are already used in common will slow us
>>down.  If anyone starts down those paths, I'll ask you, politely, to
>>refrain.
>
>IMHO: We can't document features or bugs made by a company while we are
>working on the draft. We can't document bugs as features. Several
>implementation flaws of PGP 5.x must be cleared in this draft. Otherwise,
>several people will leave the WG and protest.

It sounds as though you are agreeing with me.  If there is no rough
consensus on a particular aspect of the format, it won't be included.  If
there is, it will.

Since we agree, we'll get along just fine. <g>

"Rough consensus" is my assessment of the will of the WG.  That is my
perogative as chairman.  I'll use whatever means I deem appropriate to
obtain consensus.  The IESG agreed to have me chair this WG because I have
enough experience in the IETF to know how other WG chairman have done this,
because I have a reputation for being fair-minded, and because I was
foolish enough to agree to take the job.

You are free to disagree with my assessment and take it up with the IESG,
in particular, Jeff Schiller, the Security Area Director who monitors the
progress of this WG.  That is you perogative.  If you think I am running
this group badly, please do tell me, or tell Jeff, if you are more
comfortable with that.  I will always welcome your comments.  I may not
take your advice, but I'm sure I'll be better off, and more importantly,
the WG will be better off for my hearing your views.

My goal for this WG is to produce an implementable, and widely implemented
protocol for crytpographic messages, based on what we call "PGP".  Clearly,
what "PGP" is has come to mean different things to different people.  That
makes our work to find a common ground all the more crucial.

As much as possible, this discussion must remain apolitical and without
philosophical rants.  We are here to make decisions about the
implementation of cryptographic messages.  We must recognize that we may
disagree with some legitimate uses of cryptography.  But if there is a
legitimate need, then we must seek to allow it.  If we fail to do that
constituencies on which wide acceptance of this protocol depend will not
accept it, and it will fail to gain standard status.

That can happen despite our best work.  But with our best efforts, we put
aside philosophical differences and see what is the widest applicability of
our protocol within the bounds of good engineering and design.  It will be
implemented.  It will be accepted.  We will acheive our goal.

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: Tue, 28 Oct 1997 23:51:08 -0800
To: [email-masked] (Lutz Donnerhacke)
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: CfV: Packet <-> Elements
Cc: [email-masked]
Sender: [email-masked]

At 3:11 PM +0000 10/27/97, Lutz Donnerhacke wrote:
>* John  W. Noerenberg wrote:
>>There are more substantive issues to address than whether we continue with
>>"packets" or adopt some new term for protocol data units.
>
>Yes, so let's vote and forget the discussion. Making a ballot is the fastest
>way to switch to a new topic. A ballot can be used for every non important
>issuse. I'm not interested in the result. I can live with both results.

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.

I have heard no compelling reason to change the term.  We will continue to
use "packets" to refer to PGP protocol data units.

Continuing in this vein is counterproductive.

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

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Symmetric Algorithm
Date: 29 Oct 1997 08:15:59 GMT
Organization: IKS GmbH Jena
Lines: 28
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Paul Hoffman / IMC wrote:
>(1) MUST Triple-DES (because it's been more studied than CAST5).

I'd prefer idea or blowfish.

>(2) Only one MUST algorithm for simplicity.
>(3) SHOULD IDEA for compatibility with earlier PGPs (no need to do CAST5
>since there is little implementation history).

Agree.

>(4) Absolutely everything else is a MAY.

Agree.

>Under no circumstances should we
>list any MAYs. Implementors should be free to use whatever they want in
>addition to the MUSTs and SHOULDs.

Of course, MAY means optional, but we should list the algorithms, because

>We should add algorithm IDs for
>everything that we know might be in use (such as Blowfish and CAST5), but
>not use any words that limit the algorithms to that list.

-as you wrote- the implementors should use conforming identifiers.

BTW: This discussion can not be go to the draft, ... there is no editor.

Date: Tue, 28 Oct 1997 23:11:13 -0800
To: Adam Back <[email-masked]>
From: Bill Stewart <[email-masked]>
Subject: Re: What this WG is doing
Cc: [email-masked]
Sender: [email-masked]

> > The main manifestation of this that I know of is the addition of a
> > CMRK subpacket in the signature packet.

>I vote this does not go in.
>If this goes in, everyone will be arguing for their favourite
>extension of the day to go in, and there will be a messy political
>argument, so lets please get this draft out without further argument.

Realistically, PGP Inc. does get a bit of extra slack in OpenPGP.
In particular, if the field really was defined in 5.0 (not necessarily
used, but defined), and probably even if it only appeared in 5.5,
then accepting key records containing it should be part of the standard,
though I strongly agree that any semantics of what to do about it
shouldn't be in the standard.
				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: What this WG is doing
Date: 29 Oct 1997 08:08:43 GMT
Organization: IKS GmbH Jena
Lines: 10
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Adam Back wrote:
>> The main manifestation of this that I know of is the addition of a
>> CMRK subpacket in the signature packet.
>
>If this goes in, everyone will be arguing for their favourite
>extension of the day to go in, and there will be a messy political
>argument, so lets please get this draft out without further argument.

Current proposal includes it to avoid usage. This is required to deal
correctly with the already existing extension.

From: Uri Blumenthal <[email-masked]>
Subject: Re: Symmetric Algorithm
To: [email-masked] (Jon Callas)
Date: Tue, 28 Oct 1997 23:21:51 -0500 (EST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Jon Callas says:
> There are presently three symmetric algorithms used in PGP. They are IDEA,
> Triple-DES, and CAST5..........
> 
> (1) Which algorithm is the MUST algorithm?

I say - Triple-DES as the most proved, the most reliable and the
most "free".

> (2) Should there be more than one MUST algorithm, and if so, which ones?
> Please note that arguing for IDEA being a MUST algorithm could lead to the
> standard getting bogged down.

Due to its patented nature and some other things I strongly urge to
make IDEA "SHOULD" at most. [Yes, I'm aware of what's the main 
algorithm in PGP-2.x.]

> (3) Should any remaining algorithms from the original suite be SHOULD or MAY?

People apparently like CAST - and it looks promising. I'd make it SHOULD.

> (4) What other algorithm(s) do you want to see as MAY algorithms?

I'd make SEAL and DES/SK "MAY". I realize that there are many nice
algorithms - but how many can (and should :-) we put in?
SEAL is the fastest (but patented), and DES/SK gives
you the benefits of 3DES without the expense of 48 rounds.

> My votes:
> (1) Triple-DES (because it's less controversial than CAST5).

I'm with you.

> (2) No, only one MUST algorithm.

I'm with you.

> (3) I'd like to see both CAST5 and IDEA as SHOULD algorithms.

I prefer CAST (due to it's free nature).

> (4) I have no preferences, but ones mentioned to me are Blowfish and SAFER128.

Here we differ somewhat... My vote is for DES/SK (and for obvious reason :-).
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Tue, 28 Oct 1997 18:33:36 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Symmetric Algorithm
Sender: [email-masked]

At 05:54 PM 10/28/97 -0800, Jon Callas wrote:
>. . .
>Please note that arguing for IDEA being a MUST algorithm could lead to the
>standard getting bogged down.

I think a better term would be "shot down". The IETF has voiced a strong
preference for unencumbered algorithms when available, and IDEA is
encumbered and has other choices, as you mention.

Another way to look at it: if you have IDEA as a MUST along with other
algorithms, you will probably have RSA signatures as a MUST along with
other algorithms. :-)

My thoughts:
(1) MUST Triple-DES (because it's been more studied than CAST5).
(2) Only one MUST algorithm for simplicity.
(3) SHOULD IDEA for compatibility with earlier PGPs (no need to do CAST5
since there is little implementation history).
(4) Absolutely everything else is a MAY. Under no circumstances should we
list any MAYs. Implementors should be free to use whatever they want in
addition to the MUSTs and SHOULDs. We should add algorithm IDs for
everything that we know might be in use (such as Blowfish and CAST5), but
not use any words that limit the algorithms to that list.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 28 Oct 1997 17:54:55 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Symmetric Algorithm
Sender: [email-masked]

Questions:

There are presently three symmetric algorithms used in PGP. They are IDEA,
Triple-DES, and CAST5.

Ideally, there would be only one MUST algorithm, and the other two are
SHOULD algorithms -- because you lose some compatibility with PGP 5 if you
don't do them, but there are reasons not to do IDEA, for example (it's
patented, and you need a license).

So here are the questions:

(1) Which algorithm is the MUST algorithm?
(2) Should there be more than one MUST algorithm, and if so, which ones?
Please note that arguing for IDEA being a MUST algorithm could lead to the
standard getting bogged down.
(3) Should any remaining algorithms from the original suite be SHOULD or MAY?
(4) What other algorithm(s) do you want to see as MAY algorithms?

I am presently merging my draft of the spec with Lutz's, and will send that
out presently.

My votes:
(1) Triple-DES (because it's less controversial than CAST5).
(2) No, only one MUST algorithm.
(3) I'd like to see both CAST5 and IDEA as SHOULD algorithms.
(4) I have no preferences, but ones mentioned to me are Blowfish and SAFER128.

	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, 28 Oct 1997 22:39:43 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: What this WG is doing
Sender: [email-masked]

Ian Grigg <[email-masked]> writes:
> Rodney Thayer wrote:
> > >From: [email-masked] (Lutz Donnerhacke)
> > >IMHO: We can't document features or bugs made by a company while we are
> > >working on the draft. We can't document bugs as features. Several
> > >implementation flaws of PGP 5.x must be cleared in this draft.
> > 
> > Exactly what flaws of PGP 5.x that manifest themselves as aspects of the
> > message format are you referring to?
> 
> Anything to do with CMR.  This issue is well documented elsewhere,
> elsetime, so I won't repeat it here (let me know if I should summarise).

Seconded -- no CMR.

Experimental new features should be implemented outside the standard.
IETF is supposed to document current practice, not bleeding edge
experiments of one vendor -- standards lag behind, and that's the way
it should be.

It is possible to implement functionality extensions interoperably
outside the standard in that a proprietary extension can be used only
for communications between so enabled software.  The same kind of hack
to distinguish recipient type can be used as is currently used to
distinguish between things like pgp2.x, cryptix2.2.2 and pgp5.x -- the
keys have different version numbers.

> The main manifestation of this that I know of is the addition of a
> CMRK subpacket in the signature packet.

I vote this does not go in.

If this goes in, everyone will be arguing for their favourite
extension of the day to go in, and there will be a messy political
argument, so lets please get this draft out without further argument.

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, 28 Oct 1997 14:04:40 -0800
From: Pat Richard <[email-masked]>
To: Frank Brueckner <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: key server lookup protocol?
Sender: [email-masked]

Frank Brueckner wrote:
> 
> An additional question to that (older) thread:
> 
> >    > PGP 5.0 sends the following request:
> >    > "GET /pks/lookup?op=get&exact=on&search=<Email Address|Key ID> HTTP/1.0"
> >
> > Now, with 5.5, we have an ldap server, which will make things a lot easier.
> > We support the old HTTP one, but the ldap one is the way to go.
> >
> > Jon Callas                                         [email-masked]

So where is the document describing this and where does it sit within
the ietf-open-pgp framework. Does this exist ? Will the group accept
submissions from third parties who already have been storing PGP keys in
LDAP already, or is this not going to be part of open-pgp ? What is the
format by which 5.5 does the LDAP queries ?

> 
> O.K. now you have LDAP and HTTP as protocols.
> But if you use LDAP you need attributes containing keys|key-URLs|key-IDs|
> User-IDs.
> 
> Do you use the attribute types as suggested by Roland Hedberg
> <[email-masked]> in his (outdated) draft-ietf-asid-pgp-02.txt ?
> 
> Regards,
> --
> Frank Brueckner, SNI Directory Team,
> http://www.sni.de/public/aswba/com/en/corpdir.htm

Date: Tue, 28 Oct 1997 15:02:30 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Rodney Thayer <[email-masked]>
CC: [email-masked]
Subject: Re: What this WG is doing
Sender: [email-masked]

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

Rodney Thayer wrote:
> 
> >From: [email-masked] (Lutz Donnerhacke)
> >IMHO: We can't document features or bugs made by a company while we are
> >working on the draft. We can't document bugs as features. Several
> >implementation flaws of PGP 5.x must be cleared in this draft.
> 
> Exactly what flaws of PGP 5.x that manifest themselves as aspects of the
> message format are you referring to?

Anything to do with CMR.  This issue is well documented elsewhere,
elsetime, so I won't repeat it here (let me know if I should summarise).

The main manifestation of this that I know of is the addition of a CMRK
subpacket in the signature packet.

Others may have other feature/bug/flaw sets in mind.

- -- 
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: What this WG is doing
Date: 28 Oct 1997 14:35:39 GMT
Organization: IKS GmbH Jena
Lines: 15
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Rodney Thayer wrote:
>>IMHO: We can't document features or bugs made by a company while we are
>>working on the draft. We can't document bugs as features. Several
>>implementation flaws of PGP 5.x must be cleared in this draft.
>
>Exactly what flaws of PGP 5.x that manifest themselves as aspects of the
>message format are you referring to?

 - uniqueness of key ID and fingerprint
 - "key expiration time" subelement which is indeed a user ID expiration time
 - self-signature of encryption keys undefined for different purposes
   especially key revokation certificates
 - GAK in the format to implement CDR => format misses storage usage

And everything I missed. ;-)

Date: Tue, 28 Oct 1997 08:45:50 -0500
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Re: What this WG is doing
Sender: [email-masked]

>From: [email-masked] (Lutz Donnerhacke)
>IMHO: We can't document features or bugs made by a company while we are
>working on the draft. We can't document bugs as features. Several
>implementation flaws of PGP 5.x must be cleared in this draft.

Exactly what flaws of PGP 5.x that manifest themselves as aspects of the
message format are you referring to?

From: [email-masked] (Frank Brueckner)
Subject: Re: key server lookup protocol?
To: [email-masked]
Date: Tue, 28 Oct 1997 14:00:18 +0100 (MET)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

An additional question to that (older) thread:

>    > PGP 5.0 sends the following request:
>    > "GET /pks/lookup?op=get&exact=on&search=<Email Address|Key ID> HTTP/1.0"
>    
> Now, with 5.5, we have an ldap server, which will make things a lot easier.
> We support the old HTTP one, but the ldap one is the way to go.
> 
> Jon Callas                                         [email-masked]

O.K. now you have LDAP and HTTP as protocols.
But if you use LDAP you need attributes containing keys|key-URLs|key-IDs|
User-IDs.

Do you use the attribute types as suggested by Roland Hedberg 
<[email-masked]> in his (outdated) draft-ietf-asid-pgp-02.txt ?

Regards,
-- 
Frank Brueckner, SNI Directory Team, 
http://www.sni.de/public/aswba/com/en/corpdir.htm

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: What this WG is doing
Date: 28 Oct 1997 08:58:34 GMT
Organization: IKS GmbH Jena
Lines: 23
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* John  W. Noerenberg wrote:
[Goal: Document the format]
>However, adding new ideas that are not in any implementation will slow us
>down, changing old ideas which are already used in common will slow us
>down.  If anyone starts down those paths, I'll ask you, politely, to
>refrain.

IMHO: We can't document features or bugs made by a company while we are
working on the draft. We can't document bugs as features. Several
implementation flaws of PGP 5.x must be cleared in this draft. Otherwise,
several people will leave the WG and protest.

>For 2, there already is a PROPOSED STANDARD for MIME encapsulation of
>PGP-encrypted and/or signed messages, RFC 2015.  We know it works, as there
>are several implementations.  There appear to be a few defects of a *minor*
>nature.  We should fix them and advance it as a DRAFT STANDARD as soon as
>possible.  It already meets most of the requirements for DRAFT status.

There is only a minor change to RfC 2015 helpful to ease programming. AFAIK
the current implementation sources, these minor change does not require
any software update.

Do I miss something?

Date: Mon, 27 Oct 1997 17:35:10 -0800
To: [email-masked]
From: "John  W. Noerenberg" <[email-masked]>
Subject: What this WG is doing
Sender: [email-masked]

Over the last few days, I've been trying to respond to some of the
discussion about Lutz's draft.  It occurred to me over the weekend that I
should revisit our goals.

They are quite simple, really.  We are attempting to do two things:

1) Document current PGP message format so that users of independently
produced implementations can successfully encrypt/decrypt documents they
exchange, and, similarly, digitally sign and authenticate them.

2) Standardize a mechanism for the use of PGP with Internet email.

That's it.  That's all our charter says.

This needs to be done as quickly as humanly possible.

Once we are well on our way to accomplishing these goals, we might consider
other, related topics.  I know the two items I've listed aren't the end-all
and be-all of crypto applications.

But we have to get these done for two reasons.  One, we said we would.
Two, until these are done for PGP, nothing else much matters.  More on this
below.

For 1), we will use the historical implementations of PGP, including PGP,
Inc's recently released versions, as the basis for abstracting PGP message
format.  As a working group, we have a important advantage.  There already
exist multiple code bases that implement most of the same ideas that make
up PGP format.  And all the source code is available.  Our goal must be to
codify in an RFC those ideas which are all in common, and all the ideas
which rough consensus indicates needs to be included in all implementations.

However, adding new ideas that are not in any implementation will slow us
down, changing old ideas which are already used in common will slow us
down.  If anyone starts down those paths, I'll ask you, politely, to
refrain.

For 2, there already is a PROPOSED STANDARD for MIME encapsulation of
PGP-encrypted and/or signed messages, RFC 2015.  We know it works, as there
are several implementations.  There appear to be a few defects of a *minor*
nature.  We should fix them and advance it as a DRAFT STANDARD as soon as
possible.  It already meets most of the requirements for DRAFT status.

This is the work of this Working Group.  Other discussions which are not
germaine have no place in this mailing list.  Again, I will ask you,
politely, to refrain.

As for other work we might tackle.  (This is the "more" I promised above)
The IETF philosophy* is that once a WG finishes its work, the tasks on its
charter, it ceases to exist.  A WG's charter is malleable, it can be
changed, when necessary.  So if we encounter a task which affects the work
we've already agreed to perform, it is possible to alter our charter to
include the task.

But I don't want to be stuck with this job, forever.  So, unless you make a
pretty good case, I will ask you, politely, to refrain.

If you have any questions about this, please contact me.  I will be more
than happy to discuss it with you.

Thank you.

*(see "The Tao of the IETF", RFC1718)

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

From: [email-masked]
Date: Sun, 26 Oct 1997 18:28:42 -0800
To: "William H. Geiger III" <[email-masked]>, [email-masked] (Lutz Donnerhacke)
Original-From: Bill Stewart <[email-masked]>
Subject: Re: KeyIDs and Key Fingerprints
Cc: [email-masked]
Sender: [email-masked]

>In <[email-masked]>, on 10/21/97 
>   at 08, [email-masked] (Lutz Donnerhacke) said:
>>I do not know how to deal with key ID attacks, birthday phenomena,
>>and user provided parts of the key/user ID without defining the 
>>key ID as not unique.

I strongly agree - especially if we provide support for short keyIDs
as well as the long ones.

At 04:38 AM 10/21/1997 -0500, William H. Geiger III wrote:
>Well the way I see it we have 2 possIbilities for duplicate keyID's:
>1) Collision. Does anyone know what the probability of 2 users generating
>2 unique keys with the same keyID?  If this number is high then perhaps we
>should look at either using the fingerprint in the PGP packets or
>providing additional info in the packets to provide uniqueness.

The number of keys required to probably have a birthday collision is about 
sqrt(2**keysize) - thus 32-bit keyids will generate a collision
by about 2**16 keys (and in fact there was at least one real collision.)
64-bit KeyIDs will generate a collision by around 4 billion keys,
which is small enough that any application generating lots of public keys
for some reason will risk the problem, especially if the keys
end up in public or on some persistent server rather than being 
used once and discarded.  128-bit keyids would be fine.

>2) DEliberate Attack.  We know of the common attacks aginst the keyID &
>Fingerprint with the PGP 2.6.x keys. Are the DSS/DH keys also open to such
>attacks? Is it realy wise to allow these keys to be added to the keyring
>in the first place or should the user when confronted with duplicate
>keyID's be required to take futher action? 

There are at least two deliberate attacks.  
The less useful one requires the Bad Guy to generate two keys with 
identical KeyIDs and find some workable scam that uses them.  
It's a birthday attack again, so you need >>64-bit KeyIDs to prevent it.  
In particular, if the recipient is a program rather than a human,
will it do something useful while waiting for some human
to come over and click an "Accept/Reject" box on some GUI?
Or will it fail in some ugly fashion?

The other attack is the 0xdeadbeef attack, which is probably easier
with DSA than with RSA, since you don't need to find lots of primes.  
A DSA signature uses a long prime p, a 160-bit prime q, and a 
generator g,  all public and optionally shared, and a private key x<q
and public key g**x mod p.   So you can take your target's p,q,g,
and start generating x, g**x mod p, at a cost of one modmult each.
(An easy approach is to let x = 1, 2, 3, ...., which just requires
multiplying by g each time.  If you find a value of g**x mod p 
that's small relative to p, you can probably go much faster by
multiplying by this instead of g, since you can shortcut around the 
mod p fairly often, though I don't know if this really saves you much 
in practice when you're trying a few billion keys.
It's probably more important just to find a short multiplier to
reduce the multiplication work.)

>I may be wide off on this one but it just seems to be a bad design
>approach to allow non-unique identifIers in the PGP packets and then try
>every key that matches it.

It's an inherent problem with using KeyIDs.
The only way to prevent the problem is to use identifiers long enough
that you can't deliberately or accidentally generate a collision,
which is almost the same as just using the fingerprint or key as KeyID;
the alternative is to do the right thing with collisions if they occur.
Defining "the right thing" is hard, so it's important to avoid building 
formats and GUIs that only show the user the KeyID.
				Thanks! 		Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639
[I'm currently having hardware problems with my main email; 
send Cc: [email-masked] if you need to reach me in a hurry.]

Date: Mon, 27 Oct 1997 09:53:27 -0600
To: Lindsay Mathieson <[email-masked]>, IETF OpenPGP <[email-masked]>
From: David Hayes <[email-masked]>
Subject: Re: GAK/CDR workarounds
Sender: [email-masked]

At 08:35 AM 10/27/97 GMT, Lindsay Mathieson wrote:
>PMJI, but to me, there seems to be a very simple fix for users, if they wish
>to prevent their messages being decrypted by third-parties.
>When replying with a GAK/CDR compliant applictaion, it would seem reasonably
>easy to encrypt the message twice, i.e. embed a standard PGP encrypted
>message inside a GAK/CDR encrypted message.

Yes, Lindsay, this does the job. It's called "superencryption". It is
difficult for any cryptosystem to stop this, because it's impossible to
predict what the user might select for the first, "inner" encryption. 

Of course, many likely encryption programs are known. If you choose
PGP-inside-GAK, the standard PGP headers are recognizable. While the
government will likely not be able to read your PGP-protected message, they
could know that it's there. Under the current proposal in [US] Senate bill
909, simply the existence of the PGP message would land you in prison. 

The trick is not to send messages that the adversary can't read, but to
send messages that the adversary can't _discover_. 

The government could know that the inner PGP message is there, if they
decode the outer GAK "wrapper". There are two ways they could learn this.
First, you could be the subject of an investigation. During the course of
this investigation, they present probable cause to a magistrate, obtain a
warrant, and decrypt your messages using your GAK key from their database.
The FBI promises me that they will always operate this way. 

The second method is that the government just routinely decrypt every
message, using some undocumented back door access to the GAK database. In
this case, they subsequently claim an "anonymous informant" tipped them
off, get a warrant, and  then legally open your message. "What's this,"
they ask? Why, an illegal PGP message! (Insert astonished look on faces of
government agents.) When they introduce the evidence at your summary trial,
they have a warrant to explain how they got the message in the first place. 

The opportunities for government corruption are staggering, which is one
reason many GAK opponents _are_ GAK opponents. Governments have never been
able to resist temptation for very long.

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

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: MUST versus SHOULD in application decisions
Date: 27 Oct 1997 16:26:36 GMT
Organization: IKS GmbH Jena
Lines: 11
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* William H. Geiger III wrote:
>>In this case it should be moved to chapter nine 'Security
>>Considerations'.
>
>Sounds great!
>
>There is a lot of stuff I could put in there that I would not feel
>comfortable putting in the RFC itself. :)

Fine. Let's wait for the big boss's decision of the editor we have these
requests to address to.

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 27 Oct 97 10:17:42 -0600
To: [email-masked] (Lutz Donnerhacke)
Cc: [email-masked]
Subject: Re: MUST versus SHOULD in application decisions
Sender: [email-masked]

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

In <[email-masked]>, on 10/27/97 
   at 04:07 PM, [email-masked] (Lutz Donnerhacke) said:

>* William H. Geiger III wrote:
>>must not provide to the user. If in the Appendix you wish to put
>>application recommendations that is fine but the wording as you have it
>>now is unacceptable.

>In this case it should be moved to chapter nine 'Security
>Considerations'.

Sounds great!

There is a lot of stuff I could put in there that I would not feel
comfortable putting in the RFC itself. :)

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

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

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: MUST versus SHOULD in application decisions
Date: 27 Oct 1997 16:07:28 GMT
Organization: IKS GmbH Jena
Lines: 8
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* William H. Geiger III wrote:
>must not provide to the user. If in the Appendix you wish to put
>application recommendations that is fine but the wording as you have it
>now is unacceptable.

In this case it should be moved to chapter nine 'Security Considerations'.

Thnx 4 ur comment.

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 27 Oct 97 09:34:04 -0600
To: [email-masked] (Lutz Donnerhacke)
Cc: [email-masked]
Subject: Re: MUST versus SHOULD in application decisions
Sender: [email-masked]

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

In <[email-masked]>, on 10/27/97 
   at 03:25 PM, [email-masked] (Lutz Donnerhacke) said:

>* Ian Grigg wrote:
>>I think this language is too strong.  When you are talking about
>>protocols, then the word "MUST" makes sense.  But when you are talking
>>about application decisions, there is the likelyhood of different ways
>>of thinking, and then we need to be more flexible.

>Yes, you are right. But not a all issues.

>>> 5.2.2 Signature packet
>>> [...Subpacket definitions...]
>>>   8 - key usage (REQUIRED)
>>      ...
>>>       Storage keys MUST NOT be used in communication. They SHOULD be droped
>>>       from keyrings outside the desired storage enviroment to avoid message
>>>       key recovery. They MUST NOT occur on public keyservers. If such a key
>>>       arrives over the Internet, a warning MUST be produced and the key MUST
>>>       be droped (prefered) or disabled locally.

>Storage keys MUST NOT be used in communication. They SHOULD be droped
>from keyrings outside the desired storage enviroment to avoid message key
>recovery. They SHOULD NOT occur on public keyservers. If such a key
>arrives over the Internet, a warning SHOULD be produced and the key MUST
>be droped (prefered) or disabled locally.

I MUST STRONGLY disagree here. This is a format RFC it should not be
dictating how that format is implemented. If I chose to have my app
default to using 1 RSA key pair it is above and beyond the scope of this
RFC to tell me otherwise let alone what information my application must or
must not provide to the user. If in the Appendix you wish to put
application recommendations that is fine but the wording as you have it
now is unacceptable.

>>>       Group keys for communication encryption may be set up by a company to
>>>       address encrypt company readable e-mail to. Software MUST produce a
>>>       warning, if a group key is used. Group keys are for encryption of
>>>       communication only. Keys combining an other purpose to a group key
>>>       MUST NOT be generated and MUST NOT be accepted.

>Group keys for communication encryption may be set up by a company to
>address encrypt company readable e-mail to. Software MUST produce a
>warning, if a group key is used. Group keys are for encryption of
>communication only. Keys combining an other purpose to a group key MUST
>NOT be generated and MUST NOT be accepted.

Once again you are taking the spec into territory it has no place being.

>>>       The same key usage subpacket MUST occur on every self-signature
>>>       certificate. If other user IDs specify a different key usage, the key
>>>       MUST be disabled.

>The same key usage subpacket MUST occur on every self-signature
>certificate. If other user IDs specify a different key usage, the key
>MUST be disabled.

Why?

>>  Firstly, to say anything about what goes on a public keyserver is
>>outside the scope of this standard (I think - correct if wrong).

>Keysserver are ontopic in this draft at chapter seven. It is needed to
>provide automatic requests. I do need descriptions on http, email, dns
>and lapd servers!

You need descriptions on how to interface with the servers using the
different network protocols not how the internals of those servers work.

>>  Second, by stating such policy decisions, we now have to add in these
>>decision choices to the software, elsewise "public keyservers" will not
>>be of much use for private purposes.

>Anti-GAK features implemented in software are the best results this draft
>can generate. If 70% of deployed software actively prevent snooping, it
>is impossible to build GAK systems.

>>  Thirdly, I might invent an application where I have some externally
>>accessible storage such as an Internet data store on the web, and I
>>might want to push the keys for that onto public servers.

>Put it on the right server: Your company's server. Storage keys are for
>your local enviroment only, arn't they?

Depends on the application. I think that you are being too e-mail centric
in your thinking and thus limiting the applicability of the spec.

>>  Fourthly, some of this language assumes a resolution to the CMR/CDR
>>debate, and that, being political, is not something that a standard
>>should try and influence.

>Sure? Think about deployment.

>>  Fifthly, a "MUST produce a warning" excludes many operational
>>scenarios:  scripts, batch jobs, experienced users, new applications,
>>....

>There is no part claiming: 'The user MUST read.'
>If we do not point out the security problems. Several implementations
>will hide them from users because clicking is easierer than thinking.

There is no place in the RFC for dictating how the application interfaces
with the user. I am unaware of any other RFC's that do so.

>>On a broader issue, I am very happy to see that the CMR packets have
>>been dropped from mention in the standard.

>They are still there. I choosed a form PGP Inc. can live with.

>>I think we have to be fair
>>and also not accept the CDR alternative for inclusion or mention in the
>>standard.

>There is a need for recovery on storage keys. Several people urged me to
>include shared secrets....

>>extent.  Also, there is plenty of mileage in what the standard is trying
>>to achieve - existing practice and formats - without getting into these
>>areas, which could presumably be codified as separate add-on RFCs if so
>>desired.

>Why not doing it now with two additional paragraphs?

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

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

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: GAK/CDR workarounds
Date: 27 Oct 1997 15:37:32 GMT
Organization: IKS GmbH Jena
Lines: 11
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Georg Josef Uphoff wrote:
>As far as I know, this is just the problem, because PGP 5.5 forces you to
>encrypt with your key and the corporate key. 

AFAI read the source correct, PGP 5.0 does the same despite all additional
keys are required.

>Or is it possible to work around the GAK as stated above ?

Yes. Exchange all installed versions of PGP 5.x. Good luck.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: MUST versus SHOULD in application decisions
Date: 27 Oct 1997 15:25:30 GMT
Organization: IKS GmbH Jena
Lines: 98
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Ian Grigg wrote:
>I think this language is too strong.  When you are talking about
>protocols, then the word "MUST" makes sense.  But when you are talking
>about application decisions, there is the likelyhood of different ways
>of thinking, and then we need to be more flexible.

Yes, you are right. But not a all issues.

>> 5.2.2 Signature packet
>> [...Subpacket definitions...]
>>   8 - key usage (REQUIRED)
>      ...
>>       Storage keys MUST NOT be used in communication. They SHOULD be droped
>>       from keyrings outside the desired storage enviroment to avoid message
>>       key recovery. They MUST NOT occur on public keyservers. If such a key
>>       arrives over the Internet, a warning MUST be produced and the key MUST
>>       be droped (prefered) or disabled locally.

Storage keys MUST NOT be used in communication. They SHOULD be droped from
keyrings outside the desired storage enviroment to avoid message key
recovery. They SHOULD NOT occur on public keyservers. If such a key arrives
over the Internet, a warning SHOULD be produced and the key MUST be droped
(prefered) or disabled locally.

>>       Group keys for communication encryption may be set up by a company to
>>       address encrypt company readable e-mail to. Software MUST produce a
>>       warning, if a group key is used. Group keys are for encryption of
>>       communication only. Keys combining an other purpose to a group key
>>       MUST NOT be generated and MUST NOT be accepted.

Group keys for communication encryption may be set up by a company to
address encrypt company readable e-mail to. Software MUST produce a warning,
if a group key is used. Group keys are for encryption of communication only.
Keys combining an other purpose to a group key MUST NOT be generated and
MUST NOT be accepted.

>>       The same key usage subpacket MUST occur on every self-signature
>>       certificate. If other user IDs specify a different key usage, the key
>>       MUST be disabled.

The same key usage subpacket MUST occur on every self-signature certificate.
If other user IDs specify a different key usage, the key MUST be disabled.

>  Firstly, to say anything about what goes on a public keyserver is
>outside the scope of this standard (I think - correct if wrong).

Keysserver are ontopic in this draft at chapter seven. It is needed to
provide automatic requests. I do need descriptions on http, email, dns and
lapd servers!

>  Second, by stating such policy decisions, we now have to add in these
>decision choices to the software, elsewise "public keyservers" will not
>be of much use for private purposes.

Anti-GAK features implemented in software are the best results this draft
can generate. If 70% of deployed software actively prevent snooping, it is
impossible to build GAK systems.

>  Thirdly, I might invent an application where I have some externally
>accessible storage such as an Internet data store on the web, and I
>might want to push the keys for that onto public servers.

Put it on the right server: Your company's server. Storage keys are for your
local enviroment only, arn't they?

>  Fourthly, some of this language assumes a resolution to the CMR/CDR
>debate, and that, being political, is not something that a standard
>should try and influence.

Sure? Think about deployment.

>  Fifthly, a "MUST produce a warning" excludes many operational
>scenarios:  scripts, batch jobs, experienced users, new applications,
>....

There is no part claiming: 'The user MUST read.'
If we do not point out the security problems. Several implementations will
hide them from users because clicking is easierer than thinking.

>On a broader issue, I am very happy to see that the CMR packets have
>been dropped from mention in the standard.

They are still there. I choosed a form PGP Inc. can live with.

>I think we have to be fair
>and also not accept the CDR alternative for inclusion or mention in the
>standard.

There is a need for recovery on storage keys. Several people urged me to
include shared secrets....

>extent.  Also, there is plenty of mileage in what the standard is trying
>to achieve - existing practice and formats - without getting into these
>areas, which could presumably be codified as separate add-on RFCs if so
>desired.

Why not doing it now with two additional paragraphs?

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: CfV: Packet <-> Elements
Date: 27 Oct 1997 15:11:18 GMT
Organization: IKS GmbH Jena
Lines: 7
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* John  W. Noerenberg wrote:
>There are more substantive issues to address than whether we continue with
>"packets" or adopt some new term for protocol data units.

Yes, so let's vote and forget the discussion. Making a ballot is the fastest
way to switch to a new topic. A ballot can be used for every non important
issuse. I'm not interested in the result. I can live with both results.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Differing algortithms in chains
Date: 27 Oct 1997 15:08:12 GMT
Organization: IKS GmbH Jena
Lines: 5
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Pat Richard wrote:
>Has there been much discussion addressing the issues regarding differing
>ciphersuites/signature algorithms contained in certificate chains ?

No. Why?

Date: Mon, 27 Oct 1997 14:42:07 +0100
To: [email-masked]
From: Georg Josef Uphoff <[email-masked]>
Subject: Re: GAK/CDR workarounds
Sender: [email-masked]

At 08:35 27.10.97 +0000,  Lindsay Mathieson wrote:
>PMJI, but to me, there seems to be a very simple fix for users, if they wish
>to prevent their messages being decrypted by third-parties.
>
>When replying with a GAK/CDR compliant applictaion, it would seem reasonably
>easy to encrypt the message twice, i.e. embed a standard PGP encrypted
>message inside a GAK/CDR encrypted message. Your recipent can decrypt it
>with their private key, while the thirdy party receives a standard PGP
>encrypted message.
>

As far as I know, this is just the problem, because PGP 5.5 forces you to
encrypt with your key and the corporate key. 

Or is it possible to work around the GAK as stated above ?

If it is, would not future GAK-encryption software deny encryption of
preencrypted messages ? Or even worse demand messages to be send in special
formats which can not be altered or mailing would be denied altogether.

Regards,

George

Date: 27 Oct 1997 8:35:21 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: GAK/CDR workarounds
To: IETF OpenPGP <[email-masked]>
Sender: [email-masked]

PMJI, but to me, there seems to be a very simple fix for users, if they wish
to prevent their messages being decrypted by third-parties.

When replying with a GAK/CDR compliant applictaion, it would seem reasonably
easy to encrypt the message twice, i.e. embed a standard PGP encrypted
message inside a GAK/CDR encrypted message. Your recipent can decrypt it
with their private key, while the thirdy party receives a standard PGP
encrypted message.

--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Release Vs 2.6.1.1, on October 27, 1997, in Win95
4.0
	http://www.blackpaw.com/

Date: Sun, 26 Oct 1997 19:50:09 -0500
From: "Timothy Glenn Stockstill" <[email-masked]>
Organization: Stockstill
To: Dave Crocker / IMC <[email-masked]>, [email-masked]
Subject: Re: Armor versus MIME versus binary
Sender: [email-masked]

Dave Crocker / IMC wrote:

> At 02:52 AM, Peter Gutmann wrote:
> >>>see no reason for changing this now. I see little chance of a PGP "packet"
> >>>and a network "packet" being confused for one or another as we are
>
> I find the usage constantly confusing,

I don't find the use of the term "packet"
confusing as long as you are aware of the
context for which it is used within the
scope of the documentation.

After monitoring this list for about a week
I have found a surprising number of messages
relating to this subject.  Our corporation
publishes about 20 specifications a week
relating to our payroll product.  Within
theses specifications the same term will often
be used for different aspects of the system.
This is because it may be the most appropriate
term to describe what the document is trying
to convey.  Therefore as a preamble to most of
our specifications we provide a list of
definitions.  A simple listing of terms as
and their definitions they apply to the scope
of the document.  This list only includes
terms whose meaning could be confused with
another popular meaning for the same term.
Common terms which are used within the context
which the average developer would expect them
to be used are not included in the definitions
section.  If the same term needs to represent
several meanings within the scope of the
same document, the definition is generally the
one for which the term is most frequently used.
Other occurrences of the same term for a different
meaning would explicitly define the meaning of
the term within the scope of that section.

For example, if within a document I needed
to use the term "packet" with regards to
PGP and Network Protocols.  I may define
the term "packet" as it relates to PGP
in the definitions section of the document,
but describe a Network Packet as (TCP Packet,
IP Packet, Internet Packet, or Network Packet).
The reader therefor knows that I am not
using the term packet as it relates to PGP
in that particular section of the document.

I think with the amount of discussion
that has already been done on this, I
could never confuse the term packet with
an Internet Packet within the scope of
this document.  Readers of the
specification would not confuse the term
if a simple definitions preceded the use
of the term.

--
Timothy Glenn Stockstill
The Ultimate Software Group
mailto:[email-masked]

Date: Sun, 26 Oct 1997 13:06:35 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: [email-masked]
Subject: MUST versus SHOULD in application decisions
Sender: [email-masked]

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

> 5.2.2 Signature packet
> [...Subpacket definitions...]
>   8 - key usage (REQUIRED)
      ...
>       Storage keys MUST NOT be used in communication. They SHOULD be droped
>       from keyrings outside the desired storage enviroment to avoid message
>       key recovery. They MUST NOT occur on public keyservers. If such a key
>       arrives over the Internet, a warning MUST be produced and the key MUST
>       be droped (prefered) or disabled locally.
> 
>       Group keys for communication encryption may be set up by a company to
>       address encrypt company readable e-mail to. Software MUST produce a
>       warning, if a group key is used. Group keys are for encryption of
>       communication only. Keys combining an other purpose to a group key
>       MUST NOT be generated and MUST NOT be accepted.
> 
>       The same key usage subpacket MUST occur on every self-signature
>       certificate. If other user IDs specify a different key usage, the key
>       MUST be disabled.

I think this language is too strong.  When you are talking about
protocols, then the word "MUST" makes sense.  But when you are talking
about application decisions, there is the likelyhood of different ways
of thinking, and then we need to be more flexible.

For example, to say that "They MUST NOT occur on public keyservers" is
too constraining.

  Firstly, to say anything about what goes on a public keyserver is
outside the scope of this standard (I think - correct if wrong).

  Second, by stating such policy decisions, we now have to add in these
decision choices to the software, elsewise "public keyservers" will not
be of much use for private purposes.

  Thirdly, I might invent an application where I have some externally
accessible storage such as an Internet data store on the web, and I
might want to push the keys for that onto public servers.  I'm
hypothesizing here;  one thing I have learnt is that you should never
constrain the future generation from using your inventions in ways you
yourself didn't have the capability to grasp.  Likewise, don't try to
constrain the programmer's mindset with rules.

  Fourthly, some of this language assumes a resolution to the CMR/CDR
debate, and that, being political, is not something that a standard
should try and influence.

  Fifthly, a "MUST produce a warning" excludes many operational
scenarios:  scripts, batch jobs, experienced users, new applications,
....

Where application decisions (and politics) are concerned, I would hope
to see the strongest terms limited to "SHOULD do" rather than "MUST
do."  Then it can be considered expert advice, not protocol law.

On a broader issue, I am very happy to see that the CMR packets have
been dropped from mention in the standard.  I think we have to be fair
and also not accept the CDR alternative for inclusion or mention in the
standard.  Both of these proposals are still too young to be
incorporated in the base standard, both remain undeployed to any
extent.  Also, there is plenty of mileage in what the standard is trying
to achieve - existing practice and formats - without getting into these
areas, which could presumably be codified as separate add-on RFCs if so
desired.
- -- 
iang                                      systemics.com

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

Date: Sun, 26 Oct 1997 07:53:37 -0500
To: [email-masked]
From: Robert Hettinga <[email-masked]>
Subject: Orthogonality and Disaster Recovery
Sender: [email-masked]

--- begin forwarded text

X-Sender: [email-masked]
Mime-Version: 1.0
Date: Sat, 25 Oct 1997 13:52:05 -0700
To: [email-masked]
From: Tim May <[email-masked]>
Subject: Orthogonality and Disaster Recovery
Sender: [email-masked]
Precedence: bulk
Reply-To: Tim May <[email-masked]>
X-Loop: [email-masked]

One of the themes of modern computing I strongly support is that of
"orthogonality," or clean functionality. A browser should not also try to
be a money management program. A word processor should not also try to be
an accounting program.

Failure to observe this rule of thumb has led to spreadsheets which can run
MPEG movies in spreadsheet cells (I'm not kidding), and to Web browsers
which take 20 MB of free memory to run reliably because they also contain
mediocre news readers, mediocre mailers, and lots of bloatware cruft.

The move toward modular decomposition is supported in functional and
object-oriented languages (like Java and C++) and in modern operating
systems. Much of the strenght of Unix has obviously come from the
philosophy that a function or utility should do some small set of things
well and cleanly, with chaining of these clean tools to accomplish more
complicated tasks.

A crypto program like PGP is intended to encrypt messages between a sender
and a recipient, or to provide authentication through signatures, or to
encrypt files on a storage medium. These are the classic, well-documented,
oft-discussed functions of crypto. Look in textbooks under "crypto" and
there won't be much talk of how to supply MIS with emergency backdoors, or
ways to monitor employees.

If properly modularized and orthogonalized (so to speak), such crypto
programs can then be used as building blocks for other tasks, like
remailers, data havens, and so on.

But there is a growing tendency, as seen in the bloatware examples of
browsers and spreadsheets mentioned above, to throw in all kinds of "wish
list" and "wouldn't it be nice" stuff. PGP is headed for bloatware. ("It's
not just a crypto program, it's also a tax preparation  and disaster
planning program!")

I'm quite certain that the Security and MIS directors at various companies
asked PGP, Inc. to include message recovery features. Not so much to handle
the very rare (almost nonexistent) cases where a piece of mail sent at some
time in the past has to be recovered because Alice was hit by a truck, or
similiar unlikely events (*), but because Security and MIS folks would like
the option of "monitoring" e-mail traffic.

(* I have heard no plausible scenarios under which transient
communications, which are presumably stored in the form composed
(plaintext) on the sender's machine or in the for received and read (also
in plaintext) on the receiver's machine, need to be recovered from the
*transit* state. We know why the FBI wants access to communications
keys--because access to the transit state is what they get when they
wiretap or sniff a communications line--but there is no plausbile
explanation of why a company would not simply ask Alice for the plaintext,
or ask Bob if for some reason Alice is unavailable. The idea someone
floated, that he needs to go in and decrypt his employee's mail in
emergencies is far-fetched.)

But are such bloatware crypto programs even good for disaster recovery? I
say they are not. I say e-mail will be a tiny, tiny portion of the recovery
strategy if Alice gets hit by a truck, for example. Far more important will
be recovery of her hard disk and related files.

(No, I am _not_ proposing anything be added to PGP to deal with this
disaster planning. Nor am I proposing that PGP enforce plaintext storage,
or anything else for that matter. These are all matters _orthogonal_ to the
basic function of a crypto program, and a crypto program cannot enforce
crypto hygiene any more than a spreadsheet can enforce good tax planning
hygiene.)

I am also not terribly interested in convoluted, byzantine schemes for
building "CDR" and such into crypto programs, as some are proposing. Again,
this is trying to make a crypto program into a disaster preparation
product, and trying to (partly) solve backup and disaster problems best
solved in other ways. Not something PGP should worry about (either the
program or the company).

"What if Alice forgets her key?" (Loses her private key, forgets her
passphrase, whatever.)  A very real concern. A concern I have myself. I
won't say how I deal with it, for security reasons, but it ain't something
I expect PGP, Inc. to solve _for_ me. Nor is my solution, whatever it is, a
step toward GAKking of keys, or any kind of building of an infrastructure
for surveillance.

In fact, this was my point a while back about how a diversity of approaches
to disaster planning, to key insurance measures, makes the imposition of
mandatory key escrow or Government Message Recovery (GMR) very difficult.
The very chaos helps. "Let a thousand flowers bloom."

And it turns out that the "what if Alice forgets her key?" scenario is very
poorly dealt with by PGP 5.5 (unless the corporation actually _does_  keeps
a copy of the private key generated for or by Alice...something supporters
of CMR says is not the case. Whether it _can_ or _will_ be the case is
another issue.)

So, disaster planning, for dealing with crashed disks, dead employees,
malicious employees (who, for example, encrypt their disks and then leave
the company), and general failures to backup work product, etc., these
examples of disaster planning issues are NOT dealt with in any important
way by PGP 5.5. Nor should any communications security program try to be
this kind program.

Keep it simple, stupid. This kind of bloatware is a fig leaf for security,
and very probably introduces major new  security flaws. (I've discussed at
length the issues of just who will be reading the CMR messages. It's very
unlikely such CMR messages will simply be archived away for that rare day
when someone's old messages need to be "recovered" for the reasons usually
given...in fact, as I have been arguing, I can't imagine companies even
bothering to get some transient piece of e-mail sent 2 years earlier by
Alice to Bob. They don't archive phone calls, and these are every bit as
likely to be "critical" in some sense as old e-mail messages are.)

As this relates to PGP, it just ain't their problem to try to answer the
demands of control freaks in corporate MIS departments that backdoors be
built into crypto products.

(Call it snoopware, call it surveillance software, call it CMR. But what it
really is a backdoor built into a crypto system. And one thing we know from
several decades of crypto work is that backdoors are holes in security.
Given that these backdoors apparently have little use in any real disaster
situations, they represent a serious dilution of security for little or
nothing gained.)

PGP, Inc. should stick to its core business, and not try to build in
snoopware backdoors for control freak MIS managers.

If it is claimed that corporate America is demanding these backdoors, our
industry and community then faces a major educational battle.

If this battle is lost, as it may already be, then the same reasons for
corporations to insist on "emergency access" (which of course won't be very
"emergency" oriented, as actually used in corporations) will be seen by
many to apply to government as well. "What have you got to hide?"

Keep it simple, stupid. That makes for efficiency, functionality, and
easier product development. And it doesn't build the case for government to
later demand message recovery.

--Tim May

The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

--- end forwarded text

-----------------
Robert Hettinga ([email-masked]), Philodox
e$, 44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
The e$ Home Page: http://www.shipwright.com/
Ask me about FC98 in Anguilla!: <http://www.fc98.ai/>

Date: Sat, 25 Oct 1997 16:46:55 +0000
To: [email-masked]
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: Armor versus MIME versus binary
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 02:52 AM, Peter Gutmann wrote:
>>>see no reason for changing this now. I see little chance of a PGP "packet"
>>>and a network "packet" being confused for one or another as we are

I find the usage constantly confusing, espcially when trying to introduce
people to PGP.  It is an extremely unfortunate vocabulary choice, since it
takes an entrenched term from an entirely different part of the profession
and uses with a different meaning.  I've yet to understand why a more
typical term, like "record" or "segment" (yes, segment is used in datacom,
too, but it is more esoteric and therefore less confusing) or "block" or...

A minor point to consider, when pursuing standardization of an existing
technology, is what changes will improve the pedagogical aspects of the
specification.  Aligning language to fit more naturally in with normal
discourse is one such opportunity.

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: Ben Escoto <[email-masked]>
To: [email-masked]
Subject: Announce: Mapil v0.1 PGP/MIME interface
Date: Sat, 25 Oct 1997 09:16:22 -0700
Sender: [email-masked]

--=_Mapil-0.1_2814162

	Mapil is a script written in Python that supports the PGP/MIME
interface for signing and encrypting MIME messages on a unix system.
When a message should be encrypted, decrypted, signed, or verified,
Mapil will call PGP on the appropriate data and put the output into
the correct format.

	Mapil is fully PGP/MIME compliant, and supports PGP 5.0 and
2.6.  It can be run interactively or in batchmode, and its behavior is
very flexible, modified through an rc file or command line options.
It also supports a "policies" file so users can specify that mail to
certain users should be encrypted, to others it should be signed, etc.

	For more information or to download, see the Mapil home page:
http://www-leland.stanford.edu/~bescoto/mapil

The following is from the Changelog and describes what is new in 0.1.

Changes from 0.0 to 0.1
-----------------------

Support for PGP 5.0.  Not as good as support for 2.6, but the output
of PGP 5.0 is not as good as 2.6.  With this addition Mapil is 100%
P/MIME compatible as of the latest draft.

Depending on the verbosity, some of the configuration options will be
displayed before the message is processed, and the user may change any
of the options.  The prompt can be disabled through the 'Confirm'
option in the mapilrc file or the --confirm command line option.

Added mapil-mbox in generic directory.  It can run mapil on an
arbitrary message in a Berkeley format mailbox file.

mhmapil script moves xx.mapil back to xx if xx not produced by mapil.

Configuration file can be specified through MAPILRC environment
variable.

Hal Devore <[email-masked]> has contributed some exmh code allowing
user to run mapil on current message and more exmh information was
added.

Changed Mapil behavior so it preserves a 'From ' line if it is the
first line of a message.

The / and ~ characters can no longer be used for quoting, but they can
start a non-quoted field in config or policies file.

In the config file, if a ~ is found at the beginning of the
Policiesfilename, Backupfilename, TempDir, or PGPDirectory options, it
will be expanded to $HOME.

The MH message separator '--------' (8 dashes) on an otherwise empty
line is now accepted as a separator.

The options list in the mapilrc man page was alphabetized.

Mapil will now exit gracefully if users choose Q at menus or prompts.

Check to see if too many arguments given to certain options in
mapilrc.

--
Ben Escoto
PGP/MIME mail welcome - finger [email-masked] for key

--=_Mapil-0.1_2814162
Content-Type: application/pgp-signature

--=_Mapil-0.1_2814162--

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Armor versus MIME versus binary
Cc: [email-masked]
Reply-To: [email-masked]
Date: Sun, 26 Oct 1997 01:52:52 (NZDT)
Sender: [email-masked]

John  Noerenberg <[email-masked]> writes:
>At 3:45 AM -0500 10/24/97, William H. Geiger III wrote:
>>>The term "packet" is used by the Ascii Armor and well known to the
>>>public. Should we exchange it?
>>The term "packet" is a well known and well defined in the PGP comunity. I
>>see no reason for changing this now. I see little chance of a PGP "packet"
>>and a network "packet" being confused for one or another as we are
>>describing document formats here not network protocols.
>My feelings exactly.   We've been talking about PGP "packets" since PGP 1.0
>6+ years ago.  The meaning and context are clear.
 
The term has existed for even longer than that, Phil wrote an IEEE Computer 
article in 1986 which presented what eventually became the PGP format (with a 
few changes), so it's been around for at least 11 years.  You could even use 
the article as a reference if necessary.
 
Peter.

Date: Fri, 24 Oct 1997 17:55:00 -0700
To: "William H. Geiger III" <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: Armor versus MIME versus binary
Cc: [email-masked] (Lutz Donnerhacke), [email-masked]
Sender: [email-masked]

At 3:45 AM -0500 10/24/97, William H. Geiger III wrote:
>
>>The term "packet" is used by the Ascii Armor and well known to the
>>public. Should we exchange it?
>
>The term "packet" is a well known and well defined in the PGP comunity. I
>see no reason for changing this now. I see little chance of a PGP "packet"
>and a network "packet" being confused for one or another as we are
>describing document formats here not network protocols.
>

My feelings exactly.   We've been talking about PGP "packets" since PGP 1.0
6+ years ago.  The meaning and context are clear.

john  w noerenberg, ii
[email-masked]
pager: [email-masked]
 --------------------------------------------------------------------
  "A beautiful idea has a much greater chance of being a correct idea
   than an ugly one."
 -- Roger Penrose, "The Emperor's New Mind", 1989
 --------------------------------------------------------------------

Date: Sat, 25 Oct 1997 00:44:47 -0700
To: [email-masked] (Lutz Donnerhacke)
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: CfV: Packet <-> Elements
Cc: [email-masked]
Sender: [email-masked]

At 8:35 AM +0000 10/24/97, Lutz Donnerhacke wrote:
>
>Please fill out the following form and reply it to <[email-masked]> till
>1997-10-30-23-59-59 UTC. Everybody on this list (sic!) may send a message. I
>will collect them and will send out the summary containing the name, the
>vote, and the e-mail of each voter after the ballot finished.

Ah...time out, here <putting on the chairman's hat>.

While it is possible a straw poll on this issue could be informative, it is
equally likely to be misleading.  That's part of the reason the IETF
doesn't encourage them.  Good engineering decisions are rarely a matter of
voting.

Lutz, I'm sure your offer to tabulate a vote is genuinely made and
sincerely offered, but it is not required for this debate at this time.
Perhaps I will have occasion to ask you to do something like this in the
future.

There are more substantive issues to address than whether we continue with
"packets" or adopt some new term for protocol data units.

For now, I'm perfectly satisfied with the historical term "packets".
They've been in use for a long time without causing any undue confusion
with networking protocols that I can see.

Let's move on to something else.

<taking off the chairman's hat>

john  w noerenberg, ii
[email-masked]
pager: [email-masked]
 --------------------------------------------------------------------
  "A beautiful idea has a much greater chance of being a correct idea
   than an ugly one."
 -- Roger Penrose, "The Emperor's New Mind", 1989
 --------------------------------------------------------------------

Date: Fri, 24 Oct 1997 20:54:25 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: draft editor(s)
Sender: [email-masked]

John Noerenberg <[email-masked]> writes:
> At 2:07 PM +0000 10/23/97, William Allen Simpson wrote:
> >I suggest that this is not the correct approach.  Multi-editor documents
> >have a problematic history in the IETF.
> 
> This the only dissenting voice I've heard.   I'll take that to mean the
> consensus of the group is to proceed as I've outlined.

Lutz seems to be doing fine.

> Jon, Lutz and Rod will collaborate on a new draft that will combine
> the work they have individually done.  That will be the basis for
> the review by the group.

Sounds reasonable.

> However, there is existing material that is relevant.  And Jon is in
> the best position to combine it all together.  So that is what needs
> to happen now.  And as soon as possible.

Anything to expedite a OpenPGP version with minimal political
arguments.  The quicker OpenPGP happens the better.  KISS as Tim May
said, and lets see a finalised draft ASAP.

I think Jon is off work until next Tuesday, so I'd suggest letting Lutz 
get on with it.  Might be finished by the time he gets back, at the rate
Lutz is going :-)

Adam

Date: Fri, 24 Oct 1997 14:03:35 -0700
From: Pat Richard <[email-masked]>
To: [email-masked]
Subject: Differing algortithms in chains
Sender: [email-masked]

Has there been much discussion addressing the issues regarding differing
ciphersuites/signature algorithms contained in certificate chains ?

Date: Fri, 24 Oct 1997 11:43:09 -0700
To: "William Allen Simpson" <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: draft editor(s)
Cc: [email-masked]
Sender: [email-masked]

At 2:07 PM +0000 10/23/97, William Allen Simpson wrote:
>> From: "John  W. Noerenberg" <[email-masked]>
>>
>> Lutz's work mirrors some of the work that Jon Callas and Rod Thayer have
>> also done.  I've asked the three of them to collaborate on a single version
>> of this document to be submitted as an Internet-Draft.
>>...
>> Is everybody with me so far?
>>
>I suggest that this is not the correct approach.  Multi-editor documents
>have a problematic history in the IETF.

This the only dissenting voice I've heard.   I'll take that to mean the
consensus of the group is to proceed as I've outlined.

Jon, Lutz and Rod will collaborate on a new draft that will combine the
work they have individually done.  That will be the basis for the review by
the group.

Bill you are probably not aware of the packet format draft that Jon
submitted last July.  Few were.  Due to a series of bureaucratic snafus
which are no longer important, the draft never made it to the I-D directory.

However, there is existing material that is relevant.  And Jon is in the
best position to combine it all together.  So that is what needs to happen
now.  And as soon as possible.

I'll talk this over with the 3 of them to make sure the mailing list will
soon have a draft that combines all of their work for you to review.

Thanks.

john  w noerenberg, ii
[email-masked]
pager: [email-masked]
 --------------------------------------------------------------------
  "A beautiful idea has a much greater chance of being a correct idea
   than an ugly one."
 -- Roger Penrose, "The Emperor's New Mind", 1989
 --------------------------------------------------------------------

Date: Fri, 24 Oct 1997 14:24:39 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: secret sharing (Re: CDR design document)
Sender: [email-masked]

Jon Wienke <[email-masked]> writes:
> At 10:55 PM 2/21/97 GMT, Adam Back wrote:
> >
> >Here is a proposal for consideration for inclusion in the OpenPGP
> >standard:
> >
> >	http://www.dcs.ex.ac.uk/~aba/cdr/
> 
> Great work, Adam!  Pursuant to some of the recent rants on cypherpunks, I
> would like to see a proposal for a secret sharing mechanism that would
> allow the recovery of a storage-only key with m of n shares in the event
> that the passphrase to the storage key is unavailable, with the following
> attributes:

I think PGP Inc are considering secret sharing for later versions.
Perhaps it is too much for this iteration?

Secret sharing is nice, I agree, but can be complex too: what if it's
3 of 5, and one of the 5 leaves to join a competitor, can you
redistribute the share without creating a new key without losing
security?  What new packets would be required, etc.

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: "Tom Phinney" <[email-masked]>
To: <[email-masked]>
Subject: Re: Armor versus MIME versus binary
Date: Fri, 24 Oct 1997 08:24:03 -0000
Sender: [email-masked]

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

In <[email-masked]>, at 0145 on 97.10.24, William H.
Geiger III <[email-masked]> wrote:

> The term "packet" is a well known and well defined in the PGP comunity. I
> see no reason for changing this now. I see little chance of a PGP "packet"
> and a network "packet" being confused for one or another as we are
> describing document formats here not network protocols.

This position is understandable as long as PGP stays in its own little
world.  But IETF adoption now brings PGP into the much larger world of
networking, where the term "packet" is already overloaded and frequently
misused.  

The standard connotation of "packet" (and yes, the word has a specific
meaning in the ISO/IEC/CCITT standards community) and the commonly-accepted
overloaded use both refer to separately-transmittable messages containing
addressing and control information.  This is not the case for the PGP
message components, which are more correctly called message "elements".

The term "packet" is supposed to refer to an OSI layer three (network layer)
protocol data unit (message).  It has sometimes been misused to refer to a
layer two (data link layer) protocol data unit, where the proper term is
"frame"; this confusion was promulgated by the original Ethernet Blue Book
specs in 1980, which referred to Ethernet frames as packets.  

Whatever the scope, the term "packet" refers to a concept within the
communications layers (layers one to four), and not within the layers which
provide service enhancements (layers five to seven).  PGP clearly belongs to
this latter category (probably layer six, the presentation layer), where the
communications layer term "packet' is, has been, and remains, inappropriate.

Tom Phinney
IEEE 802, ISO and IEC standards contributor and sometimes editor
____
PGP: pub 1024 RSA:0xFA7148F1 DSS/EG:0x8A297007 on keyservers
Fingerprints: RSA: 2A85 3644 B773 3859  DA00 E429 4F79 840D
 DSS/EG: 9CE1 9906 1760 970B 6211  9D85 8B56 C548 8A29 7007

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Armor versus MIME versus binary
Date: 24 Oct 1997 13:41:56 GMT
Organization: IKS GmbH Jena
Lines: 7
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Lutz Donnerhacke wrote:
>But your comment is correct. I will move the 3.2 description to the
>beginning of 5 to support layering.

No, I'll not do this. There is a difference between "3.2 General framwork"
and "5. Packet Types". Sorry for the confusion.

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 24 Oct 97 03:45:14 -0500
To: [email-masked] (Lutz Donnerhacke)
Cc: [email-masked]
Subject: Re: Armor versus MIME versus binary
Sender: [email-masked]

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

In <[email-masked]>, on 10/24/97 
   at 08:24 AM, [email-masked] (Lutz Donnerhacke) said:

>* William Allen Simpson wrote:
>>I just caught up on the armor argument, and suggest that ASCII armor and
>>MIME are presentation issues, not message element issues.
>>
>>Therefore, they should be in separate documents from the binary message
>>elements.  A MIME conformant implementation will not necessarily
>>implement Armor, and vice versa.

>MIME encording is currently and will be seperated.  IMHO Ascii Armor
>should not be seperated, because it should not be used as independend
>layer for messages. Yes, it may contain a literal packet, but it can not
>contain a complete other level seven content.

>But your comment is correct. I will move the 3.2 description to the
>beginning of 5 to support layering.

>>Note to the editor, could you please standardize on the term "element"
>>or "message element" instead of "packet".  A packet has a well-known
>>networking definition.

>Currently this draft defines: "The octet stream of a PGP message is
>seperated into a several chunks. They are called packets."

>The term "packet" is used by the Ascii Armor and well known to the
>public. Should we exchange it?

The term "packet" is a well known and well defined in the PGP comunity. I
see no reason for changing this now. I see little chance of a PGP "packet"
and a network "packet" being confused for one or another as we are
describing document formats here not network protocols.

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

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

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: CfV: Packet <-> Elements
Date: 24 Oct 1997 08:35:36 GMT
Organization: IKS GmbH Jena
Lines: 25
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

As suggested in this ML, the term 'packet' for the several chunks a octet
stream is seperated into may be exchanged by the term 'element'.

'packet' is used by current implementations of PGP and in the ascii armor.
'packet' is used by the network layer. This may result in confusion.

Please fill out the following form and reply it to <[email-masked]> till
1997-10-30-23-59-59 UTC. Everybody on this list (sic!) may send a message. I
will collect them and will send out the summary containing the name, the
vote, and the e-mail of each voter after the ballot finished.

You can choose:
  YES     - This is the solution to choose.
  NO      - This is the solution to avoid.
  ABSTAIN - I don't know. No such strong preferences.

The proposal winning the best Yes/No ratio will win. If there is no
difference in the ratio, most Yes votes will win.

---------------------------cut here------------------------
  [YES NO ABSTAIN] packet
  [YES NO ABSTAIN] element
---------------------------cut here------------------------

Thank you.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Armor versus MIME versus binary
Date: 24 Oct 1997 08:24:10 GMT
Organization: IKS GmbH Jena
Lines: 25
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* William Allen Simpson wrote:
>I just caught up on the armor argument, and suggest that ASCII armor and
>MIME are presentation issues, not message element issues.
>
>Therefore, they should be in separate documents from the binary message
>elements.  A MIME conformant implementation will not necessarily
>implement Armor, and vice versa.

MIME encording is currently and will be seperated.  IMHO Ascii Armor should
not be seperated, because it should not be used as independend layer for
messages. Yes, it may contain a literal packet, but it can not contain a
complete other level seven content.

But your comment is correct. I will move the 3.2 description to the
beginning of 5 to support layering.

>Note to the editor, could you please standardize on the term "element"
>or "message element" instead of "packet".  A packet has a well-known
>networking definition.

Currently this draft defines: "The octet stream of a PGP message is
seperated into a several chunks. They are called packets."

The term "packet" is used by the Ascii Armor and well known to the public.
Should we exchange it?

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: draft editor(s)
Date: 23 Oct 1997 17:11:19 GMT
Organization: IKS GmbH Jena
Lines: 42
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* William Allen Simpson wrote:
>I recommend any of Callas and Thayer's useful work be incorporated in
>the new document, and that they be given second and third author credit,
>but that all editting be done by Lutz.  No diffusion of responsibility.
>Them that does the work gets the credit.

Thank you. I'll do my best. In any case some of my current tasks ge be
lifted soon. So I have more time. Next issue is to reimplement it as (L)GPL
reference implementation (that's what I'm paid for) and test it against
existing messages.

BTW some changes:

ftp://ftp.iks-jena.de/pub/mitarb/lutz/crypt/software/pgp/
                                    draft-ietf-pgp-formats.current.txt

23.10.1997
  * Armor header bug fixed.

22.10.1997
  * Clarification of sel-certificates.
  * Key expiration changed user ID expiration.
  * Key usage clarification.
  * Digests written as words.
  * MAY, SHOULD, MUST classification for every item.

21.10.1997
  * Fingerprint derivated from public key format.
  * Major extentions to signature subpackets (several new types).
  * Signature subpacket derivated from general packet framework.
  * Consequently use octet instead of byte.
  * Secret key is derivated from public key.
  * Added algorith identifiers 2 (RSA encr) and 3 (RSA sign).
  * Backward compatibility derivated from packet version of public key.
  * Started different trust models used by PGP 5.x. New trust packet.

21.10.1997
  * Corrections on Ascii Armor.
  * Armor header 'Version' defined to current use.

19.10.1997
  * published fist version of the draft completely rewritten from fragments.

Date: Thu, 23 Oct 1997 09:57:11 -0700
To: "William H. Geiger III" <[email-masked]>, [email-masked]
From: Tim May <[email-masked]>
Subject: Re: What RSA & Netscape have to offer
Cc: [email-masked]
Sender: [email-masked]

At 1:19 AM -0700 10/23/97, William H. Geiger III wrote:

>While the list is busy knocking PGP for not doing the "right thing" or
>being the "first ones to blink" I though I would share with the list what
>some of the "big boys" are doing for the spread of "Strong Crypto to the
>Masses". Below is from the most current S/MIME draft
>"draft-dusse-smime-msg-05" dated 19-Oct-1997:
...
>I think that when taking pot-shots at PGP, Inc. and Phil Zimmerman one
>should look at what the alternatives are and who are really are friends
>here. IMNSHO companies like RSA, Netscape, Microsoft, Verisign, et al, who
>would sell us all out if it improved their bottom lines do not qualify.

The consistent theme of the Cyphepunks contributors, modulo the noise and
insults and general fun over the past 5 years, has been to call a spade a
spade.

That is, regardless of what the alternatives may be, we call them as we see
them.

Weaknesses are weaknesses. Science dictates what we say.

"But Bad Option B is even worse than Bad Option A, so we should support Bad
Option A" is not very compelling to most of us.

That other companies may also be preparting GAK or GMR or deliberately
weakened ciphers is hardly news. Big Brother is leaning on companies in
many ways, ranging from threats of lawsuits, to antitrust actions, to
denial of export permits, to dangling lucrative contracts.

And the alternatives, for us as users, are not necessarily PGP for Business
5.5 vs. Netscape for Security Departments vs. Internet Explorer for
Fascists. No, the alternatives are to continue using ciphers with strong
cores and long keys.

--Tim May

The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: ASN.1 packet?
Date: 23 Oct 1997 16:13:11 GMT
Organization: IKS GmbH Jena
Lines: 11
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* William Allen Simpson wrote:
>> From: [email-masked] (Lutz Donnerhacke)
>> Shall we introduce an X.509 frame in packet version 3 and 4?
>>   "Content of this packet is a type octet determining the PKCS version,
>>    followed by the ASN.1 encoded PKCS octet stream."

>We should eliminate all references to ASN.1 in the document.  Where
>ASN.1 strings are used, they should be documented as binary values,
>without mentioning ASN.1.

Not possible. You have to know how to implement a new hash algorithm.

Date: Thu, 23 Oct 97 14:13:23 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: Re: ASN.1 packet?
Sender: [email-masked]

> From: [email-masked] (Lutz Donnerhacke)
> Shall we introduce an X.509 frame in packet version 3 and 4?
>   "Content of this packet is a type octet determining the PKCS version,
>    followed by the ASN.1 encoded PKCS octet stream."
>
We should eliminate all references to ASN.1 in the document.  Where
ASN.1 strings are used, they should be documented as binary values,
without mentioning ASN.1.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Date: Thu, 23 Oct 97 14:15:14 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: Armor versus MIME versus binary
Sender: [email-masked]

I just caught up on the armor argument, and suggest that ASCII armor and
MIME are presentation issues, not message element issues.

Therefore, they should be in separate documents from the binary message
elements.  A MIME conformant implementation will not necessarily
implement Armor, and vice versa.

To meet the requirements for IETF standard advancement, they will need
to demonstrate their interoperability separately, and thus must be
separate documents.

Note to the editor, could you please standardize on the term "element"
or "message element" instead of "packet".  A packet has a well-known
networking definition.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Date: Thu, 23 Oct 97 14:07:20 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Subject: draft editor(s)
Sender: [email-masked]

> From: "John  W. Noerenberg" <[email-masked]>
> Wow!  Lutz, I'm impressed.  While some have been arguing about numerous
> topics, you've taken the bull by the horns and produced a first cut at one
> of the documents we need to concentrate on.  This is quite a piece of work.
>
> Lutz's work mirrors some of the work that Jon Callas and Rod Thayer have
> also done.  I've asked the three of them to collaborate on a single version
> of this document to be submitted as an Internet-Draft.
>...
> Is everybody with me so far?
>
I suggest that this is not the correct approach.  Multi-editor documents
have a problematic history in the IETF.

Jon Callas did not finish his work in a timely fashion, despite
considerable public and private prompting.  Rodney Thayer is generally a
bit better at getting things done, but he has not finished either.

I recommend any of Callas and Thayer's useful work be incorporated in
the new document, and that they be given second and third author credit,
but that all editting be done by Lutz.  No diffusion of responsibility.
Them that does the work gets the credit.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Date: Thu, 23 Oct 1997 07:37:13 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Jonathan Wienke <[email-masked]>
Subject: Re: CDR design document
Cc: [email-masked]
Sender: [email-masked]

--=====_Eudora-PGP-Plugin8777==_
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:55 PM 2/21/97 GMT, Adam Back wrote:
>
>Here is a proposal for consideration for inclusion in the OpenPGP
>standard:
>
>	http://www.dcs.ex.ac.uk/~aba/cdr/

Great work, Adam!  Pursuant to some of the recent rants on cypherpunks, I
would like to see a proposal for a secret sharing mechanism that would
allow the recovery of a storage-only key with m of n shares in the event
that the passphrase to the storage key is unavailable, with the following
attributes:

1. Secret-sharing should be strongly discouraged for signature and
communication keys, for obvious anti-GAK/GACK reasons.

2. The values of m and n should be definable by the generator of (or anyone
who knows the passphrase to) the storage key.

3. The sharing algorithm and format of the share packets should be
standardised, so that any open-pgp compliant application can recover the
storage key without a passphrase, given the key and a sufficient number of
valid shares.

Jonathan Wienke

What part of "the right of the people to keep and bear Arms, shall not be
infringed" is too hard to understand? (From 2nd Amendment, U.S. Constitution)

PGP 2.6.2 RSA Key Fingerprint: 7484 2FB7 7588 ACD1  3A8F 778A 7407 2928
DSS/D-H Key Fingerprint: 3312 6597 8258 9A9E D9FA  4878 C245 D245 EAA7 0DCC
Public keys available at pgpkeys.mit.edu. PGP encrypted e-mail preferred.

US/Canadian Windows 95/NT or Mac users:
Get Eudora Light + PGP 5.0 for free at http://www.eudora.com/eudoralight/
Get PGP 5.0 for free at http://bs.mit.edu:8001/pgp-form.html

Non-US PGP 5.0 sources:
http://www.ifi.uio.no/pgp/
http://www.heise.de/ct/pgpCA/download.shtml
ftp://ftp.pca.dfn.de/pub/pgp/V5.0/
ftp://ftp.fu-berlin.de/pub/pc/win95/pgp
ftp://ftp.fu-berlin.de/pub/mac/pgp
http://www.shopmiami.com/utopia.hacktic.nl/pub/replay/pub/pgp/pgp50/win/

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`

Stupidity is the one arena of of human achievement where most people
fulfill their potential.
--=====_Eudora-PGP-Plugin8777==_
Content-Type: application/pgp-signature

--=====_Eudora-PGP-Plugin8777==_--

Date: Thu, 23 Oct 1997 11:25:51 +0100
From: Salvatore Nesta <[email-masked]>
Subject: Re: World-wide GAK
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

>For those who thought GAK was merely a local political issue,
>isolated to those barbarians in the USA, one that they could
>afford to ignore and morally refuse to address -- Quelle surprise!
>It's spreading:
>
>FRANCE PROPOSES KEY ENCRYPTION LAW
>
>The French government has proposed a law that would mandate a
>key-recovery system for all encrypted electronic documents, a
>move that is opposed by the business community and the European
>Commission.  Earlier this month, the European Commission rejected
>the key-recovery approach to encryption, which some believe would
>make it easier for competitors to gain access to a company's
>business secrets.  "I do not say this is the best system,"
>says the chief of France's Central Service for the Security of
>Information Systems.  "It is the least bad in trying to find a
>balance between national-security interests, economic interests
>and the protection of personal privacy."
>
>(Wall Street Journal 20 Oct 97)

In Italy, AIPA (Authority for Informatics in Public Administration), has
sent to Government a project of law which excludes "key escrow" and also
the hierarchy of Certification Authorities. However, AIPA didn't define
requirements of private body that can issue a certificate. So the
Governament has sent to Chambers a draft bill which establish that the
private body that can issue a certificate MUST be a S.p.A. whose registered
capital is the same necessary to licence to merchant banking: 7,5 million
dollars.
In such way, italian Internet providers (subjects technically and
structurally most qualified!) won't be able to issue certificates without
any reason.

Salvatore Nesta
[email-masked]

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 23 Oct 97 03:19:45 -0500
To: [email-masked]
Cc: [email-masked]
Subject: What RSA & Netscape have to offer
Sender: [email-masked]

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

Hi,

While the list is busy knocking PGP for not doing the "right thing" or
being the "first ones to blink" I though I would share with the list what
some of the "big boys" are doing for the spread of "Strong Crypto to the
Masses". Below is from the most current S/MIME draft
"draft-dusse-smime-msg-05" dated 19-Oct-1997:

2.6 ContentEncryptionAlgorithmIdentifier

Receiving agents MUST support decryption using the RC2 [RC2] or a
compatible algorithm at a key size of 40 bits, hereinafter called
"RC2/40". Receiving agents SHOULD support decryption using DES EDE3 CBC,
hereinafter called "tripleDES" [3DES] [DES].

Sending agents SHOULD support encryption with RC2/40 and tripleDES.

I think that when taking pot-shots at PGP, Inc. and Phil Zimmerman one
should look at what the alternatives are and who are really are friends
here. IMNSHO companies like RSA, Netscape, Microsoft, Verisign, et al, who
would sell us all out if it improved their bottom lines do not qualify.

- -- 
- ---------------------------------------------------------------
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: Andrew Bromage <[email-masked]>
Subject: Re: World-wide GAK
To: [email-masked] (Tim May)
Date: Thu, 23 Oct 1997 12:49:04 +1000 (EST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

G'day all.

Tim May wrote:

> Nor is it by any stretch the first non-US GAK measures proposed. Cf. the
> Trusted Third Parties plan in the U.K., the Australian developments, and
> various measures in the Phillipines, Singapore, Germany, Sweden, and, of
> course, the People's Republic of China.

Just in case anyone is interested in the Australian developments, the
EFA (Australian counterpart to the EFF) has published the Australian
government's "Review of policy relating to encryption technologies",
usually referred to as the Walsh Report.  It's available online:

	http://www.efa.org.au/Issues/Crypto/Walsh/

BTW, the author of this report, Gerard Walsh, is a former deputy
director-general of ASIO, the Australian Security and Intelligence
Organisation.  They're the ones responsible for national security.
Other organisations which you should know about before reading are:

	- Australian Federal Police (AFP)
	- National Crime Authority (NCA)
	- Australian Transaction Reports and Analysis Centre
	  (AUSTRAC)
	- Commonwealth Law Enforcement Board (CLEB)
	- Defense Signals Directorate (DSD)

Now that I've set the NSA line eater buzzing with excitement, we now
return you to your scheduled technical discussion.

Cheers,
Andrew Bromage

Date: Wed, 22 Oct 1997 15:13:01 -0700
To: Jeffrey Gold <[email-masked]>, ietf-open-pgp <[email-masked]>, cypherpunks <[email-masked]>, pgp-users <[email-masked]>
From: Tim May <[email-masked]>
Subject: Re: World-wide GAK
Sender: [email-masked]

At 2:31 PM -0700 10/22/97, Jeffrey Gold wrote:
>For those who thought GAK was merely a local political issue,
>isolated to those barbarians in the USA, one that they could
>afford to ignore and morally refuse to address -- Quelle surprise!
>It's spreading:

Yes, this was reported earlier by others. Fabrice Planchon, a native of
France (I believe), discussed it at length.

And it is not surprising to any of us who have been following developments,
vis-a-vis the OECD, Wasenaar Agreement, and New World Order in general.

Nor is it by any stretch the first non-US GAK measures proposed. Cf. the
Trusted Third Parties plan in the U.K., the Australian developments, and
various measures in the Phillipines, Singapore, Germany, Sweden, and, of
course, the People's Republic of China.

--Tim May

>FRANCE PROPOSES KEY ENCRYPTION LAW
>
>The French government has proposed a law that would mandate a
>key-recovery system for all encrypted electronic documents, a
>move that is opposed by the business community and the European
>Commission.  Earlier this month, the European Commission rejected
>the key-recovery approach to encryption, which some believe would
>make it easier for competitors to gain access to a company's
>business secrets.  "I do not say this is the best system,"
>says the chief of France's Central Service for the Security of
>Information Systems.  "It is the least bad in trying to find a
>balance between national-security interests, economic interests
>and the protection of personal privacy."
>
>(Wall Street Journal 20 Oct 97)

The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

Date: Wed, 22 Oct 1997 17:31:00 -0400 (EDT)
From: Jeffrey Gold <[email-masked]>
Subject: World-wide GAK
To: ietf-open-pgp <[email-masked]>, cypherpunks <[email-masked]>, pgp-users <[email-masked]>
Sender: [email-masked]

For those who thought GAK was merely a local political issue,
isolated to those barbarians in the USA, one that they could 
afford to ignore and morally refuse to address -- Quelle surprise!
It's spreading:

FRANCE PROPOSES KEY ENCRYPTION LAW

The French government has proposed a law that would mandate a 
key-recovery system for all encrypted electronic documents, a 
move that is opposed by the business community and the European 
Commission.  Earlier this month, the European Commission rejected 
the key-recovery approach to encryption, which some believe would 
make it easier for competitors to gain access to a company's 
business secrets.  "I do not say this is the best system," 
says the chief of France's Central Service for the Security of 
Information Systems.  "It is the least bad in trying to find a 
balance between national-security interests, economic interests 
and the protection of personal privacy."  

(Wall Street Journal 20 Oct 97)

Date: Wed, 22 Oct 1997 09:53:18 -0400 (EDT)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: RE: CDR design document
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

A very well thought out document, the concept of periodic key revalidation 
via server is a good one though I suspect that in the furture and in a
corporate environment, use of the local keyring will dwindle in favor of
use of a trusted server. 

The point about CMR keys is well taken though I would expect that only very 
small organizations will have but a single CMR key/repository. What I am
looking at these days is a different CMR key for each internal entity,
locally administered.

There will then likely be a hierarchy of repositories, each responsible for 
their own traffic. There will probably be a corporate repository of keys only
(please refrain from the horror of it and exclamations of the difficulty
of maintaining security/integrity. Am deliberately making the mechanism
easy to put in/difficult to extract with multiple access controls, not in 
the same locations.

One of the precepts is that the root certificate generator will never be
connected to the network and is stored in a secure container approved
for classified use. This is causing some difficulties: Microsoft IIS
v4.0 servers are insisting that they connect to the root server (which is not
going to happen). Netscape Suite Spot does not seem to have this difficulty,
there is a box that may be ticked to tell it that the root is offline.

Have a feeling that this will be a real problem with Microsoft products - 
seem to allow one and only one master certificate server/generator for the
enterprise and it *must* be online.

One of the things we are looking at is a "shadow" root server which will be
able to receive certificate requests/disseminate approved certificates but
not to generate certificates.

Expect that in a couple of years, all of this will be easy. Right now is
the first time for a *lot* of things and we need to get it right.

						Warmly,
							Padgett

ps Just an observation: with the power of today's laptops, using one for a
   root or coprorate repository makes a lot of sense provided you can
   physically secure it. Generally it is simple to swap drives and to verify
   that the network connection is removed before starting in a "sensitive"
   mode. Also the "secure container" does not need to be so large and any
   secretary can remove/replace. With a docking station, the entire unit
   may be removed/replaced as well. Since both very large drives and
   silly amounts of RAM are available, this is not a limitation. Finally
   spares and swapping is easy though it is a good idea to put red bands
   around the sensitive disk(s) so they do not accidently get swapped with 
   non-sensitive. Just make sure they are not easily stolen.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: New Draft... going forward
Date: 22 Oct 1997 09:25:09 GMT
Organization: IKS GmbH Jena
Lines: 21
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* John  W. Noerenberg wrote:
>Lutz's work mirrors some of the work that Jon Callas and Rod Thayer have
>also done. I've asked the three of them to collaborate on a single version
>of this document to be submitted as an Internet-Draft. That will be the

At the moment the state is undefined to me. I did not know the formal
procedere so I informed the chairmen yesterday after publishing the draft.
Jon Callas pointed droped me an email on this topic. Hope to come together.
Especially an editor is needed to keep a working draft up to date. I can do
it but I'm not authorized by the formal procedure..

>That will leave 3 more weeks for a 2nd revision to be posted in time for
>consideration for our meeting in Washington DC in Dec.  It is possible we
>will still be discussing the first official I-D by Nov 21.  In any event, I

It would be somewhat too expensive for me to come to W CD. ... So I urge to
finish the important part on the mailinglist.

>Is everybody with me so far?

Yep.

Date: Wed, 22 Oct 1997 02:00:19 -0700
To: [email-masked] (Lutz Donnerhacke)
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: New Draft... going forward
Cc: [email-masked]
Sender: [email-masked]

At 5:36 PM +0000 10/19/97, Lutz Donnerhacke wrote:
>
>Abstract
>
>PGP (Pretty Good Privacy) is a software product combining strong asymmetric
>and symmetric cryptography for secure e-mail communication. These services
>include confidentiality, key management, digital signature, and time
>stamping. This document specifies the message exchange format used in
>version 2.6.3x and 5.x of PGP.

Wow!  Lutz, I'm impressed.  While some have been arguing about numerous
topics, you've taken the bull by the horns and produced a first cut at one
of the documents we need to concentrate on.  This is quite a piece of work.

I've been reading thru the comments on Lutz's posting.  There have been
numerous good suggestions.  By all means continue your reading of this
document and attempts to implement it.

In order to make sure we're continuing to make progress, and that the
progress gets reflected up through the rest of the IETF, it's time to set
some ground rules.

Lutz's work mirrors some of the work that Jon Callas and Rod Thayer have
also done.  I've asked the three of them to collaborate on a single version
of this document to be submitted as an Internet-Draft.  That will be the
basis of work on message formats going forward.  I expect the reconcilation
into a single document and it's submission as an I-D to be completed by the
end of October.

That will leave 3 more weeks for a 2nd revision to be posted in time for
consideration for our meeting in Washington DC in Dec.  It is possible we
will still be discussing the first official I-D by Nov 21.  In any event, I
expect to use a good portion of our meeting in Dec discussing the message
format document that results from the collaboration of Jon, Lutz, and Rod,
and the comments it elicits from all of you.

In addition to the IETF document sites, our working group has an additional
archive at imc.org.  That archive contains copies of the  current documents
that "belong" to our working group that have been reviewed and posted by
the IETF rfc editor, as well as an archive of all the messages to this list.

I'll talk about PGP/MIME in a different message.

Is everybody with me so far?

best,

john  w noerenberg, ii
[email-masked]
pager: [email-masked]
 --------------------------------------------------------------------
  "A beautiful idea has a much greater chance of being a correct idea
   than an ugly one."
 -- Roger Penrose, "The Emperor's New Mind", 1989
 --------------------------------------------------------------------

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: ASN.1 packet?
Date: 22 Oct 1997 07:58:19 GMT
Organization: IKS GmbH Jena
Lines: 15
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Kent Crispin wrote:
>"For backward compatibility this format SHOULD be read.  It MAY be
>generated."

I will change every occurence in that way today. Furthermore I'm going to
define each packet as required, recommended and optional in application
support.

Shall we introduce an X.509 frame in packet version 3 and 4?
  "Content of this packet is a type octet determining the PKCS version,
   followed by the ASN.1 encoded PKCS octet stream."

It is sufficient to include it in packet version 3, because ASN.1 requires
the length of the packet or use indefinite length both available to packet
version 3.

From: Andrew Bromage <[email-masked]>
Subject: Re: KeyIDs and Key Fingerprints
To: [email-masked] (William H. Geiger III)
Date: Wed, 22 Oct 1997 15:05:14 +1000 (EST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

G'day all.

William H. Geiger III wrote:

> Well the way I see it we have 2 possabilities for duplicate keyID's:
> 
> 1) Collision. Does anyone know what the probability of 2 users generating
> 2 unique keys with the same keyID? If this number is high then perhaps we
> should look at either using the fingerprint in the PGP packets or
> providing additional info in the packets to provide uniqueness.

It was said in a previous post (can't recall who said it) that 95,000
new keys have been added to the MIT keyserver since 20 May (I assume
this is what was meant by the internationally puzzling incantation
5/20).

A quick calculation (Haskell source available on request) shows that
amongst these 95,000 keys, there is a 65% chance that there is at least
one ID collision.  The number of keys required to hit 95% chance of an
ID collision is just over 160,000.

I'd say that certainly constitutes "high".  Certainly too high for a
keyserver or large business.

Cheers,
Andrew Bromage

Date: Tue, 21 Oct 1997 18:01:22 -0700
To: [email-masked], [email-masked]
From: Greg Broiles <[email-masked]>
Subject: PGP 5.5 CMR key examples, mini-review
Sender: [email-masked]

An acqaintance of mine received an evaluation copy of the new PGP For
Business Security 5.5 suite, and I was able to generate some test keys to
play with the message recovery features. I've uploaded them to the cert
servers so folks with the 5.0 client software can experiment with them for
interoperability, etc.

The recovery key is "Little Brother <snoop@localhost>", fingerprint 26A5
667A 97D4 7018 1B18  2B15 D631 4776 B670 E1D0; a test user whose incoming
and outgoing mail is forced to include the recovery key is "CMR User
<snooped@localhost>, fingerprint EC79 A170 8BAE 60A1 3CAC  C517 34A4 6056
EE42 30E3. Both keys are 768-bit DH keys, as I don't expect that anyone
will use them for anything other than testing.

Installation of the package involves multiple steps - there's an
"administrator install package" (my term, not theirs), which installs a
version 5.5 of PGP, including the PGPTools, PGPKeys and PGPTray apps, as
well as a PGPAdmin program. To implement CMR, the ordinary PGPKeys app is
used to create an otherwise ordinary PGP key pair; the administrator then
runs the PGPAdmin app, which asks questions about security/recovery policy.
The admin can force incoming messages to use a recovery key, can force
outgoing messages to use a recovery key, can enable/disable conventional
encryption, can enable/disable key generation (and RSA key generation), can
force a key to be trusted and to act as a trusted meta-introducer. The
admin can also force the user to use a strong passphrase. (PGP 5.5 includes
a neat passphrase-strength-meter which changes depending on the length and
apparent alphabet-space used in the passphrase for user keys.) Finally, the
admin can force the user to sign/trust a designated Corporate Signing Key.

After the administrator sets those policy choices, the PGPAdmin tool can be
used to generate a customized installer application for distribution to
users. That installer creates a local copy of PGP, which will enforce the
policy choices made by the administrator. The user is warned upon key
generation that a message recovery key will be used (if the app is thus
configured) and that the behavior isn't optional. The recovery key ID is
displayed but not modifiable.

The user interface for 5.5 is much improved over that in 5.0, which was a
big improvement over the command line. There's an indicator (initially
preferenced to OFF, along with other information) in the PGPKeys
application which marks CMR'd keys with a red button; the interface between
PGPKeys and the key server is much improved. It's now possible to mark &
retrieve many unknown keys, then approve adding them to the local keyring
in one step, instead of approving the addition of each additional key. The
icons & screen design have been updated and are now more colorful and
easier to decipher.

When a user with CMR-only client software encrypts data, the ID of the
recovery key appears in the "encrypt to" box, and cannot be dragged out. A
CMR-client will (apparently) still do conventional encryption with no
recovery key if the admin allows this. 

--
Greg Broiles                | US crypto export control policy in a nutshell:
[email-masked]         | Export jobs, not crypto.
http://www.io.com/~gbroiles | http://www.parrhesia.com

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 21 Oct 97 19:12:50 -0500
To: [email-masked]
Cc: [email-masked]
Subject: Re: updating status of keys in public key chain..?
Sender: [email-masked]

In <Pine.GSO.3.96.971021150617.2672D-100000@log3>, on 10/21/97 
   at 02, [email-masked] said:

>I have thought of an interesting issue which has to date not been
>mentioned which is the following:

>** Methods to check the status of public keys on one's public keychain.

>Several weeks ago when I had to revoke several of my pgp keys I asked
>myself if there was any way of notifying people who send me pgp messages
>that my "public" key had been changed. 

>The only answer I could think of was to email everyone and inform them.
>However another method would be preferable. Ideally if the "public" keys
>in one's keychain could be verified/updated with those in a particular
>keyserver than one would know if a key is still valid.

>ie.

>1. (local) keychain with public keys A, B, C
>2. Key A has been revoked and sent to keyserver
>3. user performs (local) public key "refresh"
>     a. public keys in local keychain are checked against keyserver
>     b. existing keys are checked to see if valid
>     c. existing keys if invalid -> "updated key" fetched

>4. One now knows which locally held keys are "valid" (when compared vs.
>keyserver)

>I am curious as to why  this "verification" is not present in any of the
>pgp implentations  to this date. Should it be in a future implementation?

I had mentioned on the PGP Keyserver list awhile back about storing hashes
of the PGP keys on the servers and making use of those for checking if
keys had been changed (Note: hash here refers to a hash of the entire key
including userid's & Signatures but not including trust packets).

client                                           server
------                                           ------

send KeyId/Hash request ------------------>
                        <-----------------        Return Hash hash diff?
yes. request key        ------------------>       
                        <-----------------        Send Key

Update Key                                                  
hash diff?
yes. post key           ------------------>

I had also proposed using a similar mechanism for processing keyring
updates:

server 1                                         server 2
--------                                         --------

send newkey list        ------------------>       
                                                  Compare hashes to DB
                        <-----------------        and request diffs

send keys               ------------------>
                                                  Update Keys
                                                  hash diff?
                        <-----------------        send diff list   request
diff keys       ------------------>

                        <-----------------        Send Keys

Also a periodic maintenance update would be performed where a complete DB
hashlist would be exchanged and key updates processed.

-- 
---------------------------------------------------------------
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: Fri, 21 Feb 1997 22:55:37 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: CDR design document
Sender: [email-masked]

Here is a proposal for consideration for inclusion in the OpenPGP
standard:

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

(Also attached text version below [1])

It describes a mechanism for commercial data recovery which attempts
to minimise the security risks inherent in allowing disaster recovery
of stored encrypted documents.  The CDR design also avoids the
security risks in building systems which send recovery information
over open communications networks, as the CMR proposal currently does.

The CDR design offers the option of more ergonomic recovery from
forgotten passphrase.  CDR allows for more secure use to be made of
the existing pgp5.0 key expiry functionality when applied to
communications-only keys because they can be deleted with out loss of
data-availability, providing a form of PFS which is backwards
compatible with pgp5.0 and pgp5.5 clients.

Comments?

The only change addition to the standard required is to create a
distinction between a storage only key and a communications only key.
This distinction could be made via the use of an extra flag, ideally
so that keyrings can remain standardised and interchangeable between
different implementations.

The document can also be viewed as a recommendation to implementors of
how to avoid security risks (and related government abuse risks) in
implementing data recovery systems.

I would like to see the OpenPGP standard accomodate both the CMR and
CDR design so that each can fly on it's technical merits.  (And
political merits, cryptography being a highly political field, a
politically unpopular design may suffer for other than technical
reasons).

Adam

[1]	http://www.dcs.ex.ac.uk/~aba/cdr/
==============================8<==============================
Commercial Data Recovery

This document describes a mechanism, Commercial Data Recovery (CDR), to
allow companies to recover stored encrypted information as part of a
disaster recovery plan.

Introduction

This document is centered around the OpenPGP standard, and therefore
explores first what is possible within the existing standard. Several of the
CDR variants presented can be achieved entirely within the pgp5.0 standard
without adding any new functionality.

Commercial disaster recovery requirement

PGP is commonly used for two purposes: file encryption, and encryption of
email communications. The situation arises in a commercial setting that
individuals are protecting information which the company would like to be
able to recover in the event of disaster: in the event of the user
forgetting his passphrase, or in the event of the unexpected death of the
employee. Stored files which the company may require the ability to recover
include encrypted files stored in the files system, on backup tapes, or on
floppy disks; and encrypted sent and recieved emails stored in mail client
folders.

Security vs Availability

There is a security risk in adding data recovery mechanisms: the additional
risk that recovery procedure is used by other than the owners of the data to
recover plaintext.

A central goal of the CDR design described in this document is to minimise
this security risk. Keys used to encrypt email which is transmitted over the
Internet are more valuable to an attacker than keys used to encrypt stored
files because of the relative ease with which an attacker can obtain copies
of emailed ciphertext. Stored encrypted files in contrast are protected by
all the physical security systems the company is relying on to protect it's
paper files, plaintext data stored on disks, and backup tapes.

For this reason the CDR approach treats communications keys as more
sensitive than keys used to encrypt locally stored information.

Separate Signature and Encryption Keys added in pgp5.0

This section describes a feature added to PGP with the pgp5.0 release:
separate signature and encryption keys. Readers familiar with pgp5.0
functionality may like to skip this section.

pgp2.x RSA keys

pgp2.x (and pgp1.x) only had direct support for one type of public key: the
RSA public key. RSA public keys were used both as signature keys, and as
encryption keys to transfer session keys. The ability to generate RSA keys,
and to interoperate with pgp2.x is retained in pgp5.x.

pgp5.x El Gamal (DH) encryption and DSA signature keys

One reason for the introduction of separate key functionalities is the
addition, starting with pgp5.0, of the DSA digital signature algorithm which
can only function as a signature system. In addition the El Gamal (EG)
public key system which was also added with pgp5.0 is used only as a public
key encryption system. (There are some El Gamal variants which can be used
to produce digital signatures, but these are not used in pgp5.0). (El Gamal
is a Diffie-Hellman (DH) variant which is sometimes also referred to
confusingly as DH.) The DSA is itself a DH signature variant.

Patent issues

Another significant reason for the adoption of EG and DSA in particular is
the freedom from patent encumbrances these algorithms now enjoy. RSA by
contrast is patented, and unpatented algorithms are generally preferred for
internet standards.

Key expiry feature added in pgp5.0

One general security principle is that keys used to protect communications
should be replaced periodically to reduce the value to an attacker of an
individual key.

Migration path

The pgp5.0 standard provides support for this functionality in terms of the
ability to attach expiry dates to signature and encryption keys. (In the
pgp5.0 and pgp5.5 clients the signature and encryption keys are treated as a
pair, and are given the same expiry information, but both the pgp5.0 and
pgp5.5 clients can already cope with signature-only keys and encryption-only
keys with different expiry information.)

Web of Trust

In pgp5.0 with the EG public keys, the Web of Trust (WoT) is based on the
signature keys only. The users signature key is authenticated in the web of
trust. The user signs his own encryption key thereby transferring trust to
it. This ensures that encryption keys can be expired and replaced without
affecting the web of trust.

Limited Perfect Forward Secrecy

Perfect Forward Secrecy (PFS) refers the technique of destroying old
communications keys to ensure that past traffic can not be compromised after
the point of re-keying. One way to use the pgp5.0 key expiry facilities is
to have signature and encryption keys with very different expiry periods.
For example a signature key could be given no expiry period (the pgp5.0
standard supports expiry periods of `forever'), and encryption keys could be
given an expiry period of 6 months.

To obtain PFS, a more secure way of dealing with expired encryption keys is
to actually irretrievably delete them. This then simulates PFS: an attacker
is unable to decrypt traffic encrypted with old communications keys even if
he is able to coerce co-operation from the recipient. No one can be coerced
because the key has been deleted.

It seems reasonable that some users may want to use key expiry for this
purpose, and this does not require any modifications to the existing pgp5.0
standard.

Key expiry problems for stored encrypted data

One problem introduced by key expiry is that any stored data encrypted to
the expired key becomes less available. For security reasons the expired key
should ideally be deleted, and in this case access to the data is lost.
Alternatives are to attempt to store the old keys more securely, this then
presents the problem that some stored data is harder to access than other
data, and presents additional key management problems for old keys which
will be confusing for users.

Re-encrypting after key expiry

One method to solve this problem is to re-encrypt all of the encrypted files
at the point of re-keying. However this method has disadvantages in that not
all of the encrypted data may be easily available. Some of the encrypted
data may be on backup tapes, on floppy disks, or stored inside `zip' or
`tar' archives on the disk and hence may be missed.

Separate storage keys

The simplest solution to this problem seems to be to encrypt to a separate
storage key. Within the pgp5.0 standard this storage key would be a separate
El Gamal key with a long expiry date. With this system we then have three
types of keys: signature-only keys, communications-only keys and
storage-only keys. This could require minimal or even no modifications to
the pgp5.0 standard, storage and encryption keys could be differentiated
between by:

   * location storage-only key is stored in (for example a separate keyring)
   * application being configured to use a chosen encryption key as the
     storage-only key by giving a keyID
   * convention on expiry dates (expiry date `forever' could be storage key,
     other values could be communications keys)
   * extra flag to indicate a storage-only key

Once the separation of key types is made, the security benefits of re-keying
can be more fully obtained.

Sent and recieved email folders

To maintain availability after re-keying of encrypted sent and received
emails archived in mail folders, the email plaintext would be encrypted with
the storage-only key. This then means that data availability for encrypted
files on disk, floppy disk, and backup tape is maintained; and that
availability for archived sent and received emails is maintained.

Storage Recovery

If the system is being used in a commercial setting, disaster recovery can
be provided by storing recovery information to allow recovery of the
storage-only key. There is still some additional danger over the case where
there is no recovery procedure: the risk that an attacker may be able to
compromise the recovery information. However because the encrypted data is
all protected by the companies existing physical security mechanisms the
security risk is minimised.

Another form of storage recovery would be to include recovery information
with each file, and this would be a valid combination achieved by placing
CMR-style requests for additional crypto-recipients on the CDR storage-only
key. However this practice makes recovery from forgotten passphrase more
problematic: to restore user access to the data after forgotten passphrase,
the recovery agent would have to decrypt all stored files (be they on hard
disk, backup tape, floppy disk, or stored inside `zip' or other archives),
then the user would have to generate a new storage-only key, and re-encrypt
all of the files. Given the frequency with which users are prone to
forgetting passphrases implementors may decide to avoid this option for
ergonomics reasons.

CDR vs CMR

PGP Inc has an alternative data recovery proposal called Commercial Message
Recovery (CMR). The CMR proposal involves sending recovery information with
the message in the form of a second crypto recipient. In addition mechanisms
are provided in the form of a proposed CMR public key extension to the IETF
OpenPGP standard which indicates a request to the sender to include this
recovery information. In addition facilities are provided in the form of PGP
Inc's SMTP policy enforcer to partially enforce the inclusion of this
recovery information by bouncing mail which does not include it.

Security comparison

PGP Inc's CMR proposal makes re-keying problematic because data is archived
in email folders still encrypted to the encryption key. This tends to
encourage the practice of having very long term communication encryption
keys. Indeed the beta pgp5.0 implementation the author tried makes the
recommendation that most users would give keys an expiry period of
`forever'.

In addition a security risk with the CMR proposal is that an attacker is
able to obtain via coercion, bribery or burglary the CMR key used to encrypt
the traffic for this key. With a purloined CMR recovery key, and given the
long life time encouraged for such keys the previously passive attacker may
be able to recover years worth of old traffic.

Another risk is that companies may for simplicity have only one CMR key,
thereby putting at risk the entire companies secured communications over
periods of years. This is naturally a bad practice, and one which is
discouraged by PGP Inc also, but the author remains cynically confident that
some corporate users will ignore such advice.

Privacy Comparison

PGP Inc proposese the CMR communications recovery mechanism as a privacy
respecting method of achieving data recovery. The privacy features of the
CMR proposal are that there are proposed flags which are attached to a
public key to indicate statement of intent about plaintext handling to the
sender who is about to use the public key.

Three statements of intent are possible with the current CMR proposal:

   * personal key (no flags set)
   * company use key, company may read message, please encrypt to listed
     company CMR recovery key(s) (recovery flag set)
   * company may read message, encrypt to listed CMR recovery key(s) or the
     message will be bounced (strict recovery flag set)

PGP Inc's statement of intent in plaintext handling is a useful concept, in
that it explains explicitly to the sender who will be able to read the
message, and how the plaintext will be handled. Statement of intents are
always advisory, in that they are impossible to enforce; however they are
useful in encouraging ethical behaviour in this regard.

Statement of intent messages are independent of recovery mechanism, and
apply equally to the CDR mechanism described in this document. In fact the
author would like to encourage a fuller set of statement of intent flags for
both sender and recipient, allowing keys to be marked with intents:

   * personal key, messages not archived
   * personal key, messages archived
   * key used for company business, messages not archived
   * key used for company business, messages archived
   * key used for company business, messages archived and recoverable

And, in addition a similar privacy argument could be made to allow the
sender to express his preferences with regard to plaintext handling on a per
message basis. This could generalise the -m function of pgp2.x which
instructs the recipient not to save to a file. (The -m flag is the sort of
electronic version of `please burn this document after reading', this flag
is mildly enforced by the pgp2.x command line application). These set of
flags would allow a sender to send a `normal communication message', or a
`official statement, please archive with recovery if available', or
`sensitive do not archive' and so on. A privacy respecting implementation
could provide support for these functionalities. Whilst obviously easy to
over-ride, this is felt to be a useful exercise in encouraging respect for
privacy.

In addition the recipient should have ability where company policy allows to
choose which messages to archive, and which to archive with company recovery
information.

>From a privacy perspective the CDR and CMR proposals are approximately
equivalent; the statement of intent flags, and the social value of
encouraging companies to respect privacy are useful in both.

Government access to communication key politics

Another aspect of the whole data recovery area is that the US government,
French government, and UK government (as well as other governments) have
expressed an unhealthy interest in obtaining private individuals, and
companies communications keys. Many privacy advocates view this development
with fear, as it seems to many a particularly Orwellian development. Usually
the Government Access to Communication Key (GACK) attempts try to deflect
criticism by focussing on unrelated issues as a vehicle to introducing GACK:

   * Terrorist attacks and requirement for emergency government access to
     communications traffic
   * Government assistance for companies to recover stored plaintext via key
     escrow infrastructure.
   * Assisting electronic commerce by helping put in place Certification
     Authorities and digital signature laws

However readers who have followed GACK politics will recognise the above for
what they are: attempts to put in place GACK via indirect routes
(respectively: the four horsemen of the infocalypse argument (the fallacy
that terrorists will obey laws and use encryption systems which have
government backdoors), the Clipper I, II and III attemps (various attempts
by the US government to bribe and bully companies into building a GACK
architecture), and the UK TTP (Trusted Third Party) proposal where `TTPs'
are a euphamism for a Certification Authority (CA) which has been coerced by
law to keep individuals private keys).

Scenarios governments might shortly try this to request master keys for
communications might be France, where the government is changing from a
position of no encryption software without license, to a position of
unlicensed encryption software being allowed provided that the governments
has a back door into the communications. Other examples being perhaps the UK
(with it's highly controversial TTP licensing proposals), or the US with the
administration and law enforcement community pushing hard for access to
communications keys. It is likely, particularly in the UK, and US in the
authors opinion, that government backdoors would be demanded in carefully
orchestrated stages, designed to minimise public opposition. There might be
trials where the traditionally more regulated financial organisations were
required to comply, next perhaps government funded research labs, and
business organisations accustomed to large amounts of government regulation
Only towards the end would people using government funded networks
(academics), Internet services providers (ISPs) and individuals be
regulated. The final phases may use a terrorist activity, or national
emergency, or other scandal as justification for increasing the
requirements. It is likely also that the justification will be in terms of
wholesome sounding public safety safeguards.

Political Comparison

PGP Inc's CMR proposal loses heavily in the political argument in the
author's opinion because the protocol design supports the practice of
allowing third and fourth party access to communications traffic.
Particularly with the multiple CMR key requests per key which are rumored to
be coming in the next version of PGP, it will be easy technically for a
government to request that one of the recovery keys belong to the
government. Governments already have the political will to have access to
communications; the barriers are technical, and individual's resistance to
the notion. The danger with the CMR proposal is that it could become the
enabling technology for push button suveillance, the enabling technology for
wide scale secret service signals intelligence keyword scanning. This
probably not what it's proposers intend, however the danger is there in
building the technology.

The CDR proposal on the other hand focusses on recovery information of
stored information only, and as a design principle avoids sending recovery
information over open networks. Whislt governments may be interested to
obtain storage keys, they have much less value, because the ciphertext is
much harder to obtain. Also non-compliance is much harder to detect: a
government law enforcement agency would not know if an individual was
actually using storage software with government backdoor key access without
physically obtaining the storage media. For most individuals the point at
which governments executes a dawn raid is a point at which the individual is
already in trouble. The CDR proposal is much closer to the status quo in
political terms.

Date: 	Tue, 21 Oct 1997 15:29:54 -0400
From: [email-masked]
To: [email-masked]
Subject: updating status of keys in public key chain..?
Sender: [email-masked]

I have thought of an interesting issue which has to date not been
mentioned which is the following:

** Methods to check the status of public keys on one's public keychain.

Several weeks ago when I had to revoke several of my pgp keys I asked
myself if there was any way of notifying people who send me pgp messages
that my "public" key had been changed. 

The only answer I could think of was to email everyone and inform them.
However another method would be preferable. Ideally if the "public" keys
in one's keychain could be verified/updated with those in a particular
keyserver than one would know if a key is still valid.

ie.

1. (local) keychain with public keys A, B, C
2. Key A has been revoked and sent to keyserver
3. user performs (local) public key "refresh"
     a. public keys in local keychain are checked against keyserver
     b. existing keys are checked to see if valid
     c. existing keys if invalid -> "updated key" fetched

4. One now knows which locally held keys are "valid" (when compared vs.
keyserver)

I am curious as to why  this "verification" is not present in any of the
pgp implentations  to this date. Should it be in a future implementation?

Date: Tue, 21 Oct 1997 13:56:04 -0700
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: New Draft... going forward
Sender: [email-masked]

On Tue, Oct 21, 1997 at 06:40:37PM +0000, Lutz Donnerhacke wrote:
> * Gene Hoffman wrote:
> >> So the current API does not work well with MIME itself. Sue the programmers.
> 
> >This is a common problem across most every MUA.
> >
> >The whole point of this thread is that ASCII armor serves a very valid
> >purpose when dealing with the majority (by deployment) of MUA's in the
> >world.
> 
> Ok, that's fine. So forget RfC 2015.
> 
> The actual paragraph is correct, isn't it?

"For backward compatibility this format should be read but may not be
generated."

It would read better as

"For backward compatibility this format SHOULD be read.  It MAY be
generated."

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

From: "Gaon, David" <[email-masked]>
To: Roland Silver  <[email-masked]>, "William H. Geiger III " <[email-masked]>
Cc: IETF OpenPGP  <[email-masked]>
Subject: RE: Is PGP still private?
Date: Tue, 21 Oct 1997 15:52:00 -0400
Sender: [email-masked]

     Bill
     
          >>...  there is no version of PGP that allows a 3rd party to

          decrypt a message without your knowledge <<
    
    I think you are making too much out this ""knowledge""  business
    
    If this is the only way to correspond, we are lucked out.
    It may be a bad example, but you may know that nicotine is bad, but
if you 
    are an addict, ...  The only effective cure is to eliminate
availability.
    
    Cheers
    
    David Gaon

______________________________ Reply Separator
_________________________________
Subject: Re: Is PGP still private?
Author:  William H. Geiger III [SMTP:[email-masked]]  at DISAHUB
Date:    10/16/97 6:39 PM

In <v03110703b06c42291a03@[206.183.203.100]>, on 10/16/97
   at 05, Roland Silver <[email-masked]> said:
     
>I'm interested in PGP 5.x, but I don't understand the criticism of it.
Do 
>certain versions of PGP have GAK or CMR capability built in? If I use 
>such a version to send a message encrypted with Alice's public key,
will 
>someone other than Alice, such as the FBI, be able to read it without
my 
>knowledge or consent?
     
>If the answer to that question is on some FAQ, please point me to it.
     
Dispite some of the FUD and Fearmongering going on, there is no version
of 
PGP that allows a 3rd party to decrypt a message without your knowledge 
(there is no backdoors in any version of PGP). Now what Alice does after

she has decrypted the message is another matter that is beyond your 
control. :)
     
Now just for the those in the "cheap seats": If you encrypt a message
with 
and only with Alice's public key then only someone who has a copy of 
Alice's private key can decrypt it. Hopefully Alice is the only one who 
has that key, but like the decrypted message, you really have no
controll 
of what Alice does with her keys.
     
--
--------------------------------------------------------------- 
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0
     
Author of E-Secure - PGP Front End for MR/2 Ice 
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html
     
---------------------------------------------------------------

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: New Draft... going forward
Date: 21 Oct 1997 18:40:37 GMT
Organization: IKS GmbH Jena
Lines: 12
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Gene Hoffman wrote:
>> So the current API does not work well with MIME itself. Sue the programmers.

>This is a common problem across most every MUA.
>
>The whole point of this thread is that ASCII armor serves a very valid
>purpose when dealing with the majority (by deployment) of MUA's in the
>world.

Ok, that's fine. So forget RfC 2015.

The actual paragraph is correct, isn't it?

Date: Tue, 21 Oct 1997 11:35:46 -0700 (PDT)
From: Gene Hoffman <[email-masked]>
Reply-To: [email-masked]
To: Lutz Donnerhacke <[email-masked]>
cc: [email-masked]
Subject: Re: New Draft... going forward
Sender: [email-masked]

This is a common problem across most every MUA.

The whole point of this thread is that ASCII armor serves a very valid
purpose when dealing with the majority (by deployment) of MUA's in the
world.

Gene Hoffman
PGP, Inc.

On 21 Oct 1997, Lutz Donnerhacke wrote:

> * Gene Hoffman wrote:
> >I need to clarify my words above a bit. The API does not give a plugin the
> >ability to easily grab currently attached attachments, modify them, and
> >hand them back with PGP/MIME compliant semantics. It does allow one to
> 
> So the current API does not work well with MIME itself. Sue the programmers.
> 

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: New Draft... going forward
Date: 21 Oct 1997 18:31:03 GMT
Organization: IKS GmbH Jena
Lines: 6
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Gene Hoffman wrote:
>I need to clarify my words above a bit. The API does not give a plugin the
>ability to easily grab currently attached attachments, modify them, and
>hand them back with PGP/MIME compliant semantics. It does allow one to

So the current API does not work well with MIME itself. Sue the programmers.

Date: Tue, 21 Oct 1997 11:25:08 -0700 (PDT)
From: Gene Hoffman <[email-masked]>
Reply-To: [email-masked]
To: Lutz Donnerhacke <[email-masked]>
cc: [email-masked]
Subject: Re: New Draft... going forward
Sender: [email-masked]

On 21 Oct 1997, Lutz Donnerhacke wrote:

> * Gene Hoffman wrote:
> >Also, to defend the need for ASCII Armor parsing in a compatable
> >application I offer up the API to Exchange/Outlook. This MUA doesn't give
> >an application plugin the ability to process MIME attachments. The default
> >message interoperability mechanism is ASCII armored encrypted blocks in
> >the message body.
> 
> Is this true for picture viewers, too?

I need to clarify my words above a bit. The API does not give a plugin the
ability to easily grab currently attached attachments, modify them, and
hand them back with PGP/MIME compliant semantics. It does allow one to
grab the filenames, encrypt the files on disk, and replace the attached
names with new names to encrypted files...

Not many Win/Mac MUA's allow one to make drastic changes to the headers
and attachments to create a PGP/MIME style message.

Gene Hoffman
PGP, Inc.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: New Draft... going forward
Date: 21 Oct 1997 18:07:28 GMT
Organization: IKS GmbH Jena
Lines: 17
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Gene Hoffman wrote:
>Also, to defend the need for ASCII Armor parsing in a compatable
>application I offer up the API to Exchange/Outlook. This MUA doesn't give
>an application plugin the ability to process MIME attachments. The default
>message interoperability mechanism is ASCII armored encrypted blocks in
>the message body.

Is this true for picture viewers, too?

>I beleive that the benefits given to having MUST understand ASCII armor,
>and SHOULD be able to generate are great compared to the implementation

Current version clarifies it. I hope it is better. "For backward
compatibility this format should be read but may not be generated."

"should" and "may" has a special meaning in RfCs. So it is exactly what you
expect.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Changes to the current draft
Date: 21 Oct 1997 18:02:31 GMT
Organization: IKS GmbH Jena
Lines: 739
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

Thank you for mailing me and discussing. (I'm now read to also accept
spelling and grammer corrections ;-})

Base directory: ftp://ftp.iks-jena.de/pub/mitarb/lutz/crypt/software/pgp/

Current history: draft-ietf-pgp-formats.changes

21.10.1997
  * Fingerprint derivated from public key format.
  * Major extentions to signature subpackets (several new types).
  * Signature subpacket derivated from general packet framework.
  * Consequently use octet instead of byte.
  * Secret key is derivated from public key.
  * Added algorith identifiers 2 (RSA encr) and 3 (RSA sign).
  * Backward compatibility derivated from packet version of public key.
  * Started different trust models used by PGP 5.x. New trust packet.

21.10.1997
  * Corrections on Ascii Armor.
  * Armor header 'Version' defined to current use.

19.10.1997
  * published fist version of the draft completely rewritten from fragments.

In detail: draft-ietf-pgp-formats.current.txt

--- draft-ietf-pgp-formats01.txt	Mon Oct 20 09:36:53 1997
+++ draft-ietf-pgp-formats.current.txt	Tue Oct 21 19:43:11 1997
@@ -1,10 +1,10 @@
 INTERNET-DRAFT                                         Lutz Donnerhacke
 Security                                               IN-Root-CA
 Expires in six months                                  Individual Network e.V.
-                                                       October 19 1997
+                                                       October 21 1997
 
 			PGP Message Exchange Formats
-		       <draft-ietf-pgp-formats01.txt>
+		       <draft-ietf-pgp-formats01a.txt>
 
 Status of this Memo
 
@@ -195,7 +195,7 @@
   - binding of a public key and a user id => "ordinary" certificate.
   - unbinding => certificate revocation certificate.
   - compromised key => key revocation certificate.
-  
+
 There are two models of key management: Hierarchical trust and Web of trust.
 
 Hierarchical key management relies on a tree of certification authorities
@@ -235,7 +235,7 @@
   3) Every key offering a certificate (to a user ID) by at least n fully
      or m marginally trusted keys is considered trusted.
   4) Repeat at 2) until the trust chain is longer than the length l.
-  
+
 The default values are n (Completes_Needed) = 1, m (Marginals_Needed) = 2, and
 l (Cert_Depth) = 4.
 
@@ -247,6 +247,9 @@
 
   Note: Some of these lacks are fixed in PGP2.6.3in. [3]
 
+PGP 5.x provides two different trust models.
+  [pgpRngMnt.c http://www.inf.ethz.ch/personal/maurer/publications]
+
 Some CAs do offer a hierarchical certification structure in addition to the
 web of trust. This may solve the problem of finding a path. But currently
 there is no solution known to define a good trust metric in the web of
@@ -295,14 +298,17 @@
 Nowadays, MIME [5] (RfC 2015) [2] should be used wherever possible.
 
 But PGP is older than MIME. So there is a proprietary session layer called
-'Ascii Armor'.
+'Ascii Armor'. For backward compatibility this format should be read but may
+not be generated.
 
 3.1.1 MIME
 
 RfC 2015 "MIME Security with Pretty Good Privacy (PGP)" [2] contains all
-information necessary to strip or apply this layer. It may make use of the
-Ascii Armor layer, but the octect stream may also encoded directly using
-MIME itself.
+information necessary to strip or apply this layer. Despite RfC 2015
+requires the use of Ascii Armor, this standard explicitly allows the level
+seven octect stream encoded directly using MIME itself (updates RfC 2015).
+This does not confuse existing applications, due to the fact that they can
+read and generate the level seven octet stream directly.
 
 3.1.2 Ascii Armor
 
@@ -324,8 +330,8 @@
 3.1.2.1 Radix-64 encoding
 
 To encode assume the file as an octect (input) stream. Take the first three
-bytes from the stream. Convert each byte into network bit order (MSB first).
-This results into:
+octets from the stream. Convert each octet into network bit order (MSB
+first). This results into:
 
 	     +--first octect-+-second octect-+--third octect-+
 	     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
@@ -423,13 +429,13 @@
 Examples:
   "-----BEGIN PGP PUBLIC KEY BLOCK, PART 3/09-----"
   introduces the third part of nine of some public keys.
-  
+
   "-----BEGIN PGP MESSAGE, PART 091-----"
   introduces the ninty first part of a generic PGP message.
-  
+
   "-----BEGIN PGP SIGNATURE-----"
   introduces a seperate digital signature.
-  
+
 Directly after the radix-64 encoded checksum line, a footer line is
 expected. It must match the corresponding header line despite the word
 "BEGIN" is replaced by "END".
@@ -445,7 +451,7 @@
 
 The following keywords are defined:
 
-  Version   -- Denotes the version used to generate this message.
+  Version   -- Denotes the program version used to generate this message.
   Comment   -- Any user defined world readable message.
   Hash      -- Used method of hashing to ease one pass processing.
                Defined are "MD5", "MD2" and  "SHA-1".
@@ -464,7 +470,7 @@
 
   -----BEGIN PGP MESSAGE-----
   Version: 2.6.3in
-  
+
   owFbx8DAYFTCWlySkpkHZDKEFCXmFedmFhdn5ucpZKdWFiv4hgaHKPj5hygUpSbn
   l6UWpabo8XIBAA==
   =3m1o
@@ -496,12 +502,14 @@
 of used message digests.
 
 Dash escaped cleartext is the ordinary cleartext where every line starting
-with a dash '-' (US-ASCII 0x2D) is prepended by the sequence dash '-'
-(US-ASCII 0x2D) and space ' ' (US-ASCII 0x20). This prevents the parser
-from recognising armor headers of the cleartext itself. The message digest
-is computed using the cleartext itself, not the dash escaped form. So it
-is possible to seperate or join a signature from or to a cleartext without
-resigning it.
+with a dash '-' (US-ASCII 0x2D) or the sequence 0x46 0x72 0x6f 0x6d 0x20
+(US-ASCII "From ") is prepended by the sequence dash '-' (US-ASCII 0x2D) and
+space ' ' (US-ASCII 0x20). This prevents the parser from recognising armor
+headers in the cleartext itself. Futhermore it is a workaround for common
+mail clients escaping the "From " sequence itself, which causes invalid a
+signature. The message digest is computed using the cleartext itself, not
+the dash escaped form. So it is possible to seperate or join a signature
+from or to a cleartext without resigning it.
 
 3.2 General packet framework
 
@@ -514,6 +522,11 @@
 single pass aware way ending with the indefinite length packet. This may
 cause temorary storage of small amounts of data.
 
+For backward compatibility the packet version of a generated message should
+not exceed the packet version of any recipient's public key. Note that
+several PGP versions rewrite the packet version of a key from two to three
+without notice.
+
 The octets of the PGP message are described in network bit order (highest
 bit first).
 
@@ -539,7 +552,7 @@
     1001 -- conventional key encrypted packet
     1011 -- literal data packet
     1100 -- keyring trust packet
-    1101 -- user id packet
+    1101 -- user ID packet
     1110 -- comment packet
     other - undefined
 
@@ -552,24 +565,23 @@
 packet version four or higher
   Bits 5-0 -- content type
 
-    000000 -- Reserved. A packet must not have a tag with this value.
-    000001 -- Encrypted Session Key Packet
-    000010 -- Signature Packet
-    000011 -- Conventionally Encrypted Session Key Packet
-    000100 -- One-Pass Signature Packet
-    000101 -- Secret Key Packet
-    000110 -- Public Key Packet
-    000111 -- Secret Subkey Packet
-    001000 -- Compressed Data Packet
-    001001 -- Symmetrically Encrypted Data Packet
-    001010 -- Marker Packet
-    001011 -- Literal Data Packet
-    001100 -- Trust Packet
-    001101 -- User ID Packet
-    001110 -- Subkey Packet
-    010000 -- Comment Packet
+    000001 -- asymmetric encrypted session key packet
+    000010 -- signature packet
+    000011 -- conventionally encrypted session key packet
+    000100 -- one-pass signature packet
+    000101 -- secret key packet
+    000110 -- public key packet
+    000111 -- secret subkey packet
+    001000 -- compressed data packet
+    001001 -- symmetrically encrypted data packet
+    001010 -- marker packet
+    001011 -- literal data packet
+    001100 -- trust packet
+    001101 -- user ID packet
+    001110 -- subkey packet
+    010000 -- comment packet
     other  -- undefined
-  
+
 3.2.2 Packet length
 
 The packet length is the amount of content octects without the CTB (3.2.1)
@@ -587,7 +599,7 @@
 The length of the packet data is stored in network byte order (see 4.1) as
 one, two or four octet value. It is recommended to use the smallest storing
 size for the length. But some implementations default this length to two or
-four bytes length if it is necessary or not.
+four octets length if it is necessary or not.
 
 Example:
   10111001 00000011 10010000 ...912 octets...
@@ -640,8 +652,8 @@
 
 4.2 Multi-Precision Integers
 
-Multi-Precision Integers (also called MPIs) are unsigned integers used to 
-hold large integers such as ones used in cryptographic calculations. 
+Multi-Precision Integers (also called MPIs) are unsigned integers used to
+hold large integers such as ones used in cryptographic calculations.
 
 An MPI consists of two pieces: a two-octet scalar number that is the length
 of the MPI in bits followed by a string of octets that contain the actual
@@ -654,8 +666,8 @@
 The storage size in octets of an MPI is the ((length of an MPI + 7) / 8) in
 addition to the length scalar number.
 
-The length field of an MPI should describe the length starting from its
-most significant non-zero bit. Software must be able to deal with leading
+The length field of an MPI should describe the length starting from its most
+significant non-zero bit. But software must be able to deal with leading
 zero bits of an MPI.
 
 4.3 Strings
@@ -699,7 +711,8 @@
 
 The key ID (6.1) is an eight octet scalar number (4.1).
 
-The algorithm identifier is one for RSA or sixteen for ElGamal.
+The algorithm identifier is one for RSA, two for RSA (encryption only), or
+sixteen for ElGamal.
 
 If the algorithm is RSA or ElGamal, the rest of the packet is the the
 encrypted session key as a MPI (4.2).
@@ -713,7 +726,7 @@
 number as follows:
           most significant octets   ... least significant octets
          0x00 0x01 session-key checksum 0x00 random(padding) 0x01
-  
+
 PGP versions 2.3 and later encode the message digest into a long enough
 number as follows:
           most significant octets   ... least significant octets
@@ -723,7 +736,7 @@
 scalar (4.1). The random padding is required to be nonzero for each octet.
 
   [The chekcsum algorithm will be added from the source.]
- 
+
 5.1.2 Signature packet
 
 A signature packet has the CTB (3.2.1) tag 2. It is used to store any
@@ -760,22 +773,22 @@
   - a signature classification octet described below.
   - a time field (4.4), when the signature was made.
   - (optionally) a two octet scalar value (4.1), containing the validity
-    period of the signature in days.
+    period of the signature in days. It must not be generated.
 
   Owing to the way the MD5 is computed for the signature, if that field is
   variable length, it is possible to generate two different messages with
-  the same MD5 hash. One would be a file of length N, with a 7-byte
-  following section consisting of a signature type byte, 4 bytes of
-  timestamp, and 2 of validity period, while the other would be a file of
-  length N+2, whose last two bytes would be the siganture type byte and
-  the first byte of timestamp, and the last three bytes of timestamp and
-  the validity period would instead be interpreted as a signature type
-  byte and a timestmap.
-  
+  the same MD5 hash. One would be a file of length N, with a seven octet
+  following section consisting of a signature type octet, four octets of
+  timestamp, and two of validity period, while the other would be a file of
+  length N+2, whose last two octets would be the siganture type octet and
+  the first octet of timestamp, and the last three octets of timestamp and
+  the validity period would instead be interpreted as a signature type octet
+  and a timestmap.
+
 The key ID (6.1) is an eight octet scalar number (4.1).
 
-The asymmetric cryptosystem algorithm identifier octet is one for RSA,
-sixteen for ElGamal or seventeen for DSS.
+The asymmetric cryptosystem algorithm identifier octet is one for RSA, three
+for RSA (signature only), sixteen for ElGamal or seventeen for DSS.
 
 The message digest algorithm identifier octet is one for MD5 or two for
 SHA-1. The message digest output is generally shorter than the input
@@ -803,7 +816,7 @@
         Null Data (code 0x05, len 0x00)
       Scalar number (0x04, len 0x??)
         Message Digest
-      
+
   Example for MD5: 30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04 10
   followed by the 16 octets of the message digest itself.
 
@@ -816,7 +829,7 @@
 If the algorithm is DSS, the rest of the packet are the the encrypted
 message digest values as two MPIs (4.2).
 
-The signature classification field describes what kind of 
+The signature classification field describes what kind of
 signature certificate this is. There are various hex values:
   00 - Signature of a message or document, pure octet stream.
   01 - Signature of a message or document, canonical text.
@@ -888,28 +901,11 @@
 must immedeatly revoke this key.
 
 A secret key packet consists of:
-  - a version octet,
-  - a time value,
-  - a valitidy period,
-  - an algorithm octet determining the asymmetric cryptosystem,
-  - algorithm specific public data of the key,
+  - a complete public key packet (5.1.4) followed by
   - an algorithm octet determining the symmetric cryptosystem,
   - optionally the initialisation vector of the symmetric encryption,
   - encrypted algorithm specific secret data of the key, and
   - a encrypted 16 bit checksum of the secret data.
-  
-The version octet is two for PGP versions <= 2.5 or three for newer PGP
-versions.
-
-The time value (4.4) determine the moment the is not valid before.
-Ususally this is the creation time of the key.
-
-The validity period is a two octet scalar number (4.1) determining the
-validity period of the key in days. If it is zero, the key ha an unlimited
-lifetime.
-
-The algorithm identifier of the asymmetric cryptosystem is one for RSA,
-sixteen for ElGamal, or seventeen for DSS.
 
 The algorithm identifier of the symmetric cryptosystem is zero for
 unencrypted (should only occur in not pagable memory), one for IDEA, two
@@ -920,33 +916,18 @@
 
 All secret fields in the secret key certificate may be (passphrase)
 encrypted, including the checksum. The checksum is calculated from all of
-the bytes of the unenciphered secret components. The public fields are not
-encrypted. The encrypted fields are done in cipher feedback mode (CFB),
-and the checksum is used to tell if the password was good. The CFB
+the octets of the unenciphered secret components. The public fields are not
+encrypted. The encrypted fields are done in cipher feedback mode (CFB), and
+the checksum is used to tell if the password was good. The CFB
 initialisation vector field is just encrypted random data using a zero
 initialisation vector.
 
-If the algorithm is RSA, the public component consits of:
-  - a MPI (4.2) of the public modulus n, and
-  - a MPI (4.2) of the public encryption exponent e
-
 If the algorithm is RSA, the secret component consits of:
   - a MPI (4.2) of the secret decryption exponent d,
   - a MPI (4.2) of the secret factor p,
   - a MPI (4.2) of the secret factor q, and
   - a MPI (4.2) of the secret multiplicative inverse u.
 
-If the algorithm is ElGamal, the public component data consists of:
-  - a MPI (4.2) of the prime p,
-  - a MPI (4.2) of the generator g, and
-  - a MPI (4.2) of the public key y (= g**x mod p where x is secret).
-
-If the algorithm is DSS, the public component data consists of:
-  - a MPI (4.2) of the prime p,
-  - a MPI (4.2) of the group order q, (prime divisor of p-1)
-  - a MPI (4.2) of the generator g, and
-  - a MPI (4.2) of the public key y (= g**x mod p where x is secret).
-
 
 5.1.4 Public key packet
 
@@ -974,10 +955,12 @@
 
 The validity period is a two octet scalar number (4.1) determining the
 validity period of the key in days. If it is zero, the key ha an unlimited
-lifetime.
+lifetime. Note that this field is not present in packet version four or
+higher.
 
-The algorithm identifier of the asymmetric cryptosystem is one for RSA,
-sixteen for ElGamal, or seventeen for DSS.
+The algorithm identifier of the asymmetric cryptosystem is one for RSA, two
+for RSA (encryption only), three for RSA (signature only), sixteen for
+ElGamal, or seventeen for DSS.
 
 If the algorithm is RSA, the public component data consists of:
   - a MPI (4.2) of the public modulus n, and
@@ -986,13 +969,13 @@
 If the algorithm is ElGamal, the public component data consists of:
   - a MPI (4.2) of the prime p,
   - a MPI (4.2) of the generator g, and
-  - a MPI (4.2) of the public key k.
+  - a MPI (4.2) of the public key y (= g**x mod p where x is secret).
 
 If the algorithm is DSS, the public component data consists of:
   - a MPI (4.2) of the prime p,
-  - a MPI (4.2) of the group order q,
+  - a MPI (4.2) of the group order q, (prime divisor of p-1)
   - a MPI (4.2) of the generator g, and
-  - a MPI (4.2) of the public key k.
+  - a MPI (4.2) of the public key y (= g**x mod p where x is secret).
 
 5.1.5 Compressed data packet
 
@@ -1034,9 +1017,9 @@
 
 The key check prefix is composed of two identical copies of the least
 significant octets of the random prefix, stored in the same order. During
-decryption, the 9th and 10th octets of decrypted material are checked to
-see if they match the 7th and 8th octets, respectively. If these key check
-bytes meet this criterion, then the conventional key is assumed to be
+decryption, the 9th and 10th octets of decrypted material are checked to see
+if they match the 7th and 8th octets, respectively. If these key check
+octets meet this criterion, then the conventional key is assumed to be
 correct.
 
 One unusual point about the way encryption is done. Using the cipher in
@@ -1099,9 +1082,9 @@
 described in 2.3. It only exists to speed up programms. It is described in
 this RfC to discuss the trust model more in detail.
 
-The meaning of the keyring trust packet is context sensitive. The trust byte
-has three different definitions depending on whether it follows a public key
-packet, a user ID packet, or a certificate on the ring.
+The meaning of the keyring trust packet is context sensitive. The trust
+octet has three different definitions depending on whether it follows a
+public key packet, a user ID packet, or a certificate on the ring.
 
 It consists of a single octet:
 			      +---------------+
@@ -1170,9 +1153,9 @@
   Bit 6    - CHECKED bit - This means that the key checking pass has tested
              this certificate and found it good. If this bit is not set, the
 	     maintenance pass considers this certificate untrustworthy.
-  Bit 7    - CONTIG bit - Means this signature leads up a contiguous trusted 
+  Bit 7    - CONTIG bit - Means this signature leads up a contiguous trusted
              certification path all the way back to the ultimately-trusted
-	     keyring owner, where the buck stops.  This bit is derived 
+	     keyring owner, where the buck stops.  This bit is derived
 	     from other trust packets.
 
 All other trust is derived from the BUCKSTOP keys in a special maintenance
@@ -1270,7 +1253,7 @@
 
 5.2 Packet version four or higher
 
-5.2.1 Encrypted session key packet
+5.2.1 asymmetric encrypted session key packet
 
 An encrypted session key packet has the CTB (3.2.1) tag 1. It contains the
 symmetric session key for symmetrically encrypted data packets (5.2.9)
@@ -1293,11 +1276,12 @@
 A signature packet has the CTB (3.2.1) tag 2. It is used to store any
 signature or certificate.
 
-The sihnature packet consits of:
-  - a version octet, (set ot four)
+The signature packet consits of:
+  - a version octet, (set to four)
   - a signature classification octet, (hashed)
   - a asymmetric cryptosystem identifier octet (hashed)
-    which is one for RSA, sixteen for ElGamal, or seventeen for DSS,
+    which is one for RSA, three for RSA (signature only),
+    sixteen for ElGamal, or seventeen for DSS,
   - a message digest algorithm (hashed)
     which is one for MD5 or two for SHA-1,
   - a two octet scalar (4.1) determining the length of the following
@@ -1310,39 +1294,80 @@
   - the algorithm specific encrypted message digest.
 
 The signature contains subpackets of the following structure:
-  - a subpacket length (1 or 2 octets):
-      Length includes the type byte but not this length,
-        1st octet <  192: length is the numerical value of this octet
-        1st octet >= 192: length is equal to
-            (1st octet - 192) * 256 + (2nd byte) + 192;
+  - a subpacket length (one, two or four octets):
+      Length includes the type octet but not these length octets.
+      Semantics of the length octets is described in (3.2.2.2)
   - a subpacket type octet, critical if higest significant bit (Bit 7)
     is set. The remaining bits six to zero are defined the type.
   - subpacket specific data
 
-The following subpacket types are defined. Some subpackets apply to the
-signature itself and some are attributes of the key. Noncritical
-subpackets may be displayed and must be ignored. Unrecognized subpackets
-should be skipped unless marked critical. Sorted by subpacked type
-(without critical bit):
+Some subpackets apply to the signature itself and some are attributes of the
+key. Noncritical subpackets may be displayed and must be ignored even if
+marked critical. Unrecognized hashed subpackets should be skipped unless
+marked critical. Subpackets of the same type may occur as often as needed.
+The following subpacket types are defined sorted by subpacked type (without
+critical bit):
+
+  1 - signatue version
+      It is an octet determining the packet version used to generate this
+      signature.
 
   2 - signature creation time
       A time value (4.4) determining the signature was made.
-      
+
   3 - signature expiration time
-      The validity period of the signature. This is an eight octet scalar
+      The validity period of the signature. This is an four octet scalar
       continaing the number of seconds after the key creation time that
       the key expires. If this is not present or has a value of zero, the
       signature never expires.
 
-  8 - user ID flags
+  4 - user ID flags
       It is an octet which is one, if the self-certificate belongs to the
-      primary user ID. Otherwise it is zero.
-  
+      primary user ID. Otherwise it is zero. This is found on a
+      self-signature.
+
+  8 - key usage
+      It is an octet used as a bit field. This is found on a self-signature.
+        +---------------+
+        |7 6 5 4 3 2 1 0|
+	+---------------+
+        Bit 0: certification of other key/user ID bindings.
+        Bit 1: signing external data.
+        Bit 2: encrypt external data for communication.
+        Bit 3: encrypt external data for storage.
+
+      If this field is missing, this field is assumed to be 0x07 (certifying,
+      signing, and encypting communication).
+
+      Storage keys must must not be used in communication. They should be
+      droped from keyrings outside the desired storage enviroment to avoid
+      message key recovery. They must not occur on public keyservers. If
+      such a key arrives over the Internet, a warning must be produced and
+      the key must be droped (prefered) or disabled locally.
+
   9 - key expiration time
-      The validity period of the key. This is an eight octet scalar
-      continaing the number of seconds after the key creation time that
-      the key expires. If this is not present or has a value of zero, the
-      key never expires. This is found on a self-signature.
+      The validity period of the key. This is an four octet scalar
+      continaing the number of seconds after the key creation time that the
+      key expires. If this is not present or has a value of zero, the key
+      never expires. This is found on a self-signature.
+
+ 10 - symmetric key recovery key
+      This option consits of a class octet, a asymmetric cryptosystem
+      identifier octet, and twenty octets of the fingerprint. The last eight
+      octets are the key ID. So only keys of the packet format four or higher
+      can be used. This is found on a self-signature.
+
+      The class octet is one, if the use of this recovery key is required.
+      If it is zero, the use of this recovery key is up to the user. If data
+      is encrypted to such a key, it must/may (depending on the class octet)
+      be encrypted to each recovery key, too.
+
+      Keys containing this subpacket are local storage keys only. They must
+      not be used in communication. They should be droped from keyrings
+      outside the desired storage enviroment to avoid message key recovery.
+      They must not occur on public keyservers. If such a key arrives over
+      the Internet, a warning must be produced and the key must be droped
+      (prefered) or disabled locally.
 
  11 - preferred symmetric algorithms
       It is an stream of symmetric cryprosystem identifier octets with the
@@ -1350,9 +1375,28 @@
       listed are supported by the recipient's software. If this subpacket
       is not included, IDEA is assumed. This is found on a self-signature.
 
- 16 - key ID of signer
-      An eight octect scalar (4.1) containing the key ID of the signer.
-
+ 16 - key ID of the signer
+      An octect scalar (4.1) containing the last part of the key ID of the
+      signer. It is useful in conjunction with packet version four or
+      higher, where it can be extended to the full twenty octets of the
+      fingerprint (6.3).
+
+ 17 - user ID of the signer
+      The content of this subpacket is the user ID the signer wants to
+      display instead of its primary user ID. If this user ID does not
+      belong to the signer's key this packet should produce a warning and
+      must be ignored.
+
+ 18 - Unified Resource Locator
+      The content of this subpacket is a URL pointing to the policy used to
+      sign this key. The purpose is to determine the trustworthiness of the
+      signer. It is especially useful for certification authorities.
+
+ 19 - finger
+      The content of this subpacket is an e-mail address to finger for the
+      current public key of the signer. Providing this the verifier is able
+      to obtain the key (revocation certifcate) without problems. This finger
+      address should provide the key at least for the lifespan of the key.
 
 5.2.3 Conventionally encrypted session key packet
 
@@ -1489,7 +1533,15 @@
 A trust packet has the CTB (3.2.1) tag 12. It is an internal orgnaisation
 packet.
 
-The content is exactly the same as described in 5.1.8.
+A trust packet consits of one to tree octets as follows:
+  - a traditional trust octet (described in 5.1.8),
+  - a validity name octet, and
+  - a confidend introducer octet.
+
+The validity name octet and the confidend introducer octet may only present
+directly after a user ID packet. Both are generated using a more complex
+trust model. They should be written to KEYLEGIT if the trust packets are
+exported to a packet version of three or lower.
 
 5.2.13 User ID packet
 
@@ -1532,16 +1584,19 @@
 
 6.1 Key ID
 
-The key ID is the lower 64 bits of the modulus of a RSA key stored in
-packet version three or lower. The key ID is the lower 64 bits of the
-public key of en ElGamal or DSS key in packet version three or lower. It
-is trivial to forge.
+The key ID is the lower 64 bits of the modulus of a RSA key stored in packet
+version three or lower. The key ID is the lower 64 bits of the public key of
+an ElGamal or DSS key in packet version three or lower. It is trivial to
+forge.
 
 The key ID is the lower 64 bit of the fingerprint (6.3) of a key stored in
 packet version four or higher.
 
-Due to independed decentral key generation it is possible, that two keys
-has the same key ID. There is no guarantee nor any method to prevent this.
+Storing the same key in different packet versions cause the key to have
+different key IDs.
+
+Due to independed decentral key generation it is possible, that two keys has
+the same key ID. There is no guarantee nor any method to prevent this.
 That's why the key ID must be considered as not unique. Several keys with
 the same key ID must be handeled by software without any problem.
 
@@ -1581,12 +1636,12 @@
 
   UserID2 has two fully trusted certificates, eight marginal trusted
   certificates, and one untrusted certificate.
-  
+
   COMPLETES_NEEDED is two and MARGINALS_NEEDED is six.
-  
+
   So UserID1 has an 'trust value' of 3/2 + 6/6 = 2.5
   So UserID2 has an 'trust value' of 2/2 + 8/6 = 2.333...
-  
+
   UserID1 is choosen as the primary user ID.
 
 6.2.2 Matching multiple user IDs
@@ -1618,7 +1673,7 @@
 human readble informations about the e-mail address given. Non US-ASCII
 characters must be encoded using MIME [5]. "[email-masked]" is the e-mail
 address of the user. "Options" is any combination of:
-  
+
   Key usage (only one of the following may be used in a user ID)
     SIGN -- sign external octet streams (documents).
     ENCR -- encrypt external octet streams to the receiver.
@@ -1630,7 +1685,7 @@
     any cryptographic use of such keys except verifying signatures and
     certificates made while the key was valid. yyyy is the year, mm the
     month, and dd the day the key expires.
-  
+
   IN-CA:do.main
     Denotes the responsible IN-CA for the person certified by this CA.
     It is safe to ignore this option but generation should not be
@@ -1649,11 +1704,13 @@
 fingerprint and the length of the key components are a good characteristic
 for a key.
 
-Packet version four or higher use SHA-1 to hash a few header bytes
-followed by the entire public key packet starting with the version field.
-Here are the fields of the hash material:
+Packet version four or higher use SHA-1 to hash a few header octets followed
+by the entire public key packet starting with the version field. Here are
+the fields of the hash material (essentially a complete public key packet
+(5.2.6) coded with in the wrong packet version, changing this would
+definitly ease programming and invalidating existing fingerprints):
 
-  - 0x99 (one octet),
+  - CTB of version <= three public key packet: 0x99 (one octet),
   - a two octet scalar (4.1) containing the length of the following data,
   - the version number (one octet),
   - the time stamp of key creation (4.4),
@@ -1683,7 +1740,7 @@
 8. Notes
 
 PGP and Pretty Good Privacy are trademarks of Pretty Good Privacy, Inc.
-   
+
 9. Security Considerations
 
 ....
@@ -1725,7 +1782,7 @@
 
   [8] D. Crocker, "Standard for the format of ARPA Internet text
       messages", RfC 822, August 1982
-  
+
   [9] D. Balenson, "Privacy Enhancement for Internet Electronic Mail: Part
       III: Algorithms, Modes, and Identifiers", RfC 1423, October 1993

Date: Tue, 21 Oct 1997 10:18:07 -0700 (PDT)
From: Gene Hoffman <[email-masked]>
Reply-To: [email-masked]
To: Ian Grigg <[email-masked]>
cc: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: Re: New Draft... going forward
Sender: [email-masked]

On Tue, 21 Oct 1997, Ian Grigg wrote:

> 
> We only theoretically have the option to not require it.  The number of
> people using anything other than 2.6 or thereabouts is minute compared
> to the installed base of "classic" PGP.  Any clues on how many copies of
> 5.* have been sold?
> 

Some quick rough numbers. On the MIT keyservers there are now about 95,000
new public keys since 5/20. Of them 85% are DSS/DH(El Gamal) keys. Before
that I beleive that there were ~20K RSA keys...

-Gene Hoffman
PGP, Inc.

Date: Tue, 21 Oct 1997 10:14:04 -0700 (PDT)
From: Gene Hoffman <[email-masked]>
Reply-To: [email-masked]
To: Paul Hoffman / IMC <[email-masked]>
cc: [email-masked]
Subject: Re: New Draft... going forward
Sender: [email-masked]

On Mon, 20 Oct 1997, Paul Hoffman / IMC wrote:

> At 07:29 PM 10/20/97 -0500, William H. Geiger III wrote:
> >There is no need to modify the MIME toolkit or at least none above what
> >must be already done to accommodate incorporating PGP/MIME types. The
> >ascii armor encoding is handled by PGP and would be included in any PGP
> >toolkit a programmer may be using.
> 
> I don't understand why you think that everyone will use a PGP toolkit. One
> of the main purposes of us doing the open spec work is so that people don't
> have to use anyone else's toolkits. If we assume everyone will use a PGP
> toolkit, there's no need to do this work in the IETF. Simply let PGP, Inc.
> specify what is PGP x.y and be done with it.
> 

There are quite a few other toolkits that implement PGP, and I don't think
that Hal was implying that everyone would buy a toolkit from PGP, Inc. 
Odds are that other implementors (especially since they do not have to pay
anyone any royalties for any of the algorithims if they implement them
themselves) will offer fully functional "PGP" capable toolkits. 

Also, to defend the need for ASCII Armor parsing in a compatable
application I offer up the API to Exchange/Outlook. This MUA doesn't give
an application plugin the ability to process MIME attachments. The default
message interoperability mechanism is ASCII armored encrypted blocks in
the message body.

I beleive that the benefits given to having MUST understand ASCII armor,
and SHOULD be able to generate are great compared to the implementation
difficulty. Can we just include a source snippet in the draft and move on
to the next problem?

Gene Hoffman
PGP, Inc.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: New Draft... going forward
Date: 21 Oct 1997 15:45:49 GMT
Organization: IKS GmbH Jena
Lines: 9
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Hal Finney wrote:
>However it is an oversimplification to speak of the "real packet
>version".  The version field in a packet should describe the version of
>the _packet_, not of the software.  PGP messages are often composed of a

... of the packets ... they may be different.

So we need a new header? No.
So we need to redefine the header for a new purpose? Of course, no.

Date: Tue, 21 Oct 1997 07:18:45 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: New Draft... going forward
Sender: [email-masked]

Ian Grigg <[email-masked]> writes:
> So, the standard should at least point out that the "Version" field is
> akin to a comment by the software agent that produced the packet, and
> the contents are not formally indicative of any compatibility
> information.  Even to point out that the real packet version is embedded
> in the octet stream at x.x.x.x would be useful.

I agree that version strings are mostly intended for human readers and
are not going to be too useful to software.

However it is an oversimplification to speak of the "real packet
version".  The version field in a packet should describe the version of
the _packet_, not of the software.  PGP messages are often composed of a
sequence of packets, or of packets nested with various transformations.
Different packets in the message may have different versions.

So it will not make sense to look for the real version of a message
at offset such-and-such, because there is really no concept of message
version.

Hal

Date: Tue, 21 Oct 1997 11:48:08 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Lutz Donnerhacke <[email-masked]>
CC: [email-masked]
Subject: Re: New Draft... going forward
Sender: [email-masked]

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

Lutz Donnerhacke wrote:
> 
> * Paul Hoffman / IMC wrote:
> >I hope that the next version of the OpenPGP draft says what is required,
> >what is suggested, and what's completely optional. The phrase at the
> 
> Should I? Suggestions?

My position is that the first draft should seek to document the existing
software.  If the existing software has optional paramaters, then it can
say that.

However, as a practical issue, we need to pick a single, published code
base from which to derive a standard.  My understanding is that this is
PGP 5.0.  Therefore, the logical approach is to document what PGP 5.0
does.  From this point of view, there is no inherent need to "suggest"
or make optional, because PGP 5.0 does it or it doesn't.

However, there will be some points of confusion, as PGP does make some
difficult choices that fly at odds with something or somebody
somewhere.  The two contentions that spring to mind are:

   * the infamous CMRK packets that play their part
     in an emerging PGP architecture to meet corporate needs,

   * the decision to default to ElGamal keys, which is
     incompatible with 2.6 and before.

Not entering into IMHOs at this point, these are issues where I can see
that this forum must debate the relative merits of the code's approach
(i.e. PGP 5.0) and decide to accept, reject or modify.  Here, clearly,
the require/suggest/may language becomes more appropriate.

However, these areas are relatively minor.  On the whole, I believe we
need a standard that basically documents 5.0.  Then we can start working
on mods and improvements.

Standards are about compatibility and bringing the existing users
together.  Not about new work.  New work is done by lone hackers
greeting the dawn with that last bug fix.  Standards are done by
committees.  This forum seems to fall into the latter category to me.

- -- 
iang                                      systemics.com

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

Date: Tue, 21 Oct 1997 11:31:43 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Lutz Donnerhacke <[email-masked]>
CC: [email-masked]
Subject: Re: New Draft... going forward
Sender: [email-masked]

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

Lutz Donnerhacke wrote:
> 
> On Mon, Oct 20, 1997 at 07:33:14PM +0100, Mike Wynn wrote:
> > Because this is an Open protocol I think that the
> > "Version" should be split into two parts
> > one part which is which protocol version and
> > the other part who's program wrote it and its version
> > currently there is PGP versions and Cryptix Versions
> 
> You are correct in pointing out, that the Version is the program version.
> The packet version should not supplied by the header, due to the fact, that
> this information comes out while parsing the octet stream. Providing such a
> packet version armor header causes trouble due to software denoting a
> maximum value and using lower ones in the real message. Providing the really
> used packet version violates the one pass principle.

This is a very useful clarification, I have often been confused over
this point.

So, the standard should at least point out that the "Version" field is
akin to a comment by the software agent that produced the packet, and
the contents are not formally indicative of any compatibility
information.  Even to point out that the real packet version is embedded
in the octet stream at x.x.x.x would be useful.

I think this clarification would be useful because of the temptation to
treat the Version: as a version simply because it says so.  In practice,
I suspect many writers of scripts will quite happily apply this logic
(Version: is version) because they rely on downstream software to
interpret the byte stream, but need clues now to work out what packet
they are holding.

In an ideal world, we could then consider changing the name of the field
to something like "Agent:" or "Software:" or "Produced by:" or "Message
from our sponsor:" ... however I personally would shrink from suggesting
a gratuitous change.
- -- 
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: KeyIDs and Key Fingerprints
Date: 21 Oct 1997 11:20:12 GMT
Organization: IKS GmbH Jena
Lines: 15
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* William H. Geiger III wrote:
>I can see where in a Public keyserver environment it is easier to allow
>duplicate keyID's to prevent a DOS attack with a spoofed key. For a
>corporate keyserver or a local keyring I am not sure if allowing these
>keys into the database is a wise thing.

Local databases may apply a completely other policy on accpeting keys.
My current policy is to not add untrusted keys, not selfsigned user IDs, and
ask if duplicates arrive.

>I may be wide off on this one but it just seems to be a bad design
>approach to allow non-unique identifyers in the PGP packets and then try
>every key that matches it.

Defining something unique without any guarantee to be is even worse.

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 21 Oct 97 04:38:34 -0500
To: [email-masked] (Lutz Donnerhacke)
Cc: [email-masked]
Subject: Re: KeyIDs and Key Fingerprints
Sender: [email-masked]

In <[email-masked]>, on 10/21/97 
   at 08, [email-masked] (Lutz Donnerhacke) said:

>* William H. Geiger III wrote:
>>Well I think we should have had some disscussion on this. This really
>>plays havok on keyring lookups & management if keyID is nolonger unique.
>>If this is the tact to be taken then we should look at the encrypt & sig
>>packets and find a unique identifier to use with them perhaps just put the
>>whole fingerprint there. Without a unique identifyer there will be a
>>marked decrease of performance in PGP operations in areas where PGP
>>performance is poor to begin with.

>I do not know how to deal with key ID attacks, birthday phenomena, and
>user provided parts of the key/user ID without defining the key ID as not
>unique.

>A local database does not depend on the uniqueness of the global key ID.
>But we know, that if it tries to depend on it, it is attackable.

>Normally a key database is small. (large databases are still very slow in
>current versions of PGP due to bad implementation) So only a few keys has
>to be tried. Normally only a single key has to be tried. If 0xdeadbeef
>keys are removed locally, this is even true for attacked enviroments.

Well the way I see it we have 2 possabilities for duplicate keyID's:

1) Collision. Does anyone know what the probability of 2 users generating
2 unique keys with the same keyID? If this number is high then perhaps we
should look at either using the fingerprint in the PGP packets or
providing additional info in the packets to provide uniqueness.

2) Diliberate Attack. We know of the common attacks aginst the keyID &
Fingerprint with the PGP 2.6.x keys. Are the DSS/DH keys also open to such
attacks? Is it realy wise to allow these keys to be added to the keyring
in the first place or should the user when confronted with duplicate
keyID's be required to take futher action? 

I can see where in a Public keyserver environment it is easier to allow
duplicate keyID's to prevent a DOS attack with a spoofed key. For a
corporate keyserver or a local keyring I am not sure if allowing these
keys into the database is a wise thing.

I may be wide off on this one but it just seems to be a bad design
approach to allow non-unique identifyers in the PGP packets and then try
every key that matches it.

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

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

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: KeyIDs and Key Fingerprints
Date: 21 Oct 1997 08:32:00 GMT
Organization: IKS GmbH Jena
Lines: 19
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* William H. Geiger III wrote:
>Well I think we should have had some disscussion on this. This really
>plays havok on keyring lookups & management if keyID is nolonger unique.
>If this is the tact to be taken then we should look at the encrypt & sig
>packets and find a unique identifier to use with them perhaps just put the
>whole fingerprint there. Without a unique identifyer there will be a
>marked decrease of performance in PGP operations in areas where PGP
>performance is poor to begin with.

I do not know how to deal with key ID attacks, birthday phenomena, and user
provided parts of the key/user ID without defining the key ID as not unique.

A local database does not depend on the uniqueness of the global key ID.
But we know, that if it tries to depend on it, it is attackable.

Normally a key database is small. (large databases are still very slow in
current versions of PGP due to bad implementation) So only a few keys has to
be tried. Normally only a single key has to be tried. If 0xdeadbeef keys are
removed locally, this is even true for attacked enviroments.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: New Draft... going forward
Date: 21 Oct 1997 08:17:27 GMT
Organization: IKS GmbH Jena
Lines: 12
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Paul Hoffman / IMC wrote:
>I hope that the next version of the OpenPGP draft says what is required,
>what is suggested, and what's completely optional. The phrase at the

Should I? Suggestions?

>beginning of 3.1.1 of the OpenPGP draft seems wrong in that it says that
>you can follow RFC 2015 and carry either ASCII armor or binary data;
>however, RFC 2015 clearly says that you must use ASCII armor (in the second
>sentence of section 2 of that document).

Fixed.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: New Draft... going forward
Date: 21 Oct 1997 08:10:13 GMT
Organization: IKS GmbH Jena
Lines: 7
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* William H. Geiger III wrote:
>I have to agree here, so long as there is a *large* userbase of 2.6.x
>users Ascii Armor is far from outdated. I see very little advantage here

There is no problem. The is a *large* userbase of 2.6.x AND MIME compilant
software. Nearly everybody can pipe a base64 encoded stream as a pure octet
stream into any current version of PGP.

Date: Tue, 21 Oct 1997 09:31:15 +0200
From: Lutz Donnerhacke <[email-masked]>
To: Mike Wynn <[email-masked]>
Cc: [email-masked]
Subject: Re: New Draft... going forward
Sender: [email-masked]

On Mon, Oct 20, 1997 at 07:33:14PM +0100, Mike Wynn wrote:
> Because this is an Open protocol I think that the
> "Version" should be split into two parts
> one part which is which protocol version and
> the other part who's program wrote it and its version
> currently there is PGP versions and Cryptix Versions

You are correct in pointing out, that the Version is the program version.
The packet version should not supplied by the header, due to the fact, that
this information comes out while parsing the octet stream. Providing such a
packet version armor header causes trouble due to software denoting a
maximum value and using lower ones in the real message. Providing the really
used packet version violates the one pass principle.

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 20 Oct 97 22:03:01 -0500
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Subject: Re: New Draft... going forward
Sender: [email-masked]

In <[email-masked]>, on 10/20/97 
   at 09, Paul Hoffman / IMC <[email-masked]> said:

>At 07:29 PM 10/20/97 -0500, William H. Geiger III wrote:
>>There is no need to modify the MIME toolkit or at least none above what
>>must be already done to accommodate incorporating PGP/MIME types. The
>>ascii armor encoding is handled by PGP and would be included in any PGP
>>toolkit a programmer may be using.

>I don't understand why you think that everyone will use a PGP toolkit.
>One of the main purposes of us doing the open spec work is so that people
>don't have to use anyone else's toolkits. If we assume everyone will use
>a PGP toolkit, there's no need to do this work in the IETF. Simply let
>PGP, Inc. specify what is PGP x.y and be done with it.

<sigh> the majority of developers are going to use some type of toolkit
for developing OpenPGP apps (or directly communicate with the PGP exe's).
You realy don't think thay are all going to spend the time required
developing there own crypto algorithms do you?? This has nothing to do
with PGP, Inc. as there are other 3rd party toolkits available or in
development.

>>As a matter of fact any Open PGP
>>implementation would require a programmer be able to use ascii armor so
>>his program can process messages generated by older version of PGP.

>We definitely have the option of requiring that. We also have the option
>of not requiring it.

>>You
>>are not seriously advocating that an Open PGP application be unable to
>>process these older formats are you??

>I most certainly am. 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.

I strongly dissagree with this. By not being able to process the older
formats you have completly cut off a large section of curent PGP users. So
now your developers not only have to add PGP support but also have to do
the work of porting PGP itself to the operating system they are developing
on. This is a BadThing(TM) and will do more to push users to competing
specs than anything else.

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

I see, so one implementation could only process say RSA keys while another
would only process DSS/DH? One would only use MD5 while another only used
SHA1? This doesn't sound like much of a *standard* at all. Obviously there
will have to be a base set of algorithms that are *MUST* for compatibilty
reasons so far I have seen no valid reason for ascii armor not being
included in that set.

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

Obviously you have little understanding of why there is the "I woun't
bother" attatude. I have been activly involved in getting various software
vendors to include PGP support for their products for quite awhile now
(longer than there has been a PGP, Inc.). some of the more common reasons:

-- Lack of understanding the need for any encryption at all.
-- Lack of knowedge of even the most basic encryption principles. -- Lack
of proper documentation on how to integrate PGP into their products. --
Lack of tools to do so easily.
-- Lack of demand by their users.

Now added to this are items perticular to the OS/2 enviroment:

-- Lack of toolkit for OS.
-- Lack of comercial version of program.
-- General lack of support for OS. 

Now I have been doing my best addressing these issues including porting
5.0 to OS/2, documenting implementation techneques, numerious
correspondance & phone calls to various vendors, currently developing a
PGP toolkit, ... ect. It has been a real up hill battle and now you want
to make it that much harder by allowing OpenPGP application be
non-compatiable with previous implemntations! PGP Inc was smarter than
that when they came out with 5.0 by supporting old 2.6.x formats, the IMAP
group was smarter than that by including support for POP3. This is nothing
new nor unusal in providing backward compatablilty in a new standard. By
taking out backward compatabilty from the specs you have thrown away the
biggest motiviation to go with OpenPGP rather than some other standard:
the current PGP user base.

>I hope that the next version of the OpenPGP draft says what is required,
>what is suggested, and what's completely optional. The phrase at the
>beginning of 3.1.1 of the OpenPGP draft seems wrong in that it says that
>you can follow RFC 2015 and carry either ASCII armor or binary data;
>however, RFC 2015 clearly says that you must use ASCII armor (in the
>second sentence of section 2 of that document).

Well I hope before the next draft comes out that we have some debate on
the list here of what is required, what is suggested, and what is
optional. Now the keyID's & the ascii armor are two changes that have
never been disscused here before this draft was compiled I imagine that
there are more. IMHO any changes from the curent PGP implemntations need
to be examined and justifyed before they are added to the specs.

As far as the must use ASCII armor in RFC 2015 there were valid reasons
for this when we developed the RFC and those reasons are still valid
today.

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

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

Date: Tue, 21 Oct 1997 03:17:37 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: New Draft... going forward
Sender: [email-masked]

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

Paul Hoffman / IMC wrote:
> 
> At 07:29 PM 10/20/97 -0500, William H. Geiger III wrote:
> >There is no need to modify the MIME toolkit or at least none above what
> >must be already done to accommodate incorporating PGP/MIME types. The
> >ascii armor encoding is handled by PGP and would be included in any PGP
> >toolkit a programmer may be using.
> 
> I don't understand why you think that everyone will use a PGP toolkit. One
> of the main purposes of us doing the open spec work is so that people don't
> have to use anyone else's toolkits. If we assume everyone will use a PGP
> toolkit, there's no need to do this work in the IETF. Simply let PGP, Inc.
> specify what is PGP x.y and be done with it.

This is a confusion of the two meanings of PGP - another issue in itself
that must be sorted out before we can really finish the standard.

Every programmer will use a toolkit that implements PGP format tools. 
Whether they choose the one supplied by PGP, Inc is up to them.

Or, to put it another way, if your programmers are not using a toolkit,
then you have more problems than worrying about Ascii Armouring.  In all
probability, they are using an old codebase that needs replacing with a
proper toolkit.  PGP Inc have one, I recall there are a few floating
around, including a couple in the <plug> Cryptix </plug> libraries.

> >As a matter of fact any Open PGP
> >implementation would require a programmer be able to use ascii armor so
> >his program can process messages generated by older version of PGP.
> 
> We definitely have the option of requiring that. We also have the option of
> not requiring it.

We only theoretically have the option to not require it.  The number of
people using anything other than 2.6 or thereabouts is minute compared
to the installed base of "classic" PGP.  Any clues on how many copies of
5.* have been sold?

> >You
> >are not seriously advocating that an Open PGP application be unable to
> >process these older formats are you??
> 
> I most certainly am. 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.

Hardly.  They simply choose not to choose on the basis of this unneeded
feature.  All products are standardised around a set of features that is
good for most of the people and perfect for none of them.  Ignoring
non-specific features is part of their selection process.

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

True, we can construct these scenarios.  Fact is, the majority of
implementators and the majority of interested parties are here because
they have existing applications, existing code bases, existing needs. 
We'll worry about futures once we get out code into shape.

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

"Complete and secure" is not the only goal.  Standardisation necessarily
accomodates the existing implementations.  Are you seriously suggesting
that the process of standardisation would ignore major features of
existing implementations, such as the favoured method of message
passing?  That's not standardisation as I know it; that's a new
protocol.

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

A simple and useful spec that doesn't talk to the millions of 2.6 users
out there is an contradiction in terms, at least if we are still talking
about standardisation.  Just look at the chaos in the market place as
people bump into the allegedly compatible PGP 5 programs with their
incompatible default keys.  Not that I don't sympathise with PGP Inc for
their patent grumbles, but what made them think the users would accept
PGP Inc's problems with willing arms?  Users don't give a damn, they
just want to send messages.  And if the messages don't get through, then
the program doesn't work.

- -- 
iang                                      systemics.com

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

Date: Mon, 20 Oct 1997 19:17:55 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: New Draft... going forward
Sender: [email-masked]

At 07:29 PM 10/20/97 -0500, William H. Geiger III wrote:
>There is no need to modify the MIME toolkit or at least none above what
>must be already done to accommodate incorporating PGP/MIME types. The
>ascii armor encoding is handled by PGP and would be included in any PGP
>toolkit a programmer may be using.

I don't understand why you think that everyone will use a PGP toolkit. One
of the main purposes of us doing the open spec work is so that people don't
have to use anyone else's toolkits. If we assume everyone will use a PGP
toolkit, there's no need to do this work in the IETF. Simply let PGP, Inc.
specify what is PGP x.y and be done with it.

>As a matter of fact any Open PGP
>implementation would require a programmer be able to use ascii armor so
>his program can process messages generated by older version of PGP.

We definitely have the option of requiring that. We also have the option of
not requiring it.

>You
>are not seriously advocating that an Open PGP application be unable to
>process these older formats are you??

I most certainly am. 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.

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

I hope that the next version of the OpenPGP draft says what is required,
what is suggested, and what's completely optional. The phrase at the
beginning of 3.1.1 of the OpenPGP draft seems wrong in that it says that
you can follow RFC 2015 and carry either ASCII armor or binary data;
however, RFC 2015 clearly says that you must use ASCII armor (in the second
sentence of section 2 of that document).

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 20 Oct 1997 17:56:49 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: encryption key expiry in pgp5.x
Sender: [email-masked]

Adam Back writes:
> You could combine with the conventional ESK, then there would be 3
> symmetric keys, and you would actually be encrypting the bulk of the
> data in each file with a random key k1, that key would be encrypted
> with k2 and ESK(k2,k1) would be stored at the begining of the file,
> and k2 could be itself stored encrypted in the secret key ring,
> encrypted with symmetric key k3 derived from the passphrase with a
> hash function (storing: E(k3,k2)).

This three-level encryption sounds complicated, and there are some
problems.  You are introducing new kinds of dependencies between files
which haven't existed before.  Now, if you delete (or lose) your secret
keyring file, you won't be able to decrypt files that you encrypted
with a passphrase!  (Modulo recovery issues - consider a personal
user who doesn't use any kind of recovery key.)  Or what happens if
you want to use a different passphrase for different files?  Now you
have to start putting multiple encrypted keys into the secret keyring.
We'd have to keep track of how many different passphrases you had used
for conventional file encryption, and see if your new passphrase matches
any you have used before.

It's a big change and it introduces new risks of data loss.  I think
this is an idea which needs more thought before it could be seriously
considered.

> Now to go back one post, the point of all the above discussion was
> that you had a potential problem when a user expired and securely
> wiped an old encryption key, say every 6 months, and didn't want to
> lose mail archives.  Does the above sound like a reasonable way to
> solve this problem?

We have agreed that the current file formats basically will support
this, modulo the transparent-passphrase-change issue.  The remaining
issues are mostly matters of user interface and software configuration.
With some mail UAs this system could work, while others won't support
it very well.  If you are serious about permanently deleting the key
you have to be 100% sure that your system is foolproof and no data got
stashed away somewhere encrypted with that key.  It is not a technical
issue but a matter of usability and practicality.

I would like to see our spec be flexible enough to accomodate the
various ways that people are going to want to use the system, and it
sounds to me like it is adequate regarding this point.  Once we have
achieved this then, as they say, it is up to the market to decide.
Given the controversy surrounding these issues it seems best to keep
the spec flexible and able to support different ideas and approaches.

I realize that you are unhappy with features in PGP's latest products,
but you will have to take this up with management.  I continue to believe
that this is not the proper forum for political discussions.

Hal Finney

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 20 Oct 97 19:29:26 -0500
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Subject: Re: New Draft... going forward
Sender: [email-masked]

In <[email-masked]>, on 10/20/97 
   at 04, Paul Hoffman / IMC <[email-masked]> said:

>>>The primary reason ascii armor was chosen was for the case of encrypted
>>>messages.  The way RFC2015 is currently worded, a non-MIME mail user can
>>>simply pipe the whole message to pgp and everything will work just fine
>>>without the need for any additional software.  It also makes even
>>>MIME-compliant software easier to write.
>>
>>I have to agree here, so long as there is a *large* userbase of 2.6.x
>>users Ascii Armor is far from outdated. I see very little advantage here
>>of switching from Ascii Armor to Base64 other than adding one more PITA
>>for backward compatibility.

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

There is no need to modify the MIME toolkit or at least none above what
must be already done to accommodate incorporating PGP/MIME types. The
ascii armor encoding is handled by PGP and would be included in any PGP
toolkit a programmer may be using. As a matter of fact any Open PGP
implementation would require a programmer be able to use ascii armor so
his program can process messages generated by older version of PGP. You
are not seriously advocating that an Open PGP application be unable to
process these older formats are you??

>Another is that the spec does not fully specify how to do ASCII armor,
>specifically how to create the checksum. Not only does the draft not
>specify how to do this, it references a book that is "out of stock
>indefinitely" according to the publisher.

That's what source code is for. :) Serriously I had not noticed that RFC
1991 did not have the checksum info and it should be updated to include
that info.

>I strongly favor backward compatibility with the installed base, but not
>at the expense of losing developers over unneeded features. Since a
>description of ASCII armor has already been published (well, minus how to
>do th checksums) in RFC 1991, any developer who cares about backward
>compatibilty can become backward compatible.

This is silly, I really can't see anyone saying "I'm not going to support
PGP because it uses ASCII armor encoding". As far as I can see there is
nothing incompatible with using ascii armor in MIME formatted messages
neither can I see any significant improvement by not using it especially
considering the ability to process ascii armor messages will be required
in any PGP application for the forseeable future. Backward compatibility
is a serious issue, especially if you are working with one of the
"unblessed" Operating Systems.

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

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

Date: Tue, 21 Oct 1997 01:15:32 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: encryption key expiry in pgp5.x
Sender: [email-masked]

Hal Finney <[email-masked]> writes:
> One problem with pgp -c in older versions of PGP is that all the files
> are encrypted with the same session key (assuming all use the same
> passphrase).

True.  They have random IVs though, which helps.  The conventional ESK
construct you described below is another way of having different keys. 

Encrypted partitions such as SFS, PGPdisk, cfs, and so on seem to
manage with symmetric crypto, and indeed nearly have to for
performance reasons.  (They also use various other tricks, such as
mixing in block numbers as IVs, using non-conventional modes etc).

> Generally it is better to switch session keys frequently, which pgp
> -e does for you (every file uses a different session key).  Of
> course we believe the ciphers we are using are strong, so it is not
> a major security leak, but all else being equal it is good to have
> the frequent rekeying.

If performance is not an issue, you can use pgp -e with a long term
storage-only key as you describe.

I think it was you who mentioned a couple of posts back that you
expected a storage-only key would be symmetric.  It is mostly a
performance issue.

> The new PGP conventional ESK (encrypted session key) packet works
> something like this.  It supports the use of a random session key k1 to
> encrypt the data, with k1 then encrypted under a key k2 which is derived
> deterministically from the passphrase.  However it puts E(k2,k1) at the
> front of the file, along with any public ESKs, rather than putting them
> into the secret keyring.

Just depends on whether you want to have to recover each file
manually, or recover the lot at once.  An ergonomics trade off.  You
could do either.  But it just seemed to me that if you have to call in
the company recovery key holder every time you find another file that
needs recovering (after you've forgotten the passphrase), that the
recovery key holder might get overworked.  Or if you apply it
separately to each encrypted message in your mail folder, similarly
you don't want to call the overworked recovery key holder to look at
another old mail you decided you want to read.

> I think your idea requires the use of the same k1 everywhere, which again
> suffers from the problem of providing lots of ciphertext encrypted under
> the same key.

You could combine with the conventional ESK, then there would be 3
symmetric keys, and you would actually be encrypting the bulk of the
data in each file with a random key k1, that key would be encrypted
with k2 and ESK(k2,k1) would be stored at the begining of the file,
and k2 could be itself stored encrypted in the secret key ring,
encrypted with symmetric key k3 derived from the passphrase with a
hash function (storing: E(k3,k2)).

You can have public key crypto if you want the performance penalty for
the extra assurance of a public key encryption function for the
encryption of k1.  Doesn't affect main design point which is below...

> It's not clear how much you gain by being able to change your passphrase
> once a month if the files are still encrypted under the same old key.
> You're going to increase your chance of forgetting a passphrase but you
> don't seem to gain much security.

This isn't the point of it.  The point of it is that PGP Inc has
stated the user requirement of recovery of local files in case the
user forgets their passphrase.  You don't want to have to "recover"
each file individually, nor search the disk and "re-encrypt" all files
because it is inconvenient, and because many of them may be on a
backup tape or something.  (Well you can if you want, but I think it
may seem more reasonable to a user if they could more easily recover
from a forgotten passphrase).

The scenario is that you have forgotten your passphrase to your
storage-only key (be that symmetric or asymmetric).  You want to
recover the ability to decrypt those files, but you don't necessarily
want to have to choose the same passphrase again (you've forgotten it,
and if the hash is one-way, you can't re-create it from the key, an
alternative would be I suppose to actually allow recovery of the
passphrase.)

But anyway, I think it is nice to be able to change passwords in
general though because if you figure someone has shoulder surfed your
password during a demo, well you can just go change it.  With what you
have suggested you would have to decrypt and re-encrypt all files on
the disk, and on backup media just to change the passphrase.

I presume this was the motivation for the password change feature in
SFS, which uses an indirection something like your conventional ESKs;
previous versions you had to wait for the disk to decrypt and
re-encrypt to change the passphrase.  It's even worse for manually
encrypted files they may not be on the disk.

> > My CDR proposal is this extension to the above:
> >
> > Also encrypt recovery information so that your storage key k1 can be
> > recovered by second parties if you forget the passphrase.  So also
> > within the private key ring you would store: RSA(pk_r, k1), where pk_r
> > is the public recovery key, for your company, or close friend, lawyer,
> > etc.
> 
> PGP supports a mix of conventional (symmetric) ESK packets and public key
> ESK packets (not in the UI yet, though).  This will allow messages which
> can be decrypted by any of a set of key holders, or anyone who knows
> one or more passphrases.  This could be used for encryption to a group of
> people where some of them don't have public keys for some reason, but you
> share a passphrase with them via some out-of-band means.

OK, so it directly supports what I described already.

Now to go back one post, the point of all the above discussion was
that you had a potential problem when a user expired and securely
wiped an old encryption key, say every 6 months, and didn't want to
lose mail archives.  Does the above sound like a reasonable way to
solve this problem?

(ie encrypt the mail archive with the use of the "mix of conventional
(symmetric) ESK packets and public key ESK packets" you describe.  Or
simply two crypto recipients, so all keys are asymmetric if you
prefer.  One is your key, the other is to allow the recovery key
holder to recover your mail folder if you forget the key.)

So, now you can expire encryption keys easily without having to
re-encrypt anything... I think it works reasonably well, and means
that you never have to let storage recovery information go over the
wire.

This to me is the obvious intuitive way to acheive data recovery,
rather than include recovery information as a crypto recipient and try
to enforce that the sender do this.

The nice statement of intent flags can still be used on the public key
to say that the mail folder is planned to be stored recoverable by the
company.

(I think an advantage to using symmetric crypto to encrypt the
individual messages in the mail folder is that way once the key was
available, you could quickly scroll through and read encrypted posts
looking for one... the mailer I have now (emacs RMAIL w. mailcrypt.el)
it is quite tedious to search for something in an encrypted post: too
slow).

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, 20 Oct 1997 16:37:40 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: New Draft... going forward
Sender: [email-masked]

>>The primary reason ascii armor was chosen was for the case of encrypted
>>messages.  The way RFC2015 is currently worded, a non-MIME mail user can
>>simply pipe the whole message to pgp and everything will work just fine
>>without the need for any additional software.  It also makes even
>>MIME-compliant software easier to write.
>
>I have to agree here, so long as there is a *large* userbase of 2.6.x
>users Ascii Armor is far from outdated. I see very little advantage here
>of switching from Ascii Armor to Base64 other than adding one more PITA
>for backward compatibility.

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.

Another is that the spec does not fully specify how to do ASCII armor,
specifically how to create the checksum. Not only does the draft not
specify how to do this, it references a book that is "out of stock
indefinitely" according to the publisher.

I strongly favor backward compatibility with the installed base, but not at
the expense of losing developers over unneeded features. Since a
description of ASCII armor has already been published (well, minus how to
do th checksums) in RFC 1991, any developer who cares about backward
compatibilty can become backward compatible.
--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 20 Oct 1997 15:03:00 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: encryption key expiry in pgp5.x
Sender: [email-masked]

Adam Back writes:
> I think this argues for the advantages of using symmetric keys for
> storage encryption (pgp -c).  I used to do this a lot myself.  You
> don't have the same need to update storage keys.  Those files I used
> pgp -e to encrypt to myself, I am now stuck with digging them all out
> and re-encrypting them or losing them, if I did what I really should:
> revoke and burn the key I generated back in 1993.  

One problem with pgp -c in older versions of PGP is that all the files
are encrypted with the same session key (assuming all use the same
passphrase).  Generally it is better to switch session keys frequently,
which pgp -e does for you (every file uses a different session key).
Of course we believe the ciphers we are using are strong, so it is not
a major security leak, but all else being equal it is good to have the
frequent rekeying.

> One suggestion to get around this problem is to use an indirection: 
>
> Store the symmetric key used to encrypt stored files: key k1 in
> encrypted form -- store the key k1 on the disk encrypted with key k2.
> Key k2 is derived from the passphrase, k2 = hash(passphrase).  This
> allows you to change the passphrase without re-encrypting the files.
> E(k2,k1) could go with the secret keyring.  (This is what SFS does I
> think).

The new PGP conventional ESK (encrypted session key) packet works
something like this.  It supports the use of a random session key k1 to
encrypt the data, with k1 then encrypted under a key k2 which is derived
deterministically from the passphrase.  However it puts E(k2,k1) at the
front of the file, along with any public ESKs, rather than putting them
into the secret keyring.

I think your idea requires the use of the same k1 everywhere, which again
suffers from the problem of providing lots of ciphertext encrypted under
the same key.

It's not clear how much you gain by being able to change your passphrase
once a month if the files are still encrypted under the same old key.
You're going to increase your chance of forgetting a passphrase but you
don't seem to gain much security.

> My CDR proposal is this extension to the above:
>
> Also encrypt recovery information so that your storage key k1 can be
> recovered by second parties if you forget the passphrase.  So also
> within the private key ring you would store: RSA(pk_r, k1), where pk_r
> is the public recovery key, for your company, or close friend, lawyer,
> etc.

PGP supports a mix of conventional (symmetric) ESK packets and public key
ESK packets (not in the UI yet, though).  This will allow messages which
can be decrypted by any of a set of key holders, or anyone who knows
one or more passphrases.  This could be used for encryption to a group of
people where some of them don't have public keys for some reason, but you
share a passphrase with them via some out-of-band means.

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

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 20 Oct 97 16:51:01 -0500
To: Michael Elkins <[email-masked]>
Cc: [email-masked]
Subject: Re: New Draft... going forward
Sender: [email-masked]

In <[email-masked]>, on 10/20/97 
   at 01, Michael Elkins <[email-masked]> said:

>On Mon, Oct 20, 1997 at 01:13:59PM +0000, Lutz Donnerhacke wrote: > *
>Thomas Roessler wrote:
>> >Lutz Donnerhacke wrote:
>> [Allowing direct MIME encoding of the PGP octet stream]
>> 
>> >From RFC 2015:
>> >   PGP can generate either ASCII armor (described in [3]) or
>> >   8-bit binary output when encrypting data, generating a
>> >   digital signature, or extracting public key data.  The ASCII
>> >   armor output is the REQUIRED method for data transfer.  This
>> >   allows those users who do not have the means to interpret
>> >   the formats described in this document to be able extract
>> >   and use the PGP information in the message.
>> >
>> >To me, this sounds reasonable.
>> 
>> Sure, but if software is unable to deal with MIME, the user do have other
>> problems than PGP. Even RfC 2015 requires MIME compilant software to deal
>> with digital signatures. So the other part does not harm that much. It is
>> still possible to pipe a base64 encoded message through a decoder and into
>> pgp-compilant software. The only difference is, that today pgp messages
>> without MIME headers must be piped through pgp alone.
>> 
>> In short: Ascii Armor is outdated.

>The primary reason ascii armor was chosen was for the case of encrypted
>messages.  The way RFC2015 is currently worded, a non-MIME mail user can
>simply pipe the whole message to pgp and everything will work just fine
>without the need for any additional software.  It also makes even
>MIME-compliant software easier to write.

I have to agree here, so long as there is a *large* userbase of 2.6.x
users Ascii Armor is far from outdated. I see very little advantage here
of switching from Ascii Armor to Base64 other than adding one more PITA
for backward compatibility.

-- 
---------------------------------------------------------------
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: Mon, 20 Oct 1997 21:30:45 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: encryption key expiry in pgp5.x
Sender: [email-masked]

Hal Finney <[email-masked]> writes:
> Adam Back asks:
> > What happens in this scenario with pgp5.0, or pgp5.5:
> > [Replacement of encryption key and deletion of old private part.]
> >
> > If you do this, you won't be able to read your old mail folder,
> > because you no longer have the key it was encrypted to.
> >
> > Does this imply that you must keep the private key for perpetuity?
> > (Or at least as long as you want to read old mail archives).
> 
> These are good questions.  The issue of dealing with retired encryption
> keys raises many operational complications.  Not only email, but any other
> files which may have been encrypted with the key being replaced are at
> risk of being lost.

I think this argues for the advantages of using symmetric keys for
storage encryption (pgp -c).  I used to do this a lot myself.  You
don't have the same need to update storage keys.  Those files I used
pgp -e to encrypt to myself, I am now stuck with digging them all out
and re-encrypting them or losing them, if I did what I really should:
revoke and burn the key I generated back in 1993.  

> It could be that it will be appropriate to save the old private key
> in some secure location.  Because it would not have to be accessed very
> often if at all, the secure storage could be made relatively inaccessible.

Not as good as deleting the key -- if you can recover it then the
attacker can coerce you into recovering it.  Or some companies may
develop sloppy practices, and just leave the expired keys on the disk.
It's complex also, you've got to tell them how to handle this key,
explain why they need it; whereas removing the key is simple.  The
expiry feature on the key that you described means that pgp5.0 already
knows what to do when it expires, so you have backwards compatibility.

> Or perhaps software could sweep your disk to find data encrypted with the
> old key, and re-encrypt it with the new one.  Whatever solution is chosen
> will have to be based on input from customers, so that we have a safe
> and manageable way of dealing with retired keys.

The sweep the disk method sounds difficult to do reliably -- what if
there are some files on backup tape, or on floppy, or inside a zip
archive -- these may be missed.

One suggestion to get around this problem is to use an indirection: 

Store the symmetric key used to encrypt stored files: key k1 in
encrypted form -- store the key k1 on the disk encrypted with key k2.
Key k2 is derived from the passphrase, k2 = hash(passphrase).  This
allows you to change the passphrase without re-encrypting the files.
E(k2,k1) could go with the secret keyring.  (This is what SFS does I
think).

For ergonomics reasons you might have an option of using the same
passphrase for protecting key k1 as you use to protect your current
private encryption key sk_i.

If all communications messages encrypted to pk_i (your current public
encryption key) were first decrypted (using private key sk_i) and then
re-encrypted with symmetric algorithm E and key k1 before being
storaged in mail folders, you could at any time safely delete an
encryption key.

With this setup, you could reasonably generate new public encryption
keys once a month even.  This I think would be a significant security
improvement (over people like me still keeping private halves of 4
year old RSA keys).

My CDR proposal is this extension to the above:

Also encrypt recovery information so that your storage key k1 can be
recovered by second parties if you forget the passphrase.  So also
within the private key ring you would store: RSA(pk_r, k1), where pk_r
is the public recovery key, for your company, or close friend, lawyer,
etc.

You could do secret splitting as an enhancement from that simple
functionality, in a similar way to what was discussed for the next
version of CMR style recovery.

The advantage of CDR style recovery it seems to me is that no long
term keys need to be kept which are protecting communications traffic.
Also the communication can be encrytped to a minimum number of
crypto-recipients.  Communications traffic is much more vulnerable
than stored data, so these more short-lived keys, and avoidance of
more than necessary crypto-recipients who would be able to decrypt
seems appropriate, and more secure.

At the same time no-one is forced to use short lived encryption keys
if this doesn't suit them: they can use whatever they currently use as
default expiries.  The recovery mechanism could still be centered
around storage keys as shown above.

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: Mon, 20 Oct 97 14:36:51 -0500
To: [email-masked] (Lutz Donnerhacke)
Cc: [email-masked]
Subject: Re: KeyIDs and Key Fingerprints
Sender: [email-masked]

In <[email-masked]>, on 10/20/97 
   at 01, [email-masked] (Lutz Donnerhacke) said:

>* Hal Finney wrote:
>>Phil Zimmermann has suggested that we generalize the keyID concept
>>to allow it to be variable length.  Rather than fixing it as a 64 bit

>Not necessary. The new draft defines the key ID to not unique. That's
>enough.

Well I think we should have had some disscussion on this. This really
plays havok on keyring lookups & management if keyID is nolonger unique.
If this is the tact to be taken then we should look at the encrypt & sig
packets and find a unique identifier to use with them perhaps just put the
whole fingerprint there. Without a unique identifyer there will be a
marked decrease of performance in PGP operations in areas where PGP
performance is poor to begin with.

-- 
---------------------------------------------------------------
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: Mon, 20 Oct 1997 15:45:10 +0100
To: [email-masked]
From: Ian Miller <[email-masked]>
Subject: Re: Revealing individual messages.
Cc: Bill Stewart <[email-masked]>
Sender: [email-masked]

Bill Stewart wrote:-
>At 02:34 PM 10/18/1997 +0100, Ian Miller wrote, to [email-masked]
>>If part of this nonce was replaced by sender-Id,
>>timestamp and similar data, then Alice would at least learn who had sent
>>the message (Bob) and when.  They might then have to opportunity to contact
>>the Bob to ask for retransmission and warn of the interception.
>
>No way.  This is bad.  You don't want traceability built into PGP.
No.  You want the _option_ of untraceability.  If you have signed the message
then you loose _nothing_ by including sending information in the SKE packet.
(I fully agree that you should not include sender information in unsigned
messages.)

>If the sender _wants_ to be traceable, he can sign the message.
However this does not work if Mallory does not give Alice the
conventionally encrypted packet only the SKE packet, and insists (with
Court Order) that it is decrypted.  In this case, either Alice goes to jail
(possibly over a packet Mallory forged himself) or Mallory decrypts the
message without Alice even knowing who sent it.  Clearly allowing Alice to
determine the sender is not an enormous improvement but it is better than
nothing.

Ian

--
[email-masked]    FAI-D10204
PGP Fingerprint: 2A20 4610 E596 2740 91B1 95BA CAD3 BC14
Antworten auf Deutsch waeren mir angenehm.

From: Mike Wynn <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: New Draft... going forward
Date: Mon, 20 Oct 1997 19:39:42 +0100
Sender: [email-masked]

Because this is an Open protocol I think that the
"Version" should be split into two parts
one part which is which protocol version and
the other part who's program wrote it and its version
currently there is PGP versions and Cryptix Versions

either version a form like x.y.z <written by>

i.e.
Version: 0.0.1 <Cryptix 2.3.0>

or two tags
Version: Cryptix 2.3.0
MessageVersion: 0.0.1

Mike.

----------
From: 	Lutz Donnerhacke
Sent: 	19 October 1997 18:36
To: 	[email-masked]
Subject: 	New Draft... going forward

INTERNET-DRAFT                                         Lutz Donnerhacke

The following keywords are defined:

  Version   -- Denotes the version used to generate this message.
  Comment   -- Any user defined world readable message.
  Hash      -- Used method of hashing to ease one pass processing.
               Defined are "MD5", "MD2" and  "SHA-1".
  MessageID -- Random number to trace messages.
  Charset   -- Character set for the message.

From: [email-masked]
To: [email-masked]
Date: Mon, 20 Oct 1997 12:36:20 -0700
Subject: [VOTE] comp.security.pgp.test
Sender: [email-masked]

.-----------------------------------------------------------------------
| 1ST CALL FOR VOTES: comp.security.pgp.test
| Official Usenet Voting Ballot <CSPT-0001> (Do not remove this line!)
|-----------------------------------------------------------------------
| Please provide a valid name, or your vote may be rejected.  Place
| ONLY your name (i.e., do not include your e-mail address or any other
| information) after the colon on the line below.
Voter name: Joseph Tsai
| Insert YES, NO, ABSTAIN, or CANCEL inside the brackets for each
| newsgroup listed below (do not delete the newsgroup name):
 Your Vote   Newsgroup
 ---------   -----------------------------------------------------------
[   YES   ]  comp.security.pgp.test

Date: Mon, 20 Oct 1997 11:06:35 -0700
From: Michael Elkins <[email-masked]>
To: [email-masked]
Subject: Re: New Draft... going forward
Sender: [email-masked]

On Mon, Oct 20, 1997 at 01:13:59PM +0000, Lutz Donnerhacke wrote:
> * Thomas Roessler wrote:
> >Lutz Donnerhacke wrote:
> [Allowing direct MIME encoding of the PGP octet stream]
> 
> >From RFC 2015:
> >   PGP can generate either ASCII armor (described in [3]) or
> >   8-bit binary output when encrypting data, generating a
> >   digital signature, or extracting public key data.  The ASCII
> >   armor output is the REQUIRED method for data transfer.  This
> >   allows those users who do not have the means to interpret
> >   the formats described in this document to be able extract
> >   and use the PGP information in the message.
> >
> >To me, this sounds reasonable.
> 
> Sure, but if software is unable to deal with MIME, the user do have other
> problems than PGP. Even RfC 2015 requires MIME compilant software to deal
> with digital signatures. So the other part does not harm that much. It is
> still possible to pipe a base64 encoded message through a decoder and into
> pgp-compilant software. The only difference is, that today pgp messages
> without MIME headers must be piped through pgp alone.
> 
> In short: Ascii Armor is outdated.

The primary reason ascii armor was chosen was for the case of encrypted
messages.  The way RFC2015 is currently worded, a non-MIME mail user can
simply pipe the whole message to pgp and everything will work just fine
without the need for any additional software.  It also makes even
MIME-compliant software easier to write.

me

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: New Draft... going forward
Date: 20 Oct 1997 13:13:59 GMT
Organization: IKS GmbH Jena
Lines: 31
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Thomas Roessler wrote:
>Lutz Donnerhacke wrote:
[Allowing direct MIME encoding of the PGP octet stream]

>From RFC 2015:
>   PGP can generate either ASCII armor (described in [3]) or
>   8-bit binary output when encrypting data, generating a
>   digital signature, or extracting public key data.  The ASCII
>   armor output is the REQUIRED method for data transfer.  This
>   allows those users who do not have the means to interpret
>   the formats described in this document to be able extract
>   and use the PGP information in the message.
>
>To me, this sounds reasonable.

Sure, but if software is unable to deal with MIME, the user do have other
problems than PGP. Even RfC 2015 requires MIME compilant software to deal
with digital signatures. So the other part does not harm that much. It is
still possible to pipe a base64 encoded message through a decoder and into
pgp-compilant software. The only difference is, that today pgp messages
without MIME headers must be piped through pgp alone.

In short: Ascii Armor is outdated.

>> 3.1.3 Cleartext signature framework

>PGP 2.6's clear text armor goes a little bit beyond RFC 1113
>which defines the original dash escaped text: Lines beginning
>with the five characters "From " are escaped as well.

Thanx. I'll add it.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: KeyIDs and Key Fingerprints
Date: 20 Oct 1997 13:01:41 GMT
Organization: IKS GmbH Jena
Lines: 5
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Hal Finney wrote:
>Phil Zimmermann has suggested that we generalize the keyID concept
>to allow it to be variable length.  Rather than fixing it as a 64 bit

Not necessary. The new draft defines the key ID to not unique. That's enough.

Date: Mon, 20 Oct 1997 10:37:14 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: New Draft... going forward
Sender: [email-masked]

Lutz Donnerhacke wrote:

> 3.1.1 MIME
> 
> RfC 2015 "MIME Security with Pretty Good Privacy (PGP)" [2] contains all
> information necessary to strip or apply this layer. It may make use of the
> Ascii Armor layer, but the octect stream may also encoded directly using
> MIME itself.
> 
> 3.1.2 Ascii Armor
> 
> Similar to MIME encoding, the process of ascii armor encodes an 8-bit binary
> stream of data into printable characters. Every three subsequent octets are
> mapped into four subsequent ASCII characters. Futhermore ascii armor
> encoding also appends a special CRC to detect transmission errors. In order
> to ease recognition of Ascii Armored messages, a special header and footer
> is provided.

>From RFC 2015:

   PGP can generate either ASCII armor (described in [3]) or
   8-bit binary output when encrypting data, generating a
   digital signature, or extracting public key data.  The ASCII
   armor output is the REQUIRED method for data transfer.  This
   allows those users who do not have the means to interpret
   the formats described in this document to be able extract
   and use the PGP information in the message.

To me, this sounds reasonable.

> 3.1.3 Cleartext signature framework

> Dash escaped cleartext is the ordinary cleartext where every
> line starting with a dash '-' (US-ASCII 0x2D) is prepended by
> the sequence dash '-' (US-ASCII 0x2D) and space ' ' (US-ASCII
> 0x20). This prevents the parser from recognising armor headers
> of the cleartext itself. The message digest is computed using
> the cleartext itself, not the dash escaped form. So it is
> possible to seperate or join a signature from or to a cleartext
> without resigning it.

PGP 2.6's clear text armor goes a little bit beyond RFC 1113
which defines the original dash escaped text: Lines beginning
with the five characters "From " are escaped as well.

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: New Draft... going forward
Date: 20 Oct 1997 07:35:58 GMT
Organization: IKS GmbH Jena
Lines: 8
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Lutz Donnerhacke wrote:
>

I maintain this draft from now on. Current versions and diffs can be
obtained from ftp://ftp.iks-jena.de/mitarb/lutz/crypt/software/pgp/

Please mail(!) me all changes you want to include. I can not guarantee to
read the mailinglist regulary. I have to work for a living.... ;-/

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: MIME question about new draft
Date: 20 Oct 1997 07:33:10 GMT
Organization: IKS GmbH Jena
Lines: 24
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Ben Escoto wrote:
>From section 3.1.1 of the draft:
>
:RfC 2015 ... contains all information necessary to strip or apply this layer.
:It may make use of the Ascii Armor layer, but the octect stream may also
:encoded directly using MIME itself.

>The above seems to permit PGP output not being ascii-encoded
>but rather base-64 encoded.  Is my interpretation correct?

Yes.

>The section implies that nothing from rfc2015 has changed, but section 2
>of that document says "The ASCII armor output is the REQUIRED method
>for data transfer."

True. So our RfC will update RfC 2015.

>So, can the octet-stream portion of PGP/MIME messages be a
>base64 encoding of 8-bit PGP output?  Thanks.

Yes, that's the solution to choose in future (IMHO). There is no need for a
special session layer in the session layer. Of course, it's not backward
compatible to software do not understand MIME, but this does not harm.

Date: Mon, 20 Oct 1997 00:09:16 -0700
From: Kent Crispin <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Is PGP still private?
Sender: [email-masked]

On Sun, Oct 19, 1997 at 07:22:37AM +1000, Andrew Bromage wrote:
> G'day all.
> 
> Kent Crispin wrote:
> 
> > Your reencryption scheme fails because of the management of the short
> > term encryption keys, among other things.  Here's another approach I
> > will toss out, without thinking through:
> > 
> > How about formalizing superencryption, or tunneling? That is, treat
> > CMR traffic as a transport medium for messages that are themselves
> > already encrypted.  The "key" idea here is to allow layering of non
> > CMR traffic over CMR traffic.  All the code for both is obviously
> > already in PGP, with a little glue and perhaps some minor protocol
> > mods...
> 
> If we start considering that, could I suggest making the system
> _completely_ flexible?
> 
> The sort of things I'm thinking of include:  Allow any object to be
> encrypted using conventional encryption (including conventional
> encryption keys) or signed, allow any conventional encryption key to
> be public-key encrypted or split, conjunction/disjunction of two
> conventional keys, etc.
> 
> Disadvantages:
> 
> 	- Greatly complicates the decryption process.  In particular,
> 	  decrypted streams must be fed back into PGP.

My impression from a talk by ???, perhaps at the San Jose IETF, is
that the new version of PGP is actually coded to facilitate this kind
of interaction internally -- that is, it is designed around a general
interface philosophy of connecting filter modules via a stream
abstraction. 

> 	- Difficult for an end-user to specify what combination of
> 	  features they want.

I think it would be a relatively straightforward, fun project to
develop a simple scripting language that could specify this.  Not knowing 
that much, I toss this out just to give the flavor of something that could 
be in a .pgprc file:

message-to:[email-masked]
	encrypt(joes_private_private_stego_key)->
	stegosaurous.gif->
	encrypt(joes_bigco_cmr_key,bigco_cmr_key)
	address-to:[email-masked]

message-to:[email-masked]
	encrypt(joes_bigco_cmr_key,bigco_cmr_key)
	address-to:[email-masked]

message-from:[email-masked]
	decrypt(*)->encrypt(my_private_storage_key)

> 	- This working group would be around for years arguing about
> 	  details. :-)

Definitely not for version 1 of the standard.

> Advantages:
> 
> 	- Allows PGP to be used for lots of things that we haven't
> 	  thought of yet.

	- GAK would be impossible to enforce.

> 	- File format could be considerably simplified, if we could
> 	  scrap the old format.  (Unrealistic, but what the hell.)

-- 
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, 19 Oct 1997 23:42:03 -0700
From: Kent Crispin <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: why we are arguing for more resistant variants
Sender: [email-masked]

On Sun, Oct 19, 1997 at 07:15:00PM +0100, Adam Back wrote:
> 
> Kent Crispin <[email-masked]> writes:
> > On Sun, Oct 19, 1997 at 10:25:08AM +0100, Adam Back wrote:
> > > Also I must raise the point that it is not a lone stand.  Other people
> > > are arguing against PGP Inc's CMR proposal, and are arguing for more
> > > GAK resistant variants, and alternatives.  
> > 
> > Apparently for some internal reason you must raise the point, but it
> > is irrelevant.  I said your *proposals* were vaporware, not your
> > motivations.  It is, as I have said, a waste of time (and yes, mental
> > masturbation) to argue about motivations. 
> 
> Motivation is irrelevant.

Good.  We agree, and can therefore move on.

> You made one contribution in this area in your last post.  Keep up the
> technical contributions, and scenario likelihood evaluations.
> 
> > > However the biggest point of all is that: communications keys are more
> > > valuable to any attacker (government, unscrupulous little brother, or
> > > industrial spy) than storage keys.
> > > 
> > > I would be interested to see any one willing to burn their
> > > reputational capital refuting that simple point.
> > 
> > *Long term* communication keys.  Nobody is going to burn reputation
> > capital on that point because it's obvious, and really doesn't need to
> > be argued.  
> 
> If it doesn't need to be argued, why does pgp2.x and pgp5.x use long
> term communication keys? 

History.  Backward compatibility.  Time pressures.  And a design for
short term communication keys for email does not yet exist -- not from
you, not from anyone.  [Your CDR proposal uses *long term*
communication keys.]

These seem pretty compelling reasons to me. 

Just because something is desirable doesn't mean it is practical, or 
even possible.  

[...]
> 
> Surely the most straight forward way to provide recovery for email
> archives is to archive the emails encrypted to a storage-only key,
> with this key escrowed in some way?  You then don't need to recover
> email in transit -- you don't even have a copy of it.
> 
> This is clearly more resistant to government abuse.  Do you disagree?
> 
> (The above paragraph is basically all my CDR proposal is .. it seems
> straight forward, intuitive, more secure; I went through and countered
> your previous objections to worked example #1, you did not reply to
> those counter-points).

I did not because you presented it as a throwaway, with statements to
the effect that you already knew it was defective but you were
presenting it anyway.  Besides, in all honesty I did not find your
counterarguments very compelling, and I was content to wait until I 
saw a "real" proposal.  If I have a chance, though, I will go back 
and address that...

BTW, perhaps you remember a fairly long thread sometime back where I 
discussed the pros and cons of a "keysafe" model for data recovery 
keys? 

> > Furthermore the point applies just as well to current PGP keys.  The
> > *only* additional vulnerabilities of CMR come from 1) the volume of
> > data makes it a more interesting target and 2) the management of the
> > CMR key(s) may be problematic.
> 
> You missed a couple:
> 
> 3) the goverment will love to get come ask for your CMR key because it
> protects all past emailed ciphertext
> 
> 4) some governments (eg France) will probably ask for one of the CMR
> keys to be theirs

I include both of those under my number 1.

> > However, in a large organization the management of *user* keys is
> > problematic, as well, and management of the CMR key(s), on balance,
> > will probably be better.  So the additional vulnerability of CMR comes
> > from the fact that it makes a lot of data accessible from one key. 
> > This vulnerability could be reduced by having multiple CMR keys -- the
> > accounting dept has one, the CEO has one, and it is the same as his
> > private key that is not escrowed anywhere, etc etc etc.
> 
> Yes.  Several people have suggested this.  Also secret sharing is
> being considered by PGP Inc for the next version I think.
> 
> > [Is it true that the private key associated with a CMR public key 
> > could simply be discarded, rather than escrowed, and everything would 
> > still work? -- except that you couldn't recover anything, of course...]
> 
> I would think so.  This would argue for updating the CMR
> communications key as frequency as is practicable to minimise danger.
                        ^^^^^^^^^frequently?

?I don't see the connection.  My point was that you can generate a key
pair, throw away the private key, and use the public key as the CMR
key.  Perhaps you could just use random bits in the correct format for
the public key, and never generate a key pair at all.  This would meet
external requirement of having a CMR key, but it would be meaningless,
since the missing private key could never be used to decrypt anything. 
Thus, though externally an organization (say an ISP) would be
complying with a regulation, in fact it would be impossible to 
recover any email anyway...

In any case, I presume the "danger" you refer to is the danger that 
someone will snarf the CMR key.  Changing it frequently will reduce 
the number of compromised messages if any given key is compromised.  
(Of course, the CMR keys will have to be preserved forever in a 
little database of some sort -- if you change them often, that 
database will be large...)

> (Same argument as update requirements for user communications keys).
> Hal Finney discussed this requirement of matching expiry frequency on
> comms keys & corresponding CMR keys a few messages back.

> 
> > A more interesting argument is as follows: what is the real level of
> > security needed for the business communications that will be covered
> > by CMR? It seems obvious that the level of security required, on
> > average, is really quite low.  Note that businesses send all kinds of
> > important documents through regular mail, only protected *gasp* by
> > PAPER ENVELOPES. 
> 
> This suggests that Tim May is right, and the simplest solution is to
> store the decrypted received emails in clear on the disk.  Most of the
> companies are in fact storing on disk.

It is the MUA that uses PGP (Eudora, Mutt, whatever) that decides how
to store the decrypted files, not PGP.  PGP decrypts the files and
gives them to the MUA, which displays them to the user.  The MUA has
the option of storing it encrypted or not, as delivered, or with 
another key.  PGP isn't in control, it's the MUA, isn't it?

> > Anyway, Adam, I anxiously await the paper you are working on that 
> > gives the real details of your proposals.  I'm sure it's readability 
> > will be vastly improved if you religiously avoid the use of the word 
> > GAK :-)
> 
> Could you provide a less emotive suitable alternative word which I can
> use as a replacement to describe government communications key
> grabbing attempts?  GACK is what Carl Ellison proposed as a more
> accurate way to express "Goverment Access to Communications Keys" than
> terms such as "key escrow", "key recovery", which are government
> coined terms.  PGP Inc themselves being mostly cypherpunks and
> pro-privacy people use the term GACK also.
> 
> GACK seems a pretty good acronym to me, accurate, descriptive.  Are we
> getting goverment-correct now as well (as politically-correct)?  So
> that we must not use terms which are offensive to governments?
>
> (I will attempt to avoid negative political comments about PGP Inc's
> implementation, and phrase in terms of constructive criticisms though,
> and perhaps this was your point given my earlier outbursts in this
> regard; perhaps you can help proof read for this).

Whatever.  It does strike me that you seem to have difficulty in
maintaining composure whenever the term comes up, your prose gets
hasty, with missing words and odd syntax, and I suspect that your
usually razor-sharp edge suffers as well....  :-)

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

From: Ben Escoto <[email-masked]>
To: [email-masked] (Lutz Donnerhacke)
Cc: [email-masked]
Subject: Re: MIME question about new draft
Date: Sun, 19 Oct 1997 17:45:23 -0700
Sender: [email-masked]

--=_Mapil-0.1b_2854923083
Content-Transfer-Encoding: quoted-printable

=46rom section 3.1.1 of the draft:

RfC 2015 =22MIME Security with Pretty Good Privacy (PGP)=22 =5B2=5D contain=
s all
information necessary to strip or apply this layer. It may make use of the
Ascii Armor layer, but the octect stream may also encoded directly using
MIME itself.

=09The above seems to permit PGP output not being ascii-encoded
but rather base-64 encoded.  Is my interpretation correct?  The
section implies that nothing from rfc2015 has changed, but section 2
of that document says =22The ASCII armor output is the REQUIRED method
for data transfer.=22

=09So, can the octet-stream portion of PGP/MIME messages be a
base64 encoding of 8-bit PGP output?  Thanks.

--
Ben Escoto
PGP/MIME mail welcome - finger bescoto=40leland.stanford.edu for key

--=_Mapil-0.1b_2854923083
Content-Type: application/pgp-signature

--=_Mapil-0.1b_2854923083--

Date: Sun, 19 Oct 1997 16:43:12 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: encryption key expiry in pgp5.x
Sender: [email-masked]

Adam Back asks:
> What happens in this scenario with pgp5.0, or pgp5.5:
> [Replacement of encryption key and deletion of old private part.]
>
> If you do this, you won't be able to read your old mail folder,
> because you no longer have the key it was encrypted to.
>
> Does this imply that you must keep the private key for perpetuity?
> (Or at least as long as you want to read old mail archives).

These are good questions.  The issue of dealing with retired encryption
keys raises many operational complications.  Not only email, but any other
files which may have been encrypted with the key being replaced are at
risk of being lost.

It could be that it will be appropriate to save the old private key
in some secure location.  Because it would not have to be accessed very
often if at all, the secure storage could be made relatively inaccessible.
Or perhaps software could sweep your disk to find data encrypted with the
old key, and re-encrypt it with the new one.  Whatever solution is chosen
will have to be based on input from customers, so that we have a safe
and manageable way of dealing with retired keys.

I should clarify that PGP 5.0 and 5.5 do not currently provide user
interfaces for replacing encryption keys.  The data structures allow it,
and the library is designed to transparently handle the case of a key
with many encryption subkeys, where only one is still valid.  So once a
user interface is created to allow people to retire and replace subkeys,
the keys will be handled properly by the existing products.

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

Date: Sun, 19 Oct 1997 23:39:16 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: encryption key expiry in pgp5.x
Sender: [email-masked]

What happens in this scenario with pgp5.0, or pgp5.5:

- You have a signature key which you'll keep for say 2 years before
  creating a new one.

- You have a policy of generating new encryption keys every 6 months.

- Your email archives are stored as received still encrypted to your
  public encryption key (I think you have no choice but to do this with
  some of the pgp5.x plugins).

- You expire the key, and securely wipe the private half of the key.
  (An advantage of rekeying in this way is to gain forward secrecy:
  messages gathered by an attacker can no longer be decrypted with
  information you have, but to get the forward secrecy you must
  literally securely wipe the private key).

If you do this, you won't be able to read your old mail folder,
because you no longer have the key it was encrypted to.

Does this imply that you must keep the private key for perpetuity?
(Or at least as long as you want to read old mail archives).

One presumes the same problem applies to CMR recovery keys, they must
also be kept as long as recovery is required, if the user forgets the
password.

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, 19 Oct 1997 13:03:23 -0700
To: Ian Miller <[email-masked]>, [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: Revealing individual messages.
Cc: [email-masked]
Sender: [email-masked]

At 02:34 PM 10/18/1997 +0100, Ian Miller wrote, to [email-masked]
>One thing sadly lacking from all current PGP implementations is the ability
>to reveal the contents of _some_ messages encrypted to you, without handing
>over the secret key.  This is most important as damage limitation when
>ordered by a court of law to reveal certain messages.  [The most
>pathological case is where Mallory has generated those messages himself,
>merely to persuade the courts to force you to hand over your privacy key.]

The easy approach is to decrypt the message, but there's of course
no way for the Court to validate that your decryption was correct.
But if you want more than that, it's not hard to write, either by
finding where in the 7000 pages of PGP source (:-) to add a few
print statements, or by using the APIs when they come out.
Perhaps it's even there today, by setting -debug=42 or whatever.

The decryption needs to show
1) The public key that was used to encrypt the message
2) The PK-encrypted session key, including the random padding
3) The decryption of the PK-encrypted session key, including the random padding,
	(and including the algorithm indicator, if it's encrypted)
3.1) Indication of which bits are the session key  itself, for the slow-witted
4) The decrypted compressed plaintext (optional)
5) The decrypted raw plaintext

And it would be nice to have a tool that also provides a mechanism
to encrypt a random-padded session key to a public key 
to verify the output.  Perhaps Adam Back (et al.)'s 2-line perl code,
with some pretty output formatting.

> Accordingly for RSA encryption at least I propose a
>modification to the DEK plaintext that contains the session key.  Currently
>this is largely random containing over a hundred bytes of nonce
>(for a 1024bit-key).  If part of this nonce was replaced by sender-Id,
>timestamp and similar data, then Alice would at least learn who had sent
>the message (Bob) and when.  They might then have to opportunity to contact
>the Bob to ask for retransmission and warn of the interception.

No way.  This is bad.  You don't want traceability built into PGP.
If the sender _wants_ to be traceable, he can sign the message.
If the sender wants convenient but repudiable identification,
he can put his name and any other information he wants in the plaintext.

Besides, PGP doesn't know who the sender _is_ except by signature;
you can set a default key if you like, but otherwise there's no way
for PGP to decide whether to use the "Bob <[email-masked]>" key
in Bob's secret key ring, or the "Louis Freeh <[email-masked]>" key,
and for that matter PGP will work fine with no secret-key file at all.

If you're concerned about Bad Cops planting forged messages on people, 
this won't help - it's easy for them to forge unsigned information also.
After all, the PGP source code is open, so Bad Cops can add code to
set the timestamp/sender/etc themselves.  Or they can ignore code,
and just set their system clock appropriately.

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

Date: Sun, 19 Oct 1997 19:15:00 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: why we are arguing for more resistant variants (Re: Is PGP still private?)
Sender: [email-masked]

Kent Crispin <[email-masked]> writes:
> On Sun, Oct 19, 1997 at 10:25:08AM +0100, Adam Back wrote:
> > Also I must raise the point that it is not a lone stand.  Other people
> > are arguing against PGP Inc's CMR proposal, and are arguing for more
> > GAK resistant variants, and alternatives.  
> 
> Apparently for some internal reason you must raise the point, but it
> is irrelevant.  I said your *proposals* were vaporware, not your
> motivations.  It is, as I have said, a waste of time (and yes, mental
> masturbation) to argue about motivations. 

Motivation is irrelevant.  The road to hell is paved with good
intentions.  All the sides in the argument (except for Freeh and the
USG/NSA) have good intentions (and perhaps even Freeh from his
perspective).  Fooh on good intentions.  Let's keep this discussion
focussed on:

  The design of systems which are hard for governments to abuse in
  introducing GACK

You made one contribution in this area in your last post.  Keep up the
technical contributions, and scenario likelihood evaluations.

> > However the biggest point of all is that: communications keys are more
> > valuable to any attacker (government, unscrupulous little brother, or
> > industrial spy) than storage keys.
> > 
> > I would be interested to see any one willing to burn their
> > reputational capital refuting that simple point.
> 
> *Long term* communication keys.  Nobody is going to burn reputation
> capital on that point because it's obvious, and really doesn't need to
> be argued.  

If it doesn't need to be argued, why does pgp2.x and pgp5.x use long
term communication keys?  Why does pgp5.x then go exacerbate this
problem encouraging use of not one but two long term communications
keys.  Why does it provide recovery methods for long term
communications keys when the stated user requirement is to recover
stored email archives?

ie. the discussion just took this form:

Adam: X is a bad security idea.  X is used in pgp2.x and pgp5.x

Kent: modification Y to pgp5.x doesn't make it any worse

Adam: So?  It's still a bad idea, and here are ways to make it more
      secure, and harder for governments to abuse to boot

Kent: ?  (we're waiting)

Surely the most straight forward way to provide recovery for email
archives is to archive the emails encrypted to a storage-only key,
with this key escrowed in some way?  You then don't need to recover
email in transit -- you don't even have a copy of it.

This is clearly more resistant to government abuse.  Do you disagree?

(The above paragraph is basically all my CDR proposal is .. it seems
straight forward, intuitive, more secure; I went through and countered
your previous objections to worked example #1, you did not reply to
those counter-points).

> Furthermore the point applies just as well to current PGP keys.  The
> *only* additional vulnerabilities of CMR come from 1) the volume of
> data makes it a more interesting target and 2) the management of the
> CMR key(s) may be problematic.

You missed a couple:

3) the goverment will love to get come ask for your CMR key because it
protects all past emailed ciphertext

4) some governments (eg France) will probably ask for one of the CMR
keys to be theirs

> However, in a large organization the management of *user* keys is
> problematic, as well, and management of the CMR key(s), on balance,
> will probably be better.  So the additional vulnerability of CMR comes
> from the fact that it makes a lot of data accessible from one key. 
> This vulnerability could be reduced by having multiple CMR keys -- the
> accounting dept has one, the CEO has one, and it is the same as his
> private key that is not escrowed anywhere, etc etc etc.

Yes.  Several people have suggested this.  Also secret sharing is
being considered by PGP Inc for the next version I think.

> [Is it true that the private key associated with a CMR public key 
> could simply be discarded, rather than escrowed, and everything would 
> still work? -- except that you couldn't recover anything, of course...]

I would think so.  This would argue for updating the CMR
communications key as frequency as is practicable to minimise danger.
(Same argument as update requirements for user communications keys).
Hal Finney discussed this requirement of matching expiry frequency on
comms keys & corresponding CMR keys a few messages back.

> A more interesting argument is as follows: what is the real level of
> security needed for the business communications that will be covered
> by CMR? It seems obvious that the level of security required, on
> average, is really quite low.  Note that businesses send all kinds of
> important documents through regular mail, only protected *gasp* by
> PAPER ENVELOPES. 

This suggests that Tim May is right, and the simplest solution is to
store the decrypted received emails in clear on the disk.  Most of the
companies are in fact storing on disk.

> Anyway, Adam, I anxiously await the paper you are working on that 
> gives the real details of your proposals.  I'm sure it's readability 
> will be vastly improved if you religiously avoid the use of the word 
> GAK :-)

Could you provide a less emotive suitable alternative word which I can
use as a replacement to describe government communications key
grabbing attempts?  GACK is what Carl Ellison proposed as a more
accurate way to express "Goverment Access to Communications Keys" than
terms such as "key escrow", "key recovery", which are government
coined terms.  PGP Inc themselves being mostly cypherpunks and
pro-privacy people use the term GACK also.

GACK seems a pretty good acronym to me, accurate, descriptive.  Are we
getting goverment-correct now as well (as politically-correct)?  So
that we must not use terms which are offensive to governments?

(I will attempt to avoid negative political comments about PGP Inc's
implementation, and phrase in terms of constructive criticisms though,
and perhaps this was your point given my earlier outbursts in this
regard; perhaps you can help proof read for this).

Cheers,

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`

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: New Draft... going forward
Date: 19 Oct 1997 17:36:34 GMT
Organization: IKS GmbH Jena
Lines: 1733
NNTP-Posting-Host: belenus.iks-jena.de
Sender: [email-masked]

Ignore spelling and grammar...

INTERNET-DRAFT                                         Lutz Donnerhacke
Security                                               IN-Root-CA
Expires in six months                                  Individual Network e.V.
                                                       October 19 1997

			PGP Message Exchange Formats
		       <draft-ietf-pgp-formats01.txt>

Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time.  It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

This document is maintained in order to publish all necessary information
needed to develop interoperable applications based on the PGP message
exchange format. It is not a step by step cookbook for the source code, 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.

Abstract

PGP (Pretty Good Privacy) is a software product combining strong asymmetric
and symmetric cryptography for secure e-mail communication. These services
include confidentiality, key management, digital signature, and time
stamping. This document specifies the message exchange format used in
version 2.6.3x and 5.x of PGP.

Table of Contents
[autogenerated using sed -n '/^[0-9]\+\./s/^/  /p' format.txt]
  1. Introduction
  2. General functions
  2.1 Confidentiality
  2.2 Digital signature
  2.3 Key management
  2.4 Time stamping
  3. Layers of a message
  3.1 Session layer
  3.1.1 MIME
  3.1.2 Ascii Armor
  3.1.2.1 Radix-64 encoding
  3.1.2.2 Checksum
  3.1.2.3 Header and footer lines
  3.1.2.4 Armor headers
  3.1.2.5 Example
  3.1.3 Cleartext signature framework
  3.2 General packet framework
  3.2.1 Cipher Type Byte
  3.2.2 Packet length
  3.2.2.1 Packet version three or lower
  3.2.2.2 Packet version four or higher
  4. Generic data types
  4.1 Scalar numbers
  4.2 Multi-Precision Integers
  4.3 Strings
  4.4 Time fields
  5. Packet types
  5.1 Packet version three or lower
  5.1.1 Public key encrypted packet
  5.1.2 Signature packet
  5.1.3 Secret key packet
  5.1.4 Public key packet
  5.1.5 Compressed data packet
  5.1.6 Conventional key encrypted packet
  5.1.7 Literal data packet
  5.1.8 Keyring trust packet
  5.1.9 User ID packet
  5.1.10 Comment packet
  5.2 Packet version four or higher
  5.2.1 Encrypted session key packet
  5.2.2 Signature packet
  5.2.3 Conventionally encrypted session key packet
  5.2.4 One-pass signature packet
  5.2.5 Secret key packet
  5.2.6 Public key packet
  5.2.7 Secret subkey packet
  5.2.8 Compressed data packet
  5.2.9 Symmetrically encrypted data packet
  5.2.10 Marker packet
  5.2.11 Literal data packet
  5.2.12 Trust packet
  5.2.13 User ID packet
  5.2.14 Subkey packet
  5.2.15 Comment packet
  6. Key identification
  6.1 Key ID
  6.2 User ID
  6.2.1 Primary user ID
  6.2.2 Matching multiple user IDs
  6.2.3 User ID conventions
  6.3 Fingerprint
  7. Keyserver
  7.1 E-Mail keyserver
  7.2 DNS keyserver
  7.3 HTTP keyserver
  8. Notes
  9. Security Considerations
  10. Author's Address
  11. References

1. Introduction

This document provides information on the message-exchange packet formats
used by PGP to provide encryption, decryption, signing, key management and
timestamping functions. It builds on the foundation provided RfC 1991 "PGP
Message Exchange Formats" [1] and RfC 2015 "MIME Security with Pretty Good
Privacy (PGP)" [2]. Despite the well known authors (alphabetical order):
Derek Atkins, Charles Breed, Jon Callas, Dave Del Torto, Marc Dyksterhouse,
Gail Haspert, Gene Hoffman, Raph Levine, Colin Plumb, Will Price, William
Stallings, Mark Weaver, and Philip R. Zimmermann, there are several
contributions from the Internet community.

2. General functions

This standard provides four services related to the format of messages and
data files:

  - confidentiality,
  - digital signature,
  - key management,
  - time stamping.

2.1 Confidentiality

This standard provides confidentiality by compressing and encrypting
messages to be transmitted or data files to be stored locally using
conventional encryption. Each conventional key is probably used only once.
That is, a new key is generated at random for each message. Since it is to
be used probably only once, the session key is bound to the message and
transmitted with it. To protect the key, it is encrypted with the
receiver's public key. If files are stored, the owner's public key is
used. The sequence is as follows:

  1. The sender creates a message.
  2. The sending software generates a random number to be used as
     a session key for this message only.
  3. The sending software conventionally encrypts the message using
     the session key.
  4. The session key is encrypted using each recipient's public key. These
     ecrypted session keys are prepended to the encrypted message.
  5. The receiving software decrypts the session key using the approbriate
     recipient's private key.
  6. The receiving software decrypts the message using the session key.

Both digital signature and confidentiality services may be applied to the
same message. First, a signature is generated for the message and prepended
to the message. Then, the message plus signature is encrypted using a
conventional session key. Finally, the session key is encrypted using
public-key encryption and prepended to the encrypted block.

2.2 Digital signature

The digital signature uses a hash code or message digest algorithm, and a
public-key encryption algorithm. The sequence is as follows:

  1. The sender creates a message.
  2. The sending software generates a hash code of the message
  3. The sending software encrypts the hash code using the sender's private
     key.
  4. The encrypted hash code is prepended to the message.
  5. The receiving software decrypts the hash code using the sender's public
     key.
  6. The receiving software generates a new hash code for the received
     message and compares it to the decrypted hash code. If the two match,
     the message is accepted as authentic.

The terms "encrypt" and "decrypt" in this section do not refer to
confidentiality like real encryption. The message is readable by everyone.

2.3 Key management

Public key cryptography requires the knowlegde of the correct public key for
every person involved into communication. A lot of possible attacks deal
with key spoofing or man-in-the-middle key and message manipulation. Any
cryptosystem for the Internet must deal with these attacks.

In order to prove that a certain public key really belongs to the expected
person, certificates are used. A certificate is a machine readable,
digitally signed message. The following certificates are mandantory:

  - binding of a public key and a user id => "ordinary" certificate.
  - unbinding => certificate revocation certificate.
  - compromised key => key revocation certificate.
  
There are two models of key management: Hierarchical trust and Web of trust.

Hierarchical key management relies on a tree of certification authorities
(CA). Every user is certified only by "his" CA. This CA is certified be its
superior CA from the next higher level. The toplevel CA is called "root CA"
and is certified by itself. (Unfortunly in the real world the structure of
the CAs is rather a forest than one tree.) This concept offers:

  - easy implementation
  - single point of failture (compromised or unreachable CA)
  - definite policy
  - extortion and corruption cause lot of trouble (false certificates)
  - short public key packets (usually only one certificate per key)
  - guaranteed to work between every two people
  - central system trust

Web of trust key management allows everybody to certify everybody. The
problem is to find an appropriate trust function to describe and evaluate
the trust of multiple certificate chains through this web of certificates.
This concept offers:

  - a lot of implementation work (hard to implement)
  - many different trust models
  - alternative pathes
  - robustness against compromised or unreachable nodes
  - many different and unknown certification policies
  - large public key packets
  - no guaranteed path between every two people within the web of trust
  - decentralized private trust

Existing software implement the Web of trust using the following ruleset
(described more in detail in 5.1.8):

  1) Public keys of the user herself are completely trusted.
  2) The user chooses for every trusted key if she trust it's certificates
     fully, marginally or not at all.
  3) Every key offering a certificate (to a user ID) by at least n fully
     or m marginally trusted keys is considered trusted.
  4) Repeat at 2) until the trust chain is longer than the length l.
  
The default values are n (Completes_Needed) = 1, m (Marginals_Needed) = 2, and
l (Cert_Depth) = 4.

The current implementations have several flaws: Key revocation certificates
and certificate revocation certificates are not recognized; User IDs without
a selfcertificate are useable; user IDs with a self-certificate revocation
certificate are not considered to be bogus; there is no possibility to
change the default user ID for a public key.

  Note: Some of these lacks are fixed in PGP2.6.3in. [3]

Some CAs do offer a hierarchical certification structure in addition to the
web of trust. This may solve the problem of finding a path. But currently
there is no solution known to define a good trust metric in the web of
trust. Several people doing reserach on this subject.

2.4 Time stamping

A time stamp is a certificate binding an independent time source to a
document. This is especially necessary to prove the existence of a signature
before the key was revoked. So timestamping a document is the task of the
recipient of a digitally signed message. An other usage is to show that a
document existed at a certain time. (Example: European patent offices grant
a patent to the person offering the oldest source of the idea.) So
timestamping belongs only to storage operations. Time stamps should not be
used to detect replay attacks.

Time stamps are defined in the PGP format [1] but not yet implemented. In
order to obtain trustable timestamps automatically, the use of the Eternity
logfile [4] may be considered, because it is royalty free and payment free:

  1) The user calculates a cryptographic secure hash of the file to timestamp.
  2) His software telnets to logfile.iks-jena.de port 1234 and enters the hash
     value and the monetary value behind this document.
  3) The server responds with a line of new hashes.
  4) User's software digitally signes the file and the returned line.
  5) In order to prove this time stamp, the hash line must be requested by
     searching for the hash of the file. The checks are similar to the
     checks required for ordinary digital signatures.

3. Layers of a message

PGP messages occur in OSI layer seven "application layer". They are pure
octect streams. In order to exchange them beween a lot of different
architectures, the OSI layer six "session layer" is needed to define an
exchange enviroment.

The octet stream at level seven has an internal structure describing the
content of the PGP message in a machine-readable format. It is designed to
generate and process any data in a single pass in order to avoid temporary
files. So the byte order of the actual machine can be ignored.

3.1 Session layer

According to RfC 821, binary data may not be transfered as a binary stream
via electronic mail. So it has to be converted to a transport format.
Nowadays, MIME [5] (RfC 2015) [2] should be used wherever possible.

But PGP is older than MIME. So there is a proprietary session layer called
'Ascii Armor'.

3.1.1 MIME

RfC 2015 "MIME Security with Pretty Good Privacy (PGP)" [2] contains all
information necessary to strip or apply this layer. It may make use of the
Ascii Armor layer, but the octect stream may also encoded directly using
MIME itself.

3.1.2 Ascii Armor

Similar to MIME encoding, the process of ascii armor encodes an 8-bit binary
stream of data into printable characters. Every three subsequent octets are
mapped into four subsequent ASCII characters. Futhermore ascii armor
encoding also appends a special CRC to detect transmission errors. In order
to ease recognition of Ascii Armored messages, a special header and footer
is provided.

The whole ascii armored message contains:
  - a header line,
  - the armor headers,
  - a blank line,
  - the radix-64 encoded octet stream,
  - the radix-64 encoded checksum and
  - a footer line.

3.1.2.1 Radix-64 encoding

To encode assume the file as an octect (input) stream. Take the first three
bytes from the stream. Convert each byte into network bit order (MSB first).
This results into:

	     +--first octect-+-second octect-+--third octect-+
	     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
	     +-----------+---+-------+-------+---+-----------+
	     |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
	     +--1.index--+--2.index--+--3.index--+--4.index--+

Each index value points to a character of the following string (all upper
letter characters followed by all lower letter characters followed by the
digest and '+' (US-ASCII 0x2B) and '/' (US-ASCII 0x2F):
  ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

The resulting characters are send to the output stream. The numeric values
of all these characters are taken from US-ASCII [6].

Repeat the aforementioned until the input stream does contain less than
three octets. If no octet is left, the procedure is finished. If one or two
octets are left, the missing octets are assumed to be zero for the last
translation step. All indeces containing no valid bit from the data stream
(because the octect is missing), are converted to the padding character '='
(US-ASCII 0x3D). If only the third octect is missing, this happens to the
fourth index. If only the first octect is present, it happens to the third
and the fourth index, respectively.

The output stream should be broken to lines of 64 characters each.

To decode such an radix-64 encoded character (input) stream, lookup each
character in the array mentioned above. Ignore any character not in the
array and not the padding character. You must not expect any finite line
length for internal buffers.

The input stream contains a multiple of four such characters. Due to
transmission errors this assumption might fail. Any software that adheres to
this RfC must expect such situations.

Every four characters are looked up into there index values. The padding
character looked up as numerical zero. The convertion is reversed to the
three octets of this procedure. Starting with the first, octets are sent to
the output stream. Only octects containing no bit from a padding character
are sent. If even the first octect contains a padding character, the padding
character is not part of this radix-64 stream. It belongs to the next part
of of ascii armor.

3.1.2.2 Checksum

In order to detect transmission errors, a simple radix-64 encoded checksum
is appended to the radix-64 encoding of the octet stream. In order to
terminate the radix-64 encoded octet stream, the checksum is prepended by a
single radix-64 padding character. Software should output the padding
character and the radix-64 encoded checksum as a single line. Note, that the
checksum is generated using the pure octet stream and not the radix-64
encoded transport shell.

The 24-bit CRC checksum is computed by using the generator 0x864CFB and an
initialization of 0xB704CE. For more information on CRC functions, the
reader is asked to look at chapter 19 of [7].

  [This paragraph needs a lot of work. I have to rewrite the paragraph
   using the sources.]

3.1.2.3 Header and footer lines

Any ascii armored content is surrounded by a specific pair of
corresponding header/footer lines. They are used to automatically
recognise an ascii armored content and to determine the right handler for
this content. Normally the content of a ascii armored message can be
obtained by reading the radix-64 encoded octet stream. But this technique
requires software able to decode radix-64. In many cases, simple string
comparation are used to determine the right handler (i.e. using procmail).

A header line is a single line composed by:
  - five dashes '-' (US-ASCII 0x2D),
  - the words "BEGIN PGP content" seperateded by single spaces ' '
    (US-ASCII 0x20), and
  - five dashes.

"Content" is a placeholder for the content phrase. It is substituded by
one of the following phrases:

  "MESSAGE"          -- generetic content, usually signed or encrypted.
  "SIGNATURE"        -- seperate signature of some corresponding data.
  "PUBLIC KEY BLOCK" -- one or more public keys.
  "SECRET KEY BLOCK" -- one or more secret keys.

It might be possible that the octect stream is larger than the maximum
transmission size of the channel. In this case the the octet stream can be
broken into chunks. Each chunk is ascii armored seperatly. In order to
identify and reorder the seperate chunks, the content phrase is extented by
the phrase ", PART x/y" where x and y are numbers printed decimal. y denotes
the total number of chunks the octect stream was split into. x denotes the
the running number of the chunk starting with one. These number can start
with leading zeros, but are still decimal coded. The "/y" part of the phrase
is optional.

Examples:
  "-----BEGIN PGP PUBLIC KEY BLOCK, PART 3/09-----"
  introduces the third part of nine of some public keys.
  
  "-----BEGIN PGP MESSAGE, PART 091-----"
  introduces the ninty first part of a generic PGP message.
  
  "-----BEGIN PGP SIGNATURE-----"
  introduces a seperate digital signature.
  
Directly after the radix-64 encoded checksum line, a footer line is
expected. It must match the corresponding header line despite the word
"BEGIN" is replaced by "END".

3.1.2.4 Armor headers

Directly after the header line, special armor headers may exist. They are
terminated by an empty line. If no armor header exists, this empty line
should not be generated, but may be present.

The syntax of those headers is defined in RfC 822 without the extenstions
defined in later RfCs.

The following keywords are defined:

  Version   -- Denotes the version used to generate this message.
  Comment   -- Any user defined world readable message.
  Hash      -- Used method of hashing to ease one pass processing.
               Defined are "MD5", "MD2" and  "SHA-1".
  MessageID -- Random number to trace messages.
  Charset   -- Character set for the message.

The MessageID is usually derivated from the same "randomness" pool the
session key comes from. So the MessageID header introduces an unnecessary
security weekness, because the confidentiality of the message may be
attacked by attacking the "randomness" pool functions. This header must not
generated and should produce a warning to the recipient.

Any unknown armor header should produce a warning to the recipient.

3.1.2.5 Example

  -----BEGIN PGP MESSAGE-----
  Version: 2.6.3in
  
  owFbx8DAYFTCWlySkpkHZDKEFCXmFedmFhdn5ucpZKdWFiv4hgaHKPj5hygUpSbn
  l6UWpabo8XIBAA==
  =3m1o
  -----END PGP MESSAGE-----

Please note, that this example is idented by two spaces in order to not
confuse software.

3.1.3 Cleartext signature framework

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 an cleartext, this
framework is used.

It consists of:
  - the cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a single
    line,
  - some optional armor headers (3.1.2.4),
  - any number of empty lines not included into the message digest,
  - the dash escaped cleartext which is included into the message digest,
  - the ascii armored signature(s) including the armor header and footer
    lines.

If the "Hash" armor header is given, the specified message digest algorithm
is used for the signature. If this header is missing, MD5 is assumed as
default. It is possible, that more than one message digest is used in the
signature, so the "Hash" armor header may contain a comma delimited list
of used message digests.

Dash escaped cleartext is the ordinary cleartext where every line starting
with a dash '-' (US-ASCII 0x2D) is prepended by the sequence dash '-'
(US-ASCII 0x2D) and space ' ' (US-ASCII 0x20). This prevents the parser
from recognising armor headers of the cleartext itself. The message digest
is computed using the cleartext itself, not the dash escaped form. So it
is possible to seperate or join a signature from or to a cleartext without
resigning it.

3.2 General packet framework

The octet stream of a PGP message is seperated into a several chunks. They
are called packets. Every packet consists of a header and it's data tail.
The header of a packet consists of a single octet and some length
definitions. So it may be possible to skip a packet if the software is
unable to handle the content. Unfortunly some data has an indefinite length
to single pass software. So the packets in a chunk should be arranged in a
single pass aware way ending with the indefinite length packet. This may
cause temorary storage of small amounts of data.

The octets of the PGP message are described in network bit order (highest
bit first).

3.2.1 Cipher Type Byte

Every packet starts with a single octet, the CTB "Cipher Type Byte". It
determines the content of the packet and the length octets.

       +---------------+
  CTB  |7 6 5 4 3 2 1 0|
       +---------------+
  Bit 7 -- always one
  Bit 6 -- paket version four or higher is present if set

packet version three or lower
  Bits 5-2 -- content type

    0001 -- public key encrypted packet
    0010 -- signature packet
    0101 -- secret key packet
    0110 -- public key packet
    1000 -- compressed data packet
    1001 -- conventional key encrypted packet
    1011 -- literal data packet
    1100 -- keyring trust packet
    1101 -- user id packet
    1110 -- comment packet
    other - undefined

  Bits 1,0 -- length type
    00 -- one length octet
    01 -- two length octets
    10 -- four length octets
    11 -- no length octet (The packet is of indeterminate length.)

packet version four or higher
  Bits 5-0 -- content type

    000000 -- Reserved. A packet must not have a tag with this value.
    000001 -- Encrypted Session Key Packet
    000010 -- Signature Packet
    000011 -- Conventionally Encrypted Session Key Packet
    000100 -- One-Pass Signature Packet
    000101 -- Secret Key Packet
    000110 -- Public Key Packet
    000111 -- Secret Subkey Packet
    001000 -- Compressed Data Packet
    001001 -- Symmetrically Encrypted Data Packet
    001010 -- Marker Packet
    001011 -- Literal Data Packet
    001100 -- Trust Packet
    001101 -- User ID Packet
    001110 -- Subkey Packet
    010000 -- Comment Packet
    other  -- undefined
  
3.2.2 Packet length

The packet length is the amount of content octects without the CTB (3.2.1)
and length octets.

3.2.2.1 Packet version three or lower

The CTB (3.2.1) contains the length type pointing out, how many length
octets follow the CTB. The length of the following data must be known to
the generation process or the indefinite length must be used. The
indefinite length packet should be the last in the chunk. Reading software
can assume, that the indefinite length packet is the last chunk of the
stream.

The length of the packet data is stored in network byte order (see 4.1) as
one, two or four octet value. It is recommended to use the smallest storing
size for the length. But some implementations default this length to two or
four bytes length if it is necessary or not.

Example:
  10111001 00000011 10010000 ...912 octets...

3.2.2.2 Packet version four or higher

The CTB (3.2.1) is followed by several subpackets. Every subpacket
contains data of a definite length and the information if this is the last
subpacket or not.

Every subpacket starts with a single length octet:
			      +---------------+
			      |7 6 5 4 3 2 1 0|
			      +---------------+

If bit seven to five are set, the length of the subpacket is two to the
power of the numerical value of bits four to zero. This subpacket is
followed by additional subpackets.

The length octet of the last subpacket has at least on of the bits seven to
five cleared. If bit seven is cleared, the length of the subpacket is the
numerical value of of the bits six to zero. So this subpacket codes lengths
from zero to 127.

If bit seven is set and bit six is cleared, the length of the subpacket is
the numerical value of the bits five to zero plus 128. So this subpacket
codes lengths from 128 to 192.

If bit seven and bit six are set and bit five is cleared, the length of this
subpacket is the numerical value of the bits four to zero prepended to the
next octet plus 192. So this subpacket codes length from 192 to 8383. Note
that this subpacket uses two octets for it's length.

Example:
  11010000 111011011 ...134217728 octets... 11000000 00001000 ...200 octets...

4. Generic data types

This section describes the generic data elements used in this standard.

4.1 Scalar numbers

Scalar numbers are unsigned, and are always stored in big-endian format also
known as network byte order. To read a scalar from the octet stream:

  1) set the result to be to zero
  2) multiply the result to be by 256
  3) read the an octet from the steam and add it to the result to be
  4) jump to 2) until all octets of the scalar are read.

4.2 Multi-Precision Integers

Multi-Precision Integers (also called MPIs) are unsigned integers used to 
hold large integers such as ones used in cryptographic calculations. 

An MPI consists of two pieces: a two-octet scalar number that is the length
of the MPI in bits followed by a string of octets that contain the actual
integer stored exactly as an ordinary scalar number.

Example: (all numbers are in hexadecimal)
  The string of octets [00 01 01] forms an MPI that has a value of 1. The
  string [00 09 01 ff] forms an MPI with the value of 511.

The storage size in octets of an MPI is the ((length of an MPI + 7) / 8) in
addition to the length scalar number.

The length field of an MPI should describe the length starting from its
most significant non-zero bit. Software must be able to deal with leading
zero bits of an MPI.

4.3 Strings

A string consists of a one-octet length and then N octets of string data.
Characters values must fit into an octet. The default charset is US-ASCII.
So strings are limited to 255 charaters.

4.4 Time fields

A time field is a four-octet scalar number containing the number of
seconds elapsed since midnight, 1 January 1970 GMT. This is standard unix
time. Other timezones must be ajusted to GMT.

5. Packet types

5.1 Packet version three or lower

5.1.1 Public key encrypted packet

A public key encrypted packet has the CTB (3.2.1) tag 1. It contains the
symmetric session key for conventionally encrypted packets (5.1.6) later
in the stream. If a message is encrypted to more recipients, such a public
key encrypted packet occurs for every recipient.

Software must not encrypt to anybody else without interaction with the
user. The user must have the full control over the list of recipients the
message is encrypted to. This explicitly includes the EncryptToSelf
configuration option of existing implementations. The software is now
required to ask the user explicitly if he wants to encrypt to additional
recipients or not.

A public key encrypted packet consists of:
  - a version octet,
  - a key ID,
  - an algorithm identifier octet, and
  - algorithm specific data.

The version octet is two for PGP versions <= 2.5 or three for newer PGP
versions.

The key ID (6.1) is an eight octet scalar number (4.1).

The algorithm identifier is one for RSA or sixteen for ElGamal.

If the algorithm is RSA or ElGamal, the rest of the packet is the the
encrypted session key as a MPI (4.2).

The session key is generally shorter than the input blocksize of the
asymmetric algorithm. So padding is needed to enlarge the session key as
much as possible. On decrypting the session key the padding must be
checked to prove the correct secret key to be used.

PGP version 2.2 or earlier encode the message digest into a long enough
number as follows:
          most significant octets   ... least significant octets
         0x00 0x01 session-key checksum 0x00 random(padding) 0x01
  
PGP versions 2.3 and later encode the message digest into a long enough
number as follows:
          most significant octets   ... least significant octets
         0x00 0x02 random(padding) 0x00 0x01 session-key checksum

The checksum is a 16 bit checksum of the session key stored as a two octet
scalar (4.1). The random padding is required to be nonzero for each octet.

  [The chekcsum algorithm will be added from the source.]
 
5.1.2 Signature packet

A signature packet has the CTB (3.2.1) tag 2. It is used to store any
signature.

If the plaintext that was signed is included in the same octet stream as
the signature packet, it begins right after the signature packet as a
literal packet.

If the plaintext that was signed is included as a cleartext signature

If the signature is a certificate it follows the key packet and the
optionally user ID packet.

A signature packet consists of
  - a version octet,
  - a subpacket containing signature type and time,
  - a key ID,
  - an algorithm octet determining the asymmetric cryptosystem,
  - an algorithm octet determining the message digest algorithm,
  - the two most significant octets of the message algorithm, and
  - algorithm specific data.

The version octet is two for PGP versions <= 2.5 or three for newer PGP
versions.

The subpacket consists of
  - a length octet, determining how many following octets are included
    to the subpacket. All those following octets of the subpacket are
    prepended to the message in order to be hashed.
    It was designed to contain more data, but this introduces a security
    hole, so a warning must be generated, if the subpacket length has an
    other value than five.
  - a signature classification octet described below.
  - a time field (4.4), when the signature was made.
  - (optionally) a two octet scalar value (4.1), containing the validity
    period of the signature in days.

  Owing to the way the MD5 is computed for the signature, if that field is
  variable length, it is possible to generate two different messages with
  the same MD5 hash. One would be a file of length N, with a 7-byte
  following section consisting of a signature type byte, 4 bytes of
  timestamp, and 2 of validity period, while the other would be a file of
  length N+2, whose last two bytes would be the siganture type byte and
  the first byte of timestamp, and the last three bytes of timestamp and
  the validity period would instead be interpreted as a signature type
  byte and a timestmap.
  
The key ID (6.1) is an eight octet scalar number (4.1).

The asymmetric cryptosystem algorithm identifier octet is one for RSA,
sixteen for ElGamal or seventeen for DSS.

The message digest algorithm identifier octet is one for MD5 or two for
SHA-1. The message digest output is generally shorter than the input
blocksize of the asymmetric algorithm. So padding is needed to enlarge the
message digest as much as possible. On verifying the signature the padding
must be checked to prove the correct public key to be used.

  PGP version 2.2 or earlier encode the message digest into a long enough
  number as follows:
          most significant octets   ... least significant octets
            0x00 0x01 message-digest 0x00 0xFF(padding) 0x01

  PGP versions 2.3 and later encode the message digest into a long enough
  number as follows:
          most significant octets   ... least significant octets
     0x00 0x01 0xFF(padding) 0x00 ASN.1-coded-message-digest

  The ASN.1-coded-message-digest is derivated from RfC1423 [9]:
    Sequence of (code 0x30, len 0x??)
      Sequence of (code 0x30, len 0x??)
        Object Identifier (code 0x06, len 0x??)
          iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5
            (= 2a 86 48 86 f7 0d 02 05) (determining MD5)
          or ... (SHA-1)
        Null Data (code 0x05, len 0x00)
      Scalar number (0x04, len 0x??)
        Message Digest
      
  Example for MD5: 30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04 10
  followed by the 16 octets of the message digest itself.

If the algorithm is RSA, the rest of the packet is the the encrypted
message digest as a MPI (4.2).

If the algorithm is ElGamal, the rest of the packet is the the encrypted
message digest as a MPI (4.2).

If the algorithm is DSS, the rest of the packet are the the encrypted
message digest values as two MPIs (4.2).

The signature classification field describes what kind of 
signature certificate this is. There are various hex values:
  00 - Signature of a message or document, pure octet stream.
  01 - Signature of a message or document, canonical text.
  10 - Key certification, generic. Material signed is public key pkt and
       User ID pkt.
  11 - Key certification, persona. No attempt made at all to identify the
       user with a real name. Material signed is public key pkt and User
       ID pkt.
  12 - Key certification, casual identification. Some casual attempt made
       to identify user with his name. Material signed is public key pkt
       and User ID pkt.
  13 - Key certification, positive ID. Heavy-duty identification efforts,
       photo ID, direct contact with personal friend, etc. Material
       signed is public key pkt and User ID pkt.
  20 - Key compromise. User signs his own compromise certificate. This is
       independent of user ID associations, so material signed is public
       key pkt ONLY.
  30 - Key/user ID revocation. User can sign his own revocation to dissolve
       an association between a key and a user ID, or certifier may revoke
       his previous certification of this key/userid pair. Material
       signed is public key pkt and User ID pkt.
  40 - Timestamping a signature certificate. It is used to apply trusted
       timestamp. Material signed is the octet stream followed by the line
       of hashes as described in 2.4.

When a signature is made to certify a key/UserID pair, it is computed
across two packets-- the public key packet, and the separate User ID
packet: The packet headers (CTB (3.2.1) and length fields (3.2.2)) for the
public key packet and the user ID packet are both omitted from the
signature calculation for a key certification.

A key compromise certificate is issued by someone to revoke his own key
when his secret key is known or assumed to be compromised. If that
happens, a user would sign his own key compromise certificate with the key
that is being revoked. Even a encryption or storage key is used for this
signature to point out, that exactly this key is revoked. It is not
possible to revoke a encryption or storage key using the corresponding
certifictation or signature key. A key revoked by its own signature means
that this key should never be used or trusted again, in any form,
associated with any user ID. A key compromise certificate issued by the
keyholder invalidates any other key/user ID certifications made by anyone
else for that key. A key compromise signed by someone other than the key
holder is invalid.

If a key has been revoked, software must not allow its use to generate any
messages, and if an incoming message uses it, a warning must inform the
user that the key is invalidated. Its conforming to even not allow
decrypting or verifiying signatures make by this key.

A key/user ID revocation certificate (certificate revocation certificates)
issued by the keyholder must invalidate all other key certifications made
by anyone else for that key/user ID pair. Also, a third party certifier
may revoke his own previous certification of this key/user ID pair by
issuing a certificate revocation certificate. Such a revocation should not
affect the certifications by other third parties for this same key/user ID
pair.

5.1.3 Secret key packet

A secret key packet has the CTB (3.2.1) tag 5. It contain all information
of the secret component of a key pair. It must be stored using encryption.
It should not leave the local computer. If it is extracted locally, this
packet is followed by a sequence of user ID packets (5.1.9).

Only the keyowner has access to the secret component. Secret keys must not
be accessible to any other person or institution. This is even true for
employee keys of companies. If the key owner suspect a compromise by an
onther person, any company or any gouvernment of this secret component, he
must immedeatly revoke this key.

A secret key packet consists of:
  - a version octet,
  - a time value,
  - a valitidy period,
  - an algorithm octet determining the asymmetric cryptosystem,
  - algorithm specific public data of the key,
  - an algorithm octet determining the symmetric cryptosystem,
  - optionally the initialisation vector of the symmetric encryption,
  - encrypted algorithm specific secret data of the key, and
  - a encrypted 16 bit checksum of the secret data.
  
The version octet is two for PGP versions <= 2.5 or three for newer PGP
versions.

The time value (4.4) determine the moment the is not valid before.
Ususally this is the creation time of the key.

The validity period is a two octet scalar number (4.1) determining the
validity period of the key in days. If it is zero, the key ha an unlimited
lifetime.

The algorithm identifier of the asymmetric cryptosystem is one for RSA,
sixteen for ElGamal, or seventeen for DSS.

The algorithm identifier of the symmetric cryptosystem is zero for
unencrypted (should only occur in not pagable memory), one for IDEA, two
for 3DES-EDE, or three for CAST5.

The initialisation vector is a scalar number (4.1) of the blocksize of the
symmetric algorithm. It is only necessary if encryption takes place.

All secret fields in the secret key certificate may be (passphrase)
encrypted, including the checksum. The checksum is calculated from all of
the bytes of the unenciphered secret components. The public fields are not
encrypted. The encrypted fields are done in cipher feedback mode (CFB),
and the checksum is used to tell if the password was good. The CFB
initialisation vector field is just encrypted random data using a zero
initialisation vector.

If the algorithm is RSA, the public component consits of:
  - a MPI (4.2) of the public modulus n, and
  - a MPI (4.2) of the public encryption exponent e

If the algorithm is RSA, the secret component consits of:
  - a MPI (4.2) of the secret decryption exponent d,
  - a MPI (4.2) of the secret factor p,
  - a MPI (4.2) of the secret factor q, and
  - a MPI (4.2) of the secret multiplicative inverse u.

If the algorithm is ElGamal, the public component data consists of:
  - a MPI (4.2) of the prime p,
  - a MPI (4.2) of the generator g, and
  - a MPI (4.2) of the public key y (= g**x mod p where x is secret).

If the algorithm is DSS, the public component data consists of:
  - a MPI (4.2) of the prime p,
  - a MPI (4.2) of the group order q, (prime divisor of p-1)
  - a MPI (4.2) of the generator g, and
  - a MPI (4.2) of the public key y (= g**x mod p where x is secret).

5.1.4 Public key packet

A public key packet has the CTB (3.2.1) tag 6. It contains the public
component of an asymmetric key pair. This packet introduce a published
public key. It is followed by either the key compromise certificate or an
optional keyring trust packet (5.1.8) (owner trust) and several user ID
packets (5.1.9) chunks. Each user ID packet is followed in its chunk by an
optional keyring trust packet (keylegit) and several signature packets
(5.1.2) (certificates) optionally followed by a keyring trust packet
(signature trust).

A public key packet consits of:
  - a version octet,
  - a time value,
  - a validity period,
  - an algorithm identifier octet, and
  - algorithm specific public component.

The version octet is two for PGP versions <= 2.5 or three for newer PGP
versions.

The time value (4.4) determine the moment the is not valid before.
Ususally this is the creation time of the key.

The validity period is a two octet scalar number (4.1) determining the
validity period of the key in days. If it is zero, the key ha an unlimited
lifetime.

The algorithm identifier of the asymmetric cryptosystem is one for RSA,
sixteen for ElGamal, or seventeen for DSS.

If the algorithm is RSA, the public component data consists of:
  - a MPI (4.2) of the public modulus n, and
  - a MPI (4.2) of the public encryption exponent e

If the algorithm is ElGamal, the public component data consists of:
  - a MPI (4.2) of the prime p,
  - a MPI (4.2) of the generator g, and
  - a MPI (4.2) of the public key k.

If the algorithm is DSS, the public component data consists of:
  - a MPI (4.2) of the prime p,
  - a MPI (4.2) of the group order q,
  - a MPI (4.2) of the generator g, and
  - a MPI (4.2) of the public key k.

5.1.5 Compressed data packet

A compressed data packet has the CTB (3.2.1) tag 8. It contains external
data compressed to remove redundancy and save space. The compressed data
decompress into a layer seven octet stream conforming 3.2. Compressing
should be used on every external octet stream unless it enlarges the data
stream.

A compressed data packet consists of a algorithm identifier octet followed
by the octet stream of compressed data.

The algorithm identifier octet is one for ZIP.

   [A description of ZIP is needed here.]

Compressed data packets are the prominent canidates for indefinit length
packets. So they are expeced as the last ones in their enclosing object,
and the decompressor knows when to stop.

5.1.6 Conventional key encrypted packet

A conventional key encrypted packet has the CTB (3.2.1) tag 9. It contains
an encrypted octet stream. It decrypts into a layer seven the octet stream
conforming 3.2. It is recommended to contain a compressed data packet to
avoid redundacy helpful to break the symmetric cipher.

The conventional key encrypted packet consists of a stream of
conventionally encrypted octets up to the end of the packet.

After decrypting the conventionally encrypted data, a special random
prefix stored as an eight octet scalar (4.1) and two key check octets are
revealed. The random prefix and key check prefix are inserted before
encryption and discarded after decryption. This prefix group is visible
after decrypting the ciphertext in the packet.

The random prefix serves to start off the cipher feedback chaining process
with 64 bits of random material. It may be discarded after decryption.

The key check prefix is composed of two identical copies of the least
significant octets of the random prefix, stored in the same order. During
decryption, the 9th and 10th octets of decrypted material are checked to
see if they match the 7th and 8th octets, respectively. If these key check
bytes meet this criterion, then the conventional key is assumed to be
correct.

One unusual point about the way encryption is done. Using the cipher in
CFB mode, the first ten octets are decrypted normally, but octets ten to
seventeen, the first eight octets of the data proper, are encrypted using
octets two to nine as the initialisation vector. This is essentially using
CFB-16 for one part of the encryption, while CFB-64 is used elsewhere.

5.1.7 Literal data packet

A literal data packet has the CTB (3.2.1) tag 11. The content of a literal
data packet is generic data and not subject to any further interpretation.

In order to transfer storage relevant information, a literal data packet
consists of the concatination of a mode octet, a string (4.3), a time field
(4.4) and the octet stream of the data itself.

The mode octet is either 0x62 (US-ASCII 'b'), 0x74 (US-ASCII 't'), 0x01 or
0x6C (US-ASCII 'l').

Mode 'b' is the binary mode. The octet stream should be stored as an octet
stream. No conversations must be made.

Mode 't' is the text mode. The octet stream is a character stream in the
given message charset. If no charset is defined in the message, assume
US-ASCII. All necessary translations should be applied including line
termination translation.

Mode 0x01 and 'l' are local mode. The octet stream contains data in local
storage conventions. If this mode is generated, only the mode octet 'l'
should be used. The existance of mode octet 0x01 is an typographic error of
RfC 1991.

The string is used a the default file name for storing on receiver's site.
Implementors should keep in mind the security problem of overwriting
existing files especially designing an automatic batch mode.

The time field should contain the time at which the file was last modified,
if not applicable the time at which the data packet was created. If no time
should be provided, the time value is set to zero. The receiver should set
the time of the received file to the provided value or to the current time,
if the time value is zero.

The octet stream of the data starts directly after the time field and ends
with the packet. If a signature includes a literal data packet (5.1.7),
only the octet stream of the data is joined to the signature. The octet
stream is used as is for the signature process. Any translation must be
done before generating or after checking the signature. This allows to
detach the signature from the data without resigning.

5.1.8 Keyring trust packet

A keyring trust packet has the CTB (3.2.1) tag 12. Keyring trust packets
should not exported with any key transaction, but may be occur in generic
PGP data. It is not uncommon to transfer a whole local keyring which
contains the trust packets. Trust packets may be exported without any
security risks, but must not included into the receiver's database.

The keyring trust packets may useful for implementing the web of trust as
described in 2.3. It only exists to speed up programms. It is described in
this RfC to discuss the trust model more in detail.

The meaning of the keyring trust packet is context sensitive. The trust byte
has three different definitions depending on whether it follows a public key
packet, a user ID packet, or a certificate on the ring.

It consists of a single octet:
			      +---------------+
			      |7 6 5 4 3 2 1 0|
			      +---------------+

If the keyring trust packet follows a public key packet, the following bit
definitions apply:

  Bits 0-2 - OWNERTRUST bits - Trust bits for this key owner.
             The OWNERTRUST bits are set by the user. Values are:
       000 - undefined, or uninitialized trust.
       001 - unknown, we don't know the owner of this key.
       010 - usually do not trust this key owner to certify other keys.
       101 - usually do trust this key owner to certify other keys.
       110 - always trust this key owner to certify other keys.
       111 - the secret part of this key is also present in the database.
             User can't set the OWNERTRUST to this value without having the
	     corresponding secret part. Check enforced by software.
  Bit 5    - DISABLED bit - Means that this key is disabled, and
             must not be used.
  Bit 7    - BUCKSTOP bit - OWNERTRUST == 111.
             Signifies the ultimately-trusted "keyring owner".
	     "The buck stops here".

If the keyring trust packet follows a user ID packet, the following bit
definitions apply:

  Bit 0-1 - KEYLEGIT bits - Validity bits for this key. Set if we believe
	    the preceding key is legitimately owned by who it appears to
	    belong to, specified by the preceding user ID. Computed from
	    various certificates trust packets that follow. If a user ID
	    is not certified by the key itself or the corresponding signature
	    key, the user ID must be assumed to be invalid. If a trusted
	    certificate revocation certificate exisits, the new trust can
	    not be derivated automatically. User interaction is required.
       00 - unknown, undefined, or uninitialized trust.
       01 - do not trust this key's ownership.
       10 - marginal confidence of this key's ownership.
            Totally useless for certifying other keys, but may be useful
            for checking message certificates with an advisory warning
            to the user. This requires any trusted certificate.
       11 - completely trust this key's ownership.
	    This requires either:
	      - one ultimately trusted certificate (SIGTRUST=111)
	      - COMPLETES_NEEDED completely trusted certificate (SIGTRUST=110)
	      - MARGINALS_NEEDED marginally trusted certificate (SIGTRUST=101)
	      - the trust metric of 6.2.1 is one or more.
  Bit 7   - WARNONLY bit - If the user wants to use a not fully validated
	    key for encryption, he is asked if he really wants to use this
	    key. If the user answers 'yes', the WARNONLY bit gets set,
	    and the next time he uses this key, only a warning will be
	    printed. This bit gets cleared during the maintenance pass.

If the keyring trust packet follows a certificate, the following bit
definitions apply:

  Bits 0-2 - SIGTRUST bits - Trust bits for this certificate. Value is
             copied directly from OWNERTRUST bits of signer:
       000 - undefined, or uninitialized trust
       001 - unknown
       010 - untrusted certificate
       101 - reasonably trusted certificate
       110 - completely trusted certificate
       111 - ultimately trusted certificate
  Bit 6    - CHECKED bit - This means that the key checking pass has tested
             this certificate and found it good. If this bit is not set, the
	     maintenance pass considers this certificate untrustworthy.
  Bit 7    - CONTIG bit - Means this signature leads up a contiguous trusted 
             certification path all the way back to the ultimately-trusted
	     keyring owner, where the buck stops.  This bit is derived 
	     from other trust packets.

All other trust is derived from the BUCKSTOP keys in a special maintenance
pass over the key database. Any good signature made by a given key has its
SIGTRUST equal to the key's OWNERTRUST. Based on COMPLETES_NEEDED and
MARGINALS_NEEDED, if enough trusted certificates are on a key/userID pair,
the key/userid association is considered legitimate. If there is no
certificate from the keyowner itself (selfsigned or using the corresponding
signing key), the user ID is considered bogus and all certificates are
stripped away. If there is a certificate revocation certificate from the
keyowner itself, the user ID is considered invalid and all other
certificates are stripped away. If there are certificate revocation
certificates interaction with the user is required. The results of the last
interaction may be stored for reuse.

When a key has a legitimate user ID, the user is asked to set the OWNERTRUST
for the corresponding key. Ths idea is that the user ID identifies someone
the user knows, at least by reputation, so once it has been established who
holds the secret key, that person's trustworthiness as an introducer can be
established and assigned to the key.

Once that is done, this key's certificates then have weight establishing
other key/user ID associations.

There is a limit to the depth to which this can go. Keys which secret parts
are in the database are at depth zero. Keys certified by those keys are at
depth one. Keys which are fully certified using only certificates from keys
at depth one or less are at depth two. Keys which are fully certified using
only certificates from keys at depth two or less are at depth three, and so
on.

If you know all of your trusted introducers personally, and have certified
their keys, then you will never have a trused key at a depth of greater than
two. The maximum depth is limited my MAX_CERT_DEPTH. It should never get
very large in a well-connected "web of trust".

The trust of a key owner (OWNERTRUST) does not just reflect our estimation
of their personal integrity, it also reflects how competent we think they
are at understanding key management and using good judgement in signing
keys. The OWNERTRUST bits are not computed from anything -- it requires
asking the user for his opinion.

It must be possible for the user to modify the SIGTRUST or the KEYLEGIT bits
seperatly. This allows working assumptions if some certificates seems to be
unlikly. This is especially true for joke certificates or testing purposes.

New certificates are checked on adding them to the key database. Old
certificates are checked on request (checking pass). The maintenance pass is
run every time the key database changes, and operates in a
top-of-pyramid-down manner as follows.

If at any time during any of these steps the KEYLEGIT field goes from not
fully set to fully set, and the OWNERTRUST bits are still undefined, the
user is asked a question to define the OWNERTRUST bits. First, for all keys
with BUCKSTOP set, check if they are really present in the secret keyring,
if not, the BUCKSTOP bit is cleared and OWNERTRUST is requested from the
user. SIGTRUST and KEYLEGIT is initialized to zero for non-buckstop keys.

The real maintenance pass is done in a recursive scan: Start with BUCKSTOP
keys, find all user ID/key pairs certified by a key and update the trust
value of these certificates by copying the OWNERTRUST of the signer to the
SIGTRUST of the certificate. SIGTRUST values set by the user must remain.
If this makes a key fully validated, start looking for signatures made by
this key, and update the trust value for them.  Repeat until everything has
settled down.

5.1.9 User ID packet

A user ID packet has the CTB (3.2.1) tag 13. The user ID packet follows a
public or secret key. The content is a octet stream of printable
characters up to the end of the packet.

When a key/user ID pair is certified, the signature covers both the public
key packet and the user ID packet. The certificate thereby logically binds
together the user ID with the key. The user ID packet is always associated
with the most recently occurring public key regardless of whether there
are other packet types appearing between the public key packet and the
associated user ID packet.

There may be more than one user ID packet after a public key packet. They
all would be associated with the preceding public key packet.

A user ID must be followed by a keyowner certificate or a keyowner
certificate revokation certificate to be valid.

5.1.10 Comment packet

A comment packet has the CTB (3.2.1) tag 14. A comment packet is generally
just skipped over, although it may be displayed to the user when
processed.

The content is a octet stream of printable characters up to the end of the
packet.

5.2 Packet version four or higher

5.2.1 Encrypted session key packet

An encrypted session key packet has the CTB (3.2.1) tag 1. It contains the
symmetric session key for symmetrically encrypted data packets (5.2.9)
later in the stream. If a message is encrypted to more recipients, such a
public key encrypted packet occurs for every recipient.

Software must not encrypt to anybody else without interaction with the
user. The user must have the full control over the list of recipients the
message is encrypted to. This explicitly includes the EncryptToSelf
configuration option of existing implementations. The software is now
required to ask the user explicitly if he wants to encrypt to additional
recipients or not.

The content of the encrypted session key packet is exactly the same syntax
and semantic as described in 5.1.1. The version octet is two or three as
described there.

5.2.2 Signature packet

A signature packet has the CTB (3.2.1) tag 2. It is used to store any
signature or certificate.

The sihnature packet consits of:
  - a version octet, (set ot four)
  - a signature classification octet, (hashed)
  - a asymmetric cryptosystem identifier octet (hashed)
    which is one for RSA, sixteen for ElGamal, or seventeen for DSS,
  - a message digest algorithm (hashed)
    which is one for MD5 or two for SHA-1,
  - a two octet scalar (4.1) determining the length of the following
    hashed subpackets, (hashed)
  - a sequence of hashed subpackets (hashed),
  - a two octet scalar (4.1) determining the length of the following
    non hashed subpackets,
  - a sequence of non hashed subpackets,
  - the two most significant octets of message digest, and
  - the algorithm specific encrypted message digest.

The signature contains subpackets of the following structure:
  - a subpacket length (1 or 2 octets):
      Length includes the type byte but not this length,
        1st octet <  192: length is the numerical value of this octet
        1st octet >= 192: length is equal to
            (1st octet - 192) * 256 + (2nd byte) + 192;
  - a subpacket type octet, critical if higest significant bit (Bit 7)
    is set. The remaining bits six to zero are defined the type.
  - subpacket specific data

The following subpacket types are defined. Some subpackets apply to the
signature itself and some are attributes of the key. Noncritical
subpackets may be displayed and must be ignored. Unrecognized subpackets
should be skipped unless marked critical. Sorted by subpacked type
(without critical bit):

  2 - signature creation time
      A time value (4.4) determining the signature was made.
      
  3 - signature expiration time
      The validity period of the signature. This is an eight octet scalar
      continaing the number of seconds after the key creation time that
      the key expires. If this is not present or has a value of zero, the
      signature never expires.

  8 - user ID flags
      It is an octet which is one, if the self-certificate belongs to the
      primary user ID. Otherwise it is zero.
  
  9 - key expiration time
      The validity period of the key. This is an eight octet scalar
      continaing the number of seconds after the key creation time that
      the key expires. If this is not present or has a value of zero, the
      key never expires. This is found on a self-signature.

 11 - preferred symmetric algorithms
      It is an stream of symmetric cryprosystem identifier octets with the
      most perfered first. It should be assumed that only algorithms
      listed are supported by the recipient's software. If this subpacket
      is not included, IDEA is assumed. This is found on a self-signature.

 16 - key ID of signer
      An eight octect scalar (4.1) containing the key ID of the signer.

5.2.3 Conventionally encrypted session key packet

A conventionally encrypted session key packet has the CTB (3.2.1) tag 3.
It describes a session key that has been encrypted to a secondary
symmetric cipher. This allows a message to be encrypted to a company or
gouvernment key. It is a technique to implement key recovery.

Software must not generate or accept this packet in communication. Any
incoming message containing this packet must be considered escrowed. A
warning must be produced to the users frontend and should not be
decrypted. Without users supervision the message must be discarded without
decrypting it.

The body of this packet consists of:
  - a version octet, (The current version is four.)
  - an algorithm identifier octet,
  - a string (4.3) selecting the recovery key,
  - the encrypted session key itself.

  [Further specification is yet not issued by PGP Inc.]

5.2.4 One-pass signature packet

An one-pass signature packet has the CTB (3.2.1) tag 4. It tells the
processing software how to compute a signature of later data packets, so
that it does not have to read the entire message or store the signature
information in memory before starting.

The body of this packet consists of:
  - a version octet, (The current version is four.) [changed to draft00]
  - a signature type octet,
  - an algorithm identfier octet describing the message digest algorithm used,
  - an algorithm identfier octet describing the asymmetric cryptosystem used,
  - a key ID of the signing key, and
  - a flag octet.

All octets are described in the signature packet (5.2.2).

The flag octet is one, if the signature is nested, or zero, if not.

  [What does that mean?]

5.2.5 Secret key packet

A secret key packet has the CTB (3.2.1) tag 5. It contain all information
of the secret component of a key pair. It must be stored using encryption.
It should not leave the local computer. If it is extracted locally, this
packet is followed by a sequence of user ID packets (5.2.13).

Only the keyowner has access to the secret component. Secret keys must not
be accessible to any other person or institution. This is even true for
employee keys of companies. If the key owner suspect a compromise by an
onther person, any company or any gouvernment of this secret component, he
must immedeatly revoke this key.

A secret key packet consits of a version octet and the key material. If
the version octet is three or lower, the following data is described in
(5.1.3).

The version four packet format is similar to 5.1.3 except there is no
validity period field. The validity period may be specified in the self
signature.

5.2.6 Public key packet

A public key packet has the CTB (3.2.1) tag 6. It contains the public
component of an asymmetric key pair. This packet introduce a published
public key. It is followed by either the key compromise certificate or an
optional keyring trust packet (5.1.8) (owner trust) and several user ID
packets chunks. Each user ID packet is followed in its chunk by an
optional keyring trust packet (keylegit) and several signature packets
(certificates) optionally followed by a keyring trust packet (signature
trust).

A public key packet consits of a version octet and the public key
material. If the version octet is three or lower, the following data is
described in (5.1.4).

The version four packet format is similar to 5.1.4 except there is no
validity period field.

5.2.7 Secret subkey packet

A secret subkey packet has the CTB (3.2.1) tag 7. It contains a associated
subkey of a secret key (5.2.5) defined erlier in the octet stream. All
following (user ID) packets refering to a secret key uses this key instead
of the secret key of (5.2.5). Following secret subkeys refers to the
secret key of (5.2.5) instead.

Subkeys are useful to provide forward security by changing encryption keys
very often.

The content is exactly the same as described in 5.2.5.

5.2.8 Compressed data packet

A compressed data packet has the CTB (3.2.1) tag 8. It contains external
data compressed to remove redundancy and save space. The compressed data
decompress into a layer seven octet stream conforming 3.2. Compressing
should be used on every external octet stream unless it enlarges the data
stream.

The content is exactly the same as described in 5.1.5.

5.2.9 Symmetrically encrypted data packet

A symmetrically encrypted data packet has the CTB (3.2.1) tag 9. It
contains an encrypted octet stream. It decrypts into a layer seven the
octet stream conforming 3.2. It is recommended to contain a compressed
data packet to avoid redundacy helpful to break the symmetric cipher.

The content is exactly the same as described in 5.1.6.

5.2.10 Marker packet

A marker packet has the CTB (3.2.1) tag 10. It is used to provide a
standardized beginning of an octet stream conforming 3.2. It is recognised
by every version even, if the general structure defined in 3.2 will change
in future.

The content of a marker packet are the three octet sequence 0x50 0x47 0x50.
Applying US-ASCII it means "PGP".

5.2.11 Literal data packet

A literal data packet has the CTB (3.2.1) tag 11. The content of a literal
data packet is generic data and not subject to any further interpretation.

The content is exactly the same as described in 5.1.7.

5.2.12 Trust packet

A trust packet has the CTB (3.2.1) tag 12. It is an internal orgnaisation
packet.

The content is exactly the same as described in 5.1.8.

5.2.13 User ID packet

A user ID packet has the CTB (3.2.1) tag 13. The user ID packet follows a
public or secret key. The content is a string (4.3). The user ID packet
sematics are defined in 5.1.9.

5.2.14 Subkey packet

A subkey packet has the CTB (3.2.1) tag 14. It contains a associated
subkey of a public key (5.2.6) defined erlier in the octet stream. All
following packets (user IDs, certificates, trust packets, ...) refering to
a public key uses this key instead of the public key of (5.2.6). Following
subkeys refers to the public key of (5.2.6) instead.

Subkeys are useful to provide forward security by changing encryption keys
very often. So certificats of a subkey should be avoided.

The content is exactly the same as described in 5.2.6.

5.2.15 Comment packet

A comment Packet has the CTB (3.2.1) tag 16. It may be displayed and must
be ignored.

The content is exactly the same as described in 5.1.10.

6. Key identification

Usually the key ID is used to identify a key by software and the user ID is
used to identify a key by the user. Unfortunly there are many problems.

In order to certify a key, sometimes only the fingerprint is exchanged.
This is a dangerous behavior and must be avoided. To compare keys for
certifying all characteristic values - fingerprint, public key component
lengths, key ID, and user ID - has to be compared exactly.

The same goes for interactive software requests to select from ambiguios
keys.

6.1 Key ID

The key ID is the lower 64 bits of the modulus of a RSA key stored in
packet version three or lower. The key ID is the lower 64 bits of the
public key of en ElGamal or DSS key in packet version three or lower. It
is trivial to forge.

The key ID is the lower 64 bit of the fingerprint (6.3) of a key stored in
packet version four or higher.

Due to independed decentral key generation it is possible, that two keys
has the same key ID. There is no guarantee nor any method to prevent this.
That's why the key ID must be considered as not unique. Several keys with
the same key ID must be handeled by software without any problem.

If the user request a key providing a part of the key ID, software must be
present all matching keys to select the right one.

6.2 User ID

The user ID is a user provided string. It may contain everything
printable.

6.2.1 Primary user ID

A public key can have any number of user IDs. It is problematic to define,
which user ID should be printed if a special key is named.

Existing practice is to use the latest user ID added to the database. This
should be avoided, because later user IDs are often the the prefered ones.
Futhermore on any remote system (i.e. keyserver) the user IDs are added
in random order.

Software should use the latest signed primary user ID subkey packet. Older
primary user ID subkey packets may be deleted.

If no signed primary user ID subkey packet exists, the user ID with the
highest trust should be used. Note, that there is no known metric for
trust in the web of trust.

A possible solution is to add all trusted certificates of a certain user
ID/key binding. Fully trusted certificates should count the inverse of
COMPLETES_NEEDED and marginally trustet certificates should count the
inverse of MARGINALS_NEEDED.

Example:
  UserID1 has three fully trusted certificates, six marginal trusted
  certificates, and eleven untrusted certificates.

  UserID2 has two fully trusted certificates, eight marginal trusted
  certificates, and one untrusted certificate.
  
  COMPLETES_NEEDED is two and MARGINALS_NEEDED is six.
  
  So UserID1 has an 'trust value' of 3/2 + 6/6 = 2.5
  So UserID2 has an 'trust value' of 2/2 + 8/6 = 2.333...
  
  UserID1 is choosen as the primary user ID.

6.2.2 Matching multiple user IDs

Obviously there is no guarantee, that the user ID is unique.

Existing versions of PGP allow adding any user ID to any key in the local
keyring. This is widly used to add offending or misleading user IDs to
many keys. This RfC requires user IDs not selfsigned or signed with the
corresponding signature key to be removed from the database despite they
provide trusted certificates or not.

Usually the user selects the key to work with a substring of the user ID.
Some existing versions of PGP choose the first key with a matching user
ID. There are several attacks known to forge a lot of keys certified by
each other using exactly the same user IDs. That's why all matching user
IDs must be present to the user to select the right one.

6.2.3 User ID conventions

It is common to include several key properties to the user ID, due to lack
of support by software. The following convention is partially implemented
[3].

The general structure of a user ID should be usable as an RfC 822 [8]
address: Real Name (Comments) <[email-masked]> (Options)

The "Real Name" should be the name of the user. "Comments" may contain
human readble informations about the e-mail address given. Non US-ASCII
characters must be encoded using MIME [5]. "[email-masked]" is the e-mail
address of the user. "Options" is any combination of:
  
  Key usage (only one of the following may be used in a user ID)
    SIGN -- sign external octet streams (documents).
    ENCR -- encrypt external octet streams to the receiver.
    STOR -- crypt files on a storage media.
    CERT -- certify key/user ID bindings.

  EXPIRE:yyyy-mm-dd
    Defines the latest day the key is usable. Software must prevent
    any cryptographic use of such keys except verifying signatures and
    certificates made while the key was valid. yyyy is the year, mm the
    month, and dd the day the key expires.
  
  IN-CA:do.main
    Denotes the responsible IN-CA for the person certified by this CA.
    It is safe to ignore this option but generation should not be
    prevented.

Examples:
  Lutz Donnerhacke (UUCP dayly) <[email-masked]> (ENCR)
  L. Donnerhacke <[email-masked]> (CERT EXPIRE:1998-07-29)

6.3 Fingerprint

The fingerprint is a hash digest of the public key. Packet version three
or lower hashs only the content of a the MPIs of the public key components
using MD5. This allows the attack to move bits from one component of the
public key to an other without modifying the fingerprint. So only the
fingerprint and the length of the key components are a good characteristic
for a key.

Packet version four or higher use SHA-1 to hash a few header bytes
followed by the entire public key packet starting with the version field.
Here are the fields of the hash material:

  - 0x99 (one octet),
  - a two octet scalar (4.1) containing the length of the following data,
  - the version number (one octet),
  - the time stamp of key creation (4.4),
  - the asymmetric cryptosystem identifier octet, and
  - the algorithm specific public key components as full MPIs (4.2).

Due to independed decentral key generation it is possible, that two keys
has the same fingerprint. There is no guarantee nor any method to prevent
this. That's why the fingerprint must not be considered as unique. Several
keys with the same fingerprint must be handeled by software without any
problem.

7. Keyserver

7.1 E-Mail keyserver

....

7.2 DNS keyserver

....

7.3 HTTP keyserver

....

8. Notes

PGP and Pretty Good Privacy are trademarks of Pretty Good Privacy, Inc.
   
9. Security Considerations

....

10. Author's Address

  IKS GmbH
  IN-Root-CA
  c/o Lutz Donnerhacke
  Wildenbruchstr. 15
  07747 Jena, Thuringia
  Germany
  [email-masked]
  Phone: +49-3641-675-642
  Fax: +49-3641-675-655

11. References

  [1] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message Exchange
      Formats", RfC 1991, August 1996.

  [2] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RfC 2015,
      October 1996.

  [3] Donnerhacke, L., et. al, "PGP263in - an improved international
      version of PGP", ftp://ftp.iks-jena.de/mitarb/lutz/crypt/software/pgp/

  [4] Eternity Logfile, https://www.iks-jena.de/mitarb/lutz/logfile/

  [5] Borenstein, N., and Freed, N., "Multipurpose Internet Mail Extensions
      (MIME) Part xxx: Format of Internet Message Bodies.", RfC 2045 ff.,
      November 1996

  [6] V.G. Cerf, "ASCII format for network interchange", RfC 20, October
      1969.

  [7] Campbell, Joe, "C Programmer's Guide to Serial Communications"

  [8] D. Crocker, "Standard for the format of ARPA Internet text
      messages", RfC 822, August 1982
  
  [9] D. Balenson, "Privacy Enhancement for Internet Electronic Mail: Part
      III: Algorithms, Modes, and Identifiers", RfC 1423, October 1993

Date: Sun, 19 Oct 1997 10:06:20 -0700
From: Kent Crispin <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: why we are arguing for more resistant variants (Re: Is PGP still private?)
Sender: [email-masked]

On Sun, Oct 19, 1997 at 10:25:08AM +0100, Adam Back wrote:
> 
> Toto <[email-masked]> writes:
> > Kent Crispin wrote:
> > > You keep talking as if your CDR proposal is other than vaporware.  So
> > > far as I have seen you don't have a proposal, you have a wish.
> > 
> >   Given Adam's many accomplishments in the arena of CypherPunks issues,
> > I find it hard to make a case for his discussion in this area to be
> > mere mental masturbation.
> 
> Thanks for the vote of confidence Toto.
> 
> Also I must raise the point that it is not a lone stand.  Other people
> are arguing against PGP Inc's CMR proposal, and are arguing for more
> GAK resistant variants, and alternatives.  

Apparently for some internal reason you must raise the point, but it
is irrelevant.  I said your *proposals* were vaporware, not your
motivations.  It is, as I have said, a waste of time (and yes, mental
masturbation) to argue about motivations. 

[. citations of famous cryptographers and Kent Crispin snipped .]

> However the biggest point of all is that: communications keys are more
> valuable to any attacker (government, unscrupulous little brother, or
> industrial spy) than storage keys.
> 
> I would be interested to see any one willing to burn their
> reputational capital refuting that simple point.

*Long term* communication keys.  Nobody is going to burn reputation
capital on that point because it's obvious, and really doesn't need to
be argued.  Furthermore the point applies just as well to current PGP
keys.  The *only* additional vulnerabilities of CMR come from 1) the 
volume of data makes it a more interesting target and 2) the 
management of the CMR key(s) may be problematic.  

However, in a large organization the management of *user* keys is
problematic, as well, and management of the CMR key(s), on balance,
will probably be better.  So the additional vulnerability of CMR comes
from the fact that it makes a lot of data accessible from one key. 
This vulnerability could be reduced by having multiple CMR keys -- the
accounting dept has one, the CEO has one, and it is the same as his
private key that is not escrowed anywhere, etc etc etc.

[Is it true that the private key associated with a CMR public key 
could simply be discarded, rather than escrowed, and everything would 
still work? -- except that you couldn't recover anything, of course...]

A more interesting argument is as follows: what is the real level of
security needed for the business communications that will be covered
by CMR? It seems obvious that the level of security required, on
average, is really quite low.  Note that businesses send all kinds of
important documents through regular mail, only protected *gasp* by
PAPER ENVELOPES. 

Anyway, Adam, I anxiously await the paper you are working on that 
gives the real details of your proposals.  I'm sure it's readability 
will be vastly improved if you religiously avoid the use of the word 
GAK :-)

-- 
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, 19 Oct 1997 11:17:25 -0400 (EDT)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: Re: Is PGP still private?
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> >However if Alice is using a key with CMR then the user using a client
> >which understands CMR keys will present the user with a choice:
> 
> Could. Sender would also have to have/be able to get the CMR key as it is 
> essentially an additional recipient.

<The software will attempt to fetch the CMR key, if it is unable to do
<this it will say so.  (I think).

Well with the net servers, this would certainly be possible *but* the sender's
client software would have to know to add the CMR. Would be highly surprised
if server could do that since both server and sender's client software would 
have to cooperate. Day PGP does that without providing user notification will
be day it starts to go out of business.

<For example if it were installed in tinpotdictatorsville the
<enforcement could result in the user having a "choice" not to
<communicate with anyone at all.  Availability would be 0%.

If living in tinpotdictatorville, you have a much more serious problem. This
is getting a bit far fetched anyway. In this case people will simply
not send anything incriminating electronically (were a lot of other options
before the Internet).

<Even if you believe that PGP Inc will never get an export license to
<tinpotdictatorsville, there will be other companies implementing to
<the OpenPGP standard in countries with freer export regulations.,
<These people if they choose to implement to the OpenPGP standard, will
<be forced to implement the CMR feature too, otherwise the software
<will not interoperate.

This is absurd. Now you are blaiming PGP for what some other company
*might* do ? Balderdash. CMR will be an option, not a requirement. And not
a hidden one.

<Steganography, or other low bandwidth subliminal channels would work,
<but such techniques are advanced, and PGP Inc are not making similar
<scale efforts to develop and deploy these.

Of course not. You do not need software to create a book code (though it helps).

<Also if Padgett is using pgp5.5 himself, and he attempts to send a
<mail to someone living in tinpotdictatorsville, his client will
<cooperate with the dictators wishes.

You are saying that it would be better not to send at all ? Would just use 
cleartext and some other method of communicating. If it is illegal to use,
just will not use PGP or will leave TPDV off my CC list. "Implement option B"
is not something that necessarily needs encryption. PGP makes things *easier*
not renders the impossible possible.

					Warmly,
						Padgett

Date: Sun, 19 Oct 1997 11:01:40 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Callas/Grigg CMR variant (was Re: what is purpose of CMR?)
Sender: [email-masked]

Ian Grigg <[email-masked]> writes:
> > > Jon Callas <[email-masked]> writes:
> > [forward secret TLS]
> 
> It is hard from a standards and deployment issue.
> 
> It is easy to do if we assume that that we control all the software.  If
> we assume that the software concerned is the PGP policy encforcer - on
> both sides of the exchange - then there is no difficulty about putting
> together a simple protocol that allows the *policy enforcers* to
> exchange keys and use them for PFS.
> 
> It would be non-compatible with other mailers, true, but that's what
> experimentation is about, right?

If I was PGP Inc I would be doing this and using it as a selling point
... we have forward secrecy between corp offices for those who use it.
ACME corp has pgp5.5, you don't you use TIS cakware without PFS... are
you going to buy in to better security or what?  (Rest assured TIS
cakware won't be including PFS ... that will screw up GAK friendliness
which they have profit incentives to add (due to sensitivity to
government contracts)).

Even if you don't bother at all with authentication (to prevent MITM)
this is a major, major win, because active MITM attacks are much
harder for governments to perform pervasively.  Same for any other
attackers, especially non governmental ones, MITM is not that easy to
pull off.

Worry about authentication later.  Perhaps boot strap it off
IPSEC/IPv6 in a few years.

> Now, if we put in place this scenario, you might be able to make a case
> that the enforcment or strict option on the SMTP filter should only be
> turned on when you have the PFS in place.
> 
> I haven't developed this fully, but it does have the advantage of
> allowing a migration path from our current situation.

This is seriously clever, Gary.  If long term this TLS takes off in
the same way that SSL did, everyone will be using it anyway.  PFS TLS
is a major security and GAK resistant win.  Governments need copies of
all the transient forward secret keys.  They have to modify software
to get them, because

You can then use this as a base to ramp up user controlled forward
secret keys to further increase security and government resistance.
(Stuff which I described earlier as even more government resistant,
and privacy preserving technology).

Long term GAK resistance is possibly more important than immediate GAK
resistance even.  It may take governments another couple of years to
get to optimum GAK argument, and persuade everyone.

This propsal is a winner in my view, and easy for PGP Inc to
implement, right now.

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: Sat, 18 Oct 1997 14:34:19 +0100
To: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
From: Ian Miller <[email-masked]>
Subject: Revealing individual messages.
Sender: [email-masked]

One thing sadly lacking from all current PGP implementations is the ability
to reveal the contents of _some_ messages encrypted to you, without handing
over the secret key.  This is most important as damage limitation when
ordered by a court of law to reveal certain messages.  [The most
pathological case is where Mallory has generated those messages himself,
merely to persuade the courts to force you to hand over your privacy key.]

What is required is:
1) The format of a Message Revelation certificate.  Which provides the
information necessary to decrypt a message.  Probably it should be the PKE
plaintext information rather than merely the session key so that the PKE
operation for the relevant SKE packet can be verified.
2) Implementations to generate these packets as required, and to verify the
packets and decrypt messages with them.

Whereas all this is possible within the PGP framework, it is not possible
with any existing implementations.  Any PGP user subject to a court order
to provide someone else with the facilities to decrypt certain messages
would (with current implementations) have to hand over the secret key to
comply.  I think this is highly unsatisfactory.

There are a number of other advantages to this approach.  Notably that
Mallory has to give Alice copies (or at least the SKE packets of) any
messages that he is demanding that Alice decrypts.  This at the very least
enables her to know that these messages exist.  [Consider the case where
Mallory has intercepted the message and prevented its delivery.]  Currently
however it would tell Alice very little about the message beyond its
existence.  Accordingly for RSA encryption at least I propose a
modification to the DEK plaintext that contains the session key.  Currently
this is largely random containing over a hundred bytes of nonce
(for a 1024bit-key).  If part of this nonce was replaced by sender-Id,
timestamp and similar data, then Alice would at least learn who had sent
the message (Bob) and when.  They might then have to opportunity to contact
the Bob to ask for retransmission and warn of the interception.

As a system administrator considering cryptography requirements for my
employers I see facilities of this type to be vital.  Indeed I would
consider it a pre-requisite for the enabling of any CMR facility.
Otherwise the misbehaviour by any one employee might result in the
compromising of the CMR key.

Ian

--
[email-masked]    FAI-D10204
PGP Fingerprint: 2A20 4610 E596 2740 91B1 95BA CAD3 BC14
Antworten auf Deutsch waeren mir angenehm.

Date: Sun, 19 Oct 1997 10:25:08 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: why we are arguing for more resistant variants (Re: Is PGP still private?)
Sender: [email-masked]

Toto <[email-masked]> writes:
> Kent Crispin wrote:
> > You keep talking as if your CDR proposal is other than vaporware.  So
> > far as I have seen you don't have a proposal, you have a wish.
> 
>   Given Adam's many accomplishments in the arena of CypherPunks issues,
> I find it hard to make a case for his discussion in this area to be
> mere mental masturbation.

Thanks for the vote of confidence Toto.

Also I must raise the point that it is not a lone stand.  Other people
are arguing against PGP Inc's CMR proposal, and are arguing for more
GAK resistant variants, and alternatives.  

Several amongst those who have so argued are higher reputation than
myself: Bruce Schneier, (plus some others with similar crypto
credentials I have asked for comments from off list which I can not
reveal due to ethics of email confidentiality).  I have some small
about of credibility myself I think also.

In addition I consider myself, Tim May, Peter Trei, Attila T Hun, and
the many others arguing for more resistant variants to have some
reputation, and it seems unlikely to me that we would all burn our
reputations over an insignifcant point.  We are collectively arguing
because (and I think the others will agree) we think that there are
more resistant variants than the CMR proposal used in pgp5.5.  These
variants are also practical within the constraints imposed by the
plug-in APIs, and user requirements PGP must work within, I believe.

Even Kent Crispin who seemed to dismiss the first round as an
insignificant difference, is offering more resistant variants.  PGP
Inc's Jon Callas together with cypherpunks Bill Stewart, Attila T Hun,
and myself were also arguing that even TLS (transport level security),
or in other words an extra encryption envelope over the recovery
information is an improvement.  (Particularly if you do as I argue for
and try to make the TLS keys user owned where possible, and try to
make the system as forward secrect as possible).

However the biggest point of all is that: communications keys are more
valuable to any attacker (government, unscrupulous little brother, or
industrial spy) than storage keys.

I would be interested to see any one willing to burn their
reputational capital refuting that simple point.

That point is the simple central starting point for all arguments
about the dangers of allowing recovery information to be transmitted
with the communication.  Recovery information should be local
whereever possible.  Bruce Schneier had harsh words to say about
violating this principle in one of his recent cypherpunks posts.

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: Sat, 18 Oct 1997 15:58:50 -0600
From: Toto <[email-masked]>
Reply-To: [email-masked]
Organization: TOTO Enterprises
To: Kent Crispin <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Is PGP still private?
Sender: [email-masked]

Kent Crispin wrote:

> On Sat, Oct 18, 1997 at 08:48:56AM +0100, Adam Back wrote:
> > My reasoning is this: as PGP Inc can not justify expense on such
> > developments, my CDR proposal would be much safer for them to
> > implement because it requires no steganography support, or other
> > privacy patches to provide protection against abuse of the software
> > for uses other than PGP Inc's designers intentions.
 
> You keep talking as if your CDR proposal is other than vaporware.  So
> far as I have seen you don't have a proposal, you have a wish.

  Given Adam's many accomplishments in the arena of CypherPunks issues,
I find it hard to make a case for his discussion in this area to be
mere mental masturbation.
  'Democracy in America' is also vaporware--always has been, always 
will be--but I see no reason we should not go on discussing it and 
hoping that we will not having to keep pushing the release date of the
finished product back, time and time again.
 
> [...]
> 
> > > You are in error. The only time that you are forced to use CMR is when (1)
> > > you share the CMRK with the other party AND (2) the strict flag is set. In
> > > all other cases, you can opt-out, on a message-by-message basis.

> Adam, it is a complete and utter waste of time to debate this.

  I agree. I think that we should just wait until someone comes out
with an actual product, and then castigate them for their ideas being
"ill-thought out." 

> What would *not* be a waste of time would be more concrete proposals.
> Whether PGP implements something is a separate question -- I would
> like to get back to the question of designing a better email
> encryption system.
> 
> Your reencryption scheme fails because of the management of the short
> term encryption keys, among other things.  Here's another approach I
> will toss out, without thinking through:
> 
> How about formalizing superencryption, or tunneling? That is, treat
> CMR traffic as a transport medium for messages that are themselves
> already encrypted.  The "key" idea here is to allow layering of non
> CMR traffic over CMR traffic.  All the code for both is obviously
> already in PGP, with a little glue and perhaps some minor protocol
> mods...

  In return for your positive suggestions, the CDR Board of Dirctors
has voted to allow you two posts containg cheap shots at the list
member of your choice, without including any points of redeeming,
on-topic, list value.

Toto
~~~~
"The Xenix Chainsaw Massacre"
http://bureau42.base.org/public/xenix
"WebWorld & the Mythical Circle of Eunuchs"
http://bureau42.base.org/public/webworld
"InfoWar"
http://bureau42.base.org/public/infowar3
"The Final Frontier"
http://www3.sk.sympatico.ca/carljohn

From: Andrew Bromage <[email-masked]>
Subject: Re: Is PGP still private?
To: [email-masked] (Kent Crispin)
Date: Sun, 19 Oct 1997 07:22:37 +1000 (EST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

G'day all.

Kent Crispin wrote:

> Your reencryption scheme fails because of the management of the short
> term encryption keys, among other things.  Here's another approach I
> will toss out, without thinking through:
> 
> How about formalizing superencryption, or tunneling? That is, treat
> CMR traffic as a transport medium for messages that are themselves
> already encrypted.  The "key" idea here is to allow layering of non
> CMR traffic over CMR traffic.  All the code for both is obviously
> already in PGP, with a little glue and perhaps some minor protocol
> mods...

If we start considering that, could I suggest making the system
_completely_ flexible?

The sort of things I'm thinking of include:  Allow any object to be
encrypted using conventional encryption (including conventional
encryption keys) or signed, allow any conventional encryption key to
be public-key encrypted or split, conjunction/disjunction of two
conventional keys, etc.

Disadvantages:

	- Greatly complicates the decryption process.  In particular,
	  decrypted streams must be fed back into PGP.

	- Difficult for an end-user to specify what combination of
	  features they want.

	- This working group would be around for years arguing about
	  details. :-)

Advantages:

	- Allows PGP to be used for lots of things that we haven't
	  thought of yet.

	- File format could be considerably simplified, if we could
	  scrap the old format.  (Unrealistic, but what the hell.)

Cheers,
Andrew Bromage

Date: Sat, 18 Oct 1997 22:17:44 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: anti-GAK design principles: worked example #1
Sender: [email-masked]

Bill Stewart <[email-masked]> writes:
> > [separate signing and encryption keys]
> 
> On the other hand, if the keys are separate, Louis Freeh
> can tell the Congress that it's not a big problem,
> he'd NEVER dream of GAKing your signature keys,

Valid argument with some value yes.  Actually now that you bring it up
I dimly remember this aspect being raised on cypherpunks some time
back.  Perhaps it was you who raised it even.  Or perhaps it was Phil
Karn, or someone.

> Similarly, your corporate security bureaucrats can understand
> the concept that if they CAK your privacy keys,
> they're risking having official company signatures get forged,
> and they'll often do the right thing and desist,
> but with separate keys that won't stop them.

Hmmm.  I think that if companies start encrypting anything, they're
going to need recovery of some sort.  Else they just won't use it at
all.

Most of them aren't using storage encryption right now anyway, which
is why Tim May's suggestion to store emails after decrypt in the clear
makes a lot of sense as a simple interim way out of this problem until
the issues have been explored more.

This largely avoids company requirement to recover emails.

One valid objection to this approach is that if the employee forgets
their password whilst there are lots of emails queued up to receive
that those emails will be lost.  Or if the employee gets hit by a
truck.

However I'm not so sure this is a big deal for a number of reasons:

1. how often do employees get hit by trucks?
2. how often do employees forget passwords? (all the time unfortunately)
3. things which are important the sender is likely able to resend because
   he has in clear on disk
4. senders using the same software can have archives of what they have sent
   and easily able to resend.

> >Does pgp5.0 reply encrypting to just me as individual, or two crypto
> >recipients me, and Mega Corp recovery key?
> Just you.

If you are right, it will bounce when it hits an enforcer with the
strict setting turned on.

Is this what will happen?

This will mean that the users will have to manually figure out how to
solve (get enforcer key, multiple encrypt to that key, possibly by
cc'ing to enforcer email address/userID even if this bounces).

> >It is evil.  But it is not _as_ evil.
> >
> >The reason for this is that government access to storage keys is not
> >as evil as government access to communications keys, because the
> >government has to come and capture the ciphertext (take your disk),
> >whereas with communications they can grab them via an arrangement with
> >your ISP.
> 
> First of all, the only reason for having a CMRK attached to your key
> is that either your mail service will reject mail to you that doesn't
> contain it, or your employer insists on it.  In either case,
> it can be done without a special CMRK field on your key --
> PGP multiple recipients are enough to do that, and the sender
> just has to remember to include the (no longer automagically attached) CMRK.
> So leaving out the CMRK doesn't protect you.

Lack of automation is some weak protection.  What are users to do?
Send Cc: <[email-masked]>.  What if they forget?  Much more
plausible to forget.  Makes strict penalties for forgetting difficult
in western countries.  5 years jail time for forgetting?  Don't think
so.

What about the traffic?  If you make it an invalid address, just to
pick up the key it'll flood email systems with bounces; every single
encrypted mail will get a bounce.

Not an overwhelming protection, but may mean more people will more
resist it, and more people will forget often with the current email
MUA deployed base.

With many people using CMR based pgp5.5, forgetting will be much less
plausible.

Putting in CMR encourages adoption of this kind of filtering/bouncing
approach.

I am interested in analysis and discussion of the level of
significance this difference makes to user uptake of GAK in say the US
as an example (say some time in 1998 when many more businesses and
individuals have upgraded to pgp5.x).  What differences are there in
resistance between a pgp5.5 using CMR and with a pgp5.6 using CDR (or
storage-CAK as Bill terms the approach)?

> Second, if the government is coming to get your disk anyway,
> they can get themselves a court order to have you reveal the key,
> and you can argue with the judge about whether you should be
> compelled to reveal it, and at least in the US there's a 
> Fifth Amendment backing up your arguments (though like the
> other amendments, it's weakened by the "except for drugs" clause...)

Yes.  This is the kind of reason I argue that storage recovery is less
dangerous than communications recovery.  They've got to get the disk
first.  And they can't tell if you have used GAK until they get it;
when they get it if you're suspecting they will try this, you will
ensure there is no GAK access, you will use other software, as you
have nothing to lose.

> GAK asserts that the government has the right to your keys
> before you get to court.  

Well that is the scenario that Freeh is arguing for yes.  Faced with a
choice of giving him your comms keys or your storage keys, I'd go for
storage keys anyday.  I can lie to him, and give him some random
numbers and he'll never know.  The point at which he will know will be
after the dawn raid; if it gets to dawn raids you are indendently in
trouble anyway.

> On yet another hand, while it may be obvious when the government
> steals your disk and uses Storage-GAK, companies using Storage-CAK
> or Storage-CMR can use it just as well on the backup tapes without
> your notice as on your disk drive.  Furthermore, you can think of
> the data backup process as communications from you to the
> backupmeister, so Storage-CAK _is_ Message-CAK, and Storage-CMR is
> Message-CMR.

Technically yes.  Practically no, there is a large difference.  The
extra protection of Storage-CAK method is the extra GAK resistance due
to the fact that availability of access to communications is patchy,
and more expensive for the government to achieve, and enforcement is
patchy, even detection is patchy.  This patchiness is good.  Mass
keyword scanning is impossible on a wide scale.  The government can
keyword scan some of you, but they can do that already at similar cost
levels: they can plant bugs, have undercover federal investigator
inflitrate your company in guise of employee etc.  The aim of the game
is to make the cost higher than existing physical attacks, or at least
as high as possible.

> But CAKing the disk doesn't protect the company's information,
> and there's therefore no excuse for using it.  

Surely it does?

If you are in ACME Corp and they want all disks encrypted as a
security policy.  They provide smart cards to employees, and
workstations data is inaccessible until correct smart card is
inserted.  Employee lets dog chew on smart card.  No recovery implies
that this data is irretrievably lost.

> Superencryption is always possible, in messages as well as files,
> but with message encryption the eavesdropping-prone corporation can
> detect superencrypted messages going by (though not stego'd), while
> PGP-encrypted files on your disk only show up _after_ you've been
> hit by the bus on your way to the headhunter's.

This is good.  Both systems are hackable from all three directions.
(individuals can hack around system to increase privacy; corporations
can hack around to decrease privacy (keyboard sniffer); governments
can too by walking in and taking disks and threatening people fail
time for not handing over keys.)  Many aspects of this are better with
storage data recovery than they are with communications recovery.
Especially government aspects.  Company aspects are almost neutral
non-issue in my mind due to ease with which company can remove your
privacy as they own machines, and can do all sorts of things to your
software, hardware, video cam, bug phone, keyboard sniffer, keyboard
log, etc.,etc.

> BTW, PGP5.5 CMR _is_ CMR'd storage encryption.  
> It's not as convenient as encrypted file systems 
> like PGPdisk and Secdev, 
> but people are using it to encrypt stored data,
> including email and non-email files.

Yes.  pgp5.0 which I looked at windows version (available on
ftp://ftp.replay.com/ (netherlands) somewhere for other non-US
people), does file and email encryption.  As does linux version.

> On a technical note, GAK for storage can be made less dangerous,
> though not less offensive, by adding a layer of indirection -
> use your public key to encrypt a symmetric key, store the encrypted
> symmetric key on your disk, and then use the symmetric key for
> encrypting the storage (or as a master key for encrypting the
> per-file or per-block storage keys, if you're doing that, 
> which you probably should.)  This means that a search warrant
> which is required to itemize the things it's looking for can be
> more effectively restricted to specific files rather than
> cracking the whole disk and every other disk that uses the
> same encryption keys.

Good point.

> >The point though is that storage recovery is a completely separable
> >issue from communications "recovery" which is a euphamism for allowing
> >companies to read, or snoop, employees email, unless it is being used
> >soley for data recovery of mail stored in mail folders (which seems to
> >be what PGP Inc means by CMR term), in which case it is not necessary
> >functionality, and can be better acheived by encrypting the mail
> >archive with a user symmetric key with company storage recovery on
> >that key.
> 
> Trust me - you _really_ don't want mailboxes encrypted,
> recovery key or no recovery key, unless it's implemented very very well.

PGP Inc does use this otherwise there would be no argument about need
for recovery information -- you don't need recovery information for
plaintext.

> [100Mb mail folder corruption nightmares]

Your example of corruption problems with large mail boxes is one
argument against this practice.

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: Sat, 18 Oct 1997 20:05:50 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: jurisdictional interactions (Re: Is PGP still private?)
Sender: [email-masked]

Kent Crispin <[email-masked]> writes:
> On Sat, Oct 18, 1997 at 08:48:56AM +0100, Adam Back wrote:
> > 
> > Jon Callas <[email-masked]> writes:
> [...]
> > 
> > My reasoning is this: as PGP Inc can not justify expense on such
> > developments, my CDR proposal would be much safer for them to
> > implement because it requires no steganography support, or other
> > privacy patches to provide protection against abuse of the software
> > for uses other than PGP Inc's designers intentions.
> 
> You keep talking as if your CDR proposal is other than vaporware.  So 
> far as I have seen you don't have a proposal, you have a wish.

I have described the CDR proposal in some detail, and have been able
to counter all arguments raised against it.

It is vaporware, but there are people who are offering to implement it
as an extension to systemics PGP capable library as a demonstrator for
the OpenPGP standardisation process to show how it would work in
practice.

You do have a point in that I should collect my arguments and write a
paper describing the tradeoffs.  I am in the process of doing this,
and will be interested in yours and others comments on this proposal.

> > However I simply posit that if you live in a scenario where everyone
> > you would like to communicate is forced to operate under your
> > combination: for example the local laws state all businesses and ISPs
> > insisting that they use pgp5.5 policy enforcer and turn on strict
> > flag.
> > 
> > This possibility seems to be being discounted as unrealistic, or at
> > least as being optional, because you can by pass it.
> 
> It does seem rather unrealistic.  It would essentially involve
> replacing the entire email infrastructure, at a significant cost, and
> a rather sweeping suite of further laws that restrict the use of
> encryption to only PGP, forbid me running sendmail on my linux box,
> etc, etc

I fail to follow your argument.  Could you explain further?  I am very
interested in discussion of the realism of scenarios for ways that GAK
might be enforced in various types of regimes examples being perhaps:

- Singapore hi-tech, but somewhat authoritarian government

- US, UK hi-tech, government interested in installing GAK (with
  euphamisms being used such as TTP (UK), "Key recovery"/"key escrow"
  (US)).

- Muslim countries, some oil rich, largely I think currently

- France with current position of no use of crypto without license
  (not typically availble), low enforcement rate (individuals use crypto
  with very low likelihood of prosecution), but more recent moves to
  allow unlicensed crypto which has mandatory access.

In what way does replacing the sendmail infrastructure have relevance?
You can always communicate in the clear so I am not claiming you can
not commmunicate, just that there are interesting interactions between
deployed software bases and different jurisdictions with different
legal restrictions on cryptography (ranging from none to weakly
enforced mandatory access, to heavily enforced mandatory access to ban
on cryptography).  If you consider this legal framework, the dynamics
of the ways that you can best estimate GAK will be introduced, and the
likelihood for each jurisidction, the enforcement rate, severity of
penalty for failure to comply, you have a very complex system. 

I would be interested to see comments on these issues, and what issues
this raises for protocol designers and software implementors.

My GAK resistant design principles attempt to provide useful rules of
thumb in making individual software systems, international standards,
and the distributed system formed of the deployed user base, and
enforcement rates, severities maximally resistant to GAK.

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

My claim is that software implementations, and messaging standards
such as OpenPGP are not neutral in this process.  I think this is a
relatively obvious statement, which most would agree with.  I know
that PGP Inc has spent a lot of time considering alternatives on these
kinds of issues, and on privacy issues.

> > I can not see that being able to by pass it helps you in my scenario
> > if a) you will be detected when you do bypass it because the law
> > enforcers will discover they can't recover plaintext;
> 
> This implies a law against using any other form of crypto, period.  
> If such a law is passable the exemption for PGP's protocol will 
> really be immaterial.  That is, Yes, under an extremely draconian 
> regieme, extremely draconian things are possible.

There are regimes which would like to allow the government to read all
communications where it would not be practical to outlaw encryption
because many people can demonstrate a business case for it.

You live in one such regime: the US.  I live in another such regine:
the UK.

> > and b) you have
> > a "choice" of not being able to communicate with anyone, because in
> > practical terms you have a need to communicate. 
> 
> Implies that *all* other forms of communication have been outlawed.  
> Completely unrealistic.

It does not imply that at all.  If you presume that you wish to
communicate securely, faced with the above scenario, you are faced
with the choice I described: don't communicate at all, or communicate
insecurely.

> Adam, it is a complete and utter waste of time to debate this. 

Why?

I shall continue simply because I consider I have no moral
alternative, than to try to explore more GAK resistant variants of
CMR, or additions to CMR. Or to explore the CDR alternative approach
as a plausible alternative more resistant to GAK take over.

If you have any specific objections to my technical points, or
strategic analysis of usefulness of the two proposals in frustrating
government mass email snooping I would be interested to have you
discuss them.

> What would *not* be a waste of time would be more concrete proposals.  
> Whether PGP implements something is a separate question -- I would 
> like to get back to the question of designing a better email 
> encryption system.

That is a worth while endeavour independently.  However PGP Inc has
financial and implementational constraints (such as plugin APIs, and
so forth) which it naturally must work within.  Asking more than this
is not reasonable; these are the laws of gravity in the problem space.

To produce something which meets PGP Inc's design constraints seems
much more valuable to me than independent freeware or payware attempts
to explore alternative approaches simply because PGP is likely to have
the largest deployed base.  Increasing the resistance of PGP Inc's
systems by even a marginal amount is therefore automatically valuable.

> Your reencryption scheme fails because of the management of the short
> term encryption keys, among other things.  

I presume you are here referring to my suggestion that forward secrecy
would make the system more resistant to GAK take over.

PGP already has a mechanism to deal with short term encryption keys:
the expiry mechanism which has been available starting with pgp5.0.

The only novel suggestion relating to this is to reduce the expiry
period, to reduce exposure of keys.  This does not seem a radical
proposal.  It is independently a good security improvement.

Tim May has suggested that the simplest way to deal with the problems
of recovery is just to store the received email in clear text.

If PGP would like to enhance security of email archives by storing
them in encrypted then CDR is one practical way to do that.

> Here's another approach I will toss out, without thinking through:
> 
> How about formalizing superencryption, or tunneling? That is, treat
> CMR traffic as a transport medium for messages that are themselves
> already encrypted.  The "key" idea here is to allow layering of non
> CMR traffic over CMR traffic.  All the code for both is obviously
> already in PGP, with a little glue and perhaps some minor protocol
> mods...

This is a good suggestion.  It would be an improvement over allowing
CMR traffic to appear in the outer layer.  Jon Callas, Attila T Hun,
and Bill Stewart were discussing variations of this.  My suggestion
for forward secrecy could also be used in this way, and has similar
motivation, but is not necessarily end-to-end, as I gave specific
examples in my previous reply to you attempted to show.

A hybrid approach like this would be somewhere between the two systems
in resistance to government abuse.  It is a definate improvement.

Please don't give up on the debate as threatened above Kent;
constructive ideas like this are useful as they explore a wider
spectrum of properties in the proposed system variants.

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: Sat, 18 Oct 1997 09:26:36 -0700
From: Kent Crispin <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Is PGP still private?
Sender: [email-masked]

On Sat, Oct 18, 1997 at 08:48:56AM +0100, Adam Back wrote:
> 
> Jon Callas <[email-masked]> writes:
[...]
> 
> My reasoning is this: as PGP Inc can not justify expense on such
> developments, my CDR proposal would be much safer for them to
> implement because it requires no steganography support, or other
> privacy patches to provide protection against abuse of the software
> for uses other than PGP Inc's designers intentions.

You keep talking as if your CDR proposal is other than vaporware.  So 
far as I have seen you don't have a proposal, you have a wish.

[...]

> > You are in error. The only time that you are forced to use CMR is when (1)
> > you share the CMRK with the other party AND (2) the strict flag is set. In
> > all other cases, you can opt-out, on a message-by-message basis.
[...]
> However I simply posit that if you live in a scenario where everyone
> you would like to communicate is forced to operate under your
> combination: for example the local laws state all businesses and ISPs
> insisting that they use pgp5.5 policy enforcer and turn on strict
> flag.
> 
> This possibility seems to be being discounted as unrealistic, or at
> least as being optional, because you can by pass it.

It does seem rather unrealistic.  It would essentially involve
replacing the entire email infrastructure, at a significant cost, and
a rather sweeping suite of further laws that restrict the use of
encryption to only PGP, forbid me running sendmail on my linux box,
etc, etc

> I can not see that being able to by pass it helps you in my scenario
> if a) you will be detected when you do bypass it because the law
> enforcers will discover they can't recover plaintext;

This implies a law against using any other form of crypto, period.  
If such a law is passable the exemption for PGP's protocol will 
really be immaterial.  That is, Yes, under an extremely draconian 
regieme, extremely draconian things are possible.

"Tinpotdictatorsville" is not a useful counterexample, because the 
TPD can mandate anything, including no use of crypto at all.

> and b) you have
> a "choice" of not being able to communicate with anyone, because in
> practical terms you have a need to communicate. 

Implies that *all* other forms of communication have been outlawed.  
Completely unrealistic.

Adam, it is a complete and utter waste of time to debate this. 

What would *not* be a waste of time would be more concrete proposals.  
Whether PGP implements something is a separate question -- I would 
like to get back to the question of designing a better email 
encryption system.

Your reencryption scheme fails because of the management of the short
term encryption keys, among other things.  Here's another approach I
will toss out, without thinking through:

How about formalizing superencryption, or tunneling? That is, treat
CMR traffic as a transport medium for messages that are themselves
already encrypted.  The "key" idea here is to allow layering of non
CMR traffic over CMR traffic.  All the code for both is obviously
already in PGP, with a little glue and perhaps some minor protocol
mods...

-- 
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, 18 Oct 1997 13:05:28 +0000
From: Ian Grigg <[email-masked]>
Organization: Systemics
To: Adam Back <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: what is purpose of CMR?
Sender: [email-masked]

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

Adam Back wrote:
> Jon wrote:
> > I think it would be a good thing to send a PGP message over an
> > encrypted link (TLS or other).
> 
> This is an independently good idea and would mitigate some of the
> possibilites of CMR functionality being used for purposes other than
> it's designers intended.
> 
> However it is hard to do; and the keys have different security focus
> becuase it is hard to use user <-> user end to end TLS because of the
> store and forward nature of email.

It is hard from a standards and deployment issue.

It is easy to do if we assume that that we control all the software.  If
we assume that the software concerned is the PGP policy encforcer - on
both sides of the exchange - then there is no difficulty about putting
together a simple protocol that allows the *policy enforcers* to
exchange keys and use them for PFS.

It would be non-compatible with other mailers, true, but that's what
experimentation is about, right?

Now, if we put in place this scenario, you might be able to make a case
that the enforcment or strict option on the SMTP filter should only be
turned on when you have the PFS in place.

I haven't developed this fully, but it does have the advantage of
allowing a migration path from our current situation.

- -- 
iang
[email-masked]

Date: Sat, 18 Oct 1997 11:59:58 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: Hal Finney <[email-masked]>
CC: [email-masked]
Subject: Re: Secure receipts
Sender: [email-masked]

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

> RFC 1894 describes a message-delivery-status MIME message format which
> is similar to what you are asking for.  If it were encapsulated in a
> PGPMIME signed message then you would have the authentication security
> that you want.  The RFC is more oriented towards the MTA rather than MUA
> level, so it would indicate that the message had arrived in the user's
> mailbox, but not whether he had read it.  However the 1894 syntax could
> be extended to cover that case as well.

Cool.

> You might want to take a look at the following drafts:
> 
>     An Extensible Message Format  for Message Disposition Notifications
>         draft-ietf-receipt-mdn-05.txt
> 
> and
> 
>     MIME-based Secure EDI
>         draft-ietf-ediint-as1-04.txt

Great. KISS is definitely the right principle for OpenPGP. If we can do
secure receipts without altering the format, all the better.

Ian >:)

Date: 18 Oct 1997 8:46:19 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: PGP 5.0 Secret Key Formats
To: IETF OpenPGP <[email-masked]>, [email-masked]
Sender: [email-masked]

Anyone know the format of the secret key (Diffie-Helman & DSS) in PGP 5.0 ?
and how to decode it if you know the passphrase ?

Thanks - Linz
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Release Vs 2.6.1.1, on October 18, 1997, in Win95
4.0
	http://www.blackpaw.com/

Date: Sat, 18 Oct 1997 08:48:56 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Is PGP still private?
Sender: [email-masked]

Jon Callas <[email-masked]> writes:
>    > Adam Back <[email-masked]> writes:
>    > >I'm not clear on this last one, but it may even be that a pgp5.0
>    > >implementation knows how to reply to a CMR key also.
>    
> Pardon me for being testy, Adam, but I've said this before, and I do have
> other things to do. 

I have been following closely list discussions and did not see this
clarified before.  My question was not intended in any hostility, but
was motivated by a desire to see this clarified.

> With 5.0, it recognizes the CMRK and brings up a dialog box showing you
> what you're about to do. You can always remove a CMRK using 5.0 or 5.5
> personal privacy/freeware.

I applaud the privacy options that are built into pgp5.x.  The option
to remove the CMR in the pgp5.x personal privacy clients is a good
privacy option.

However, it does not help significantly in preventing this scenario:

>    Even if you believe that PGP Inc will never get an export license to
>    tinpotdictatorsville, there will be other companies implementing to
>    the OpenPGP standard in countries with freer export regulations.
>    These people if they choose to implement to the OpenPGP standard, will
>    be forced to implement the CMR feature too, otherwise the software
>    will not interoperate.
>    
> No.
> 
> Software that does not implement CMR will always interoperate with software
> that does. That's a feature. 

In one sense you are correct.  However, consider:

1. If the software purposely does not implement ability to reply to
   CMR public keys users of this software can not communicate with
   that proportion of pgp5.5 for business deployed base which has
   policy enforcement turned on.

2. If pgp5.5 with policy enforcement turned on becomes more popular
   than PGP Inc anticipates with companies (and with the dictator in
   tinpotdicatorsville), vendors may find themselves under pressure to
   add the functionality even though it is a MAY in the standard,
   becuase users find too many messages are bouncing.

3. I expect that most will comply even though it is a MAY simply
   because without this they will not interoperate (in the useful
   sense of being able to deliver mail) to that proportion of the
   deployed base which does have pgp5.5 with policy enforcer turned on.

>    Steganography, or other low bandwidth subliminal channels would work,
>    but such techniques are advanced, and PGP Inc are not making similar
>    scale efforts to develop and deploy these.
>    
> Actually, we *are* considering putting in stego and some other features.
> The major deciding factor about when we do them all revolves around who
> will buy them.

That was not a criticism of PGP's motives; it was a statement of PGP
Inc's natural financial restrictions as a business, which I fully
appreciate.

My reasoning is this: as PGP Inc can not justify expense on such
developments, my CDR proposal would be much safer for them to
implement because it requires no steganography support, or other
privacy patches to provide protection against abuse of the software
for uses other than PGP Inc's designers intentions.

>    Also if Padgett is using pgp5.5 himself, and he attempts to send a
>    mail to someone living in tinpotdictatorsville, his client will
>    cooperate with the dictators wishes.  If the CMR mechanism were not
>    used at all the dictator would find he had far less use for pgp5.6
>    (with CDR in place of CMR).  This is because CDR does not provide any
>    third party access to communications.  It provides third party access
>    for stored data.  The dictator only has 1000 soldiers (it is a small
>    dictatorship), and they can only collect backup tapes from 100 houses
>    per day.  They are never sure if the citizens aren't hiding another
>    machine somewhere.  The process is inefficient and costs lots of
>    resources.  In fact the dictators job is now much harder than it would
>    have been were PGP to keep the CMR method.
>    
> You are in error. The only time that you are forced to use CMR is when (1)
> you share the CMRK with the other party AND (2) the strict flag is set. In
> all other cases, you can opt-out, on a message-by-message basis.

If I am in error I would like to know so that I can desist from
wasting peoples time.

However I can not see that I am in error.  I have been unable to find
any PGP employees or anyone else who can present a reasoned argument
as to why I am wrong that holds up under scrutiny.  I do not think
this is because I am being closed minded on the subject.

I fully understand that "The only time that you are forced to use CMR
is when (1) you share the CMRK with the other party AND (2) the strict
flag is set. In all other cases, you can opt-out, on a
message-by-message basis."  I understood this a week ago also.

However I simply posit that if you live in a scenario where everyone
you would like to communicate is forced to operate under your
combination: for example the local laws state all businesses and ISPs
insisting that they use pgp5.5 policy enforcer and turn on strict
flag.

This possibility seems to be being discounted as unrealistic, or at
least as being optional, because you can by pass it.

I can not see that being able to by pass it helps you in my scenario
if a) you will be detected when you do bypass it because the law
enforcers will discover they can't recover plaintext; and b) you have
a "choice" of not being able to communicate with anyone, because in
practical terms you have a need to communicate. 

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: Sat, 18 Oct 1997 08:17:06 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: proposal: commercial data recovery
Sender: [email-masked]

Jon Callas <[email-masked]> writes:
>    Right now, whoever has the corporate key can read everyone's email.  What
>    happens when there is an insider trading lawsuit when the CIO reads the
>    CEO's "private" email?  I can think of other examples.  And if the
>    corporate key is compromised, I assume that compromises every piece of
>    email up to that point?
> 
> I don't think you've been reading the descriptions of how it works. You're
> also focusing on using it with a single key. Every user can have a
> different key. No user MUST have a key.

The fact that it is all optional does not mean that a company may
choose to use it in that way.

I suspect that many companies with their strict property ownership
opinions will have one CMR key, and use the pgp5.5 for business
framework to enforce that all users use it.

>    But let me ask a question about PGP, Inc. - Do they use the PGP 5.5
>    version with corporate key recovery internally?
>    
> No, we don't. We have no need to. It would be inappropriate for our
> environment.

Most companies aren't as progressive as PGP, and most companies have a
corporate proprety ownership attitude even if they similarly have no
need for the actual functionality.

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: Sat, 18 Oct 1997 08:23:07 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: what is purpose of CMR?
Sender: [email-masked]

Jon Callas <[email-masked]> writes:
> At 12:54 AM 10/18/97 +0100, Adam Back wrote:
>    
> > [what is CMR key for surveillance/ or disaster recovery]
> 
> It's not for surveillance. It's for recovering from disaster. 

In that case recovery can be much more simply and securely achieved
locally to the recipient.  Escrow or use locally stored recovery
information.  The CMR key is not needed for this functionality.

> I think it would be a good thing to send a PGP message over an
> encrypted link (TLS or other).

This is an independently good idea and would mitigate some of the
possibilites of CMR functionality being used for purposes other than
it's designers intended.

However it is hard to do; and the keys have different security focus
becuase it is hard to use user <-> user end to end TLS because of the
store and forward nature of email.

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: Sat, 18 Oct 1997 02:30:01 -0700
To: Jon Callas <[email-masked]>
From: Bill Stewart <[email-masked]>
Subject: Re: proposal: commercial data recovery
Cc: [email-masked]
Sender: [email-masked]

At 05:14 PM 10/17/1997 -0700, Jon Callas wrote:
> >   But let me ask a question about PGP, Inc. - Do they use the PGP 5.5
> >  version with corporate key recovery internally?
>No, we don't. We have no need to. 
>It would be inappropriate for our environment.

You've got applications it would be fine for:
- tech support, so people can encrypt messages to
	somebody at tech support and other people
	could read it if it's their turn on support that day.
- secretaries having access to their bosses' email
				Thanks!
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Sat, 18 Oct 1997 01:49:19 -0700
To: Adam Back <[email-masked]>
From: Bill Stewart <[email-masked]>
Subject: Re: anti-GAK design principles: worked example #1
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 06:27 PM 10/17/1997 +0100, Adam Back wrote:
>Bill Stewart <[email-masked]> writes:
>> I'll duck the 5.5 argument for now, but you're 
>> incorrect on 5.0.  The PGP 5.0 key format includes
>> separate keys for signature and privacy, which is a mostly good thing,
>A very good thing.

It's very good, but it does have its own risks.
If you use the same keys for signature and encrypting to you,
and the government wants to GAK your encryption keys,
they have to steal your signature keys also, 
which just about everybody agrees is Bad, and it's
simply unacceptable in a business environment.
On the other hand, if the keys are separate, Louis Freeh
can tell the Congress that it's not a big problem,
he'd NEVER dream of GAKing your signature keys,
he only wants emergency access to your privacy keys --
this may give the GAK folks a better chance of getting it.
Similarly, your corporate security bureaucrats can understand
the concept that if they CAK your privacy keys,
they're risking having official company signatures get forged,
and they'll often do the right thing and desist,
but with separate keys that won't stop them.

> The PGP 5.0 key format [....]
>> and includes the ability to associate a group of
>> keyIDs and flag bits with each privacy key.
>So can you use pgp5.0 to construct a CMR key which would
>interoperate with pgp5.5 for business?

No.  As far as I know (without reading 7000 pages of code :-),
pgp5.0 won't construct CMR key fields, and won't use them,
it just isn't supposed to die if it receives a key containing them.

>Clearly pgp5.0 does nothing with these flags on reciept, 
>but does it understand them when sending?

If it receives a key containing CMRKs, it doesn't choke on the CMRKs,
and when you encrypt a message to the key, it ignores the CMRKs.
If it receives a message encrypted to both real people and CMRKers,
there's no way to tell which are which (though if you don't have
CMRKs in your key, they're obviously not your CMRKs.)

>Does pgp5.0 reply encrypting to just me as individual, or two crypto
>recipients me, and Mega Corp recovery key?
Just you.

>> >- store a copy of the private half of the users PGP encryption key
>> >  encrypted to the company data recovery key on the users disk.
>> No.  This is evil.  Don't go there.  Even with secret sharing,
>> and especially without.
>
>It is evil.  But it is not _as_ evil.
>
>The reason for this is that government access to storage keys is not
>as evil as government access to communications keys, because the
>government has to come and capture the ciphertext (take your disk),
>whereas with communications they can grab them via an arrangement with
>your ISP.

First of all, the only reason for having a CMRK attached to your key
is that either your mail service will reject mail to you that doesn't
contain it, or your employer insists on it.  In either case,
it can be done without a special CMRK field on your key --
PGP multiple recipients are enough to do that, and the sender
just has to remember to include the (no longer automagically attached) CMRK.
So leaving out the CMRK doesn't protect you.

Second, if the government is coming to get your disk anyway,
they can get themselves a court order to have you reveal the key,
and you can argue with the judge about whether you should be
compelled to reveal it, and at least in the US there's a 
Fifth Amendment backing up your arguments (though like the
other amendments, it's weakened by the "except for drugs" clause...)
GAK asserts that the government has the right to your keys
before you get to court.  Corporate access to storage keys,
on the other hand, is concerned with protecting the company's
information on the company's computers, and you can reasonably
negotiate how much of that you want to live with and comply with.
Some companies want to protect their information in case you
get hit by a bus, or a lawsuit; other companies don't even
have the sense to provide decent automated network-based backup
to protect their information from head crashes.

On yet another hand, while it may be obvious when the
government steals your disk and uses Storage-GAK,
companies using Storage-CAK or Storage-CMR can use it 
just as well on the backup tapes without your notice
as on your disk drive.  Furthermore, you can think of
the data backup process as communications from you
to the backupmeister, so Storage-CAK _is_ Message-CAK,
and Storage-CMR is Message-CMR.

But CAKing the disk doesn't protect the company's information,
and there's therefore no excuse for using it.  Superencryption
is always possible, in messages as well as files, but with
message encryption the eavesdropping-prone corporation can
detect superencrypted messages going by (though not stego'd),
while PGP-encrypted files on your disk only show up _after_
you've been hit by the bus on your way to the headhunter's.

BTW, PGP5.5 CMR _is_ CMR'd storage encryption.  
It's not as convenient as encrypted file systems 
like PGPdisk and Secdev, 
but people are using it to encrypt stored data,
including email and non-email files.

On a technical note, GAK for storage can be made less dangerous,
though not less offensive, by adding a layer of indirection -
use your public key to encrypt a symmetric key, store the encrypted
symmetric key on your disk, and then use the symmetric key for
encrypting the storage (or as a master key for encrypting the
per-file or per-block storage keys, if you're doing that, 
which you probably should.)  This means that a search warrant
which is required to itemize the things it's looking for can be
more effectively restricted to specific files rather than
cracking the whole disk and every other disk that uses the
same encryption keys.

>This is not avoidable for storage ... if you are encrypting data on
>disk, and if you want recovery information, you have no choice but to
>allow company access.    The recovery information should be 
as decentralised as much as possible.  

>The point though is that storage recovery is a completely separable
>issue from communications "recovery" which is a euphamism for allowing
>companies to read, or snoop, employees email, unless it is being used
>soley for data recovery of mail stored in mail folders (which seems to
>be what PGP Inc means by CMR term), in which case it is not necessary
>functionality, and can be better acheived by encrypting the mail
>archive with a user symmetric key with company storage recovery on
>that key.

Trust me - you _really_ don't want mailboxes encrypted,
recovery key or no recovery key, unless it's implemented very very well.
Microsoft Mail, and as near as I can tell Microsoft Exchange,
puts the user's entire mailbox, stored message folders and all,
in one big ugly cheaply-encrypted file.  The encryption isn't
strong enough to keep the NSA out, but it's strong enough to keep
you from repairing the file if part of it gets damaged,
and enough to keep you from extracting the undamaged parts,
or accessing it with sorting tools not built into MSMail.
Combined with the Microslush Mail Mindset of never sending text
when a Microsoft Word file could do, and never sending Word
when an even-more-bloated PowerPoint Presentation can fit,
your mailbox easily expands to over 100MB, too big to fit
on a ZIP drive.  Eventually, something always gets corrupted,
and you end up with Corporate Message Non-Recoverability.

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

Date: Fri, 17 Oct 1997 22:46:17 -0400
From: Anonymous <[email-masked]>
Comments: This message was remailed by a FREE automated remailing service. For additional information on this service, send a message with the subject "remailer-help" to [email-masked]. The body of the message will be discarded. To report abuse, contact the operator at [email-masked].  Headers below this point were inserted by the original sender.
Subject: Re: what is purpose of CMR?
To: Jon Callas <[email-masked]>, Adam Back <[email-masked]>, [email-masked]
Sender: [email-masked]

you wrote:

>It's not for surveillance. It's for recovering from disaster. I think it
>would be a good thing to send a PGP message over an encrypted link (TLS or
>other).
>
>	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)
>
>

I have a question, exactly which clients of PGP requested GAK PGP? Air America? Who is the driving force behind causing PGP to embrace GAK? CIA and NSA shell companies with taxpayers money to spend to implement GAK, who know their version would never sell, get you to do it for them?

CuriousMonger

Date: Fri, 17 Oct 1997 17:14:12 -0700
To: [email-masked], Hal Finney <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: proposal: commercial data recovery
Cc: [email-masked]
Sender: [email-masked]

At 07:02 PM 10/17/97 -0400, [email-masked] wrote:
   On Tue, 14 Oct 1997, Hal Finney wrote:
   
   One thing PGP has not looked into would be having a master key such that N
   bits will be the same from the corporate master key to any user's key.
   Then you could recover any user key from the corporate key, but it would
   requrire some expense and effort, so it would prevent casual
   eavesdropping by the administrators.
   
   A second method would require N (typically 3) escrow keys to recreate the
   access key, and would work best if it only decrypted one user's messages.
   
   I would rather not trust a single party within a corporation.

Take a look at my "Why CMR isn't Key Escrow" essay. In it I recommend not
using a single CMRK, and mention a couple of easy-to-implement,
fault-tolerant uses.

In our plans for the next release is putting in secret sharing for a number
of purposes. I'm in favor of requiring that a CMRK be secret-shared, even
if a tin pot dictator can easily own all the shares.
   
   Right now, whoever has the corporate key can read everyone's email.  What
   happens when there is an insider trading lawsuit when the CIO reads the
   CEO's "private" email?  I can think of other examples.  And if the
   corporate key is compromised, I assume that compromises every piece of
   email up to that point?

I don't think you've been reading the descriptions of how it works. You're
also focusing on using it with a single key. Every user can have a
different key. No user MUST have a key.
   
   But let me ask a question about PGP, Inc. - Do they use the PGP 5.5
   version with corporate key recovery internally?
   
No, we don't. We have no need to. It would be inappropriate for our
environment.

	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, 17 Oct 1997 17:07:04 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Is PGP still private?
Cc: [email-masked]
Sender: [email-masked]

At 12:19 AM 10/18/97 +0100, Adam Back wrote:
   
   Padgett Peterson <[email-masked]> writes:
   > Adam Back <[email-masked]> writes:
   > >I'm not clear on this last one, but it may even be that a pgp5.0
   > >implementation knows how to reply to a CMR key also.
   > 
   > Source code is available, or am sure pgp will answer.
   
   No answer so far.  It would be quicker for someone who does know to
   say yay or nay, than for me to read through the source.  Or simply for
   someone who has both pgp5.0 and pgp5.5 test rig to try it and see with
   a CMR key to see what pgp5.0 thinks of it; and what pgp5.5 + policy
   enforcer thinks of what pgp5.0 sends it in response.
   
Pardon me for being testy, Adam, but I've said this before, and I do have
other things to do. (Also, I am not caught up on my mail from last week,
even -- I'm not ignoring anyone, I'm just slow.).

With 5.0, it recognizes the CMRK and brings up a dialog box showing you
what you're about to do. You can always remove a CMRK using 5.0 or 5.5
personal privacy/freeware.

   Even if you believe that PGP Inc will never get an export license to
   tinpotdictatorsville, there will be other companies implementing to
   the OpenPGP standard in countries with freer export regulations.
   These people if they choose to implement to the OpenPGP standard, will
   be forced to implement the CMR feature too, otherwise the software
   will not interoperate.
   
No.

Software that does not implement CMR will always interoperate with software
that does. That's a feature. 

   Steganography, or other low bandwidth subliminal channels would work,
   but such techniques are advanced, and PGP Inc are not making similar
   scale efforts to develop and deploy these.
   
Actually, we *are* considering putting in stego and some other features.
The major deciding factor about when we do them all revolves around who
will buy them.

   Also if Padgett is using pgp5.5 himself, and he attempts to send a
   mail to someone living in tinpotdictatorsville, his client will
   cooperate with the dictators wishes.  If the CMR mechanism were not
   used at all the dictator would find he had far less use for pgp5.6
   (with CDR in place of CMR).  This is because CDR does not provide any
   third party access to communications.  It provides third party access
   for stored data.  The dictator only has 1000 soldiers (it is a small
   dictatorship), and they can only collect backup tapes from 100 houses
   per day.  They are never sure if the citizens aren't hiding another
   machine somewhere.  The process is inefficient and costs lots of
   resources.  In fact the dictators job is now much harder than it would
   have been were PGP to keep the CMR method.
   
You are in error. The only time that you are forced to use CMR is when (1)
you share the CMRK with the other party AND (2) the strict flag is set. In
all other cases, you can opt-out, on a message-by-message basis.

	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, 17 Oct 1997 16:54:08 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: what is purpose of CMR?
Cc: [email-masked]
Sender: [email-masked]

At 12:54 AM 10/18/97 +0100, Adam Back wrote:
   
   This is a question which I am unclear on about PGP Inc's design goals
   in using the CMR method.
   
     Is the CMR field to allow the company to recover from the user
     forgetting his password?  (recover his mail folder full of encrypted
     email).
   
   or
   
     Is the CMR field to allow the company to read the email in transit
   
   This seems like a fairly important distinction.

It's not for surveillance. It's for recovering from disaster. I think it
would be a good thing to send a PGP message over an encrypted link (TLS or
other).

	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: Sat, 18 Oct 1997 00:54:05 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: what is purpose of CMR?
Sender: [email-masked]

This is a question which I am unclear on about PGP Inc's design goals
in using the CMR method.

  Is the CMR field to allow the company to recover from the user
  forgetting his password?  (recover his mail folder full of encrypted
  email).

or

  Is the CMR field to allow the company to read the email in transit

This seems like a fairly important distinction.

Adam

Date: Sat, 18 Oct 1997 00:46:02 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: binding cryptography
Sender: [email-masked]

Padgett Peterson <[email-masked]> writes:
> Adam Back <[email-masked]> writes:
> >In addition it is acknowledged that this is a weak enforcement in that
> >it is relatively easy to create messages which will fool the CMR
> >enforcement agent, which will still be decryptable by Alice.
> 
> That goes without saying: unless the policy server contains the CMR private
> key (which will not happen unless someone is completely clueless) it will
> be unable to do more than verify that something which appears to be the 
> CMR header exists in the file. Such an appendage would be trivial to add.
> 
> If the server could do more, THEN I would be concerned.

One way that the server could be modified to do more would be to use
Koops et als Binding Cryptography construct.  (A net search would find
htmlized paper).

It works with El Gamal and allows a fourth party (the SMTP CMR
enforcer in this case) to verify that the same session keys are used
inside the PKE without need for access to the CMR private key.  This
provides the third party with better enforcement.

When Binding Cryptography was discussed first by it's authors on
cypherpunks, Hal Finney came up with several ways to bypass it.

The obvious one (super encrypt), and the suggestion that you could
make the session key itself be a public key encrypted packet, so that
the fourth party would find that the two session keys were correct,
but when the third party tried to decrypt, it would find a key which
didn't work; the true recipient would decrypt the nested public key
and use the session key contained in that.

However this offers significant extra protection against hacking by
the sender because the sender would then require co-operation with the
receiver.

Crude protection against super-encryption could be provided by having
the client refuse to accept plaintext which looked like a pgp message.

Just trying to be helpful in ensuring the enforcement is all it's
cracked up to be.

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: Sat, 18 Oct 1997 00:19:10 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Is PGP still private?
Sender: [email-masked]

Padgett Peterson <[email-masked]> writes:
> Adam Back <[email-masked]> writes:
> >I'm not clear on this last one, but it may even be that a pgp5.0
> >implementation knows how to reply to a CMR key also.
> 
> Source code is available, or am sure pgp will answer.

No answer so far.  It would be quicker for someone who does know to
say yay or nay, than for me to read through the source.  Or simply for
someone who has both pgp5.0 and pgp5.5 test rig to try it and see with
a CMR key to see what pgp5.0 thinks of it; and what pgp5.5 + policy
enforcer thinks of what pgp5.0 sends it in response.

> >However if Alice is using a key with CMR then the user using a client
> >which understands CMR keys will present the user with a choice:
> 
> Could. Sender would also have to have/be able to get the CMR key as it is 
> essentially an additional recipient.

The software will attempt to fetch the CMR key, if it is unable to do
this it will say so.  (I think).

> >Some CMR keys will be marked to state that if the CMR key holder does
> >not use the application to say he wants to allow the CMR key holder to
> >read the information, that the message will not reach Alice, because a
> >CMR policy enforcer will bounce it back.
> 
> Correct: *but* in the event of a bounce, no one else can read the message
> so privacy is maintained. Referring to the CIA triangle, confidentiality and
> integrity have been maintained, it is availablity that has failed.

You are correct, availability has failed.  This is a very effective
enforcement mechanism: if you wish to communicate with someone you
can't because the policy enforcement says "no", you either comply or you
lose the ability to send to that destination.

If this system were to be used for purposes other than those which
it's designers have envisaged, this enforcement could become
dangerous.

For example if it were installed in tinpotdictatorsville the
enforcement could result in the user having a "choice" not to
communicate with anyone at all.  Availability would be 0%.

Even if you believe that PGP Inc will never get an export license to
tinpotdictatorsville, there will be other companies implementing to
the OpenPGP standard in countries with freer export regulations.
These people if they choose to implement to the OpenPGP standard, will
be forced to implement the CMR feature too, otherwise the software
will not interoperate.

> >In addition it is acknowledged that this is a weak enforcement in that
> >it is relatively easy to create messages which will fool the CMR
> >enforcement agent, which will still be decryptable by Alice.
> 
> That goes without saying: unless the policy server contains the CMR private
> key (which will not happen unless someone is completely clueless) it will
> be unable to do more than verify that something which appears to be the 
> CMR header exists in the file. Such an appendage would be trivial to add.
> 
> If the server could do more, THEN I would be concerned.

If you consider the case in tinpotdictatorsville above, it can do
more.  This is the case we should be focusing on because it is the
case we are trying to avoid.

This is because even though you can hack around it, the dictator will
be able to tell you have hacked around it because he will not be able
to recover the plaintext.

You can use super encryption but that will be detected also.

Steganography, or other low bandwidth subliminal channels would work,
but such techniques are advanced, and PGP Inc are not making similar
scale efforts to develop and deploy these.

Also if Padgett is using pgp5.5 himself, and he attempts to send a
mail to someone living in tinpotdictatorsville, his client will
cooperate with the dictators wishes.  If the CMR mechanism were not
used at all the dictator would find he had far less use for pgp5.6
(with CDR in place of CMR).  This is because CDR does not provide any
third party access to communications.  It provides third party access
for stored data.  The dictator only has 1000 soldiers (it is a small
dictatorship), and they can only collect backup tapes from 100 houses
per day.  They are never sure if the citizens aren't hiding another
machine somewhere.  The process is inefficient and costs lots of
resources.  In fact the dictators job is now much harder than it would
have been were PGP to keep the CMR method.

(CDR is Corporate Data Recovery.  With CDR messages are sent encrypted
only for the recipients keys.  Recovery is provided by storing
recovery information alongside the data.  The recipient is presented
with a choice as to whether to archive a message, and whether to
enable recovery information.  It is a more secure, and less dangerous
design.)

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, 17 Oct 1997 19:02:56 -0400
From: [email-masked]
To: Hal Finney <[email-masked]>
cc: [email-masked]
Subject: Re: proposal: commercial data recovery
Sender: [email-masked]

On Tue, 14 Oct 1997, Hal Finney wrote:

> You do a good job of saying what you want to avoid, but not much about
> what you want to accomplish!  You are doing this to satisfy some kind
> of market need for commercial access to data.  What are the requirements
> your design will satisfy?  What do the customers need?  You can't design
> a system based solely on what it doesn't do.
> 
> PGP, Inc. has made its design choices based on interaction and discussion
> between people responsible for security, human interface, sales/marketing
> and customer support, as well as the customers themselves.  The lessons
> which have come out of this include an emphasis on solutions which
> people can use and which will work in the field.  This means they have
> to be transparent, easy to learn, fit into existing procedures, and
> be reliable, as well as being secure.  Systems which require extensive
> retraining, new operational procedures, or which will hurt reliability
> are not acceptable - they simply won't be deployed.  That's the reality.

One thing PGP has not looked into would be having a master key such that N
bits will be the same from the corporate master key to any user's key.
Then you could recover any user key from the corporate key, but it would
requrire some expense and effort, so it would prevent casual
eavesdropping by the administrators.

A second method would require N (typically 3) escrow keys to recreate the
access key, and would work best if it only decrypted one user's messages.

I would rather not trust a single party within a corporation.

Right now, whoever has the corporate key can read everyone's email.  What
happens when there is an insider trading lawsuit when the CIO reads the
CEO's "private" email?  I can think of other examples.  And if the
corporate key is compromised, I assume that compromises every piece of
email up to that point?

But let me ask a question about PGP, Inc. - Do they use the PGP 5.5
version with corporate key recovery internally?

Date: Fri, 17 Oct 1997 16:55:09 -0400 (EDT)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: Re: Is PGP still private?
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

>I think also that pgp5.5 for personal use probably knows how to reply
>to a CMR key also.

>I'm not clear on this last one, but it may even be that a pgp5.0
>implementation knows how to reply to a CMR key also.

Source code is available, or am sure pgp will answer.

>However if Alice is using a key with CMR then the user using a client
>which understands CMR keys will present the user with a choice:

Could. Sender would also have to have/be able to get the CMR key as it is 
essentially an additional recipient.

>Do you want to allow the CMR key holder to be able read the message as
>well as Alice?

Well if the policy enforcemnt says it must, then to send to Alice, you must.

>Some CMR keys will be marked to state that if the CMR key holder does
>not use the application to say he wants to allow the CMR key holder to
>read the information, that the message will not reach Alice, because a
>CMR policy enforcer will bounce it back.

Correct: *but* in the event of a bounce, no one else can read the message
so privacy is maintained. Referring to the CIA triangle, confidentiality and
integrity have been maintained, it is availablity that has failed.

>In addition it is acknowledged that this is a weak enforcement in that
>it is relatively easy to create messages which will fool the CMR
>enforcement agent, which will still be decryptable by Alice.

That goes without saying: unless the policy server contains the CMR private
key (which will not happen unless someone is completely clueless) it will
be unable to do more than verify that something which appears to be the 
CMR header exists in the file. Such an appendage would be trivial to add.

If the server could do more, THEN I would be concerned.

					Warmly,
						Padgett

Date: Fri, 17 Oct 1997 19:18:32 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: KeyIDs and Key Fingerprints
Sender: [email-masked]

William Geiger <[email-masked]> writes:
> Well there are two points here:
> 
> 1. Will a decreased size keyID really provide your goal of deniability??
> As I posted in my last message if the goal is anonymidity the the solution
> is to provide no keyID at all.

I agree with this.  I have argued for this before with Colin and Derek
back when they were doing 3.0 before PGP Inc was formed.

Also a second point re. anonmity: what about Hal Finney's stealth
transform (I have a beta standalone implementation for pgp2.x at:
http://www.dcs.ex.ac.uk/~aba/stealth/ which I did some time back);
without that you don't have much anonymity anyway because, the PKEs
are all below EG public modulus, or RSA modulus, which is identifies
user statistically after a few messages.

The stealth transform would require packet mods.  Perhaps this is a
reason to defer the whole argument for next version of standard.  KISS
as Tim says, no novel features, no new CMR features, etc this time
around?  (Also sorry Ian B. no new message receipt).

> 2. By having a limited or no keyID in the encryption packet, the end user
> is denighed the knowledge of who the message was encrypted to. Was the
> company key used? Was a government key covertly added?

Hadn't thought of this implication.  They are indeed conflicting.  I would
take this to mean the obvious thing to do make KeyIDs below a chosen length
be rejected by the CMR enforcement filter.

(modulo my argument about CMR being used at all).

> It should be noted that Hal never mentioned where or how Phil whished to
> make use of these variable size keyID's. I still stand by my original
> conclution that the cost benifit case needs to be made on this before such
> a departure from the curent keyID structure is made.

Variable sized key ids are good in themselves I think because they get
around the spoofing problem: you can crank them up to full hash.

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, 17 Oct 1997 19:28:02 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Is PGP still private?
Sender: [email-masked]

William Geiger III <[email-masked]> writes:
> In <v03110703b06c42291a03@[206.183.203.100]>, on 10/16/97 
>    at 05, Roland Silver <[email-masked]> said:
> >I'm interested in PGP 5.x, but I don't understand the criticism of it. Do
> >certain versions of PGP have GAK or CMR capability built in? If I use
> >such a version to send a message encrypted with Alice's public key, will
> >someone other than Alice, such as the FBI, be able to read it without my
> >knowledge or consent?
> 
> >If the answer to that question is on some FAQ, please point me to it.
> 
> Dispite some of the FUD and Fearmongering going on, there is no version of
> PGP that allows a 3rd party to decrypt a message without your knowledge
> (there is no backdoors in any version of PGP). Now what Alice does after
> she has decrypted the message is another matter that is beyond your
> control. :)

I don't think that is a fair answer.  Roland asked "do certain versions
of pgp have ... CMR capability built in?"

The honest answer is yes: pgp5.5 for business does.

I think also that pgp5.5 for personal use probably knows how to reply
to a CMR key also.

I'm not clear on this last one, but it may even be that a pgp5.0
implementation knows how to reply to a CMR key also.

This is an apolitical explanation.

I welcome clarification of the question of what pgp5.0 knows how to
send to.

> Now just for the those in the "cheap seats": If you encrypt a
> message with and only with Alice's public key then only someone who
> has a copy of Alice's private key can decrypt it. Hopefully Alice is
> the only one who has that key, but like the decrypted message, you
> really have no controll of what Alice does with her keys.

That is also generalising.

If Alice is using a key without CMR facility then what you said is
always true.

However if Alice is using a key with CMR then the user using a client
which understands CMR keys will present the user with a choice:

Do you want to allow the CMR key holder to be able read the message as
well as Alice?

Some CMR keys will be marked to state that if the CMR key holder does
not use the application to say he wants to allow the CMR key holder to
read the information, that the message will not reach Alice, because a
CMR policy enforcer will bounce it back.

In addition it is acknowledged that this is a weak enforcement in that
it is relatively easy to create messages which will fool the CMR
enforcement agent, which will still be decryptable by Alice.

This is also an apolitical explanation.

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, 17 Oct 1997 18:27:35 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: anti-GAK design principles: worked example #1
Sender: [email-masked]

Bill Stewart <[email-masked]> writes:
> I'll duck the 5.5 argument for now, but you're 
> incorrect on 5.0.  The PGP 5.0 key format includes
> separate keys for signature and privacy, which is a mostly good thing,

A very good thing.

> and includes the ability to associate a group of
> keyIDs and flag bits with each privacy key.

So can you use pgp5.0 to construct a CMR key which would
interoperate with pgp5.5 for business?

> 	(or each set of privacy key + signature key??  Jon?)
> What semantics are attached to this association are dependent
> on the computer program, and PGP 5.0 does nothing CMRish with them,
> much less GAKish.  

Clearly pgp5.0 does nothing with these flags on reciept, but does it
understand them when sending?

Scenario: I work for Mega Corp, and it is using pgp5.5, and is using
CMR with companies key.

Does pgp5.0 reply encrypting to just me as individual, or two crypto
recipients me, and Mega Corp recovery key?

I would be interested on clarification of this point.

> OpenPGP could do anything it wants with the field,
> such as use it for keyids (or IPv4 addresses, since it's 32 bits)
> of keyservers with copies of the keys, or whatever.
> PGP 5.6 could at least take the case of multiple keyids
> and secret-share the session key between them rather than
> allowing any single key to access it.

Yes, I'm not so much arguing about the flexibility or the mechanism,
as what it is being used for.  I consider there are more secure and
more GAK resistant ways to acheive same functionality.

> >- store a copy of the private half of the users PGP encryption key
> >  encrypted to the company data recovery key on the users disk.
> No.  This is evil.  Don't go there.  Even with secret sharing,
> and especially without.

It is evil.  But it is not _as_ evil.

The reason for this is that government access to storage keys is not
as evil as government access to communications keys, because the
government has to come and capture the ciphertext (take your disk),
whereas with communications they can grab them via an arrangement with
your ISP.

> >- (optional) design the software to make it hard to copy the data
> >  recovery packet from the disk, hide the data, bury it in keyrings,
> >  stego encode it, whatever, use your imagination.  
> This is secutity by obscurity; not highly useful.

Indeed.  It is of only marginal use.

> >Possible objections:
> >objection #1. what if disk burns?
> >counter #1:   backup your disk
> >objection #2: users don't back up disks
> 
> Objection 3 - users _do_ back up disks -
> that means every backup tape or disk or server volume
> potentially contains your disk's encryption keys
> CAKked up with the Corporate Master Key, which is Bad,
> and wildly out of the user's control, violating
> one of your principles.

See point above.

This is not avoidable for storage ... if you are encrypting data on
disk, and if you want recovery information, you have no choice but to
allow company access.

The recovery information should be as decentralised as much as
possible.  (Perhaps this should be the Stewart corollary).

The point though is that storage recovery is a completely separable
issue from communications "recovery" which is a euphamism for allowing
companies to read, or snoop, employees email, unless it is being used
soley for data recovery of mail stored in mail folders (which seems to
be what PGP Inc means by CMR term), in which case it is not necessary
functionality, and can be better acheived by encrypting the mail
archive with a user symmetric key with company storage recovery on
that key.

I would be interested to hear novel ways to minimise the likelihood
that the government could walk into your offices, grab the CD duke
box, grab the single corporate recovery key and walk off.

Decentralisation is one good way -- recovery keys are in hands of
department and group heads -- secret splitting is another good way --
and (your suggestion) omitting some of recovery bits is a small
addtional hinderance to intruders after plaintext.

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: Fri, 17 Oct 97 10:40:45 -0500
To: Will Price <[email-masked]>
Cc: [email-masked]
Subject: Re: KeyIDs and Key Fingerprints
Sender: [email-masked]

In <v04001d09b06cea8d4a97@[205.180.137.244]>, on 10/17/97 
   at 04, Will Price <[email-masked]> said:

>>Well I really have to say that I don't like this. It basically blows
>>months of work in the area of keylookup optimization techniques that I
>>have developed for my products. Due to the uniqueness of the keyid in a
>>given keyring

>This has never actually been a valid assumption in old PGP, and is only a
>reasonably valid assumption in 5.0+ with the 64bit keyIDs, so "months" of
>work which depended on this seems based on an error.  We have seen both
>0xdeadbeef keys and actual random collisions in the old RSA keys.  The
>security reasons for combining the KeyID and Fingerprint and thus being
>able to take advantage of the extra size and security were very well laid
>out by Hal.

Of courese this is a valid assumption, PGP does not allow the addition of
a key to a keyring if that keyid is already found in the keyring, therfore
it is safe to assume that for a given keyring all keyids are unique. We
are not talking of using the keyID for determining the authentication of a
key merly for doing keylookup before processing a encrypt/sig block. I am
well aware of a varity of spoof attacks on the PGP keys and have written
on them in the past.

>>Variable KeyId's blow KeyId uniqueness out of the water. should id 123456,
>>id 5456, & id 456 be considered three unique keys or two unique keys ??

>I think you must have misunderstood something about Hal's message.  The
>KeyID in the *key* is never variable.  As Hal outlined, RSA keys use the
>old 32bit method, and DSS/DH keys use the new fingerprint/keyID 160/64
>bit method.  We're only really talking about the ESK packet on encrypted
>messages here for variable size keyIDs.  The issue is how much
>information to reveal there.  The one thing that wasn't implemented in
>5.0/5 was the small key ID size ESK Hal described -- I'd never heard it
>but it sounds a truly great idea from a privacy perspective.  Sometimes
>it is far more important to have deniability for privacy reasons than
>incur the extremely unlikely possibility of going through the extra
>milliseconds of trying more than one private key, and the few bits will
>solve at least 95% of the cases in one try.

Well there are two points here:

1. Will a decreased size keyID really provide your goal of deniability??
As I posted in my last message if the goal is anonymidity the the solution
is to provide no keyID at all.

2. By having a limited or no keyID in the encryption packet, the end user
is denighed the knowledge of who the message was encrypted to. Was the
company key used? Was a government key covertly added?

I hope you can see how these two different needs are in conflict. I don't
see the reduced keyID as being a solution to either one. It does not
provide the needs of those whishing anonymitity nor does provide enough
information for the user who wishes to know who his communications has
been encrypted too.

It should be noted that Hal never mentioned where or how Phil whished to
make use of these variable size keyID's. I still stand by my original
conclution that the cost benifit case needs to be made on this before such
a departure from the curent keyID structure is made.

As an added note what effects will theis have on backward compatibility??
While the the breaking of compatibility was grudgingly accepted with 5.x
and the DSS/DH keys I doubt that same will be true for less benificial
"features".

>>Key Server Identifiers & URL's are of only limited use (communicating to
>>the keyservers).

>Seems pretty darn useful to me.  Bob has a key.  It is on one server out
>of thousands of keyservers.  Which one?  Who knows!  Fortunately, Bob's
>key hint tells me that his key is available for updates (revocations, new
>signatures, new user IDs, etc...) from ldap://keyserver.company.com.  The
>old system of one big monstrous keyserver at MIT has been eliminated with
>5.5 along with innumberable other improvements to the keyserver
>infrastructure which will soon become apparent as we have time to get all
>the information properly written up and everyone gets a chance to play
>with 5.5 soon when we release the Personal version.  This URL hint idea
>was not implemented in 5.5.  Easy to add.

Will, we have already disscused adding URL's and such to the key format
via the userID with a type identifier flag and some internal format
checking. I am assuming this is what you are talking about or are you
sugesting something different here? Regardless it is still of limited
value as it is only of use durring a keylookup on the *server* and then
only if you already have a copy of the key. The majority of
communincations to the server are not going to be for updated keys but for
an origianl copy of the key. In such a case all the person will have to go
on is the e-mail address and perhaps the keyID if a previously signed
message has been obtained.

-- 
---------------------------------------------------------------
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: Fri, 17 Oct 1997 04:27:09 -0700
To: "Tom Phinney" <[email-masked]>
From: Will Price <[email-masked]>
Subject: Re: KeyIDs and Key Fingerprints
Cc: <[email-masked]>
Sender: [email-masked]

At 5:57 PM -0700 10/16/97, Tom Phinney wrote:
>BTW, the PGP 5.0 practice of not identifying which key has been received makes
>guessing the appropriate passphrase a real PITA.  I use common passphrases for
>same-length keys (RSA or DSS/EG), but different passphrases for different
>lengths, and each nym has its own distinct passphrase (a second-line of
>protection against my confusing my nyms, each of which has a distinct
>purpose).

Fixed in 5.5.  All sorts of issues like this were fixed in 5.5 -- one of
those noted earlier by Jon of seeing who else can read a received message.
The reason 5.0 did this was because we were using an absolutely horrendous
API between our library code and client code.  The API was burnt at the
stake in a bloody caveman-like ritual shortly after 5.0 and replaced with a
beautiful new API that is part of our SDK.

-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=0x5797A80B>

Date: Fri, 17 Oct 1997 04:07:43 -0700
To: "William H. Geiger III" <[email-masked]>
From: Will Price <[email-masked]>
Subject: Re: KeyIDs and Key Fingerprints
Cc: [email-masked]
Sender: [email-masked]

>Well I really have to say that I don't like this. It basically blows
>months of work in the area of keylookup optimization techniques that I
>have developed for my products. Due to the uniqueness of the keyid in a
>given keyring

This has never actually been a valid assumption in old PGP, and is only a
reasonably valid assumption in 5.0+ with the 64bit keyIDs, so "months" of
work which depended on this seems based on an error.  We have seen both
0xdeadbeef keys and actual random collisions in the old RSA keys.  The
security reasons for combining the KeyID and Fingerprint and thus being
able to take advantage of the extra size and security were very well laid
out by Hal.

>Variable KeyId's blow KeyId uniqueness out of the water. should id 123456,
>id 5456, & id 456 be considered three unique keys or two unique keys ??

I think you must have misunderstood something about Hal's message.  The
KeyID in the *key* is never variable.  As Hal outlined, RSA keys use the
old 32bit method, and DSS/DH keys use the new fingerprint/keyID 160/64 bit
method.  We're only really talking about the ESK packet on encrypted
messages here for variable size keyIDs.  The issue is how much information
to reveal there.  The one thing that wasn't implemented in 5.0/5 was the
small key ID size ESK Hal described -- I'd never heard it but it sounds a
truly great idea from a privacy perspective.  Sometimes it is far more
important to have deniability for privacy reasons than incur the extremely
unlikely possibility of going through the extra milliseconds of trying more
than one private key, and the few bits will solve at least 95% of the cases
in one try.

>Key Server Identifiers & URL's are of only limited use (communicating to
>the keyservers).

Seems pretty darn useful to me.  Bob has a key.  It is on one server out of
thousands of keyservers.  Which one?  Who knows!  Fortunately, Bob's key
hint tells me that his key is available for updates (revocations, new
signatures, new user IDs, etc...) from ldap://keyserver.company.com.  The
old system of one big monstrous keyserver at MIT has been eliminated with
5.5 along with innumberable other improvements to the keyserver
infrastructure which will soon become apparent as we have time to get all
the information properly written up and everyone gets a chance to play with
5.5 soon when we release the Personal version.  This URL hint idea was not
implemented in 5.5.  Easy to add.

-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=0x5797A80B>

Date: Fri, 17 Oct 1997 01:51:10 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: anti-GAK design principles: worked example #1
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 11:45 PM 10/15/1997 +0100, Adam Back wrote:
>We'll instead take it as a given that 
>pgp5.5 and pgp5.0 are GAK compliant because of CMR and
>that this is a bad thing.

I'll duck the 5.5 argument for now, but you're 
incorrect on 5.0.  The PGP 5.0 key format includes
separate keys for signature and privacy, which is a mostly good thing,
and includes the ability to associate a group of
keyIDs and flag bits with each privacy key.
	(or each set of privacy key + signature key??  Jon?)
What semantics are attached to this association are dependent
on the computer program, and PGP 5.0 does nothing CMRish with them,
much less GAKish.  OpenPGP could do anything it wants with the field,
such as use it for keyids (or IPv4 addresses, since it's 32 bits)
of keyservers with copies of the keys, or whatever.
PGP 5.6 could at least take the case of multiple keyids
and secret-share the session key between them rather than
allowing any single key to access it.

>The rest of Will's post seems to miss the point, so it seems to me
>that the best way to transfer understanding of how to use the anti-GAK
>design principles to design less GAK friendly systems is to present a
>worked example.

Good - we'll attempt to nitpick it at least as thoroughly as
we're nitpicking PGP 5.5 :-)

>- store a copy of the private half of the users PGP encryption key
>  encrypted to the company data recovery key on the users disk.
No.  This is evil.  Don't go there.  Even with secret sharing,
and especially without.

>- (optional) design the software to make it hard to copy the data
>  recovery packet from the disk, hide the data, bury it in keyrings,
>  stego encode it, whatever, use your imagination.  
This is secutity by obscurity; not highly useful.

>Possible objections:
>objection #1. what if disk burns?
>counter #1:   backup your disk
>objection #2: users don't back up disks

Objection 3 - users _do_ back up disks -
that means every backup tape or disk or server volume
potentially contains your disk's encryption keys
CAKked up with the Corporate Master Key, which is Bad,
and wildly out of the user's control, violating
one of your principles.

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

From: "Tom Phinney" <[email-masked]>
To: <[email-masked]>
Cc: "Hal Finney" <[email-masked]>
Subject: Re: KeyIDs and Key Fingerprints
Date: Fri, 17 Oct 1997 00:57:08 -0000
Sender: [email-masked]

On Thursday, October 16, 1997, Hal Finney <[email-masked]> wrote:

> It would be interesting to hear if there are other cases where being
> able to vary the size and specificity of the keyID would be appropriate.
> Are there any sizes besides small (about 3 bits, perhaps), medium (64
> bits), and large (160 bits) which seem useful?

My PGP 5.0 keyring currently has 12 private keys, some for nyms (pseudonymous
servers), and some under my name but with different algorithms and/or different
key lengths.  (FYI, I use longer unpublished key-pairs for certain
communications, and bootstrap the key exchange through my shorter published
public keys.)

Under these conditions, three bits seems a bit too light. :-)  More seriously,
an eight-bit keyID would still leave a large amount of ambiguity about which of
millions (potentially billions) of recipients was intended, but would provide a
reasonable chance that the correct key could be identified by the recipient's
software at first trial.

BTW, the PGP 5.0 practice of not identifying which key has been received makes
guessing the appropriate passphrase a real PITA.  I use common passphrases for
same-length keys (RSA or DSS/EG), but different passphrases for different
lengths, and each nym has its own distinct passphrase (a second-line of
protection against my confusing my nyms, each of which has a distinct purpose).

Tom Phinney
[email-masked]
[email-masked]

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 16 Oct 97 23:41:56 -0500
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: KeyIDs and Key Fingerprints
Sender: [email-masked]

Hi Hal,

Well I really have to say that I don't like this. It basically blows
months of work in the area of keylookup optimization techniques that I
have developed for my products. Due to the uniqueness of the keyid in a
given keyring and the exposure of the keyids in both encryption &
signature blocks I have been able to greatly improve PGP performance both
on the client and sever. I think that perhaps you have undervalued the
"hint" feature of the keyid.

Key Server Identifiers & URL's are of only limited use (communicating to
the keyservers).

Variable KeyId's blow KeyId uniqueness out of the water. should id 123456,
id 5456, & id 456 be considered three unique keys or two unique keys ??

How will PGP match sig block & encrypt blocks to the appropriate key when
due to the reduced key size that match is ambiguous?? Test every
possessible key?? I see very little justification for increasing key
matching & message processing times.

Then we have two golden rules:

- KISS: Keep It Simple Stupid
- Don't fix what ain't broke

There are only 2 cases where KeyID exposure is a problem and this is only
in the encryption block:

-- BCC's: I have discussed my solution to handleing BCC's in an automated
encryption system both on the mailing lists/newsgroups and with several of
the PGP staff. Any e-mail message that contains BCC's a separate message
needs to be sent to each BCC recipient and encrypting it with only the key
for that recipient.

-- Anonymous Posts: any "hint" provided in the encryption block is a
decrease in security. For such messages all identifying information needs
to be stripped from the message including the keyID.

Sorry but if Phil is interested in going this route then he needs to show
that the benefits of doing so outweighs the cost of implementation. Right
now I see the benefits as very low and the costs very high.

In <[email-masked]>, on 10/16/97 
   at 07, Hal Finney <[email-masked]> said:

>Another thread pointed out the difference between keyIDs and key
>fingerprints as ways of referring to keys.

>Currently, keyIDs and key fingerprints are defined somewhat differently
>for RSA keys than for newer keys.  The RSA definitions are a legacy for
>backwards compatibility, while the new methods have improved properties.

>With RSA keys, the keyID is the low order 64 bits of the RSA modulus. It
>turns out that it is trivial to generate keys which match a target key's
>low 64 bits, hence a keyID is not at all a unique handle for referring to
>a key.  (This is sometimes referred to as the "dead beef" attack, after
>someone demonstrated that they could generate a key with a keyID whose
>low 32 bits were 0xdeadbeef.)

>In most cases, keyIDs are not used in a context where this forgeability
>is a problem.  The most common use of a keyID is to help find a signature
>or decryption key.  It can be thought of as a "hint" to point the
>software to the right key.  However only one key will actually work to
>decrypt or signature-verify the message.  If the hint turns out to be
>ambiguous, it can still be useful.  (We anticipate adding other kinds of
>key-finding hints in the future, perhaps URLs or key server identifiers.)

>The RSA key fingerprint is intended to be more difficult to forge. It is
>an MD5 hash on the numeric data of the RSA modulus and exponent. However
>it turns out that this is not completely immune to forgery, as the hash
>value is not sensitive to where the modulus ends and the exponent begins. 
>You could have different keys with some modulus data moved to the
>exponent, and they would have the same RSA fingerprint.

>These problems were solved in the new keyID and fingerprint algorithms
>introduced in PGP 5.0.  They apply to the non-RSA keys, presently the DSS
>and ElGamal keys.

>The fingerprint is still a hash over the key data, but this time the
>entire public key packet is hashed.  This includes length fields which
>make it effectively impossible to have two keys which hash to the same
>fingerprint.  Furthermore, the fingerprint hash function is changed from
>MD5, which is now suspected to be weak, to SHA-1, a newer, larger, and
>more secure hash.  The new fingerprints are therefore 20 bytes long
>compared to 16 bytes for the old ones.

>KeyIDs for the new keys are defined to be the rightmost 64 bits of the
>fingerprint.  The only way to generate two new keys with the same keyID
>would be to keep trying at random until two of them happened to match, a
>much more difficult problem.

>Phil Zimmermann has suggested that we generalize the keyID concept to
>allow it to be variable length.  Rather than fixing it as a 64 bit
>substring of the fingerprint, we would make it a variable sized
>substring. (Phil would also prefer that it be a left substring rather
>than a right substring, for readability.)

>This allows the software to be flexible about how specific it needs to be
>when it refers to a key.  For most purposes, the 64 bit keyID is about
>right.  To be completely specific, the keyID could be expanded to be the
>full 160 bits of the fingerprint.

>An interesting case arises where you might want the keyID to be smaller.
>In some contexts it is a privacy leak that an encrypted message contains
>the keyID of the key which can decrypt it.  In that case you might want
>the keyID to be just a few bits long.

>(You'd probably want it to be a few bits rather than zero bits, because
>the recipient frequently has more than one decryption key.  Leaking a few
>bits of keyID doesn't significantly hurt privacy, since there would still
>be a very large number of keys which would match.  But it will simplify
>the decryption process, since it will generally still allow a single
>decryption key to be tried.)

>Doing this would allow us to merge the two concepts of keyID and key
>fingerprint into one variable-sized keyID.  The actual number of bits
>shown would then depend on the context in which it was used.

>It would be interesting to hear if there are other cases where being able
>to vary the size and specificity of the keyID would be appropriate. Are
>there any sizes besides small (about 3 bits, perhaps), medium (64 bits),
>and large (160 bits) which seem useful?

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

-- 
---------------------------------------------------------------
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: Fri, 17 Oct 1997 13:57:08 +1000 (EST)
From: David Formosa <[email-masked]>
Reply-To: [email-masked]
To: Bonatti Chris <[email-masked]>
cc: Ian Brown <[email-masked]>, IETF OpenPGP <[email-masked]>
Subject: Re: Secure receipts
Sender: [email-masked]

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

On Thu, 16 Oct 1997, Bonatti Chris wrote:

> > Does this sound feasible/desirable? If so, maybe this could go
> > in the second draft?

[...]

> > ASAP, but this is quite a simple and isolated proposal which
> > shouldn't be too difficult to add in...

>      Yes, I think this is a desireable function.

While I too aggry that it is a desireable function that could be simply
added I think if we do we will quickly feature bloat the standard as each
person tries to get there own pet feature into the system.

I belave that we should conentrate on getting the minimum possable number
of features in the standard so to ease the abilty to create conforming
products.

- -- 
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, 16 Oct 1997 17:59:36 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: KeyIDs and Key Fingerprints
Sender: [email-masked]

Another thread pointed out the difference between keyIDs and key
fingerprints as ways of referring to keys.

Currently, keyIDs and key fingerprints are defined somewhat differently
for RSA keys than for newer keys.  The RSA definitions are a legacy for
backwards compatibility, while the new methods have improved properties.

With RSA keys, the keyID is the low order 64 bits of the RSA modulus.
It turns out that it is trivial to generate keys which match a target
key's low 64 bits, hence a keyID is not at all a unique handle for
referring to a key.  (This is sometimes referred to as the "dead beef"
attack, after someone demonstrated that they could generate a key with
a keyID whose low 32 bits were 0xdeadbeef.)

In most cases, keyIDs are not used in a context where this forgeability is
a problem.  The most common use of a keyID is to help find a signature or
decryption key.  It can be thought of as a "hint" to point the software
to the right key.  However only one key will actually work to decrypt
or signature-verify the message.  If the hint turns out to be ambiguous,
it can still be useful.  (We anticipate adding other kinds of key-finding
hints in the future, perhaps URLs or key server identifiers.)

The RSA key fingerprint is intended to be more difficult to forge.
It is an MD5 hash on the numeric data of the RSA modulus and exponent.
However it turns out that this is not completely immune to forgery,
as the hash value is not sensitive to where the modulus ends and the
exponent begins.  You could have different keys with some modulus data
moved to the exponent, and they would have the same RSA fingerprint.

These problems were solved in the new keyID and fingerprint algorithms
introduced in PGP 5.0.  They apply to the non-RSA keys, presently the
DSS and ElGamal keys.

The fingerprint is still a hash over the key data, but this time the
entire public key packet is hashed.  This includes length fields which
make it effectively impossible to have two keys which hash to the same
fingerprint.  Furthermore, the fingerprint hash function is changed
from MD5, which is now suspected to be weak, to SHA-1, a newer, larger,
and more secure hash.  The new fingerprints are therefore 20 bytes long
compared to 16 bytes for the old ones.

KeyIDs for the new keys are defined to be the rightmost 64 bits of the
fingerprint.  The only way to generate two new keys with the same keyID
would be to keep trying at random until two of them happened to match,
a much more difficult problem.

Phil Zimmermann has suggested that we generalize the keyID concept
to allow it to be variable length.  Rather than fixing it as a 64 bit
substring of the fingerprint, we would make it a variable sized substring.
(Phil would also prefer that it be a left substring rather than a right
substring, for readability.)

This allows the software to be flexible about how specific it needs
to be when it refers to a key.  For most purposes, the 64 bit keyID
is about right.  To be completely specific, the keyID could be expanded
to be the full 160 bits of the fingerprint.

An interesting case arises where you might want the keyID to be smaller.
In some contexts it is a privacy leak that an encrypted message contains
the keyID of the key which can decrypt it.  In that case you might want
the keyID to be just a few bits long.

(You'd probably want it to be a few bits rather than zero bits, because
the recipient frequently has more than one decryption key.  Leaking a
few bits of keyID doesn't significantly hurt privacy, since there would
still be a very large number of keys which would match.  But it will
simplify the decryption process, since it will generally still allow a
single decryption key to be tried.)

Doing this would allow us to merge the two concepts of keyID and key
fingerprint into one variable-sized keyID.  The actual number of bits
shown would then depend on the context in which it was used.

It would be interesting to hear if there are other cases where being
able to vary the size and specificity of the keyID would be appropriate.
Are there any sizes besides small (about 3 bits, perhaps), medium (64
bits), and large (160 bits) which seem useful?

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

Date: Thu, 16 Oct 1997 17:13:00 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Secure receipts
Sender: [email-masked]

At 03:52 PM 10/16/97 -0700, Karen Rosenthal wrote:
>You might want to take a look at the following drafts:
>
>    An Extensible Message Format  for Message Disposition Notifications
>        draft-ietf-receipt-mdn-05.txt
>
>and
>
>    MIME-based Secure EDI
>        draft-ietf-ediint-as1-04.txt
>

Yes, we all might. This Working Group should reuse other work being done by
other Working Groups where possible. Reinventing MDNs does *not* seem like
a good use of our time.
--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 16 Oct 1997 15:52:05 -0700
From: Karen Rosenthal <[email-masked]>
Organization: Premenos
To: Ian Brown <[email-masked]>
CC: IETF OpenPGP <[email-masked]>
Subject: Re: Secure receipts
Sender: [email-masked]

You might want to take a look at the following drafts:

    An Extensible Message Format  for Message Disposition Notifications
        draft-ietf-receipt-mdn-05.txt

and

    MIME-based Secure EDI
        draft-ietf-ediint-as1-04.txt

The MDN draft decribes the specifics for request of and syntax for
repudiatable receipts.  Request is at the RFC822 level of the
originating document, receipt is in multipart/report format, and
includes the original-message-id of the originating document.

The MIME-based Secure EDI draft adds non-repudiation to the MDN (it is
unfortunate that this was buried in the EDIINT draft, rather than
standing as a draft on its own merit), adding a hash of the original
message data within the multipart/report, and encasing the MDN in a
multipart/signed construct, signable using either S/MIME or PGP.

Regards,
Karen

Ian Brown wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
>
> Something which has been mentioned over the last few days, which I
> also
> think would be enormously useful, is the possibility to do secure
> message receipts. When an OpenPGP client succesfully decrypts a
> message
> which has a flag set requesting a message receipt, it could mail back
> a
> secure receipt packet which would look something like the following
> (this is just a very first draft, based on the current Signature
> packet):
>
> Header: We would need to choose a new packet ID number
> Version number = 4
> Length of following material included in MD calculation
> |Signature classification
> |Timestamp
> |Some identification of the message receipt is for (e.g.
> <[email-masked]> as given in the Message-ID: field of a
> message). This could be flexible to allow for receipts for data
> transferred using other protocols.
> |Message digest algorithm
> |Digest of message receipt is for
> Key ID for key used for signing
> Public-key cryptosystem type
> Message digest algorithm
> First two bytes of MD output as checksum
> Signed digest of fields above marked with |
>
> Does this sound feasible/desirable? If so, maybe this could go in the
> second draft? I know we want to get the standard out ASAP, but this is
>
> quite a simple and isolated proposal which shouldn't be too difficult
> to
> add in...
>
> Ian.
>
> -----BEGIN PGP SIGNATURE-----
> Version: Cryptix 2.2.2
>
> iQCVAgUBNEY5jJpi0bQULdFRAQEuJAQAnylXfYZ/FZosCvd0yCwtBoGC31WmBMLW
> Pyff3tsOAqpuFxgMAtahnykEXOSs9AJJJOo7ER5AFUawja2/RVEbn7m3XELdTWZa
> 5QlenZ8Ac4U5OTpdLQvavsWClzAppD7WwaOj4+9aMau6QUMR6W0w7ZFYAr1OOzEr
> e1oz3CtQ+L8=
> =nVqZ
> -----END PGP SIGNATURE-----

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

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 16 Oct 97 17:39:34 -0500
To: Roland Silver <[email-masked]>
Cc: IETF OpenPGP <[email-masked]>
Subject: Re: Is PGP still private?
Sender: [email-masked]

In <v03110703b06c42291a03@[206.183.203.100]>, on 10/16/97 
   at 05, Roland Silver <[email-masked]> said:

>I'm interested in PGP 5.x, but I don't understand the criticism of it. Do
>certain versions of PGP have GAK or CMR capability built in? If I use
>such a version to send a message encrypted with Alice's public key, will
>someone other than Alice, such as the FBI, be able to read it without my
>knowledge or consent?

>If the answer to that question is on some FAQ, please point me to it.

Dispite some of the FUD and Fearmongering going on, there is no version of
PGP that allows a 3rd party to decrypt a message without your knowledge
(there is no backdoors in any version of PGP). Now what Alice does after
she has decrypted the message is another matter that is beyond your
control. :)

Now just for the those in the "cheap seats": If you encrypt a message with
and only with Alice's public key then only someone who has a copy of
Alice's private key can decrypt it. Hopefully Alice is the only one who
has that key, but like the decrypted message, you really have no controll
of what Alice does with her keys.

-- 
---------------------------------------------------------------
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: Andrew Bromage <[email-masked]>
Subject: Re: Secure receipts
To: [email-masked] (Ian Brown)
Date: Fri, 17 Oct 1997 08:43:37 +1000 (EST)
Cc: [email-masked]
Sender: [email-masked]

G'day.

Ian Brown wrote:

> Something which has been mentioned over the last few days, which I also
> think would be enormously useful, is the possibility to do secure
> message receipts.

I also think this is an excellent idea.  There are a few ways to do it.
Your way (to make a new packet) isn't bad, but then we're going to be
using signatures for a lot more in the future (e.g. machine-checkable
timestamping and authentication come to mind, but I'm sure there will be
more uses that hasn't occurred to us), so a more extensible solution is
better IMO.

A simple implementation which needn't affect the Open-PGP format beyond
perhaps one flag is to come up with a standard certificate format which
can be decoded by the appropriate software, which is then signed using
normal PGP document signing (perhaps flagged as "this is a certficate"
with an appropriate modification to the message hash, but that's not
strictly necessary --- anyone reading the signed document will see that
it is a certificate).  Some simple format such as:

	- Some ASCII data describing the kind of certificate in a
	  machine-parsable form with an appropriate human-readable
	  version.

	- An appropriately quoted version of the original document.

In fact, I would suggest this implementation _because_ it doesn't
affect the OpenPGP format very much.

> Does this sound feasible/desirable? If so, maybe this could go in the
> second draft? I know we want to get the standard out ASAP, but this is
> quite a simple and isolated proposal which shouldn't be too difficult to
> add in...

Definitely wait until the second draft, yes.

Cheers,
Andrew Bromage

Date: Thu, 16 Oct 1997 16:19:27 -0600
To: IETF OpenPGP <[email-masked]>
From: Roland Silver <[email-masked]>
Subject: Is PGP still private?
Sender: [email-masked]

I'm interested in PGP 5.x, but I don't understand the criticism of it. Do
certain versions of PGP have GAK or CMR capability built in? If I use such
a version to send a message encrypted with Alice's public key, will someone
other than Alice, such as the FBI, be able to read it without my knowledge
or consent?

If the answer to that question is on some FAQ, please point me to it.

-- Rollo Silver <[email-masked]>

Date: Thu, 16 Oct 1997 21:17:23 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: PGP Inc apology deal
Sender: [email-masked]

Whoops: dcs.ex mail system was misbehaving and appeared to be hanging
on SMTP connects to mail hub.  I was attempting modifying my
sendmail.cf with different mail hubs to get mail back to functioning,
and nothing appeared to work.  I in the end I rlogged in to mail hub
and cut and paste into emacs rmail.

Clearly somethings went through while appearing to hang.

Anyway, I thought it was a good post, but didn't intend to send 3
copies.  I am most anxious for PGP Inc to accept challenge.

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, 16 Oct 1997 20:50:46 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: "Anthony E. Greene" <[email-masked]>
CC: IETF OpenPGP <[email-masked]>
Subject: Re: Secure receipts
Sender: [email-masked]

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

> Why does a receipt need to be secure?

I would have thought the people on this list, above all, would
appreciate the need for security ;-) When I send important messages, I
like to know they have been received. An unsigned reply, whatever form
it took, could be sent by an attacker who had intercepted my message.

You could get your mailer to simply create a signed message with a body
saying "Your message of x (id x) was received at x". However, it is
*much* easier for automated processing at the other end if it is a
packet. In fact, using a packet scheme, you can have two levels of
compliance. The receipt packet could be sent inside a clearsigned
message saying "your message received". A mailer which didn't understand
receipts would simply check the signature (if it was PGP compatible) of
the message. A receipt-compatible mailer could take several actions. The
one I would like most is to look in my Sent-mail folder; if it finds the
message referred to by the receipt, it can mark it as "securely
received". 

A receipt would also be *extremely* useful for other protocols where
important data is being transmitted over an insecure link and the sender
*needs* to know that it has arrived safely.

Ian.

Comments: Authenticated sender is <ieca2@[205.252.27.1]>
From: "Bonatti Chris" <[email-masked]>
Organization: IECA, Inc.
To: Ian Brown <[email-masked]>
Date: Thu, 16 Oct 1997 16:00:11 -0500
Subject: Re: Secure receipts
Reply-to: [email-masked]
CC: IETF OpenPGP <[email-masked]>
Sender: [email-masked]

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

On Thu, 16 Oct 1997 Ian Brown <[email-masked]> wrote:
>
> Something which has been mentioned over the last few days,
> which I also think would be enormously useful, is the
> possibility to do secure message receipts. When an OpenPGP
> client succesfully decrypts a message which has a flag set
> requesting a message receipt, it could mail back a secure
> receipt packet which would look something like the following

<snip>

> Does this sound feasible/desirable? If so, maybe this could go
> in the second draft? I know we want to get the standard out
> ASAP, but this is quite a simple and isolated proposal which
> shouldn't be too difficult to add in...

Ian,

     Yes, I think this is a desireable function.

     I agree, also, that it needs to be deferred until the
second draft.  Aside from the obvious technical concerns, there
are a number of thorny user-oriented issues that will need to be
addressed.  Most notably the relationship (if any) to mail
receipts will need to be determined.  The semantics of the
secure receipt will also need to be established in terms of
whether it is manually authorized by the message recipient,
generated automatically, or some combination of the two.

Chris

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

Date: Thu, 16 Oct 1997 12:39:36 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Secure receipts
Sender: [email-masked]

Ian Brown writes:

> Something which has been mentioned over the last few days, which I also
> think would be enormously useful, is the possibility to do secure
> message receipts. When an OpenPGP client succesfully decrypts a message
> which has a flag set requesting a message receipt, it could mail back a
> secure receipt packet which would look something like the following
> (this is just a very first draft, based on the current Signature
> packet):

I'd suggest that rather than use any sort of binary encoding, this could be
better handled at the MIME level.  Particularly if you are bringing in
material which is outside the body of the message, like message-ids, it
is going to be very client-dependent how to get to that information.

RFC 1894 describes a message-delivery-status MIME message format which
is similar to what you are asking for.  If it were encapsulated in a
PGPMIME signed message then you would have the authentication security
that you want.  The RFC is more oriented towards the MTA rather than MUA
level, so it would indicate that the message had arrived in the user's
mailbox, but not whether he had read it.  However the 1894 syntax could
be extended to cover that case as well.

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

From: Mike Wynn <[email-masked]>
To: IETF OpenPGP <[email-masked]>, "'Ian Brown'" <[email-masked]>
Subject: RE: Secure receipts
Date: Thu, 16 Oct 1997 20:21:23 +0100
Sender: [email-masked]

Ian,

  Would it not be better to start using KeyFingerPrint
rather than KeyID as the identifier.

where a KeyFingerPrint Field is

KeyID (for old software and keyservers)
Message digest algorithm used
Digest of Key

as it is easy to produce a key with a specific KeyID
and Those people still wanting Vanity Keys can still have
there message within the Base64 Encoded Public Key.

Mike

----------
From: 	Ian Brown
Sent: 	16 October 1997 16:58
To: 	IETF OpenPGP
Subject: 	Secure receipts

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

Something which has been mentioned over the last few days, which I also
think would be enormously useful, is the possibility to do secure
message receipts. When an OpenPGP client succesfully decrypts a message
which has a flag set requesting a message receipt, it could mail back a
secure receipt packet which would look something like the following
(this is just a very first draft, based on the current Signature
packet):

Header: We would need to choose a new packet ID number
Version number = 4
Length of following material included in MD calculation
|Signature classification
|Timestamp
|Some identification of the message receipt is for (e.g.
<[email-masked]> as given in the Message-ID: field of a
message). This could be flexible to allow for receipts for data
transferred using other protocols.
|Message digest algorithm
|Digest of message receipt is for
Key ID for key used for signing
Public-key cryptosystem type
Message digest algorithm
First two bytes of MD output as checksum
Signed digest of fields above marked with |

Does this sound feasible/desirable? If so, maybe this could go in the
second draft? I know we want to get the standard out ASAP, but this is
quite a simple and isolated proposal which shouldn't be too difficult to
add in...

Ian.

Date: Thu, 16 Oct 1997 19:03:54 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: PGP Inc apology deal (Re: anti-GAK design principles: worked example #1)
Sender: [email-masked]

To reply to Jon Callas request for an apology for my rudeness, I'll
offer a deal:

- If I am unable to show you how to improve the GR (GAK resistance)
  property of a fully viable, implementable email security system within
  your choice of user requirement, ergonomic, and typical corporate
  environments restrictions, I will publically apologize for being
  rude, and for wasting your time.

- However, in return: if I am succesful in proving to PGP Inc that they
  can improve the GR property of an email security system within their
  requirements, I _don't_ want an apology.

  I want something much more interesting: 

	I want PGP Inc to implement and deploy it.

- The group which will judge this process is PGP Inc.

Do we have a deal?

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: Adam Back <[email-masked]>
Date: Thu, 16 Oct 97 19:10:42 BST
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: PGP Inc apology deal
Sender: [email-masked]

To reply to Jon Callas request for an apology for my rudeness, I'll
offer a deal:

- If I am unable to show you how to improve the GR (GAK resistance)
  of a system with a similar set of recovery properties to the CMR
  system; which replacement design is vialble to use in a typical
  corporate environment I will publically apologize for being rude,
  and for wasting your time.

- If I am able to show you how to improve the GR (GAK resistance)
  of a system with a similar set of recovery properties to the CMR
  system which replacement design is vialble to use in a typical
  corporate environment, I _don't_ want an apology.

  I want something much more interesting: 

	I want PGP Inc to implement and deploy it.

- The group which will judge this process is PGP Inc.

Do we have a deal?

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, 16 Oct 1997 18:58:39 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: PGP Inc apology deal (was Re: anti-GAK design principles: worked example #1)
Sender: [email-masked]

To reply to Jon Callas request for an apology for my rudeness, I'll
offer a deal:

- If I am unable to show you how to improve the GR (GAK resistance)
  property of a fully viable, implementable email security system within
  your choice of user requirement, ergonomic, and typical corporate
  environments restrictions, I will publically apologize for being
  rude, and for wasting your time.

- However, in return: if I am succesful in proving to PGP Inc that they
  can improve the GR property of an email security system within their
  requirements, I _don't_ want an apology.  

  I want something much more interesting: 

	I want PGP Inc to implement and deploy it.

- The group which will judge this process is PGP Inc.

Do we have a deal?

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, 16 Oct 1997 10:40:56 -0700
To: [email-masked], Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Praise the Lord! / Re: anti-GAK design principles: worked example #1
Cc: Adam Back <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 03:39 AM 10/16/97 -0600, TruthMonger wrote:

     I could be wrong, *but*:
     With PGP 5.0, I found that if someone sent me a message that
   was encrypted to someone else, I would get a message telling me
   that I didn't have the proper key, but would not tell me who the
   message *was* encrypted to.

You're right, that was in PGP 5.0. It sucked. It's fixed in 5.5. 5.5 shows
you a nice little box on every message showing you who it is encrypted to.

	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, 16 Oct 1997 16:58:00 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: IETF OpenPGP <[email-masked]>
Subject: Secure receipts
Sender: [email-masked]

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

Something which has been mentioned over the last few days, which I also
think would be enormously useful, is the possibility to do secure
message receipts. When an OpenPGP client succesfully decrypts a message
which has a flag set requesting a message receipt, it could mail back a
secure receipt packet which would look something like the following
(this is just a very first draft, based on the current Signature
packet):

Header: We would need to choose a new packet ID number
Version number = 4
Length of following material included in MD calculation
|Signature classification
|Timestamp
|Some identification of the message receipt is for (e.g.
<[email-masked]> as given in the Message-ID: field of a
message). This could be flexible to allow for receipts for data
transferred using other protocols.
|Message digest algorithm
|Digest of message receipt is for
Key ID for key used for signing
Public-key cryptosystem type
Message digest algorithm
First two bytes of MD output as checksum
Signed digest of fields above marked with |

Does this sound feasible/desirable? If so, maybe this could go in the
second draft? I know we want to get the standard out ASAP, but this is
quite a simple and isolated proposal which shouldn't be too difficult to
add in...

Ian.

Date: Thu, 16 Oct 1997 14:39:16 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: re. GAK resistant design principles: worked example #1
Sender: [email-masked]

Kent Crispin has a tenacious ability to continue to think logically
and critically, and not be drawn into emotional exchanges in the face
of jibes and hostilities (I am referring to previous unpleasantaries
on cypherpunks).  I think we all could take a leaf out of his book.  I
am going to attempt to myself from this point on in the CMR vs CDR
argument.  (I accept Jon Callas comments along similar lines.)

Kent Crispin <[email-masked]> writes:
> On Wed, Oct 15, 1997 at 11:45:01PM +0100, Adam Back wrote:
> > 
> > 
> > Part of the problem in this debate I think is that I have proposed
> > many alternate designs, with varying degrees of GAK-hostility.
> > 
> > Also I have been accused of using "lots of anti GAK rhetoric, but
> > giving no proposals" by Kent.
> 
> Adam, you've tossed out half-baked ideas buried in several thousand
> lines of anti-GAK rant.  None of them were thought through in terms of
> infrastructure impact.  

I have resolved to repent my ways with regard to unconstructive
ranting and rudeness.  This should have the positive side effect of
reducing the length of my posts, and ensuring that more people read
them critically.

That the ideas seemed initially fuzzy is a reflection of the fact that
I have, as I presume others have also, been gradually improving my
understanding of these complex issues.

I found the exercise in attempting to codify what I consider to be
optimal design decisions from the point of view of maximising the GAK
resistance properties of protocol designs, software implementations
and communications standards useful in clarifying my thoughts.

I feel confident in my ability to demonstrate that my GR (GAK
resistant) design principles can be usefully applied to increase the
GAK resistance of the design of systems using confidentiality and
communicatons.

I will comment on your specific comments on this aspect below.

> The idea of reencrypting the data strikes me as half-baked, as well
> -- I sit and wonder about the pass-phrase handling for the transient
> encryption keys that are changing on a daily or weekly basis -- or
> is there no pass-phrase -- is the key just stored on disk with no
> protection

Your suggestion that the re-encryption construct is weak from a GAK
resistancy (GR) perspective is correct.  See my earlier comments on
realising the danger of that construct.

> > I reject that claim.  (I did use lots
> > of rhetoric, but this was to try to impress upon those arguing for CMR
> > of it's dangers.  They do not seem to acknowledge them.)
> 
> The evidence seems to suggest that the PGP folks agonized pretty 
> heavily over their design.  A stupid attack such as yours is far more 
> likely to cement resistance than it is likely to win cooperation.

I am forced to agree that emotional attacks are likely to hinder
cooperation.  Therefore emotional attacks on this topic are themselves
likely to be counter to global GR optimisation.  It is for this reason
that I will attempt from this point on in this discussion to swallow
my anger unless I can justify outbursts in terms of GR optimisation.
Readers are encouraged to remind me if I start slipping.

I can only offer as an excuse that it seems to me that PGP Inc could
be doing more to increase the GAK resistance of their product and
design within the financial and user requirement constraints they
face.  Emotional appeals are as you say is not likely to be the best
means to explain this belief.

I also offer as a mild excuse that in carrying out interactive list
discussions with people in the US who are on GMT-8 that my sleep
deprivation may have been showing through in irritability :-) I found
myself for instance going to bed at 8.30 am the other night.

> > I'll try in
> > this post to steer clear of anti-GAK rhetoric.  We'll instead take it
> > as a given that pgp5.5 and pgp5.0 are GAK compliant because of CMR and
> > that this is a bad thing.
> 
> Trying real hard...

Allow me to rephrase that in the light of my GR maximisation motivated
apparent character reform:

I believe that PGP Inc could make their design more resistant to GAK. 

The reason I believe that PGP Inc has thus far arrived at different
design conclusions than I, Bruce Schneier, Tim May, Ian Brown, and
others, is that PGP Inc have differently prioritised the multiple
desirable properties of a socially progressive crypto design.

Desirable properties are in prioritsed order of importance as I see
them:

1. preventing big brotherish governments enforcing GAK
2. discouraging little brotherish business practices
3. encouraging transparency of intent (marking keys with statements of
   intent on handling of plaintext)
4. application ergonomics

I think that PGP Inc has transposed criteria 1 and 2 in their
prioritisation.  I believe PGP Inc's design decisions and
recommendations to companies reflect honest attempts to discourage
little brother, and their use of statement of intent technology
demonstrates their commitment to preventing big brother.  But I fear
that their prioritisation reduces the big brother resistance of their
CMR system because this resistance has been traded off to attempt to 
provide little brother resistance.

If I understand correctly several PGP employees have claimed that you
should attempt to enforce the statement of intent principle with
protocol modifications.  Whilst statement of intent is useful, and a
good innovation which I applaud, criteria 1 and 2 should take
precedence where protocol modifications which are thought to
strengthen statement of intent have a side effect of reducing GAK
resistance.

Independently I think that it is not semantically useful to try to
enforce statement of intent at the protocol level with the CMR method.
This is because having an enforced second recipient in no way
guarantees that the second recipient will read the message, or is able
to read the message (the second recipient might not receive the
ciphertext, or he might have lost the company access key).

> > Will is correct on one point: at the begining I had not properly
> > thought one aspect through:
> 
> I suspect there are several other flaws you are now quite aware 
> of...too bad, I hoped you had something.

I believe that using the GAK resistant design principles allows one to
focus more clearly on the benefits of the various trade-offs possible
and to more acurately prioritise the multiple social criteria.

> > Design 1.
> > 
> > Instructions:
> > 
> > - scrap the CMR key extension
> > 
> > - store a copy of the private half of the users PGP encryption key
> >   encrypted to the company data recovery key on the users disk.
> 
> I work for a large organization, I have a unix workstation, an
> xterminal booting off a departmental server, and a Mac in my office. 
> As is typical in large organizations, a system admin team takes care
> of all routine administration of my systems.  They all have root, of
> course, and routinely do system upgrades and software installs on my
> Mac.

Sounds like a good example to base discussions upon: X-terminals,
multi user unix work stations and remotely configurable PCs.

> Your solution doesn't seem to fit this environment very well...

I would take your point there to be that you can't store the recovery
key on the local disk for the reason that the disk isn't local, and
that when the recovery key is stored on the local disk on remotely
administered or multi-user workstations that this is less secure.

I agree.  It is less secure.

(I have htmlized, and attempted to more clearly re-word the GR design
principles:

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

I have also added a fourth corollary which you might like to comment
on (it's not relevant to the above point).)

To return to your criticisms based on the mish-mash of shared user and
X-terminals typical of corporate environments, corollary 2 expresses
the best that can be done in this scenario:

> Corollary 2: where communications are transmitted in ways which
> violate principles 1, 2 or 3 it is in general more GAK resistant to
> enforce as far as possible that the recovery or escrow information
> remains in as close proximity to the data as possible, and as much
> under the control of the user as possible.

So if you are using an X-terminal, your passphrase will be going over
the ethernet, and all the files will be on a unix box.  About all you
can do about this to minimise security problems is to try to secure
your ethernet with IPSEC technology.  This is not currently very
widely deployed especially for intranet use.

Certainly if you are using your X-terminal to connect to machines over
the internet many companies have taken steps to reduce the dangers of
this.  VPN systems, and SSH achieve this kind of thing.  IPSEC and VPN
technology are typically fairly GAK resistant anyway, because use of
forward secrecy is common.

The overall system is _still_ more GAK resistant than CMR for the
sorts of logistical reasons that Tim May has been describing.  You may
like to comment on this claim which I am willing to defend.

> > Recovery method:
> > 
> > Custodian of recovery key inserts recovery floppy disk in machine,
> > decrypts copy of users private key, hands control back to user to
> > choose new passphrase.
> 
> Must be a very special boot floppy, of course, otherwise I just 
> subvert the floppy driver, feign forgetting my passphrase, and 
> collect the corporate crown jewels.  Or I hack into somebody else's 
> system and corrupt their key...

You can hack around it, and this is implicitly acknowledged.  The
point is that in trying to design the system so that it must be hacked
around before allowing easy use in a mandatory GAK setting you have
built in extra GAK resistance in the form of the deployment and
logistical problems the government will have in developing, and
deploying patches and making sure every one applies them.

> [...]
> > 
> > - what is stopping you implementing this
> 
> It's completely unrealistic.

It was stated in it's simplest possible form for clarity.

It is however possible to build resistance into the system in the form
of inertia of the deployed code base in not providing automated ways
to access the recovery information outside of the software package.

Bill Stewart came up with the very good suggestion for example that
you only keep some of the bits of the recovery key to ensure that
recovery appears is artificially made time consuming.  This means that
with out replacing your software base, the government has a much
harder time installing GAK.  This also has the social benefit of
discouraging companies from using what are intended to be data
recovery features as snooping features.  This is exactly the sort of
lateral thinking that I am hoping to encourage.

> > - are there any plug ins which can't cope with this
> > - are there user requirements which it can't meet
> > - is there some fundamental flaw you think I have missed
> > - can you see ways that this could be perverted to implement GAK
> >   (yes I can too, btw, but...)
> > - are those ways logisitically harder for GAKkers to acheive than for CMR
> > 
> > Please be specific, no general waffle about understanding the
> > complexities of balancing user ergonomics, user requirements etc.
> 
> Unfortunately, for real products you do have to consider these 
> factors. 

I fully agree that you have to acknowledge user ergonomics and user
requirements.  What I was asking was that people in criticising my GR
design principles explain which user requirements they think can not
be met, or which user ergonomics features are hindered.  I also
explicitly state in design principle 4 that you should balance these
considerations to maximise the global GAK resistance of the deployed
software and hardware in the target jurisdiction.

> > principle 3:
> >    communications should be encrypted to the minimum number of
> >    recipients (typically one), and those keys should have as short a
> >    life time as is practically possible
> 
> Key lifetime is a major issue.  Keys are either protected by 
> pass-phrase, or vulnerable.  Think about how you are going to 
> generate new keys every day, or every week...

Perhaps if I give some examples of how some one designing a protocol
according to these principles might proceed in this direction it would
be clearer how to minimise the impact on ergonomics without losing
security to the extent that it allows government access simply as a
property of the induced weakness.  (In otherwords I am willing to
trade security for extra GAK resistance if it comes to it, but
typically does not seem to be required as GR design principles 1, 2,
and 3 are independently sound security objectives).

Companies would protect all keys by password, or by smart card token,
or by secured facilities or just by the nature of it being sufficient
for their security requirements to rely on the same weak physical
security which protects their paper files.

So: the signature key does not have recovery information -- I think
this is agreed by all.  The storage key used in encrypting information
on your disk is has recovery information stored as described.  The
shorter lived forward secret keys could be also recovery protected
(during their lifetime).  PGP 5.x already has this feature.  Consider
the encryption keys to be your forward secret keys.  Give them shorter
than normal expiry dates.

Your next comment is very pertinent in demonstrating the sorts of
problems you must work around in attempting to maximise use of forward
secrecy.

> Think about off-line composition of email -- I have a laptop, download
> my mail from the pop server, compose email.  Now I can't store my
> friends public keys on my disk, because they expire every day.  So I
> have to go to the public keyserver for every correspondent's public
> key -- if the keyserver is unaccessible I'm out of luck.  This
> radically changes the expected semantics of email.

I have 2 comments on this problem:

Consider: a system which automatically adapts and is forward secret
when it is able but not when it is not possible is more GAK resistant
than one which never uses forward secrecy at all because of the
existance of some situations where it is difficult to use.

Consider also: a system which is relatively forward secret (perhaps
with key updates every week, or month) is more GAK resistant than one
which makes no frequent key recommendations and leaving people to
choose long expiries of 1 year or with user no comments made on the
dangers of not having expiries at all is more dangerous.

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, 16 Oct 1997 03:39:37 -0600
From: TruthMonger <[email-masked]>
Reply-To: [email-masked]
Organization: "It's not FUD until *I* say it's FUD!"
To: Jon Callas <[email-masked]>
CC: Adam Back <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Praise the Lord! / Re: anti-GAK design principles: worked example #1
Sender: [email-masked]

Jon Callas wrote:
> At 11:45 PM 10/15/97 +0100, Adam Back wrote:
 
> Okay, Adam, I'll be civil here, but here's something I want to note:
> 
> You've ranted, raved, politicized, propagandized, given ad hominem attacks,
> and stated the opinion that anyone who disagrees with you is evil. You've
> sent flames to our internal development lists, which is at least impolite.
> Yet you say, "constructive criticism only." Sure. I'd like an apology from
> you, though. Deal?

  Praise the Lord!
  The CypherPunks mailing list dialogue re: CMR/PGP is CypherPissing at
its finest.

  As a cryptographer, I am pretty much a carpetbagging pretender, but,
up to now, I have managed to fool quite a number of people into thinking
that I may understand the issues involved in privacy, security and
encryption.

  Now that the shit has seriously hit the fan, however, I find that I
am completely clueless as to the true import of the latest developments
which will decide the future of encryption. (And I suspect that I am
not alone in this.)
  I believe that my philosophical viewpoints of encryption issues are
valid in many ways (and probably irrelevant in other ways), but the
current nadir point in encryption development is one in which there is
no possibility of many of us making sound decisions as to what position
we should ethically take, unless those who truly have a solid grounding
in the underlying technology manage to accurately explain the issues
involved to those of us who *don't* dream in algorithms.

  I am extremely pleased with Adam Back's in-your-face, "I'm from
Missouri...show me!" attitude, since I think that this issue is
important enough that no one should give an inch of ground until
their philosophical opponents have given them valid cause for doing
so. I am also pleased that Adam is honestly and openly asking for
those who *can* 'show' him, to do so.
  I am also every bit as interested in hearing and learning from the
position that Jon Callas is taking, based upon his own knowledge of
what CMR/PGP is, and is not.

  I honestly do not care in the least whether Adam and Jon are 'both
right', whether they are both 'half-right', or none of the above.
  What I *do* care about is that they both honestly state their case
to the extent that I have enough information to make my own decision
as to what future course of action I should take on these issues.

  My depth of concern in this matter springs from the following:
I care...and I act. As a result, my actions have effects, for which
I consider myself responsible.
  I truly believe that abortion results in the extinguishing/murder
of a divine spark of human/spiritual life energy. Yet I risked my
life and my freedom, helping my sister smuggle home-abortion 
literature into a predominantly Catholic country behind the Iron
Curtain. Why? Because it is not up to me to make the decisions
for *everyone*, and I do not believe that it is in the interest
of humanity to have *two* spirits die because those who choose
to do home abortions do not have access to information that will
preserve their life.
  The 'Right To Life' faction will publish *their* statistics and
opinions, as will the 'Pro Choice' faction, but I refuse to take
the easy way out and convince myself that I can flip a coin to
decide which faction will bear the responsibility for *my* own
decision in the matter.

  The coming developments in information technology will undoubtably
make George Orwell look like an optomist.
  We have to make our decisions without having the benefit of hindsight
that history affords us. If Hitler had indeed only wanted 'Austria', 
then the concessions that world leaders of the time made might have
proven to have saved many needless deaths. History has proven this to
be wrong, but those of us who did not live through that time would have
a difficult time divining who was 'honestly wrong' and who 'sold out.'

  How many guilty men should go free in order to guarantee that a single
innocent man is not imprisoned?
  My answer: "More than one, less than a million." (ymmv)

> Fair-warning. In my first missive, I talked about my own principles, and
> one of them is the "fair-warning" principle. It states that users should
> know what is going on. If you have a key that is used in this system, there
> is nothing in it that tells me that your company can read a message I send
> you. I see this as a flaw, and one that I consider to be a *very* big deal.
> Full disclosure is one of my hot buttons.

  I could be wrong, *but*:
  With PGP 5.0, I found that if someone sent me a message that
was encrypted to someone else, I would get a message telling me
that I didn't have the proper key, but would not tell me who the
message *was* encrypted to.
  I could drop into PGP 2.6.2 and get a message saying (paraphrased),
"Encrypted to John Doe <[email-masked]>, you don't have that key."
(OK, *badly* paraphrased.)

  With PGP 2.6.2, I routinely used a bogus password in my first pass at
decyphering messages, so that I could find out who all the message was
encrypted to. It makes me nervous that one has to 'make a mistake' in
order to get 'the rest of the story', rather than automatically be
informed when a message is also encrypted to others.

  Also, as a 'teaser', I would like to announce to one and all that
the quickly closing saga of 'InfoWar' will include an epilogue
chapter titled, "I Broke PGP," written by myself.
  Believe it or not, I speak the truth, although not in a way that
it direct and obvious.
  If you think I am bullshiting, then stop washing your asshole,
starting today, because if you can show me I am wrong, I will kiss
your ugly, hairy ass.

Love and Kisses,
TruthMangler

Date: Thu, 16 Oct 1997 08:11:28 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: anti-GAK design principles: worked example #1
Sender: [email-masked]

Gene Hoffman <[email-masked]> writes:
> On Wed, 15 Oct 1997, Adam Back wrote:
> 
> > 
> > - store a copy of the private half of the users PGP encryption key
> >   encrypted to the company data recovery key on the users disk.
> > 
> 
> You would rather have PGP implement private key escrow?

Yes.  

This is less GAK friendly than the way that PGP are implementing CMR.

In worked example #2 and I might do a #3 as well, I will as promised
show you how to apply the design principles to achieve greater
GAK-hostility than example #1 which you are objected to above.

However, in the mean time, I would like you and other PGPers to
re-read my post and answer the questions contained in it:

> - can you see ways that this could be perverted to implement GAK
>   (yes I can too, btw, but...)
> - are those ways logisitically harder for GAKkers to acheive than for CMR

You appear to claim that your answer to the second question is no.

I would like to see you explain your reasoning for why this is so.

You may find it constructive to re-read some of Tim May's recent posts
as he explains the logic of this fairly clearly.  Tim May does not
need the anti-GAK design principles to think in an critical
GAK-hostile way.

PGP Inc does appear to need them because their design principles are
currently at best GAK-neutral, and appear to be largely based on
wooly, ill thought-out pro-privacy / liberal thinking.

You have to think in a crypto-anarchist, saboteur mindset to maximise
your ability to prevent mandatory GAK becoming reality.  The anti-GAK
design principles are a codification of the crypto-anarchist GAK
saboteur's natural predilections to want to prevent the GAKkers.

I have in waiting some other design principles which codify more
general crypto-anarchist design principles.  I will not be adding
these to the anti-GAK design principles at this stage for fear of
confusing the first issue: how to best prevent GAK occuring in our and
other countries.

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: Ben Escoto <[email-masked]>
To: IETF Open-PGP List <[email-masked]>
Subject: Re: PGP/MIME Partial compliance test 
Date: Thu, 16 Oct 1997 00:10:00 -0700
Sender: [email-masked]

--=_Mapil-0.1b_839625641

>>>>> "AG" == Anthony E Greene <[email-masked]>
>>>>> wrote the following on Thu, 16 Oct 1997 03:12:47 +0200

  >> Because PGP 5.0 can't seem report whether or not it is using the
  >> MD5 or SHA1 hash, my PGP/MIME program can't provide that
  >> information in the Content-Type header without maintaining a
  >> database of keys or something awkward like that.

  AG> What about the hash lengths?

	Hmm, I noticed that md5 signatures always seemed to be longer.
Is this reliable?  Perhaps I could just check the PGP signature output
file and if it is longer than xx bytes I could call it MD5?

--
Ben Escoto
PGP/MIME mail welcome - finger [email-masked] for key

--=_Mapil-0.1b_839625641
Content-Type: application/pgp-signature

--=_Mapil-0.1b_839625641--

Date: Thu, 16 Oct 1997 03:12:47 +0200
To: IETF Open-PGP List <[email-masked]>
From: "Anthony E. Greene" <[email-masked]>
Subject: Re: PGP/MIME Partial compliance test
Sender: [email-masked]

At 17:56 1997-10-15 -0700, Ben Escoto wrote:
>	Because PGP 5.0 can't seem report whether or not it is using
>the MD5 or SHA1 hash, my PGP/MIME program can't provide that
>information in the Content-Type header without maintaining a database
>of keys or something awkward like that.

What about the hash lengths?

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

From: Ben Escoto <[email-masked]>
To: [email-masked]
Subject: PGP/MIME test, addendum
Date: Wed, 15 Oct 1997 23:19:49 -0700
Sender: [email-masked]

--=_Mapil-0.1b_3179510717

	Sorry, I forgot to mention in my previous message that the key
I signed with was a DSS key and not the one available by fingering
[email-masked].  It is available from the keyservers, and
I am also sticking it in this message.  Sorry for any confusion.
Also, this message is totally compliant, so give me feedback on the
last one, not this one.  Thanks.

--
Ben Escoto
PGP/MIME mail welcome - finger [email-masked] for key

--=_Mapil-0.1b_3179510717
Content-Type: application/pgp-signature

--=_Mapil-0.1b_3179510717--

Date: Wed, 15 Oct 1997 20:35:09 -0700
From: Kent Crispin <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: anti-GAK design principles: worked example #1
Sender: [email-masked]

On Wed, Oct 15, 1997 at 11:45:01PM +0100, Adam Back wrote:
> 
> 
> Part of the problem in this debate I think is that I have proposed
> many alternate designs, with varying degrees of GAK-hostility.
> 
> Also I have been accused of using "lots of anti GAK rhetoric, but
> giving no proposals" by Kent.

Adam, you've tossed out half-baked ideas buried in several thousand
lines of anti-GAK rant.  None of them were thought through in terms of
infrastructure impact.  The idea of reencrypting the data strikes me
as half-baked, as well -- I sit and wonder about the pass-phrase
handling for the transient encryption keys that are changing on a daily 
or weekly basis -- or is there no pass-phrase -- is the key just 
stored on disk with no protection

> I reject that claim.  (I did use lots
> of rhetoric, but this was to try to impress upon those arguing for CMR
> of it's dangers.  They do not seem to acknowledge them.)

The evidence seems to suggest that the PGP folks agonized pretty 
heavily over their design.  A stupid attack such as yours is far more 
likely to cement resistance than it is likely to win cooperation.

> I'll try in
> this post to steer clear of anti-GAK rhetoric.  We'll instead take it
> as a given that pgp5.5 and pgp5.0 are GAK compliant because of CMR and
> that this is a bad thing.

Trying real hard...

> Will is correct on one point: at the begining I had not properly
> thought one aspect through:

I suspect there are several other flaws you are now quite aware 
of...too bad, I hoped you had something.

[...]

> Design 1.
> 
> Instructions:
> 
> - scrap the CMR key extension
> 
> - store a copy of the private half of the users PGP encryption key
>   encrypted to the company data recovery key on the users disk.

I work for a large organization, I have a unix workstation, an
xterminal booting off a departmental server, and a Mac in my office. 
As is typical in large organizations, a system admin team takes care
of all routine administration of my systems.  They all have root, of
course, and routinely do system upgrades and software installs on my
Mac.

Your solution doesn't seem to fit this environment very well...
[...]

> Recovery method:
> 
> Custodian of recovery key inserts recovery floppy disk in machine,
> decrypts copy of users private key, hands control back to user to
> choose new passphrase.

Must be a very special boot floppy, of course, otherwise I just 
subvert the floppy driver, feign forgetting my passphrase, and 
collect the corporate crown jewels.  Or I hack into somebody else's 
system and corrupt their key...

[...]
> 
> - what is stopping you implementing this

It's completely unrealistic.

> - are there any plug ins which can't cope with this
> - are there user requirements which it can't meet
> - is there some fundamental flaw you think I have missed
> - can you see ways that this could be perverted to implement GAK
>   (yes I can too, btw, but...)
> - are those ways logisitically harder for GAKkers to acheive than for CMR
> 
> Please be specific, no general waffle about understanding the
> complexities of balancing user ergonomics, user requirements etc.

Unfortunately, for real products you do have to consider these 
factors. 

[...]
> 
> Adam
> 
> [1]
> ==============================8<==============================
> GAK-hostile design principles
> 
> If we take the design goal of designing systems including
> confidentiality which are not GAK compliant, we can most succinctly
> state this design goal as the task of ensuring that:
> 
> - at no point will any data transferred over communications links be
>   accessible to anyone other than the sender and recipient without
>   also obtaining data on the recipient and/or senders disks

This is great. 

> We can then derive the design principles required to meet the design
> goal of a non-GAK compliant system with confidentiality services down
> to ensuring that:
> 
> principle 1:
>    no keys used to secure communications in any part of the system are
>    a-priori escrowed with third parties
> 
> principle 2:
>    second crypto recipients on encrypted communications are not
>    used to allow access to third parties who are not messaging
>    recipients manually selected by the sender
> 
> principle 3:
>    communications should be encrypted to the minimum number of
>    recipients (typically one), and those keys should have as short a
>    life time as is practically possible

Key lifetime is a major issue.  Keys are either protected by 
pass-phrase, or vulnerable.  Think about how you are going to 
generate new keys every day, or every week...

Think about off-line composition of email -- I have a laptop, download
my mail from the pop server, compose email.  Now I can't store my
friends public keys on my disk, because they expire every day.  So I
have to go to the public keyserver for every correspondent's public
key -- if the keyserver is unaccessible I'm out of luck.  This
radically changes the expected semantics of email. 

-- 
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: Wed, 15 Oct 1997 19:00:21 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: anti-GAK design principles: worked example #1
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 11:45 PM 10/15/97 +0100, Adam Back wrote:

Okay, Adam, I'll be civil here, but here's something I want to note:

You've ranted, raved, politicized, propagandized, given ad hominem attacks,
and stated the opinion that anyone who disagrees with you is evil. You've
sent flames to our internal development lists, which is at least impolite.
Yet you say, "constructive criticism only." Sure. I'd like an apology from
you, though. Deal?

   
>   Also I have been accused of using "lots of anti GAK rhetoric, but
>   giving no proposals" by Kent.  I reject that claim.  (I did use lots
>   of rhetoric, but this was to try to impress upon those arguing for CMR
>   of it's dangers.  They do not seem to acknowledge them.) I'll try in
>   this post to steer clear of anti-GAK rhetoric.  We'll instead take it
>   as a given that pgp5.5 and pgp5.0 are GAK compliant because of CMR and
>   that this is a bad thing.

Uh huh. Steer clear of rhetoric, but we'll take it as a given that you're
right and everyone else is wrong. At least this is a de-escalation.
   
>   Design 1.
>   
>   Instructions:
>   
>   - scrap the CMR key extension
>   
>   - store a copy of the private half of the users PGP encryption key
>     encrypted to the company data recovery key on the users disk.

Okay -- constructive criticism only. I sincerely hope I'm reading this
correctly. You're saying that someone's private key should be encrypted to
the corporation's key. This sounds like key escrow to me. How does this
differ from the overly strict, nit-picking, freedom-threatening definition
that I gave? 

This is better than the throw-the-floppy-in-the-safe model in that the
company-readable version of your key is sitting on your machine. That's good. 

I see a threat here that if the corporation backs up my disk, they they
have my secret key and thus can read all files that key has ever encrypted.
This is bad. Normally, if they back up my system, they have my secret key,
but they have to hack my secret key. Most people's passphrases are easier
to crack than a public key, but I think this is worse.

With this system, the corporation can read everything I encrypt with that
key, because they effectively own it. Encrypting my secret key to them
essentially gives it to them. With CMR, I have the option of making some
files readable, and some not. This isn't necessarily a good thing -- some
companies want access to all data, and your proposal helps them.

I'm actually very surprised by this design of yours. On the scale of
property-balanced-with-privacy, you've come down hard on the side of
property. Your system makes it so that an employee of a company can *never*
use this key for a purpose the company can't snoop on. This isn't
necessarily bad, I think that people *should* have separate keys for work
and personal use. This just makes the work key definitely the work key. A
number of our customers will like that.
   
>   - (optional) design the software to make it hard to copy the data
>     recovery packet from the disk, hide the data, bury it in keyrings,
>     stego encode it, whatever, use your imagination.  This is to attempt
>     to restrict the third parties ability to by pass the principle of
>     non communication of recovery information
   
This is security through obscurity. We publish our source code, so this
won't work.
   
>   Recovery method:
>   
>   Custodian of recovery key inserts recovery floppy disk in machine,
>   decrypts copy of users private key, hands control back to user to
>   choose new passphrase.

Choosing a new passphrase is not sufficent. If the custodian ever uses that
key, it *must* be revoked, a new encryption key issued, and all data
encrypted with it re-encrypted. There is also the problem of
re-distributing the revocation and new encryption key to all the people who
have your old one. This is no worse than any other revocation problem, but
CMR does not require revoking the user's key.   
   
>   Possible objections:
>   
>   objection #1. what if disk burns?
>   counter #1:   backup your disk
>   
>   objection #2: users don't back up disks
>   counter #2:   that is a good way to loose data :-) if they don't have
>                 the data the key protecting the data won't help them

This is no different with CMR. One of the design goals of CMR is to avoid
the myriad logistic and security problems associated with data archival.
   
>   GAK-hostility rating:
>   
>   Harder to pervert for GAK than pgp5.5 / pgp5.0 CMR design.

Why? With your mechanism, if the G manages to A the K, then they can
decrypt every message that key has ever encrypted. I think this is a design
flaw. 

>   I'd be interested to see Will, or Hal, or other PGPer's criticisms of this
>   simple modification, perhaps criticisms could most constructively answer:
>   
>   - what is stopping you implementing this
>   - are there any plug ins which can't cope with this
>   - are there user requirements which it can't meet
>   - is there some fundamental flaw you think I have missed
>   - can you see ways that this could be perverted to implement GAK
>     (yes I can too, btw, but...)
>   - are those ways logisitically harder for GAKkers to acheive than for CMR
>   
>   Please be specific, no general waffle about understanding the
>   complexities of balancing user ergonomics, user requirements etc.
>   That is a no-brainer, you need to do this analysis, the cost function
>   for evaluating such design issus is now expressed explicitly in design
>   principle 4 rather than being assumed.  List problems and explain the
>   significance of the all important deployability criteria.
>   
>   Cryptographic protocol designs are very flexible; most design goals can
>   be met, or worked around I claim within the positive GAK-hostility
>   side of the cryptographic protocol and product design solution space.
>   
>   Lastly, I would encourage readers to be critical of the GAK-hostile design
>   principles themselves:
>   
>   - can you see any aspects which inaccurately reflect trade-offs
>   - can you see methods to bypass inadvertently or deliberately the design 
>     that might require another corollary to correct.
>   
>   In anticipation of constructive criticism,

Okay, general observations:

I'm really surprised at this. In the continuum between privacy and
property, you've come down hard on the side of property. You've said that a
key owned by a corporation is *fully* owned by the corporation, and any
employee who uses it for personal purposes is daft. This is not what I
expected you to be arguing.

Enforcement. Most corporations want some level of enforcement on their
policies. The enforcement we put in isn't fool-proof, but it's far easier
to comply than resist. This is a design goal. I have a concern that the
only enforcement that the corporation has is to take your private key. If
this is their only way to make you follow their rules, they'll do it. Many
of them will play nice if possible, but hardball if they have to.

Fair-warning. In my first missive, I talked about my own principles, and
one of them is the "fair-warning" principle. It states that users should
know what is going on. If you have a key that is used in this system, there
is nothing in it that tells me that your company can read a message I send
you. I see this as a flaw, and one that I consider to be a *very* big deal.
Full disclosure is one of my hot buttons.

I think this is breaks a number of your principles.

Principle 1: The end-user's keys *are* escrowed with the company. If my
disk is ever backed up, then the corporation has my secret key. In order to
keep it from being implicitly escrowed, I have to put it someplace like
off-line media that can be gotten to if I'm hit by a bus. If you disagree,
please tell me how this is different from escrow.

Principle 2: The corporation is always a tacit crypto-recipient. It's no
different than CMR, and has the additional disadvantage that senders don't
know that the implicit receivers are there.

Principle 3: Again, the corporation is a tacit recipient in *all* uses of
the key. With CMR, they are an explicit recipient, and it's possible to
exclude them. There's no way to exclude the corporation here.

Principle 4: I don't see how this differs between your proposal and CMR.

Lastly, I here's a summation of what I think.

I think it's an interesting proposal. You're much more of a
corporate-control proponent than I am. I think control and privacy have to
be balanced, whereas you obviously think corporate control is trump. We
disagree there.

I am uncomfortable at the ease with which the end user can lose their key.
The end user must somehow prevent the employer from even so much as backing
up their computer, or it's just plain escrow.

I am uncomfortable not only with your siding with the corporation against
the employee's privacy, but also with your siding against the privacy of
someone who sends a message to the employee. Furthermore, I think that the
absence of a disclosure mechanism in your protocol is for us, a fatal flaw.
We'd never implement a system that does not have disclosure.

I do not see how your system is GAK-hostile. I think it is no more
GAK-hostile than CMR, and potentially more GAK-friendly, because it is
based around manipulating the actual secret key material. The failure mode
of CMR is that an adversary can decrypt messages, whereas the failure mode
of your proposal is that the adversary gets the key.

	Jon

   Adam
   
   [1]
   ==============================8<==============================
   GAK-hostile design principles
   
   If we take the design goal of designing systems including
   confidentiality which are not GAK compliant, we can most succinctly
   state this design goal as the task of ensuring that:
   
   - at no point will any data transferred over communications links be
     accessible to anyone other than the sender and recipient with out
     also obtaining data on the recipient and/or senders disks

   We can then derive the design principles required to meet the design
   goal of a non-GAK compliant system with confidentiality services down
   to ensuring that:
   
   principle 1:
      no keys used to secure communications in any part of the system are
      a-priori escrowed with third parties
   
   principle 2:
      second crypto recipients on encrypted communications are not
      used to allow access to third parties who are not messaging
      recipients manually selected by the sender
   
   principle 3:
      communications should be encrypted to the minimum number of
      recipients (typically one), and those keys should have as short a
      life time as is practically possible
   
   principle 4:
      deployment wins.  violating any of principles 1 to 3 whilst
      still retaining some GAK-hostility can be justified where
      deployment is thereby increased to the extent that the violations
      increase the degree of GAK hostility in the target jurisdictions
      overall
   
   Corrollary 1: Included in design principle 2) is the principle of not
   re-transmitting keys or data after decryption over communication
   channels, re-encrypted to third parties -- that is just structuring --
   and violates design principle 2.
   
   Corrollary 2: where communications are transmitted which violate
   principles 1, 2 or 3 it is in general more GAK hostile to enforce as
   far as possible that the recovery or escrow information remains in as
   close proximity to the data as possible.
   
   Corrollary 3: where communications are transmitted which violate
   principles 1, 2 or 3 it is in general more GAK hostile to make these
   communications as difficult to automate as possible.  For example no
   scripting support is given to enforce that GUI user interaction is
   required, and/or that the process is made artificially time consuming,
   and/or that the communication must not use electronic communication
   channels
   
   ==============================8<==============================

-----
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: Ben Escoto <[email-masked]>
To: [email-masked]
Subject: PGP/MIME Partial compliance test
Date: Wed, 15 Oct 1997 17:56:14 -0700
Sender: [email-masked]

--=_Mapil-0.1b_1931420379

	Because PGP 5.0 can't seem report whether or not it is using
the MD5 or SHA1 hash, my PGP/MIME program can't provide that
information in the Content-Type header without maintaining a database
of keys or something awkward like that.

	This message is not PGP/MIME compliant because the hash is
wrong.  If anyone reading this has a PGP/MIME system, please tell me
if this message is processed correctly.  If all existing mailers
process it correctly, I will just ignore the problem and wait for
better output from PGP 5.0.  Thanks.

--
Ben Escoto
PGP/MIME mail welcome - finger [email-masked] for key

--=_Mapil-0.1b_1931420379
Content-Type: application/pgp-signature

--=_Mapil-0.1b_1931420379--

From: [email-masked]
Date: Wed, 15 Oct 1997 11:38:56 -0700
To: Will Price <[email-masked]>, Adam Back <[email-masked]>, [email-masked]
Original-From: Bill Stewart <[email-masked]>
Subject: Re: proposal: commercial data recovery
Cc: [email-masked]
Sender: [email-masked]

At 02:34 AM 10/15/1997 -0700, Will Price, probably annoyed at the
flaming that PGP5.5 has received, flames out Adam Back's proposal
for not doing the right things for his perceived market.
But PGP5.5 doesn't do most of those same things either.

>First, let me state some overriding design goals of a 
>data recovery system required to ensure privacy: 
>the sender must know and consent to every key
>that will be able to read the message during its lifetime, 

As Ian and Ian have pointed out, this is bogus - 
the sender can't control the recipients' uses of the message.
At most the sender has a right to control who receives the
message _until_ the recipient gets it,
and if they don't trust the recipient, they shouldn't send it.

>the encryption must be end-to-end, and 
This is fine.

>the recipient must know exactly who else can decrypt the message.  

PGP 5.5 does not provide this; the message headers only provide KeyID
for each recipient, not the person using the keys, so the recipient
only knows those recipients whose KeyIDs he knows or can look up.
(Plus deadbeef attacks make even those suspect.)

>In your model, the recipient automatically
>decrypts and then re-encrypts to a data recovery key -- even though
>end-user computers are likely to be insecure thus making this decrypt &
>reencrypt step rather specious at best.  

Again, this is bogus - if the recipient's computer is insecure,
then the data is insecure from the moment the recipient decrypts it,
a step that even PGP5.5 does not usually prevent :-)

>As an actual data recovery system, it also fails fundamental tests.
>If I encrypt critical data to a colleague wiping it from my system 
>after sending, then the colleague is incapacitated before receipt 
>and processing of the message, the data can never be retrieved.  

Bogus.  If you send critical data to a colleague entirely in the clear,
and sendmail eats it instead if delivering it to your colleague,
or the colleague's mailbox disk drive crashes before he reads it,
and you have wiped the only copy before confirming receipt of the message, 
you lose and PGP5.5 won't help any, since neither PGP5.5 nor the
PGP SMTP filters cause extra copies to be created.
If you do this sort of thing often, you need a new definition of critical.

What you need is automated message receipts, and the decryption system 
needs to offer your recipient a user-friendly way to send receipts
when he actually reads the message.  PGP5.5 doesn't do this 
(not its job - it's an encryption program, not a mail user agent) 
and the mail client's receipts aren't enough, since they don't know 
if your recipient could decrypt the message successfully  
(nor whether they could read the language it was written in,
nor whether the contents made any sense, 
nor whether the recipient agreed with the content of the message. :-)

>I'm truly amazed that you would attack in such a spiteful fashion

If you can't tell serious concerns from spite, your ego's in the way
(you've probably been reading too many negative reviews lately. :-)
There are serious problems with the PGP5.5 approach, even though it 
does solve real business problems that some of your real customers have,
or at least think they have.

>a simple system which adds a recipient-requested, sender-approved 
>extra recipient which is end-to-end wherein all recipients are 
>under the sender's control and

Only the choice of keys is under the sender's control, 
not the knowledge of what actual _people_ hold those keys or 
what the CMRKers will do with the data, or even whether they 
have received copies unless she mails copies them directly
In the PGP SMTP filter context, if the sender must include
certain keys to get the message delivered, that's a rather 
limited definition of "under the sender's control".

> each recipient knows who can read the message with no key escrow 

As above, the recipients don't know each other unless
they happen to have each others' KeyIDs on their keyservers,
and since PGP5.5 "elegantly" doesn't indicate whether a recipient
is there because the sender wanted them or whether they're CMRKers.
Sure, if there's only one real recipient, both sender and recipient
know the eavesdroppers, but if there's more than one real recipient,
there's no way to tell.

>using the same old PGP message format we all know and love without change, 
If you count 5.0 message format as "old" :-)  And while the
CMRK fields apparently were in 5.0 key record formats, they weren't used,
and the semantics are much different even if the syntax is the same.
Treating desired recipients and undesirable recipients the same
is one approach, but it doesn't accomodate people who want
secret sharing to prevent a single CMRker from recovering the message.

>and yet you propose a much less secure system which allows hiding 
>critical information from the sender and does not adequately perform 
>its stated purpose of data recovery.
I'm not flaming Adam's proposal here; that's a job for another message :-)
In particular, it seems to be evolving, and I haven't figured it out yet,
nor am I convinced there is a way to adequately perform the purposes
of data recovery.
				Thanks!
					Bill
Bill Stewart, [email-masked]
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Wed, 15 Oct 1997 16:11:09 -0700 (PDT)
From: Gene Hoffman <[email-masked]>
To: Adam Back <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: anti-GAK design principles: worked example #1
Sender: [email-masked]

On Wed, 15 Oct 1997, Adam Back wrote:

> 
> - store a copy of the private half of the users PGP encryption key
>   encrypted to the company data recovery key on the users disk.
> 

You would rather have PGP implement private key escrow?

Gene Hoffman
PGP, Inc.

Date: Wed, 15 Oct 1997 23:45:01 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: anti-GAK design principles: worked example #1
Sender: [email-masked]

Part of the problem in this debate I think is that I have proposed
many alternate designs, with varying degrees of GAK-hostility.

Also I have been accused of using "lots of anti GAK rhetoric, but
giving no proposals" by Kent.  I reject that claim.  (I did use lots
of rhetoric, but this was to try to impress upon those arguing for CMR
of it's dangers.  They do not seem to acknowledge them.) I'll try in
this post to steer clear of anti-GAK rhetoric.  We'll instead take it
as a given that pgp5.5 and pgp5.0 are GAK compliant because of CMR and
that this is a bad thing.

Will is correct on one point: at the begining I had not properly
thought one aspect through: my earlier decrypt & re-encrypt construct
violates anti-GAK design principle 2; namely it is guilty of the same
violation as CMR, it has an effective second crypto recipient outside
of the senders control. I agree with Will Price's comments on the GAK
pervertability tendencies of this construct.  I spotted the error of
my ways since clarifying my thoughts on the subject by constructing
the more formalised anti-GAK design principles.  Readers will see my
codification of my recognition of the dangers of the re-encrypting
construct in corollary 1 of the anti-GAK design principles (copy of
principles below [1]).  The fact that I posted this corollary in
updated copies of the design principles prior to Will's post should
show that this claim is sincere and not an attempt at side stepping
Will's observation: he is correct, I agree.

The rest of Will's post seems to miss the point, so it seems to me
that the best way to transfer understanding of how to use the anti-GAK
design principles to design less GAK friendly systems is to present a
worked example.

This first simple CDR replacement for PGP's CMR method also attempts
to keep changes necessary to implementations and packet formats to a
minimum.  Please understand also that it violates one of the major
design principles in order to acheive this simplicity and so that
objections that it is not that much more valuable than CMR will be
countered by showing you how to achieve an even more GAK-hostile
design by removing the violation of design principle 3, albeit with
more coding effort and design modifications on PGP's part.  Never the
less it is already much harder to pervert for GAK than CMR.

Design 1.

Instructions:

- scrap the CMR key extension

- store a copy of the private half of the users PGP encryption key
  encrypted to the company data recovery key on the users disk.

- (optional) design the software to make it hard to copy the data
  recovery packet from the disk, hide the data, bury it in keyrings,
  stego encode it, whatever, use your imagination.  This is to attempt
  to restrict the third parties ability to by pass the principle of
  non communication of recovery information

Recovery method:

Custodian of recovery key inserts recovery floppy disk in machine,
decrypts copy of users private key, hands control back to user to
choose new passphrase.

Possible objections:

objection #1. what if disk burns?
counter #1:   backup your disk

objection #2: users don't back up disks
counter #2:   that is a good way to loose data :-) if they don't have
              the data the key protecting the data won't help them

GAK-hostility rating:

Harder to pervert for GAK than pgp5.5 / pgp5.0 CMR design.

I'd be interested to see Will, or Hal, or other PGPer's criticisms of this
simple modification, perhaps criticisms could most constructively answer:

- what is stopping you implementing this
- are there any plug ins which can't cope with this
- are there user requirements which it can't meet
- is there some fundamental flaw you think I have missed
- can you see ways that this could be perverted to implement GAK
  (yes I can too, btw, but...)
- are those ways logisitically harder for GAKkers to acheive than for CMR

Please be specific, no general waffle about understanding the
complexities of balancing user ergonomics, user requirements etc.
That is a no-brainer, you need to do this analysis, the cost function
for evaluating such design issus is now expressed explicitly in design
principle 4 rather than being assumed.  List problems and explain the
significance of the all important deployability criteria.

Cryptographic protocol designs are very flexible; most design goals can
be met, or worked around I claim within the positive GAK-hostility
side of the cryptographic protocol and product design solution space.

Lastly, I would encourage readers to be critical of the GAK-hostile design
principles themselves:

- can you see any aspects which inaccurately reflect trade-offs
- can you see methods to bypass inadvertently or deliberately the design 
  that might require another corollary to correct.

In anticipation of constructive criticism,

Adam

[1]
==============================8<==============================
GAK-hostile design principles

If we take the design goal of designing systems including
confidentiality which are not GAK compliant, we can most succinctly
state this design goal as the task of ensuring that:

- at no point will any data transferred over communications links be
  accessible to anyone other than the sender and recipient with out
  also obtaining data on the recipient and/or senders disks

We can then derive the design principles required to meet the design
goal of a non-GAK compliant system with confidentiality services down
to ensuring that:

principle 1:
   no keys used to secure communications in any part of the system are
   a-priori escrowed with third parties

principle 2:
   second crypto recipients on encrypted communications are not
   used to allow access to third parties who are not messaging
   recipients manually selected by the sender

principle 3:
   communications should be encrypted to the minimum number of
   recipients (typically one), and those keys should have as short a
   life time as is practically possible

principle 4:
   deployment wins.  violating any of principles 1 to 3 whilst
   still retaining some GAK-hostility can be justified where
   deployment is thereby increased to the extent that the violations
   increase the degree of GAK hostility in the target jurisdictions
   overall

Corrollary 1: Included in design principle 2) is the principle of not
re-transmitting keys or data after decryption over communication
channels, re-encrypted to third parties -- that is just structuring --
and violates design principle 2.

Corrollary 2: where communications are transmitted which violate
principles 1, 2 or 3 it is in general more GAK hostile to enforce as
far as possible that the recovery or escrow information remains in as
close proximity to the data as possible.

Corrollary 3: where communications are transmitted which violate
principles 1, 2 or 3 it is in general more GAK hostile to make these
communications as difficult to automate as possible.  For example no
scripting support is given to enforce that GUI user interaction is
required, and/or that the process is made artificially time consuming,
and/or that the communication must not use electronic communication
channels

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

Date: Wed, 15 Oct 1997 16:34:31 -0700
To: Will Price <[email-masked]>, Adam Back <[email-masked]>, [email-masked]
From: "Richard Johnson" <[email-masked]>
Subject: Re: proposal: commercial data recovery
Sender: [email-masked]

At 02:34 -0700 on 10/15/97, Will Price wrote:
> Adam:
> ...
> I'm truly amazed that you would attack in such a spiteful fashion a simple
> system which adds a recipient-requested, sender-approved extra recipient
> which is end-to-end wherein all recipients are under the sender's control
> and each recipient knows who can read the message with no key escrow using
> the same old PGP message format we all know and love without change, and
> yet you propose a much less secure system which allows hiding critical
> information from the sender and does not adequately perform its stated
> purpose of data recovery.

I don't see Adam's proposals as spiteful attacks.  His proposed
alternatives may or may not do the job, but I believe they are honest
attempts to provide for corporate data recovery without enabling a greater
problem.

Enforcing encryption to a 3rd-party key, in addition to the intended
recipient's key, is bad.

Doing so makes GAK easier for a government or other attacker to manage, as
they'll only have to handle thousands of corporate recovery keys, not
millions of individual keys.

Doing so also provides easy hooks to mandate such access.  In the USA, for
example, broadcast messages usually have no legal expectation of privacy.
Encrypting to a general recipient may cause messages to fall into that
category, and thus require no warrant for interception (but IANAL).

Doing so also opens up new avenues for illicit third-party snooping.  With
enforced (or merely requested) encryption to 3rd-party keys, it may be
possible, depending on the implementation, to engineer a "man-on-the-side"
attack in order to snoop on message content.  At the very least, it's
something else for an implementation to trip over.

Finally, doing so creates a higher value target key, the recovery key.  An
attacker who can, for example, social-engineer the passphrase for that key
out of an executive assistant can thus achieve a greater payoff.

For those basic reasons, I would prefer to keep open-pgp simple.  Perhaps
specify that conforming implementations must not enforce encryption of
messages to 3rd-party keys, but at the very least simply leave any kind of
specific 3rd-party key specification and enforcement out of the standard.

Richard

Date: Wed, 15 Oct 1997 11:09:22 -0700
To: Will Price <[email-masked]>, Adam Back <[email-masked]>, [email-masked]
From: "Richard Johnson" <[email-masked]>
Subject: Re: proposal: commercial data recovery
Cc: [email-masked]
Sender: [email-masked]

At 02:34 -0700 on 10/15/97, Will Price wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Adam:
> ...
> The design you have been espousing for the last week or so in your many
> messages takes the power out of the hands of the sender and encourages
> automated violations of the sender's privacy by the recipient (perhaps even
> unbeknownst to the recipient). ...

This is simply a reflection of reality.  The sender has little real control
over what the recipient actually does with any message.  If the recipient
shares the information content, the sender is basically limited to civil or
criminal sanctions after that sharing becomes evident.

Designing a standard for encrypted communications that attempts to fight
that fact will likely be wasted effort.

Richard

Date: Wed, 15 Oct 1997 16:37:04 -0400 (EDT)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: RE: Time to move on
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Then you are *really* going to hate one scenario that will represent
a likely end point:

Average (l)user has only one public key besides his/her/its/other's own -
the Post Office key. 

Messages are composed, signed, encrypted with PO key and sent with list
of recipients.

PO then retrieves key of each recipient and encrypts session key with that,
then affixes header (might also replicate each message so recipients each
receive individual message. Machs nix.)

Any of several variations would also accomodate CMR or GAK.

Why likely ? Is most brane-ded mechanism possible for corporate use and 
most people just won't care.

Not saying *I* like the idea, just that it is likely.

						Warmly,
							Padgett 

Date: Wed, 15 Oct 1997 11:46:32 -0700
To: Rick Smith <[email-masked]>, Adam Back <[email-masked]>, [email-masked]
From: Tim May <[email-masked]>
Subject: Re: Just say "No" to key recovery concerns...keep OpenPGP pure
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 12:14 PM -0700 10/15/97, Rick Smith wrote:
>While I think that a variety of robust and successful products will proably
>emerge that support various types of key recovery, I strongly agree with
>Tim on engineering grounds: Keep It Simple, Stupid.
>
>When it comes to deciding on the contents of a standard, let's keep in mind
>that we're working with a relatively new technology. We'll make more
>progress by standardizing proven concepts, and these integrated key
>recovery hacks don't have the operating history that vanilla PGP has. If
>anything, my experience with Guard keying suggests that the proposed
>mechansims aren't enough. The problem has more hair than our sheepdog.
>
>I don't think the protocol standard needs to take a political statement
>about key recovery mechanisms, but it *must* outline the protocol's
>traditional security objectives pretty much the way Tim outlined them. That
>sets the context for a robust protocol that has a successful history.

Thanks for the comments, and the support is nice, too.

As Rick notes, the whole "foobar recovery" (where foobar may be plaintext
messages or keys) technology is untested, besides being dangerous in
various ways.

It represents an escalation of complexity, both for the users and the
developers. (My message is being directed at the OpenPGP folks trying to
figure out what features to support, not to PGP, Inc., which can make its
own decisions about how to spend its engineering and marketing
resources...though I hope they are taking the reactions of many of us to
heart.)

At this stage, where governments of the world are planning to make foobar
recovery mandatory (either GAK or GAP), it's a bad time to launch an
untested and potentially dangerous technology. As others have noted,
Congress is already using PGP's support of message recovery as evidence
that industry can rise to the challenge of providing message recovery for
law enforcement.

OpenPGP needs to stick to basics. And PGP, Inc. needs to get back to basics.

--Tim May

The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

Date: Wed, 15 Oct 1997 13:14:19 -0600
To: Tim May <[email-masked]>, Adam Back <[email-masked]>, [email-masked]
From: Rick Smith <[email-masked]>
Subject: Re: Just say "No" to key recovery concerns...keep OpenPGP pure
Cc: [email-masked], [email-masked]
Sender: [email-masked]

While I think that a variety of robust and successful products will proably
emerge that support various types of key recovery, I strongly agree with
Tim on engineering grounds: Keep It Simple, Stupid.

When it comes to deciding on the contents of a standard, let's keep in mind
that we're working with a relatively new technology. We'll make more
progress by standardizing proven concepts, and these integrated key
recovery hacks don't have the operating history that vanilla PGP has. If
anything, my experience with Guard keying suggests that the proposed
mechansims aren't enough. The problem has more hair than our sheepdog.

I don't think the protocol standard needs to take a political statement
about key recovery mechanisms, but it *must* outline the protocol's
traditional security objectives pretty much the way Tim outlined them. That
sets the context for a robust protocol that has a successful history.

Now I need to shut off my mailer and go pack my suitcase.

Rick.
[email-masked]           Secure Computing Corporation
"Internet Cryptography" now in bookstores http://www.visi.com/crypto/

Date: Wed, 15 Oct 1997 11:25:05 -0600
To: Adam Back <[email-masked]>
From: Rick Smith <[email-masked]>
Subject: Re: proposal: commercial data recovery
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

In response to some things I said about crypto and firewalls, Adam Back wrote:

>I'm not sure whether pgp5.5 has this ability to screen messages prior
>to reading, and also not sure whether it has the ability to snoop
>messages prior to sending built in.

It's not a feature of 5.5, it's a separate activity that relies on the
presence of a third party key. The actual inspection occurs at a security
choke point like a firewall. That way the tests are applied consistently
regardless of mistakes made by clients in software installation or
configuration.

You noted that it might in fact be possible to get the same result with a
more GAK resistant implementation, and I agree. For example, if the
principals all update their public keys fairly often, then there's no
relatively key that's easy to escrow. The practical version of forward
secrecy, as it were. I have no objection to that. As far as I can tell,
there's nothing intrinsic in the current PGP proposals to prevent such an
implementation.

Concerning your other examples, I agree that there are ways to trade off
between degrees of GAK sensitivity and various customer security
objectives. However, this whole discussion revolves around the fact that
people rely heavily on off the shelf solutions, and there aren't the right
tools to do everything you're suggesting. I'd like to see things in the
crypto marketplace be as flexible as possible. Just because a few provide
some features that could in theory be applied to GAK doesn't IMHO mean that
those will manage to prevail. A diverse marketplace of crypto devices is
essential for it to flourish -- one that gives every customer the flavor
they want. That way the general public will develop a working understanding
of it. And we'll all learn what really works and what doesn't.

Let's face it, crypto is at about the same stage as cars were when Henry
Ford started building them. We really know as much about how crypto will
change the future as he did about the effects of cars. We can't start
engineering in governors to restrict our speed, or be restricting our
designs to governor-proof transmissions.

I regret I'll have to bow out of this discussion because I'll be on travel
for a couple of weeks. Have fun everyone.

Rick.
[email-masked]           Secure Computing Corporation
"Internet Cryptography" now in bookstores http://www.visi.com/crypto/

From: "Gaon, David" <[email-masked]>
To: "[email-masked] " <[email-masked]>, "[email-masked] " <[email-masked]>
Subject: RE: Time to move on
Date: Wed, 15 Oct 1997 11:31:00 -0400
Sender: [email-masked]

     
     But here is a 4th alternative that Tim May suggested:
     
     ""a standard that does not allow ""key recovery"" for Gov or Corp
as there 
     are other mechanisms (outside communications) to enable this.
     
     I must admit I find ""key recovery"" as used in this thread for GAK
or CAK 
     in the context of e-mail correspondence, a misuse of the term as
was 
     originally coined,  and that is, a means of obtaining user keys
from a 
     trusted repository after legal recourse.
     
     It appears, from my reading of this thread, that PGP 5.5 would
allow sender 
     to also encryt copies to Gov or Corp with or without sneder's
consent or 
     the consent of the recipient depending on the mail security
policies of 
     their respective organizations.
     
     This, to me, is a new and disturbing twist on ""key
recovery/escrow""
     
     David Gaon

______________________________ Reply Separator
_________________________________
Subject: Time to move on
Author:  [email-masked] [SMTP:[email-masked]]  at DISAHUB
Date:    10/15/97 10:30 AM

( Quick summary: two contrasting implementations should
  advance, outside Open PGP.  Open PGP should standardise 
  the base.  Else we'll stall and lose everything! )

     
We seem to be reaching a new phase in the debate.
     
There appear to be three possibilities currently circulating:
     
  * PGP Inc-sponsored designs to achieve various customer-
    demanded recovery features, as typified by their 5.5 
    product.  These include SMTP policy enforcers and 
    protocols for communicating warnings and requesting 
    certain key encryptions, so as to ease the 
    incorporation of corporate recovery options into large 
    sites.
     
  * Alternative designs by a cartel led by Adam that seek
    to minimise the potential for a GAK attack on any 
    infrastructure that is built up.
     
  * A base implementation that neither promotes nor impedes
    either of the above.
     
Perhaps the new phase is characterised by exhaustion, or by 
battle lines firmly drawn, but for all the efforts put in to 
the debate, it would appear that no consensus approach to 
data recovery has arisen.  So, assuming that if we haven't 
by now made everybody in the world happy together, we might 
start thinking about strength (and happiness) through 
diversity.
     
As many have pointed out, the Open PGP standardisation 
effort should naturally lag behind the implementation of 
various companies or cartels.  Indeed, where there is 
dispute, and competing but potentially incompatible 
variants, then there is a need to encourage experimentation 
within the market place in order to determine which way 
standards should go.
     
The Open PGP standard needs then to support the competing 
implementations without prejudice.  It must therefore provide 
a base standard that permits additional modes, such as the 
space for extra flags, but does not define the behaviour of 
such flags so as to not impose any limits on them.
     
If later implementations succeed in showing that these flags are 
beneficial then proposals can be made to add them.  There also is 
more value in a base implementation that gets out quickly than a 
"complete" implementation that takes a long time.
     
I am also increasingly concious of the need to keep everyone 
on board here.  If we do develop a rift within the community, 
there is some degree of danger that the standard will stall.
Now, this is the worst scenario for all of us, as it will sound 
the death knell for an strong independant email standard.
     
Other efforts have faltered.  What we are trying to do within 
this standards process is shown therefore to be very difficult. 
Remember that just the process alone of developing an RFC is 
long and tortuous, and consequently requires a lot of effort. 
Some people and companies are willingly providing this effort; 
we need to ensure that these efforts are not disenfranchised.
     
Both the alternate implementors have signalled their willingness 
to pursue their philosophies, and this can best be done and 
debated outside the Open PGP forum, within other more development 
oriented groups.  As long as we are agreed that the Open PGP 
standard does not in any way impinge on either variant, then we 
can get on with the really important task of producing the RFC.
     
iang
     
PS: see also TCMs post.

From: "Gaon, David" <[email-masked]>
To: "[email-masked] " <[email-masked]>, "'Adam Back'"  <[email-masked]>, Mike Wynn  <[email-masked]>
Subject: RE: Schneier comment on CMR
Date: Wed, 15 Oct 1997 11:06:00 -0400
Sender: [email-masked]

     But you should not be using corporate assets for this
doctor-patient 
     communication.
     If you do, then the coorporation may argue they have a right to the

     data on/in their system, and therefore CDR
     
     If however, you use a GAK compliant e-mail system, then Gov may see

     your communication whether or not you like it or know it.
     
     David Gaon

______________________________ Reply Separator
_________________________________
Subject: RE: Schneier comment on CMR
Author:  Mike Wynn [SMTP:[email-masked]]  at DISAHUB
Date:    10/15/97 4:22 AM

But I thought that the question of CDR was to do with personal 
privacy, not weither I was criminal or not!
I may not wish my mail, which could, be of a private nature to 
me to be recoverable by any one but the recipient
     
i.e. an e-mail conversation with my doctor.
     
Mike.
     
----------
From:      Adam Back
Sent:      15 October 1997 03:06
To:      [email-masked]
Subject:      Schneier comment on CMR

(Quoted with permission from email).
     
Bruce Schneier <[email-masked]>: 
>
>      Corporate Data Recovery does not have to be resiliant to a
hostile
>      user.  If a criminal is stupid enough to use a system with
corporate 
>      data recovery to commit his crime, then he is stupid enough to do
>      half a dozen other things that will get him caught.  If he is
smart 
>      enough to turn off a consentual data recovery feature, then he is
>      also smart enough to use a different encryption system if the
data 
>      recovery feature cannot be turned off.
     
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: [email-masked]
Date: 15 Oct 1997 14:30:54 -0000
To: [email-masked]
Subject: Time to move on
Sender: [email-masked]

( Quick summary: two contrasting implementations should
  advance, outside Open PGP.  Open PGP should standardise
  the base.  Else we'll stall and lose everything! )

We seem to be reaching a new phase in the debate.

There appear to be three possibilities currently circulating:

  * PGP Inc-sponsored designs to achieve various customer-
    demanded recovery features, as typified by their 5.5
    product.  These include SMTP policy enforcers and
    protocols for communicating warnings and requesting
    certain key encryptions, so as to ease the
    incorporation of corporate recovery options into large
    sites.

  * Alternative designs by a cartel led by Adam that seek
    to minimise the potential for a GAK attack on any
    infrastructure that is built up.

  * A base implementation that neither promotes nor impedes
    either of the above.

Perhaps the new phase is characterised by exhaustion, or by
battle lines firmly drawn, but for all the efforts put in to
the debate, it would appear that no consensus approach to
data recovery has arisen.  So, assuming that if we haven't
by now made everybody in the world happy together, we might
start thinking about strength (and happiness) through
diversity.

As many have pointed out, the Open PGP standardisation
effort should naturally lag behind the implementation of
various companies or cartels.  Indeed, where there is
dispute, and competing but potentially incompatible
variants, then there is a need to encourage experimentation
within the market place in order to determine which way
standards should go.

The Open PGP standard needs then to support the competing
implementations without prejudice.  It must therefore provide
a base standard that permits additional modes, such as the
space for extra flags, but does not define the behaviour of
such flags so as to not impose any limits on them.

If later implementations succeed in showing that these flags are
beneficial then proposals can be made to add them.  There also is
more value in a base implementation that gets out quickly than a
"complete" implementation that takes a long time.

I am also increasingly concious of the need to keep everyone
on board here.  If we do develop a rift within the community,
there is some degree of danger that the standard will stall.
Now, this is the worst scenario for all of us, as it will sound
the death knell for an strong independant email standard.

Other efforts have faltered.  What we are trying to do within
this standards process is shown therefore to be very difficult.
Remember that just the process alone of developing an RFC is
long and tortuous, and consequently requires a lot of effort.
Some people and companies are willingly providing this effort;
we need to ensure that these efforts are not disenfranchised.

Both the alternate implementors have signalled their willingness
to pursue their philosophies, and this can best be done and
debated outside the Open PGP forum, within other more development
oriented groups.  As long as we are agreed that the Open PGP
standard does not in any way impinge on either variant, then we
can get on with the really important task of producing the RFC.

iang

PS: see also TCMs post.

Date: Wed, 15 Oct 1997 12:01:51 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: Will Price <[email-masked]>
CC: Adam Back <[email-masked]>, [email-masked], [email-masked]
Subject: Re: proposal: commercial data recovery
Sender: [email-masked]

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

> The design you have been espousing for the last week or so in your many
> messages takes the power out of the hands of the sender and encourages
> automated violations of the sender's privacy by the recipient (perhaps even
> unbeknownst to the recipient).

Whatever you do, the recipient has the plaintext (has the argument
really descended to this level?) As Ian Grigg has pointed out, there are
*no* technical means a message sender can employ to stop the recipient
'violating their privacy'. You are splitting hairs again. As Adam has
repeatedly pointed out, there is no problem with flagging on a key that
the message may be read by someone else. This is actually more honest
than a scheme where 'this message can be read by key X' flags are used;
once the recipients have the plaintext, they can give it to whoever they
like to read. Adam's scheme does not put in place an infrastructure
which encourages automated snooping. It leaves it entirely up to
separate organisations as to whether they implement data recovery. Have
you *read* Bruce Schneier's post on how quickly GAK proponents in
Washington have picked up on this? Are you proud to have provided an
argument for S909? Are you happy to have the NSA using you as an
argument that GAK works?!!!

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

Adam's design does NOT "encourage automated violations of the sender's
privacy" - that I would reserve for PGP 5.5. You split hairs yet again
by claiming PGP 5.5 is "a simple system... wherein all recipients are
under the sender's control". As Adam has pointed out in his "many
posts", it's not much use letting the sender remove the extra recipient
if they know the message will then simply be bounced. Adam's request for
you to remove these fields make the system simpler. His communications
key idea adds additional security, but that is the only reason for the
increased complexity - an *additional* security feature.

This argument is exhausting. You may not give two hoots what I, or Adam
Back, or any number of people say. But could you not at least listen to
Schneier, who you must admit is quite an authority in this field? Even
if you *were* right, you have not managed to convince him. Do you really
think it's going to be good for PGP Inc if he recommends that clients
and anyone else who asks should not use PGP Inc products?

Ian.

Date: Wed, 15 Oct 1997 02:34:01 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Will Price <[email-masked]>
Subject: Re: proposal: commercial data recovery
Cc: [email-masked]
Sender: [email-masked]

Adam:

First, let me state some overriding design goals of a data recovery system
required to ensure privacy: the sender must know and consent to every key
that will be able to read the message during its lifetime, the encryption
must be end-to-end, and the recipient must know exactly who else can
decrypt the message.  The sender's privacy is paramount as it is their data
which is being trusted to the system.  These are basic principles not only
of a data recovery system, but for any cryptosystem.

The design you have been espousing for the last week or so in your many
messages takes the power out of the hands of the sender and encourages
automated violations of the sender's privacy by the recipient (perhaps even
unbeknownst to the recipient).  In your model, the recipient automatically
decrypts and then re-encrypts to a data recovery key -- even though
end-user computers are likely to be insecure thus making this decrypt &
reencrypt step rather specious at best.  The only information the sender
has before sending the message is "your message might be able to be read"
by someone else, or more likely no information whatsoever as there is no
need to put such information in the protocol as far as the format is
concerned.  Either way, the sender is thus easily led into a false
assumption of security.  The encryption is not end-to-end but rather is
completely unwrapped in the middle and then rewrapped introducing serious
security flaws, and the sender has no idea to whom the message will be
auto-reencrypted by the receiver.

As an actual data recovery system, it also fails fundamental tests.  If I
encrypt critical data to a colleague wiping it from my system after
sending, then the colleague is incapacitated before receipt and processing
of the message, the data can never be retrieved.  A data recovery system
must solve this kind of issue -- data recovery here means that from
end-to-end the data is recoverable in case of emergency.  One cannot ignore
message transit time in this -- it can take days for a message to travel
from AOL to the outside world.  If you don't need data recovery, don't use
it, but at least respect the people who do need it and need it to actually
work at all points.

>With these three principles you still have lots of flexibility because
>you can escrow storage keys

I'm truly amazed that you would attack in such a spiteful fashion a simple
system which adds a recipient-requested, sender-approved extra recipient
which is end-to-end wherein all recipients are under the sender's control
and each recipient knows who can read the message with no key escrow using
the same old PGP message format we all know and love without change, and
yet you propose a much less secure system which allows hiding critical
information from the sender and does not adequately perform its stated
purpose of data recovery.

- -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=0x5797A80B>

From: Mike Wynn <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Adam Back'" <[email-masked]>
Subject: RE: Schneier comment on CMR
Date: Wed, 15 Oct 1997 09:22:44 +0100
Sender: [email-masked]

But I thought that the question of CDR was to do with personal
privacy, not weither I was criminal or not!
I may not wish my mail, which could, be of a private nature to
me to be recoverable by any one but the recipient

i.e. an e-mail conversation with my doctor.

Mike.

----------
From: 	Adam Back
Sent: 	15 October 1997 03:06
To: 	[email-masked]
Subject: 	Schneier comment on CMR

(Quoted with permission from email).

Bruce Schneier <[email-masked]>:
>
> 	Corporate Data Recovery does not have to be resiliant to a hostile
> 	user.  If a criminal is stupid enough to use a system with corporate
> 	data recovery to commit his crime, then he is stupid enough to do
> 	half a dozen other things that will get him caught.  If he is smart
> 	enough to turn off a consentual data recovery feature, then he is
> 	also smart enough to use a different encryption system if the data
> 	recovery feature cannot be turned off.

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, 14 Oct 1997 22:04:30 -0700
To: [email-masked]
From: Marshall Clow <[email-masked]>
Subject: Re: proposal: commercial data recovery [P]
Cc: [email-masked]
Sender: [email-masked]

Anthony Green may have written:
>At 15:42 1997-10-14 -0600, Rick Smith wrote:
>>ObPolitics: Personally, I think it's too soon to tell if PGP's
>>implementation would benefit the FBI in its pursuit of wiretapping keys. At
>>most it might resolve whether such mechanisms are in fact a practical
>>technology. I'm not yet convinced.
>
>A major reason GAK runs into such strong opposition is the gut feeling
>that it violates the expectation of privacy. If the communication in
>question is already accessible by a third party, it can be argued that
>that expectation no longer exists. In this environment a government
>might succeed in passing GAK legislation that requires organizations
>that have third-party access to encrypted communications to provide the
>plaintext to the government on issue of a subpoena or court order.
>
This is a very important point.
>From what I read, the law about privacy is falling to two extremes,
"private", or
"no expectation of privacy"; i.e, public.

Cell phones and cordless phones, for example, fall into the "no expectation"
class.

Calling patterns, (numbers dialed, and length of calls), also have "no
expectation
of privacy", because you disclose them to a third party (the phone company).
You can't avoid disclosing them, but that doesn't seem to matter. :-(

I can see a court deciding that since you encrypted to your company's CMR key,
your email is not private. Even if you are a company officer discussing company
business with the corporate attorney. IANAL, though.

This is not a weakness in CMR, per se, as a weakness in any
"encrypt to additional recepients" scheme.

-- Marshall

Marshall Clow     Aladdin Systems   <mailto:[email-masked]>

"In Washington DC, officials from the White House, federal agencies and
Congress say regulations may be necessary to promote a free-market
system." --  CommunicationsWeek International April 21, 1997

Date: Tue, 14 Oct 1997 20:43:11 -0700
From: "Paul Rarey" <[email-masked]>
Organization: The Clorox Company
To: [email-masked]
Subject: Cuz' Me....
Sender: [email-masked]

I find this stuff interesting... But when do we get to the issues of PGP/MIME.

1) What are the issues we need to overcome to gain r-concensus on PGP's current
public distribution.

1.A) Now that I've got your attention - classify PGP's current weaknesses & focus
on solutions not retoric.

2) What are the issues we need to overcome to gain r-concensus for MIME transport
of PGP services?

3) Define other issues (don't solve them).

Cheers,
[ psr ] (some grunt @ Clorox)

Date: Wed, 15 Oct 1997 03:06:41 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Subject: Schneier comment on CMR
Sender: [email-masked]

(Quoted with permission from email).

Bruce Schneier <[email-masked]>:
>
> 	Corporate Data Recovery does not have to be resiliant to a hostile
> 	user.  If a criminal is stupid enough to use a system with corporate
> 	data recovery to commit his crime, then he is stupid enough to do
> 	half a dozen other things that will get him caught.  If he is smart
> 	enough to turn off a consentual data recovery feature, then he is
> 	also smart enough to use a different encryption system if the data
> 	recovery feature cannot be turned off.

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: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: the case for separate comms keys
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Date: Wed, 15 Oct 1997 15:34:34 (NZDT)
Sender: [email-masked]

Death rays from Mars made Adam Back <[email-masked]> write:
 
>You can also acheive the same flexibility with an extra indirection with
>symmetric storage keys (optionally held in escrow).  In fact I think this is
>what later versions of Peter Gutmann's SFS do.  The reason he uses for this is
>that it allows you to change your passphrase without re-encrypting the whole
>disk, because the _actual_ disk encryption key is encrypted itself with the
>hash of your passphrase, rather than using the hash of the passphrase directly
>as the key.
 
There are also a few other reasons for doing this, and I've extended the idea
used in SFS for use with my cryptlib encryption toolkit.  Instead of encrypting
just the key, you also encrypt the algorithm details, ie:
 
    E          ( algorithm, algorithmInfo, key )
     passphrase
 
    E                             ( data )               
     algorithm, algorithmInfo, key
 
This makes the job of an attacker somewhat harder because even if they have
some means of performing a reasonable attack on the second encryption step,
they won't know exactly what it is, so even if it only has a 40-bit key they
might need to search half a dozen algorithms before finding the right one.
This makes it a lot harder to just brute-force everything going past in the
hope of finding something useful.  This is especially entertaining for
algorithms like RC5 and Safer, where you can produce dozens of variations by
playing with algorithm parameters, in effect adding extra bits to the key
length.
 
As Adam mentions, you can also escrow[0] the second key (which SFS does using a
threshold scheme with the parameters controlled by the user).  In this way the
user can change their password without destroying the ability of the escrow to
access the data.
 
Finally, using the session-key mechanism means you never encrypt two lots of
data using the same key, and means you can encrypt a single message for
multiple recipients just like the public-key equivalent.
 
Peter.
 
[0] This is "escrow" used in the true sense, not the GAK euphemism.  It's
    completely under the control of the user, it's optional, and it's intended
    for recovery of stored data when you forget the passphrase.

To: [email-masked]
Date: Tue, 14 Oct 1997 18:17:54 MDT
Subject: Re: proposal: commercial data recovery
From: [email-masked] (Anonymous Remailer)
Sender: [email-masked]

On Tue, Oct 14, 1997 at 10:37:21AM +0100, Adam Back wrote:
> 
> If we take the design goal of designing a commercial data recovery
> system which is not GAK compliant, we can most succinctly state this
> design goal as the task of ensuring that:

I take a certain sad pleasure in reminding people that among my first
posts on this list I warned that cypherpunks had better design a
commercial key recovery system, or one they didn't like would be
forced down their throats.  Attila now spouts my line exactly, Adam is
busy designing (though he still can't bring himself to use the term
'key recovery', being meme-dominated as he is), and Tim nods
approvingly. 

Good luck, gentlemen -- you should have been doing this a year ago.

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

This message was automatically remailed. The sender is unknown, unlogged,
and nonreplyable. Send complaints and blocking requests to
<[email-masked]>.

From: Andrew Bromage <[email-masked]>
Subject: Re: commercial data recovery
To: [email-masked] (Zooko Journeyman)
Date: Wed, 15 Oct 1997 09:58:50 +1000 (EST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

G'day all.

Zooko Journeyman wrote:

> I wonder if it is too much early-days to start talking about
> advanced protocols e.g. secret-splitting in IETF-Open-PGP?  

One list member has encouraged me to write an internet-draft for a key
quorum system, so I am.  The trouble is that my proposed implementation
needs some info that isn't in the current IETF draft (the format of the
"string to key" object).

Is it actually documented anywhere that we can access?

Cheers,
Andrew Bromage

Date: Tue, 14 Oct 1997 14:28:01 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Tim May <[email-masked]>
Subject: Just say "No" to key recovery concerns...keep OpenPGP pure
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I have an even simpler solution to the problem of how the OpenPGP committee
should solve the key recovery/message recovery/corporate/GAK problem: Don't.

Just decide and announce that neither plaintext nor key recovery will be
part of the OpenPGP spec. This is a cleaner and simpler approach, and the
functions of encryption are placed front and center.

(Let some other task force deal with building some kind of "OpenGAK" or
"OpenSnoopware" program!)

That is, OpenPGP need only worry about providing a robust, secure, etc.,
open standard for end-to-end encyption (communication) and local encryption
(storage). Don't try to solve the "disaster planning" problem ("Alice hit
by a truck") by building snoopware/escrow into the core cryptosystem, and
don't try to solve the snoopware ("What is Alice saying to Bob?") desires
of companies either.

For comparison, we certainly don't see the world's telecommunications
bodies, committees, and companies working on a "conversation recovery" mode
to make the job of enforcing the U.S. Digital Telephony and similar
wiretapping desires.

Dealing primarily with communication and file security is what PGP has
historically focussed on, in all versions from 1.0 to 5.0 (not counting the
anomaly of ViaCrypt). Sounds fine to me. The "mission" of PGP and other
public key cryptosystems (until now) has been to secure communications and
files, not to provide mechanisms for corporations to monitor
communications. (Disaster planning, for "what if Alice gets hit by a
truck?" scenarios, are of course handled by having Alice lock up her
private keys in her safe, or perhaps her department manager's safe,
whatever. This is a dangerous security flaw, if the key is released, but
has the advantage that it's a fairly conventional recovery approach, and is
not built into the cryptosystem itself. Trying to solve this problem, that
of "backup keys" or "spare keys" floating around, is not easy in any
case...OpenPGP would do well to just avoid the issue and let conventional
disaster planning measures deal with the problem.)

If corporations, agencies, governments, etc., want to have access to
Alice's files, to Alice's communications to Bob, this is really a file
managment and archiving strategy problem, not something OpenPGP has to
concern itself with.

Keep it Simple, Stupid. KISS. Often the simplest approach to dealing with
complex specifications and conflicting desires is to just ignore them.

Let Big Brother and Little Brother try to get snoopware deployed when
OpenPGP is widely available.

Whether PGP, Inc. will go along with this is unlikely, but this doesn't
change the reasons for keeping OpenPGP true to the original aims of PGP.

--Tim May

The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

Date: Tue, 14 Oct 1997 23:42:08 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: proposal: commercial data recovery
Sender: [email-masked]

Rick Smith <[email-masked]>
> Regarding the practical uses of e-mail key disclosure, let me include one
> from the guard/firewall world that I haven't seen mentioned yet:
> 
> We've been shipping products since 1994 that scan the contents of e-mail
> messages and reject contents that violate specified filtering criteria.
> Sites use it to block importation of viruses or other inappropriate
> attachments, and to block the export of improperly released information.
> Most of these systems have been sold to the government and use the Message
> Security Protocol to encrypt data. The system rejects messages that don't
> contain an extra key so that the firewall can scan message contents.

I'm not sure whether pgp5.5 has this ability to screen messages prior
to reading, and also not sure whether it has the ability to snoop
messages prior to sending built in.

The basis is there for the functionality in the enforced second
recipient, but I'm not sure whether the client, or SNMP management
tools, or SMTP policy enforcer implement this functionality.

I'd welcome clarification from PGP Inc., employees, or anyone in the
US has tried the pgp5.5 software for business suite.

> This violates the assumed requirement that the contents of an e-mail
> message must not be viewed by anyone except the message's author and
> recipient.

It does yes.  And that demonstrates that the principle is achieving
it's function in high-lighting areas of a design which could be used
for GAK purposes.

> However, it's a security trade-off that some organizations want to
> make for certain applications.

Absolutely.  You should try hard though to see if there are any
software hacks or protocol reorganisations you can do to make the
system unusable for GAK, or as close to unusable as you can.

> PGP's key recovery protocol isn't the perfect solution, but it would help
> resolve a big problem.

Where that problem is can messages be screen by processes?  One
solution if you restrict yourself to processes is to move the function
to the client and scan after decrypt.  This isn't as easy to integrate
into existing MUAs but would be possible for fresh re-writes like
pgp5.x clients.

If you want ability for humans to scan messages manually as well, and
you can't live with the modifications in the client, you can do this
within the CDR design principles:

Have all email received by the company encrypted to the companies
public key.  Have your virus filter/human screener check the email,
and then pass on to user in clear, or pass on to user encrypted with
users key.

Actually this is more secure than your solution, because the client
already has an in memory master key; and now you have one crypto
recipient rather than two to blow your security for you by allowing
inadvertent key compromise.

For outgoing email, configure the mail client plugin to either send in
plain-text, or to sign only (one hopes with non escrowed signature
keys, else your MIL friends will be able to forge each others mail),
or to encrypt to the outgoing filtering agent, and have the outbound
mail hub filter, or forward to human screener content checking.

CDR compliant.  Has some extra resistance to GAK corruption.

As an additional application of CDR anti-GAK principles you could do
the small software hack of allowing the clients and/or mail filtering
agents to only communicate with each other if the machine IP addresses
look like they are on the same mail hub.

Don't provide source.  (I suspect your company doesn't anyway for this
kind of app, or do MIL people like to inspect source?)

So now your system has a number of extra protections against being
used for GAK.  They are not perfect, but you've done what you can, and
it's a definate improvement over what you had before.

However I'm not sure it matters for your application really whether it
is GAK compliant or not.  This is because your application sounds like
it is mainly for defense contractors, and MIL or NSA type use.  As far
as I'm concerned that lot deserve GAK.  Keep themselves honest :-)

> To send mail through these systems, the users must be trained to
> include the firewalls as message recipients -- this produces a copy
> of the symmetric key encrypted with the firewalls' individual PKs.
> If a user forgets, then the message can not pass through. The PGP
> approach of warning or demanding another PK token would help solve
> that problem at least in simple cases.

You can acheive the same functionality by insisting on mail being
encrypted for the firewall.  Firewall can re-encrypt for intended
user.

> ObPolitics: Personally, I think it's too soon to tell if PGP's
> implementation would benefit the FBI in its pursuit of wiretapping keys. At
> most it might resolve whether such mechanisms are in fact a practical
> technology. I'm not yet convinced.

I think you have a point there and that it's not entirely clear how
this would work out.

> Also, if commercial sites have already co-opted PGP's recovery key for
> their own uses, it's not clear that the FBI will be able to use it for
> clandestine investigations. If they approach the site's IS managers to
> acquire copies of the firewall keys, there's a good chance a rumor will get
> back to the people being targeted for surveillance. 

I don't think that's the way it will work.  What they'll do is require
SEC cleared companies to provide this key as a matter of law to the
government.  If cheating is detected the bosses will get prison terms.
Then they'll slowly spread it from SEC cleared firms to other
companies.  Maybe Public companies.  Then they'll create a reichstag
fire FBI constructed publicity type cases; perhaps money laundering,
or purported mafia front business as an example of a public threat
from allowing companies to communicate without escrow.  Individuals
too, some terrorist cases, a few more large scale bombings.  No
problem.

If PGP provided facility for multiple enforced extra crypto
recipients, it would be even more GAK compliant, as companies could
just put a NSA key into the recipient box.

The CDR design principles also apply to standards.  Standards are very
powerful things.  If OpenPGP requires capability to understand and
encode to second crypto recipients which are not message recipients
for conformancy, we are in trouble also because all clients will then
be required to make GAK easier to enforce; the capability is right
there in pgp5.0 and pgp5.5 now.

If on the other hand the OpenPGP standard does not include the second
non message recipient crypto recipient feature, then companies who do
chose to do so must build up their own client base outside of the
installed client base, because they won't be able to build
GAK and have interoperability at the same time.

(We'll see whether or not PGP argue for this feature to go in the
standard in a bit, when the draft standard is released, and
discussions commence).

Also remember that another danger with GAK software is that your
country might be too liberal for the government to get away with
various things, but others aren't.

We don't want to encourage civil rights abuses.  In some countries
saying non-government approved thoughts results in prison terms,
torture, and painful death.

> Also, I believe the overhead for separate eavesdropping keys would
> produce too clear a sign to everyone that the FBI is
> listening. There is no precendent for such a thing and even if it's
> adopted temporarily I doubt it will persist. People will notice, it
> it will make them mad -- it will show them that the FBI is indeed
> under everyones' bed. Even the FBI can't stand up against broadly
> based grassroots pressure. Of course, I've been wrong before about
> politics.

Well I hope you're right of course, but I feel PGP could do more to
prevent the scenario I present above, which I feel is fairly
realistic.

I also hope I have provided some worked examples of the logic in
applying the CDR design principles.

(They are counter-intuitive sorts of principles to work with because
they are all negatives: don't do this, don't do that, no
recommendations as such on what _to do_.  This is because what you do
is explore the solution space outside of the restriction they apply on
it.  They are also strange in that it is unusual to see formally
codified cryptographic property design principles which reflect
entirely a political issue.  Must me a first :-)

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, 14 Oct 1997 17:32:09 -0500 (CDT)
From: Omegaman <[email-masked]>
To: Adam Back <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

Adam Back writes:
 > Jonathan Seybold <[email-masked]> writes:
 > > Adam, one aspect of your suggestion puzzles me:
 > > 	One thing which concerns me most is KNOWING when a message I send
 > > (or receive) could be read by someone else. The PGP CMR scheme makes this
 > > very clear: if there is an extra CMR key, the message may be read by
 > > whomever controls that key, if not, only the recipient may decrypt the
 > > message.
 > > 	If, however, the message is secretly re-encrypted to a corporate
 > > storage key AFTER it is received, I will never know that.
 > 
 > You will if you mark the key with this information.

This is a straw man anyway.  You don't know this now.  Someone you are
communicating with could already be forwarding plaintext to a third
party unbeknownst to the sender.  

This is a "do you trust the recipient" issue.

 > What I _am_ arguing is that in designing systems to provide companies
 > with data recovery mechanisms that you should a) not weaken security
 > more than necessary, and b) that it would be nice if you used a method
 > which doesn't introduce GAK compliancy for communications keys.
 > 
 > I presented I think in plenty of detail an alternate mechanism which
 > is both non-GAK compliant, and more secure.  So what is the problem?
 > Is there a technical flaw in my solution?

No.  But there is in their's(PGP Inc.) as I think you and others have
amply demonstrated.  The technical issues alone are enough to reject
usage of PGP5.5's CMR features.

It intrigues me that there has been virtual silence from PGP employees
on the technical issues.  Only Hal Finney via the IETF-Open-PGP has come
anywhere near commenting upon this.  I haven't seen anyone from PGP
Inc. comment on your data-recovery implementation ideas.  

In my optimistic moments, I take this as a sign that internally, PGP
inc. is giving consideration to producting more sensible and effective
solutions.  (Maybe even as outlined here)

 > > 	This means, I believe, that they should NEVER INVOLVE HIDDEN BACK
 > > DOORS THAT USERS ARE NOT AWARE OF.
 > 
 > Agreed.  You can flag backdoors with either solution.

See above.  The prescence of flags does not prevent this.  By
definition I might add ;).  Trust issues, etc. are involved.

 > It works well enough, but it could be made much more secure, by
 > separating storage key functionality from transient message key
 > functionality.  This would also give you the chance to resolve the
 > articificially created need for GAK compliancy, which arises because
 > you are being forced by this lack of distinction between key
 > functionalities to use one key for both long term storage and what
 > should be transient communications key usage.

Hal Finney's description of key sttributes indicate that implementing
separate storage keys would not be hard for PGP Inc to implement in
the next release.  

 > Decentralised control is good, of course, but the pgp5.5 and SMTP
 > policy enforcer is a ready to roll GAK system.  

Of course, other companies could have (and will) implement similar
systems.  That PGP, with it's reputation and stated policies, would is
surprising.  

Hopefully, PGP will live up to their reputation by realizing this
misstep and correcting it with a more secure, less GAK-compliant
implementation. 
 
 > The PGP bashing PGP observes is an attempt by the pro-privacy crypto
 > community to influence PGP to re-think the GAK compliancy, and to
 > point out the more secure way to implement corporate recovery of
 > stored email messages without GAK compliancy.
 > 
 > I reserve the right to bash any company which attempts to field GAK
 > compliant software.

The "bashing" in this notoriously harsh forum has been rather tender
in my view.

Perhaps the perception of "bashing" is based on recognition (and
guilt) that the CMR mechanism is flawed and goes against "the spirit
of PGP."  Methinks, y'all doth protest too much.
 
-- 
---------------------------------------------------------------------
Omegaman <mailto:[email-masked]>|"When they kick out your front door,
   PGP Key fingerprint =        | How are you gonna come? 
   6D 31 C3 00 77 8C D1 C2      | With your hands upon your head,   
   59 0A 01 E3 AF 81 94 63      | Or on the trigger of your gun?" 
Send email with "get key" as the| -- The Clash, "Guns of Brixton"
"Subject:"to get my public key  |   _London_Calling_ , 1980
---------------------------------------------------------------------

Date: Tue, 14 Oct 1997 23:43:25 +0200
To: IETF Open-PGP List <[email-masked]>
From: "Anthony E. Greene" <[email-masked]>
Subject: Re: proposal: commercial data recovery [P]
Sender: [email-masked]

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

At 15:42 1997-10-14 -0600, Rick Smith wrote:
>ObPolitics: Personally, I think it's too soon to tell if PGP's
>implementation would benefit the FBI in its pursuit of wiretapping keys. At
>most it might resolve whether such mechanisms are in fact a practical
>technology. I'm not yet convinced.

A major reason GAK runs into such strong opposition is the gut feeling 
that it violates the expectation of privacy. If the communication in 
question is already accessible by a third party, it can be argued that 
that expectation no longer exists. In this environment a government 
might succeed in passing GAK legislation that requires organizations 
that have third-party access to encrypted communications to provide the 
plaintext to the government on issue of a subpoena or court order.

>Also, if commercial sites have already co-opted PGP's recovery key for
>their own uses, it's not clear that the FBI will be able to use it for
>clandestine investigations. If they approach the site's IS managers to
>acquire copies of the firewall keys, there's a good chance a rumor will get
>back to the people being targeted for surveillance.

Assuming GAK legislation is passed, any such action on the part of an IS 
manager would be illegal.

Date: Tue, 14 Oct 1997 15:42:32 -0600
To: Adam Back <[email-masked]>, [email-masked]
From: Rick Smith <[email-masked]>
Subject: Re: proposal: commercial data recovery
Cc: [email-masked], [email-masked]
Sender: [email-masked]

It should be clear by now that privacy is not the only security objective
sought by customers of information security products, nor even by all
customers of crypto products. Practical users rarely pursue privacy at all
costs, nor do they pursue accountability and traffic visibility at all
costs. Many must find a balance between two fundamentally conflicting goals.

Regarding the practical uses of e-mail key disclosure, let me include one
from the guard/firewall world that I haven't seen mentioned yet:

We've been shipping products since 1994 that scan the contents of e-mail
messages and reject contents that violate specified filtering criteria.
Sites use it to block importation of viruses or other inappropriate
attachments, and to block the export of improperly released information.
Most of these systems have been sold to the government and use the Message
Security Protocol to encrypt data. The system rejects messages that don't
contain an extra key so that the firewall can scan message contents.

This violates the assumed requirement that the contents of an e-mail
message must not be viewed by anyone except the message's author and
recipient.

However, it's a security trade-off that some organizations want to make for
certain applications.

PGP's key recovery protocol isn't the perfect solution, but it would help
resolve a big problem. To send mail through these systems, the users must
be trained to include the firewalls as message recipients -- this produces
a copy of the symmetric key encrypted with the firewalls' individual PKs.
If a user forgets, then the message can not pass through. The PGP approach
of warning or demanding another PK token would help solve that problem at
least in simple cases.

ObPolitics: Personally, I think it's too soon to tell if PGP's
implementation would benefit the FBI in its pursuit of wiretapping keys. At
most it might resolve whether such mechanisms are in fact a practical
technology. I'm not yet convinced.

Also, if commercial sites have already co-opted PGP's recovery key for
their own uses, it's not clear that the FBI will be able to use it for
clandestine investigations. If they approach the site's IS managers to
acquire copies of the firewall keys, there's a good chance a rumor will get
back to the people being targeted for surveillance. Also, I believe the
overhead for separate eavesdropping keys would produce too clear a sign to
everyone that the FBI is listening. There is no precendent for such a thing
and even if it's adopted temporarily I doubt it will persist. People will
notice, it it will make them mad -- it will show them that the FBI is
indeed under everyones' bed. Even the FBI can't stand up against broadly
based grassroots pressure. Of course, I've been wrong before about politics.

Rick.
[email-masked]           Secure Computing Corporation
"Internet Cryptography" now in bookstores http://www.visi.com/crypto/

Newsgroups: news.groups
Date: Wed, 15 Oct 1997 06:28:22 +1000 (EST)
From: ? the Platypus {aka David Formosa} <[email-masked]>
Reply-To: [email-masked]
To: Dave Del Torto <[email-masked]>
cc: IETF OpenPGP List <[email-masked]>
Subject: Re: [VOTE] comp.security.pgp.test
Sender: [email-masked]

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

[...Also posted to news.groups...]

On Tue, 14 Oct 1997, Dave Del Torto wrote:

> The "comp.security.pgp.test" newsgroup has been proposed and voting is
> underway (courtesy of the UVV).

[...prefilled ballot snipped...]

Distrabuting prefilled voting ballots is voting fraud under the UVV rules
and is highly likely to cause the results to be invalidated.  It is within
the bounds of probility that this action of yours will force a revote and
delay the creation of this group.

- -- 
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: Tue, 14 Oct 1997 20:44:30 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: proposal: commercial data recovery
Sender: [email-masked]

Hal Finney <[email-masked]> writes:
> Adam Back <[email-masked]> writes:
> > [CDR or "anti-GAK" design principles]
> 
> You do a good job of saying what you want to avoid, but not much about
> what you want to accomplish!  You are doing this to satisfy some kind
> of market need for commercial access to data.  What are the requirements
> your design will satisfy?  What do the customers need?  You can't design
> a system based solely on what it doesn't do.

So?  Of course you can't design a system based soley of don't dos.

The instructions for using the principles are:

  The principles are a set of negative "don't dos" to overlay on to the
  normal cryptographic protocol and software architecture design
  process.

  Use your ingenuity and existing knowledge of cryptographic
  primitives and good software design, user ergonomics, and user
  requirements to design a system which meets your user requirements
  while breaking as few as possible of the principles. 

What the principles attempt to do is codify the pro-privacy
cryptographers natural tendencies to want to avoid implementing and
fielding systems which can be of use to GAKkers.

I have not seen any refutation of my demonstrations that pretty much
all of PGP's current functionality can be acheived within anti-GAK
design principles.

The most worrying of uses that your software could be put to by
GAKkers is as an implementation of a fully functioning GAK system in a
company like Iraq where the thought police will literally torture
citizens to death for non-government approved thoughts.

PGP Inc's CMR design could I think it is reasonable to argue is a
ready to roll GAK system.  It could be installed by the Iraqi
government with force of law tomorrow.  Each service provider installs
the PGP policy enforcer, and configures the "message recovery" key to
be "[email-masked]"; each business with a leased line is ordered
to do as the ISPs, and individuals are required to use pgp5.0 or
pgp5.5 (either of which is GAK compliant).

Now the secret police can read all their citizens mail, and PGP will
have provided the technology.  Does that make your collective chests
swell with pride?  No it doesn't.  It fills you with dispair, and
disgust that someone would so abuse your software, and so ignore your
well meaning recommendations about ethical business behaviour.

However your disgust and despair, and well meangings won't help
prevent the civil rights violations occuring in Iraq using your
software.  Your well meaning won't help people in the US either, if
the USG adopts PGP and passes laws to do the same as I described for
Iraq.  It could happen.  If PGP is sucessful, and the OpenPGP standard
makes it to Netscape SSL like acceptance levels, and the OpenPGP
standard includes the CMR functionality, well you will have built the
GAKkers their dream system.  Something with a smooth migration path
for GAK.

You will notice that Bruce Schneier forwarded a message to cypherpunks
where the GAKkers are quoteed already praising the functionality of
pgp 5.5 in proving them with GAKware.

If PGP on the other hand were to adopt the CDR system, and put their
energies in working out the design details, they would find firstly
that they can acheive all the necessary functionality, and that I and
Bruce Schneier, and Peter Trei, and lots of other people would stop
saying rude things about them.  But more importantly, they would be
fielding a non-GAK compliant system, and a non-GAK compliant protocol
in OpenPGP, and that will do much more to save our collective bacon
from having our comms key word searched by the GAKkers than PGP Inc's
undubitably well meaning words of assurance of their good intentions.
Really, once you strip out the sarcasm, I am not at all denying PGP
Inc's good intentions.

The problem is: good intentions don't prevent GAK.

Albert Einstein designed the nuke.  He was a nice enough guy, who
wouldn't have advocated nuking millions of people but that sure didn't
help prevent Hiroshima.

> PGP, Inc. has made its design choices based on interaction and discussion
> between people responsible for security, human interface, sales/marketing
> and customer support, as well as the customers themselves.  The lessons
> which have come out of this include an emphasis on solutions which
> people can use and which will work in the field.  This means they have
> to be transparent, easy to learn, fit into existing procedures, and
> be reliable, as well as being secure.  Systems which require extensive
> retraining, new operational procedures, or which will hurt reliability
> are not acceptable - they simply won't be deployed.  That's the reality.

Of course, and you would use those considerations to balance the
"don'ts" in the design principles.  An important consideration of the
design principles is that deployment of anti-GAK software wins;
therefore the design principles also state that you should do your
best to design systems which your users will be pleased with, which
they will buy.  As a pro-privacy advocate in the crypto software
industry you therefore have dual moral obligation:

- to design systems which aren't GAK compliant

- to work your butt off making your user ergonomics so excellent that
  you wipe out the competition

This is because your concern should be to ensure that the majority of
users are using non-GAK compliant software, so that the GAKkers will
find it more logistically difficult to install GAK; so that they will
have a hard time persuading users to switch to TIS
"voluntary/mandatory" GAKware.  The won't switch because they love the
slick GUI, they won't switch because they don't want to be bothered
replacing their software, and a few won't switch because they realise
what the GAKkers are up to.

> A system with forward secrecy on email and rapid turnover of
> communications keys has some attractive security properties, but you
> need to look at the other aspects of using it.  How will it respond to
> errors?  How can companies guarantee that they will be able to decrypt
> data when they need it?  Can you assure that no data will ever be around
> which requires a key which no longer exists, and can you do so not in
> a theoretical world where everything works perfectly, but in a real
> company where people make mistakes and forget things?

The forward secrecy is a separable issue, actually.  And is a good
example of balancing anti-GAK design principles against ergonomics
etc.  Personally I think you could acheive it without that much extra
effort with minimal to no ergonomic impact.  We can argue about this
separately as it is not really the central issue.

The key points are that there should only be one crypto recipient of a
message, and that the key used to encrypt the message and that
compromise of either the senders and/or the recipients systems should
be required to compromise the message.

This clearly allows recovery of the message contents, because the
communications key can be stored encrypted to a recovery key on the
recipients disk.

> With our current design, as I described earlier, we have data structures
> which will enable people to easily replace encryption keys, 

So?  That is just as easy to do in any number of possible design
permutations without having GAK compliancy.

> It looks to me like our current model supports the necessary feature
> set for what you want to do, so I don't see any need for changes.

What _I_ want to do completely irrelevant.  It matters not a fig what
I do tinkering with some scripts for my own amusement, or in selling
to 1% of the market.  What matters is what PGP does in selling to 50%+
of the market, and what the OpenPGP standard says in being used by 90%
of the market.  If the OpenPGP standard requires GAK compliancy we
have a serious problem.

I'm much more interested in persuading you personally, and PGP Inc
that what they are doing is GAK compliant, and that by switching to a
CDR design they can avoid this GAK compliancy.

My interest in OpenPGP is that in the event that we are unsuccessful
in persuading PGP of dangers of their CMR system, that we have a fall
back in being able to still make OpenPGP compatible clients which
aren't compatible, so that other companies can field systems which
aren't GAK compliant, and can achieve their corporate data recovery in
morally responsible ways.  In this event I would be vying for the
other companies to flourish at the expense of PGP Inc going bankrupt.

> The one new suggestion has been to have separate communication and storage
> keys, but this has several problematic aspects.  Unlike the distinction
> between encryption and signature keys, where it is obvious whether a key
> is being used properly, it is not at all clear whether a particular
> function represents communication or storage.  Consider the case of a
> remotely mounted file system, where what looks like a storage operation
> is actually travelling across a (possibly insecure) network.

That has nothing to do with the design of the way PGP implements to
the OpenPGP standard.

What that says is that if you are involved in design of VPN or IPSEC
products that they should also be designed with anti-GAK design
principles.

You have to develop a sense of proportionality about the significance
of each anti-GAK principle as applied to each communication you apply
it to.

> Another example comes from the initial version of the Eudora API.  When
> that makes calls out to the crypto library to encrypt messages, Eudora
> actually stores the message in a disk file, has the library encrypt that
> to another disk file, then constructs the message from that output file.
> It will look to the library like it is encrypting a disk file using a
> communications key, a violation of this proposed security policy.

If the disk is NFS mounted it would be.

You have to apply some critical thinking to designing any system.  So
it is with designing according to the anti-GAK principles.  Having
sound design principles doesn't negate the need for critical thought
in any design field.

What are you thinking above?  That GAK might be implemented by
governments forcing us to use GAK compliant replacements for SSH, for
IPSEC and VPN software, and thereby be able to snoop on your email?

Firstly it sounds kind of round-about approach, and secondly the
correct area to solve this problem is in the purchase of non-GAK
compliant IPSEC and VPN software.  Or if PGP gets around to IPSEC in
the design of non-GAK compliant IPSEC software.  (Don't tell me: PGP
would design IPSEC packets with GAK compliant CMR also?)

You have to apply the above sort of critical reasonsing, and balanced
evaluation of weak point of the system.

> In fact, in most cases a storage key will not be a public key at all,
> but will be a symmetric cipher key, such as with our own PGPDisk product.

When I was arguing for a separate storage key, I was thinking that you
would want a symmetric storage key.  Perhaps pgp -c, or pgp -cs
functionality.

If you use the CDR method, and use symmetric storage keys, with
multiple storage recipients (one symmetric key (you), one asymmetric
company recovery key) for the stored mail folder, you have message
recovery.

Actually you could get away without storage keys as such, in that you
could store the recovery information for your encryption key on the
local disk.  If you were to use this simple change and discard the
second enforced crypto recipient field (which breaks the second
anti-GAK princile) you could have the minimal set of modifications
needed to convert pgp 5.5 into an non-GAK compliant system.

See any specific flaws in that?

The only thing it does not allow is corporate message snooping.  I
have yet to see a PGP employee admit that pgp5.5 is designed to meet
the user requirement of message snooping.

> This allows transparent disk encryption and decryption.  In that case you
> really don't have "storage keys" as such in the public key infrastructure,
> so there is no need for a distinction.

Yes.  And that is the ideal system in my view.  However I notice that
pgp doesn't have a PGPdisk for the PC, nor for any versions of unix.

I don't have a MAC.  MACs are nice machines and all, but they don't
actly have the lions share of the market as IBM compatible PCs do.  I
encourage you to develop disk systems for other platforms.

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, 14 Oct 1997 15:17:15 -0400
From: [email-masked]
To: [email-masked]
cc: IETF OpenPGP List <[email-masked]>
Sender: [email-masked]

.-----------------------------------------------------------------------
| 1ST CALL FOR VOTES: comp.security.pgp.test
| Official Usenet Voting Ballot <CSPT-0001> (Do not remove this line!)
|-----------------------------------------------------------------------
| Please provide a valid name, or your vote may be rejected.  Place
| ONLY your name (i.e., do not include your e-mail address or any other
| information) after the colon on the line below.
 
Voter name: Robert Guerra

| Insert YES, NO, ABSTAIN, or CANCEL inside the brackets for each
| newsgroup listed below (do not delete the newsgroup name):
 
Your Vote   Newsgroup
---------   -----------------------------------------------------------
[   YES   ]  comp.security.pgp.test

Date: Tue, 14 Oct 1997 19:11:18 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: proposal: commercial data recovery
Sender: [email-masked]

Bill Frantz <[email-masked]> writes:
> At 2:37 AM -0700 10/14/97, Adam Back wrote:
> >...
> >2. second crypto recipients on encrypted communications are not
> >   used to allow access to third parties who are not messaging
> >   recipients manually selected by the sender
> >...
> >
> >Included in 2) is the principle of not re-transmitting over
> >communication channels keys or data re-encrypted to third parties
> >after receipt -- that is just structuring -- and violates design
> >principle 2.
> 
> This requirement tries to enforce something which can not be enforced by
> technical means.  That is, when you send another person some data, there is
> no technical way you can prevent them from using it however they want.  For
> example, a user can always program his filters (given something like
> procmail) to send decrypted data anywhere he wants.

I agree with that statement entirely.

The principle has deeper meaning than your point.  It acknowledges
that there are limits to what can be done to enforce things in
software.  What it argues is that you should enforce what you can
where this helps you to make your software less useful to GAKkers
without modifications.  So if this means that the GAKkers can't use
your software with out getting you to re-write it, or without making
the modifications themselves this is good because fielded systems have
intertia.  It takes time and costs money to make software updates,
doubly so where people will be hostile to those updates.  People who
would otherwise not care about GAK will suddenly "care" because they
are too lazy to update their system, or becaues the update will cost
them money.

Btw. Lest it is not clear, when I say "should" in this discussion of
the anti-GAK protocol design process I mean "should" according to my
CDR or "anti-GAK" protocol design principles.  If following these
principles causes you to have non functioning or unsaleable designs,
and when this occurs you should still try to violate as few of the
design principles as possible.

So for your .procmail filter example: what the principle says is that
you should make it as non-automatable as possible in your software to
do this redirection in electronic form.  The danger about automated
redirection in electronic form is that there will be a nice little box
saying for you to type: "recovery@lazarus", where lazarus is the
address of the recovery machine on your LAN, but then the GAKkers can
pass laws and all the people who bought your software will be
automatically able to comply by filling in that box with
"[email-masked]"; alternately the GAKkers may buy your software
for re-sale in Iraq and then fill in the field with or
"[email-masked]", with the result that Iraqis.

So for example with your .procmail example: the email client should
decrypt the traffic with short lived keys to provide forward secrecy,
and re-encrypt the plaintext for storage in your mail folder with a
recoverable key (presuming you want corporate data recovery of your
mail folder in case your dog chews your smart card key token).

Forwarding of email at the .procmail level won't help the GAKkers in
this case because the email is still encrypted; and the anti-GAK
protocol design principles state that the encrypted message should be
encrypted to one recipient only: you.

The anti-GAK design principles also mean that you should offer no
tools to decrypt from the command line.  This ensures that GAKkers
will be hindered from using software provided by you to cobble
together a GAK system, without writing and distributing software
themselves.

Think of the CDR or anti-GAK software principles as attempting to
codify your natural predilections as a GAK hating protocol designer.
They codify how best to design your software to hinder GAKkers.

Clearly the GAKkers can pass a law saying that you must manually
forward each of your emails after decryption to them, but if the
software provides no easy way to automate this process they are asking
the impossible if there are 10 million US citizens using the software.

Contrast this to PGP Inc's CMR design where all that is required is a
change to one field for completely automated over the wire key word
searches.

> N.B. I applaud Adam's direction of building the data recovery businesses
> need without helping 3rd parties engage in undetected snooping.  Keeping
> the decryption keys (if data is not stored in the clear) near the
> legitimate copies seems to be a useful step in this direction.

I like your locality point.

It is something I had not earlier considered had more than binary
meaning (communicated or not ever communicated).  However it does.
The Frantz corollary to the anti-GAK protocol design principles is
then:

i)  recovery information should be kept as close to the data as possible

ii) if recovery information is moved it should in preference not be
    transferred using over communications networks, and should
    not be transferred automatically by the software without requiring
    human interaction.

You can see that this design principle leads to some at first
apparently absurd requirements, but actually they are all sensible and
pertinent.  If the software requires user interaction to transmit
recovery information this means therefore that it should not be
possible with the software as is to write automatic scripts; this
contributes to the uselessness of the software to the GAKkers.

Of course there are ways around everything (eg. scripting software
which allows mouse and keyboard actions to be automated); but we are
trying to avoid easy cobbling together actions by the GAKkers allowing
them to convert our software designed under anti-GAK principles into
one which can then becomes automated GAK system.

Also clearly there is some user intelligence required in the design
process to work out functionalities it is worth forgoing where it
comes to this by comparing their potential value to the GAKker against
the ergonomic or utility advantage to the user.

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, 14 Oct 1997 11:02:45 -0700
To: IETF OpenPGP List <[email-masked]>
From: Dave Del Torto <[email-masked]>
Subject: [VOTE] comp.security.pgp.test
Sender: [email-masked]

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

The "comp.security.pgp.test" newsgroup has been proposed and voting is
underway (courtesy of the UVV). See: <news:[email-masked]>, or
go to <news:comp.security.pgp.resources> ("comp.security.pgp.test" thread).
This newsgroup is proposed as a place for interoperability test-posts of PGP messages/objects. It could be of great value to anyone building an OpenPGP implementation, so if such is your interest, I urge a YES vote.

To place a "yes" vote, send mail to: <[email-masked]>
<mailto:[email-masked]?subject=Re:%20CFV:%20comp.security.pgp.test>
The BODY of your message should contain ONLY the following lines (DO NOT
include the "cut lines"):

................................. cut line .................................

.-----------------------------------------------------------------------
| 1ST CALL FOR VOTES: comp.security.pgp.test
| Official Usenet Voting Ballot <CSPT-0001> (Do not remove this line!)
|-----------------------------------------------------------------------
| Please provide a valid name, or your vote may be rejected.  Place
| ONLY your name (i.e., do not include your e-mail address or any other
| information) after the colon on the line below.

Voter name: *****INSERT-YOUR-NAME-HERE*****

| Insert YES, NO, ABSTAIN, or CANCEL inside the brackets for each
| newsgroup listed below (do not delete the newsgroup name):

 Your Vote   Newsgroup
 ---------   -----------------------------------------------------------
[   YES   ]  comp.security.pgp.test

................................. cut line .................................

Date: Tue, 14 Oct 1997 17:45:37 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Discussion
Sender: [email-masked]

[The question of list relevance... is there a better place to discuss
this where all the parties are reading (OpenPGP standards authors, PGP
Inc employees, and other interested parties)?  The political
discussion does seem somewhat relevant in that both PGP with their CMR
system and the CDR proposal base many of the technical features on
privacy issues.  One suggestion is perhaps to flag political
discussion [P] on the subject line.  Then people seeking to discuss
purely technical issues can skip to those items.  Comments?]

Tim Philp <[email-masked]> writes:
> At 10:11 AM 10/14/97 +0100, you wrote:
> > I'm not saying that the recipient's organisation doesn't have a
> > right to read their e-mail. I think everyone pretty much agrees on
> > this point by now.
>
> I would NOT assume this. Does a company have the right to read any 
> snail mail that you receive at your office? Not if it is addressed to 
> you. I think that this is an extention of this privacy. This is off 
> topic for this list, but I felt the point had to be made. Don't give 
> up on issues like this or others may give up on issues such as GAK!

Tim has a good point there.

We, in discussing ways to design non GAK compliant company data
recovery software face an extremely fine balancing act.

We have to demonstrate to people who argue that GAK compliant software
such as pgp5.5 using PGP Inc's GAK compliant CMR design that software
designed to CDR anti-GAK design principles can meet all of their
perceived requirements.  We have to do this otherwise they will throw
up their arms and claim that they couldn't possibly use CDR because it
can't do x.  So far the closest to an x CDR can't directly cope with
is Zooko's example of off-site backup (backup in the hard disk backup
meaning) with company data recovery.  CDR principles do however still
improve the anti-GAK rating of the software considerably through use
of foward secrecy and super encryption on the channel.

The thing to remember when the anti-GAK CDR side of the fence people
are running through these exercises thrown at them by the GAK-happy
CMRers (and also presented by CDRers to help think-ahead about things
CMRers may object to (I am fairly confident that both Zooko falls into
this category)), that it is likely that where the CMRers challenge
involves unsavoury overtones, that the person doing the demonstration
is fully aware of this, and merely doing the exercise to prove that
CDR has equivalent functionality.  

In an effort to demonstrate this distaste, to prevent
misunderstanding, you may see the anti-GAK person make disclaimers
such as "not that I'd recommend you do this or anything, it seems more
than a bit big brotherish to me", or you may see them come up with
suggestions for what more liberal minded companies should so instead,
or offer as options.  I will mark such counter points as "counter:"
below in the analysis of the types of recovery being argued for by the
CMRers.

Also it is important to note that just because something is possible
to implement with anti-GAK CDR principles doesn't mean you should
build it.  Your company might make a stance against for example email
screening by not providing software which can do this.  Or another
method is to maintain separate versions of your software which cater
to different levels, and to make the more snoopy ones progressively
more expensive to deter people from buying them unless they have a
need.  Also your company can make risk assesments for the company and
suggest least snoopy versions.

There are three real requirements which are being argued for here:

1. recovery of data on a disk after the user loses keys (forgets
   password, lets dog chew smart card etc)

2. recovery of email which is stored in mail folders in encrypted form
   by a mail client (password loss again)

3. snooping on email with some weak amount of tamper resistance to
   prevent the sender or recipient hacking around it

Type 1: is relatively uncontroversial: most people will agree with this
if the data on the disk has commercial value to the company, they need
good data availability, and good assurance that data will not be lost.

Counter 1: Disk encryption software can be designed with options for
more progressive companies to allow their users the option of a
separate encryption partition without company recovery facility.
(See, a disclaimer of the type I mentioned above:-)

Type 2: is a bit more politically sensitive people make points such as
you do drawing analogies to paper mail received at work and the
expectations of privacy that this has.

Counter 2: One way to diffuse the political aspects of this situation
is to encourage companies to have transparent policies (and this idea
is credited to the CMRers at PGP Inc, so they are not entirely lost
causes).  This idea says that where the email address is archived such
that the company could read it when they recover the users key if he
forgets his passphrase, that this possibility for company reading of
archived email should be made clear to both the sender and the
recipient by their mail clients.  This is a very good idea.  There are
a whole selection of statements of intent about how email will be
treated which it might be nice to make clear to both sender and
recipient examples might be:

- no archive kept

- archive kept, but company has secret split recovery keys in small
  tight nit company, and users have high expectation that company will
  not snoop

- no recovery of this key, no archive either

and so on.

Counter 2b: Another way to diffuse this is to design the email
standard and client software so that it has two email address fields.
One for company use, and another private comments.  People can fill in
the private field with their email account at a commercial ISP.  The
keys used to encrypt to this second email would not be recoverable
through the companies data recovery mechanism.

Type 3: now we really get controversial, do companies have the right
to snoop employees email if they get suspicious, or even have policy
of screening outgoing and reading incoming mail.  Most people get
uncomfortable about this one.  

Counter 3: I'm not convinced that it's necessary for anyone without
NSA HQ style strip search at door, with no electronics allowed in or
out of building.  Never the less it is possible with CDR to do
something similar, and this is good to the extent that certain CMRers
might argue against using CDR anti-GAK principles at all without this.

The over-riding principle is to field no GAK compliant software.  CDR
allows that.  A second principle is to encourage companies to behave
nicely, and to allow as much personal privacy as they can be persuaded
to allow.

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, 14 Oct 1997 09:29:10 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: proposal: commercial data recovery
Sender: [email-masked]

Adam Back <[email-masked]> writes:

> If we take the design goal of designing a commercial data recovery
> system which is not GAK compliant, we can most succinctly state this
> design goal as the task of ensuring that:
>
> - at no point will any data transferred over communications links be
>   accessible to anyone other than the sender and recipient with out
>   also obtaining data on the recipient and/or senders disks

You do a good job of saying what you want to avoid, but not much about
what you want to accomplish!  You are doing this to satisfy some kind
of market need for commercial access to data.  What are the requirements
your design will satisfy?  What do the customers need?  You can't design
a system based solely on what it doesn't do.

PGP, Inc. has made its design choices based on interaction and discussion
between people responsible for security, human interface, sales/marketing
and customer support, as well as the customers themselves.  The lessons
which have come out of this include an emphasis on solutions which
people can use and which will work in the field.  This means they have
to be transparent, easy to learn, fit into existing procedures, and
be reliable, as well as being secure.  Systems which require extensive
retraining, new operational procedures, or which will hurt reliability
are not acceptable - they simply won't be deployed.  That's the reality.

A system with forward secrecy on email and rapid turnover of
communications keys has some attractive security properties, but you
need to look at the other aspects of using it.  How will it respond to
errors?  How can companies guarantee that they will be able to decrypt
data when they need it?  Can you assure that no data will ever be around
which requires a key which no longer exists, and can you do so not in
a theoretical world where everything works perfectly, but in a real
company where people make mistakes and forget things?

If you were to talk to people responsible for human engineering and
deployment you'd find that there are many more considerations which go
into a successful system than theoretical security properties.  Otherwise
we'd all be using one time pads.

With our current design, as I described earlier, we have data structures
which will enable people to easily replace encryption keys, if a system
can be designed to solve the usability problems in a practical way.
It looks to me like our current model supports the necessary feature
set for what you want to do, so I don't see any need for changes.

The one new suggestion has been to have separate communication and storage
keys, but this has several problematic aspects.  Unlike the distinction
between encryption and signature keys, where it is obvious whether a key
is being used properly, it is not at all clear whether a particular
function represents communication or storage.  Consider the case of a
remotely mounted file system, where what looks like a storage operation
is actually travelling across a (possibly insecure) network.

Another example comes from the initial version of the Eudora API.  When
that makes calls out to the crypto library to encrypt messages, Eudora
actually stores the message in a disk file, has the library encrypt that
to another disk file, then constructs the message from that output file.
It will look to the library like it is encrypting a disk file using a
communications key, a violation of this proposed security policy.

In fact, in most cases a storage key will not be a public key at all,
but will be a symmetric cipher key, such as with our own PGPDisk product.
This allows transparent disk encryption and decryption.  In that case you
really don't have "storage keys" as such in the public key infrastructure,
so there is no need for a distinction.

As it stands, you could design a system to use rapid replacement of
email encryption keys in order to provide forward secrecy, without any
changes whatsoever to the existing key structure as it is documented
in the current draft spec.  The operational problems of creating such a
system which is reliable and usable are going to be very severe, but the
support is there in the Open-PGP data formats, and other companies and
groups are welcome to tackle them.  However I don't think that Open-PGP
is the right forum for the discussion, since the issues are largely
matters of user interface and customer support.

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

Date: Tue, 14 Oct 1997 08:53:56 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Bill Frantz <[email-masked]>
Subject: Re: proposal: commercial data recovery
Cc: [email-masked]
Sender: [email-masked]

At 2:37 AM -0700 10/14/97, Adam Back wrote:
>...
>2. second crypto recipients on encrypted communications are not
>   used to allow access to third parties who are not messaging
>   recipients manually selected by the sender
>...
>
>Included in 2) is the principle of not re-transmitting over
>communication channels keys or data re-encrypted to third parties
>after receipt -- that is just structuring -- and violates design
>principle 2.

This requirement tries to enforce something which can not be enforced by
technical means.  That is, when you send another person some data, there is
no technical way you can prevent them from using it however they want.  For
example, a user can always program his filters (given something like
procmail) to send decrypted data anywhere he wants.

The idea that you can control what users do with data thru technical means
is the most common flaw I see when people think about security.

N.B. I applaud Adam's direction of building the data recovery businesses
need without helping 3rd parties engage in undetected snooping.  Keeping
the decryption keys (if data is not stored in the clear) near the
legitimate copies seems to be a useful step in this direction.

-------------------------------------------------------------------------
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: Tue, 14 Oct 1997 14:29:33 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: commercial data recovery
Sender: [email-masked]

Zooko Journeyman <[email-masked]> writes:
> Adam, I applaud your effort to steer discourse toward 
> productive work re: GAK, CMR, CDR.  I haven't thought about 
> your idea enough to have a definite opinion, but at first blush
> it seems a promising strategy to design high-security and 
> forward-secrecy for communication but recovery/sharing features
> for stored data.

Thank you.  I would encourage others to read the proposal, and
provide criticisms of it.

> I wonder if it is too much early-days to start talking about
> advanced protocols e.g. secret-splitting in IETF-Open-PGP?  
> Probably so.  Better just punch out a standard with current
> tech...

I agree entirely.  The motivation for attempting to formalise the CDR
design principles, and for exploring designs which are non-GAK
compliant is based on these lines of reasoning, that we should:

1. Persuade PGP Inc that there are less GAK friendly ways of
   implementing data recovery

2. If that argument fails, and in the event that PGP were to try to
   influence the IETF OpenPGP forum to adopt any features relating to
   pgp5.5 GAK compliant functionality into the OpenPGP standard that we
   have an alternate proposal well enough thought through to compete
   with PGP's CMR proposal with sound technical arguments.

3. Of improving the state of the technology by working to include
   forward secrecy as much as possible into secure email messaging.
   This is a very effective method of giving the bird to the
   GAKkers, by purposefully destroying communications keys as soon as
   possible after the fact.  This is consistent with the CDR design
   goal: make the GAKkers job as difficult as possible.  Frustrating the
   GAKkers is a fun, morally satisfying activity.

> Hm.  What about the idea of storing your data remotely (for
> cost-efficiency, safety, etc.) using encryption to maintain 
> your privacy?  In that case, the distinction between comms and
> storage keys is blurred.  A company may choose to e.g. store 
> all long-term data at Zooko's Backup Server, encrypted in such
> a way that some combination of corporate keys (controlled by 
> individual employees and/or departments) is necessary to 
> decrypt each package of data.  This would open the door, as you
> fear, for a government to mandate that _its_ key be added to 
> each set, with authority to open any package even without the 
> cooperation of any corporate keys.

The application you describe has very interesting implications for the
CDR vs CMR debate.

I think that one way that you could implement remote backup in a way
which is sympathetic to CDR design principles like this:

- The communications security aspect could be acheived via the normal
  design for securing communications derived from the CDR design
  principles.  That is using short lived communications keys with no
  third party access to communications in transit without access to
  hard disks at either end.

- The data would be super-encrypted to the companies backup recovery
  storage key(s).

This technically violates the CDR design goal and principles of not
allowing third party access to communicated data, super encryption
doesn't negate this, it is just more structuring.

However, super-encryption does minimise the damage by preserving CDR
principle that recovery of data should require physical compromise of
one or both end points, which I think is an important principle, and
a useful property in this case.

This lesson leads to the corollary to the CDR principles that:

- if you can't keep to the principle of not transmitting data with third
  party recovery information attached,

that:

- super-encryption of the transmitted recoverable data can be
  used to at least preserve the requirement for one or both ends of
  the communication to be compromised to effect third party access.

But still, the remaining way that this system could be perverted would
be as you say for the GAKkers to demand to be one of the storage
accessors for the encrypted disk backup, and for the GAKkers to then
attempt to coerce the remote storage service provider to hand over the
ciphertext, or for the government to set themselves up as a central
provider of off site backup services.

The GAKkers desire for automatic access to communicated storage data
is frustrated to the maximal extent possible by those CDR design
principles we have managed to retain.  To achieve automated access the
GAKkers must start replacing software, and we have prevented automatic
snooping of our backup data whilst it is in communication, with
software we have fielded.

- CDR design principles do not prevent someone modifying software, but
  as we all know deployed systems are additional obstacles to overcome:
  they have to coerce some company in to implementing the new software
  with built in GAK, and they have to coerce everyone into replacing
  their existing software with this unpopular new software.

Widely deployed systems can be large obstacles.  The mess the US IRS
in with their millions of lines of hard to modify source attest to
this fact.

The IRS scenario has some lessons for us, for possible additional CDR
design principles:

- keep the source code out of reach of GAKkers so that they can not
  coerce us so easily to modify it.  Off shore backup might be useful;
  destroy the backup recovery key if GAK comes in.

- make systems non-interoperable where this does not interfere with
  functionality

- have mandatory GAK company contingency plans such as moving the
  company to Switzerland.

That first suggestion costs so much in the loss of user access to
source code to assure ourselves that there is no backdoor that we
probably can't employ it.  The other two look like sound principles to
me.

> Zooko's Backup Server can be physically located in a country 
> free of such intrusive organizations, but of course it is the
> intrusive organizations of the _client's_ country that become
> important with that kind of protocol...

One comfort which can be drawn from the above design using super
encryption inside a communications envelope protected with short lived
non-escrowed communication keys, is that the fielded software could
not be used as-is to prevent the practice of jurisdiction shopping.

Another comfort is that companies can, even if forbidden from using
offshore remote backup facilities, simply stop using remote backup
facilities at all, unless the GAKkers really go overboard and demand
that all citizen units will run this government remote backup software
to upload diffs of their disks to government run backup services.  I'm
sure they would love to do that, and charge you for the "service" too.

Also I expect there would be significant political hurdles for the
GAKkers to overcome in mandating government run remote backup services
for citizen units, or even for companies in our countries.

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, 14 Oct 1997 09:29:24 -0400
To: [email-masked]
From: Tim Philp <[email-masked]>
Subject: Re: Discussion
Sender: [email-masked]

At 10:11 AM 10/14/97 +0100, you wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Anthony E. Greene wrote:
>
>> Isn't this what personal email accounts are for?
>
>I'm not saying that the recipient's organisation doesn't have a 
right to
>read their e-mail. I think everyone pretty much agrees on this point 
by
>now. 

I would NOT assume this. Does a company have the right to read any 
snail mail that you receive at your office? Not if it is addressed to 
you. I think that this is an extention of this privacy. This is off 
topic for this list, but I felt the point had to be made. Don't give 
up on issues like this or others may give up on issues such as GAK!

Tim Philp

PGP Key Fingerprint: AFA0 8393 8D8A 00EC FBFF 4822 DCD1 5C27 0069 02E7 
Public key available at pgpkeys.mit.edu

From: [email-masked]
Date: Tue, 14 Oct 1997 14:13:39 +0200 (MET DST)
To: Zooko Journeyman <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: commercial data recovery
Sender: [email-masked]

On Tue, 14 Oct 1997, Zooko Journeyman wrote:

> Zooko's Backup Server can be physically located in a country 
> free of such intrusive organizations, but of course it is the
> intrusive organizations of the _client's_ country that become
> important with that kind of protocol...

How about also having Alex' Backup Server, and using some
shared-secret/whatever tech to ensure that you need to contents of _both_
servers to actually reconstruct the data. This would be a 'Distributed
Encrypted Backup Sysyem'.

This might make it very hard for anyone to access your data without your
knowledge/cooperation.

And if you use something like Onion Routers, it might even be quite
impossible for some lawenforcement agency to actually find out which one
of those encrypted files on the servers contains your backup.

Alex

---
I dabble in techno-house and sometimes,
I do that badass hip-hop thang...
But the F U N K gets me every time!

Date: Tue, 14 Oct 1997 12:53:39 +0200 (MET DST)
From: Zooko Journeyman <[email-masked]>
To: [email-masked]
Subject: commercial data recovery
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

[Note-- I am not subscribed to ietf-open-pgp at this time.  My
 apologies if this submission from a non-subscriber is 
 unwanted.  I will be brief.  --Zooko]

Adam, I applaud your effort to steer discourse toward 
productive work re: GAK, CMR, CDR.  I haven't thought about 
your idea enough to have a definite opinion, but at first blush
it seems a promising strategy to design high-security and 
forward-secrecy for communication but recovery/sharing features
for stored data.

I wonder if it is too much early-days to start talking about
advanced protocols e.g. secret-splitting in IETF-Open-PGP?  
Probably so.  Better just punch out a standard with current
tech...

Hm.  What about the idea of storing your data remotely (for
cost-efficiency, safety, etc.) using encryption to maintain 
your privacy?  In that case, the distinction between comms and
storage keys is blurred.  A company may choose to e.g. store 
all long-term data at Zooko's Backup Server, encrypted in such
a way that some combination of corporate keys (controlled by 
individual employees and/or departments) is necessary to 
decrypt each package of data.  This would open the door, as you
fear, for a government to mandate that _its_ key be added to 
each set, with authority to open any package even without the 
cooperation of any corporate keys.

I'm not sure how to weigh the relative risks and benefits.  
I (ever so humbly) think that Zooko's Backup Server would be a
great value for businesses, and that part of that value would
be the ability to make data unlockable by various keys, both
for administrative/internal security purposes and for 
robustness against accidents and saboteurs.

Zooko's Backup Server can be physically located in a country 
free of such intrusive organizations, but of course it is the
intrusive organizations of the _client's_ country that become
important with that kind of protocol...

Regards,

Zooko

P.S.  There is already a company whose name I have forgotten 
that offers hard-drive backups over TCP/IP.  They use some 
encryption but I don't know how strong.

Date: Tue, 14 Oct 1997 10:37:21 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: proposal: commercial data recovery
Sender: [email-masked]

If we take the design goal of designing a commercial data recovery
system which is not GAK compliant, we can most succinctly state this
design goal as the task of ensuring that:

- at no point will any data transferred over communications links be
  accessible to anyone other than the sender and recipient with out
  also obtaining data on the recipient and/or senders disks

I think we can distill the design principles required to meet the
design goal of a non-GAK compliant Corporate Data Recovery (CDR) down
to ensuring that:

1. no keys used to secure communications in any part of the system are
   a-priori escrowed with third parties

2. second crypto recipients on encrypted communications are not
   used to allow access to third parties who are not messaging
   recipients manually selected by the sender

3. communications should be encrypted to the minimum number of
   recipients (typically one), and those keys should have as short a
   life time as is practically possible

Included in 2) is the principle of not re-transmitting over
communication channels keys or data re-encrypted to third parties
after receipt -- that is just structuring -- and violates design
principle 2.

With these three principles you still have lots of flexibility because
you can escrow storage keys, do secret splitting of storage keys, and
store keys encrypted to second storage accessors on the local disk for
stored data recovery purposes.

As an additional bonus, principle 3 adds extra security against
attackers gaining access to encrypted traffic after the fact -- the
recipient no longer has the key -- this is a form of forward secrecy.

Systems designed to the CDR design principles are of significantly
less use to GAKkers than PGP Inc's GAK compliant Commercial Message
Recovery (CMR) design.  The CDR design significantly hinders the take
up of GAK if widely deployed.  

Design principle 3 -- forward secrecy -- is inherently hostile to
GAKkers, and is the strongest statement you can make against GAK: you
are purposelly _destroying_ communications keys at the earliest
possible moment to ensure that GAKkers can not obtain the keys by
legal and extra-legal coercion, black mail, and rubber hose
cryptanalysis.

The whole system translates into the Feds having to come and
physically take your disk to obtain information about you, which is
much better than GACK, and not what the GAKkers are interested in at
this point.  The GAKkers would like to install themselves, and coerce
companies into installing for them (via GAKker/USG/NSA/NIST organised
efforts such as the 56 bit export permit for companies installing key
escrow; and efforts such as the Key Recovery Parners Alliance (KRAP)).
I fear that PGP Inc's CMR proposal inadvertently meets most of the
NIST/NSA specified KRAP requirements.

What the GACKers want is systems where they can perform routine key
word scanning and fishing expeditions into your communications from
the comfort of their offices, without your knowledge.  This is push
button Orwellian government snooping.

Within the constraints imposed by the CDR design principles, there is
plenty enough flexibility to acheive the commercial data recovery
functionality to similarly weak levels of enforcability as achieved by
the CMR design.  Weak levels of enforceability are appropriate because
there are other exceedingly easy bypass routes: super-encryption, and
walking out of the office with a DAT tape.

I would like to organise a collaborative effort to write a white paper
discussing how to implement various functionalities using the CDR
design principle.

Then I would like to see discussion of which set of these
functionalities which best acheive the user requirement for company
data recovery.

Lastly I would like to see a collaborative development effort to
provide a example implementation of a CDR system which can be used as
a discussion point for the OpenPGP standardisation process.

I suppose the best place to discuss this process is the IETF forum for
discussion of the OpenPGP standard, the OpenPGP mailing list
(subscribe by sending message body "subscribe ietf-open-pgp" to
"[email-masked]").

I have already had people express in email to me their interest in
doing this.  Those people can speak up if they want to.  Technical
input is sought from people opposed to GAK compliant software, and
from PGP Inc, and others defending PGP's GAK compliant CMR proposal.

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`

To: Jeffrey Gold <[email-masked]>
Cc: IETF OpenPGP <[email-masked]>, pgp-users <[email-masked]>
Subject: Re: Politics & PGP 
Date: Tue, 14 Oct 1997 18:38:24 +0900
From: Hironobu Suzuki <[email-masked]>
Sender: [email-masked]

I>>>>> "Je" == Jeffrey Gold <[email-masked]> writes:
 Je> To those outside the USA, who think they are immune, I suggest
 Je> that your politicians are not any better then those in the USA.

I feel that US goverment have promoted and pressured their policy to
other country ;-<

Anyway, I think that CMRK feature in PGP5.x is political problems of
US goverment or productive problems of PGP Inc for the markets.

I hope to discuss about Open-PGP which should be IETF RFC documents.

						--hironobu
-- 
Hironobu SUZUKI        Independent Software Consultant
E-Mail: [email-masked]
Tokyo, JAPAN.

Date: Tue, 14 Oct 1997 10:11:57 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: IETF OpenPGP <[email-masked]>
Subject: Re: Discussion
Sender: [email-masked]

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

Anthony E. Greene wrote:

> Isn't this what personal email accounts are for?

I'm not saying that the recipient's organisation doesn't have a right to
read their e-mail. I think everyone pretty much agrees on this point by
now. The system proposed by Adam allows this just as easily.

> The only real problems I see with supporting "Recommended Secondary
> Recipient" or "Required Secondary Recipient" are political, not
> technical.

Have you read Adam's posts on this topic? I think he has presented a
very good technical case on why PGP's current implementation is less
secure than the one he has proposed.

> Are we going to discuss the political implications of
> including CMRK in Open-PGP on this list?

I think it is such an important topic that this is unavoidable. But as
Adam said, even without the politics, there are very good technical
reasons for not using the form of CMR that PGP has proposed.

Ian.

Date: Tue, 14 Oct 1997 11:24:04 +0200
To: Open-PGP List <[email-masked]>
From: "Anthony E. Greene" <[email-masked]>
Subject: Re: Discussion
Sender: [email-masked]

At 10:15 13-10-1997 +0100, Ian Brown wrote:
>Will Price wrote:
>
>> If
>> you choose to not send to the CMRK, you can remove it by simply double
>> clicking the CMRK to remove it and the message will be encrypted to the
>> intended recipient only.
>
>Great. If this option is set, it is virtually guaranteed that the
>recipient's organisation is running the SMTP snoop enforcer, so your
>message will be bounced.

Isn't this what personal email accounts are for?

The only real problems I see with supporting "Recommended Secondary
Recipient" or "Required Secondary Recipient" are political, not technical.
Are we going to discuss the political implications of including CMRK in
Open-PGP on this list?

Tony

Date: 14 Oct 1997 5:27:39 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: PGP Implemention
To: [email-masked], IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>To join the pgp-dev group which is very quiet,
I'm already on it - it sure is quiet ! The only mail recently I've seen is my
test mail, and your reply telling me not to do it ! <g>

--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Release Vs 2.6.1.1, on October 14, 1997, in Win95
4.0
	http://www.blackpaw.com/

Date: 14 Oct 1997 5:27:39 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: PGP Implemention
To: "William Allen Simpson" <[email-masked]>, IETF OpenPGP <[email-masked]>
Sender: [email-masked]

>Well, it is SUPPOSED to be about PGP formats and algorithms.
>Unfortunately, PGP(Inc) has not released the formats and algorithms.

RFC 1991 & OpenPGP draft seem to come close, I can try & jigger it from there
..

PGP are beta testing a PGP API, but of course they can't export it ... Why
don't they just move to Britain or New Zealand or something ...
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Release Vs 2.6.1.1, on October 14, 1997, in Win95
4.0
	http://www.blackpaw.com/

From: [email-masked]
Date: 14 Oct 1997 01:44:00 -0000
To: [email-masked]
Subject: Re: PGP Implemention
Cc: [email-masked]
Sender: [email-masked]

From: Lindsay Mathieson <[email-masked]>

> I've been lurking for a while. I am implememnting pgp and was wondering if
> this is an appropriate forum to ask technical questions re the PGP formats
> and algorithms

Well, there is http://www.imc.org/ietf-open-pgp/formats00 which seems
to include the formats - perhaps incompletly - for PGP 5.0.

This group is trying to draft the *future* standard, although there are
some distractions :-)  The future standard looks as though it will be
based on 5.0, so if that is your staring point, look at the above.

As to technical questions on *existing* formats, there are a large
body of developers in lurk mode on the [email-masked] group,
and sometimes PGP, Inc will answer questions - hunt around on their
site for the tech info address.

( To join the pgp-dev group which is very quiet, send mail to
   [email-masked] with a body of "subscribe pgp-dev" only. )

-- 
iang
[email-masked].

Date: Mon, 13 Oct 97 22:47:53 GMT
From: "William Allen Simpson" <[email-masked]>
To: IETF OpenPGP <[email-masked]>
Subject: Re: PGP Implemention
Sender: [email-masked]

Laughing out Loud....

> Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id NAA26707 for <[email-masked]>; Mon, 13 Oct 1997 13:55:30 -0700 (PDT)
> Message-Id: <[email-masked]>
> Received: (qmail 5644 invoked from network); 13 Oct 1997 20:58:42 -0000
> Received: from unknown (HELO lindsay) (unknown)
>   by unknown with SMTP; 13 Oct 1997 20:58:42 -0000
>...
> From: Lindsay Mathieson <[email-masked]>
> I've been lurking for a while. I am implememnting pgp and was wondering if
> this is an appropriate forum to ask technical questions re the PGP formats
> and algorithms
>
Well, it is SUPPOSED to be about PGP formats and algorithms.
Unfortunately, PGP(Inc) has not released the formats and algorithms.

Instead, this has become a forum for speculating about future PGP(Inc)
products, and arguing about crypto-politics.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Date: 14 Oct 1997 19:50:49 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: PGP Implemention
To: IETF OpenPGP <[email-masked]>
Sender: [email-masked]

Hi All,

I've been lurking for a while. I am implememnting pgp and was wondering if
this is an appropriate forum to ask technical questions re the PGP formats
and algorithms

Thanks - Linz
--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Release Vs 2.6.1.1, on October 14, 1997, in Win95
4.0
	http://www.blackpaw.com/

Date: Mon, 13 Oct 1997 13:28:36 -0400 (EDT)
From: Jeffrey Gold <[email-masked]>
Subject: Politics & PGP
To: IETF OpenPGP <[email-masked]>, pgp-users <[email-masked]>
Sender: [email-masked]

I agree that politics should not be considered in the design
of an OPEN-PGP standards.  However, politics cannot be totally 
ignored.  To do so invites politicians to develop, promote, and 
ultimately pass adverse legislation.  

To those outside the USA, who think they are immune, I suggest
that your politicians are not any better then those in the USA.
They are just a little behind the curve - and once your media 
starts running scare stories (to boost circulation), your
politicians will be able to catch up quick.

Here are some more examples of what is going on in the USA 
political front.

<1> Creation of "President's Commission on Critical 
    Infrastructure Protection" http://www.pccip.gov/
Their charter is to recommend solutions on how to 
prevent "attacks" via computer.  Do you think they
will try to generate headlines which scare the public?

<2> U.S. IN DANGER OF CATASTROPHIC CYBER ATTACK
Robert Marsh, the chairman of  the Commission on Critical 
Infrastructure Protection says that neither government nor 
industry now has the means to protect the United States 
against computer attacks that could shut down communications 
and power grid.  The  commission will deliver its report to
President Clinton this week.  (Montreal Gazette 8 Oct 97)

<3> Fantasy of every unethical policeman and corrupt bureaucrat.
Recently the FBI has started to demand a creepy new anti-privacy
law. It requires that all future technologies -- from cell
phones to WordPerfect -- include a kind of electronic peephole
to let law enforcement agents snoop through your private files
and communications without your knowledge or permission. One
House committee has already approved the FBI's bill.
http://cgi.pathfinder.com/netly/opinion/0,1042,1466,00.html

I do not think that this kind of political rhetoric will
remain confined to the USA.  So, I ask you to CONSIDER 
how to address the political implications, WITHOUT DILUTING 
the effectiveness of PGP.

Date: Mon, 13 Oct 1997 16:14:51 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: IETF OpenPGP <[email-masked]>
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

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

Padgett wrote, quoting Adam:

> >A weakly comparable example might be perhaps the IPSEC standardisation
> >process, and the effect of export regulations on key sizes.  Are IPSEC
> >key sizes allowed to be restricted in the standards so that IPSEC
> >products can be exportable?
> 
> Hope you are not referring to PGP 5.5 here, key sizes are the same 
> as they have always been. Recovery key can be up to 2048 bits.

No, IPSec is a totally different standard relating to Internet Protocol
Security. See IETF drafts at http://www.ietf.org/ids.by.wg/ipsec.html

> Really all that is needed 
> in the standard is the ability to send to multiple recipients - *how*
> or *who* they are is up to the vendor, has nothing to do with the 
> transmission protocol.

OK. We have that. Can we stick with that, rather than adding a field to
a public key that says "if you don't also encrypt to this corporate
access key, your message will simply not be read."

> a gateway or postoffice could refuse to
> handle any message that did not have a specified recipient(s) but again this
> has nothing to do with the transmission protocol.

It does, as it tells sending users that they MUST use the corporate key
or the message will not be received.

Regards,

Ian.

Date: Mon, 13 Oct 1997 10:35:39 -0400 (EDT)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: RE: PGP CAKware & IETF controlled Open-PGP standard
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

>A weakly comparable example might be perhaps the IPSEC standardisation
>process, and the effect of export regulations on key sizes.  Are IPSEC
>key sizes allowed to be restricted in the standards so that IPSEC
>products can be exportable?

Hope you are not referring to PGP 5.5 here, key sizes are the same 
as they have always been. Recovery key can be up to 2048 bits.

>Now some would argue, and with some justification, that emails sent
>using company equipment are the property of that company.  

A bit different here: have never said that the e-mail was the property 
of company (do not think of e-mail as property and doubt that the 
transmission media would imply an immediate transfer/granting of copyright)
still, put enough money in front of a lawyer...

The notion I have put forward is that if you use someone else's property
to send e-mail, they have the right to read it (providing notice will generally
keep you out of court but have never heard of a decision that the owner
could not read).

Is a simple concept: if you use my system, I can control. Now it is true
that "common carriers" have gone to great lengths to absolve themselves
of any responsibility for content. Thusfar no-one has brought suit (that
I know of, ANAL) for someone failing to excercise control. Yet. But the
potential is there (why it is so important to say "may be monitored"
rather than "will be monitored").

>However
>there are other considerations also.  Expectation of privacy is one.

Privacy IMNSHO is not a guarenteed right. In order to have an expectation
of privacy, the sender must perform an act establishing that expectation.
Sealing an envelope is such an act. Encrypting a message is such an act
(possibly even if you just use ROT13). Sending a message in the clear
does noting to provide that expectation - is really the same as sending
a postcard. Reading one may be bad manners but is not criminal.

The negative aspects of a society in which most companies have become
little brother institutions, becoming small versions of what many of
us are fighting: mandatory government access to keys, big brother
wanting the ability to read all traffic.

>I would be somewhat concerned if PGP Inc's recently announced the key
>escrow functionality becomes part of the Open-PGP standard, because it
>will set a bad precedent, and possibly force others who would
>otherwise wish to implement to the open-PGP standard to also implement
>features useful to secret service special interests in enforcing
>mandatory domestic government access to keys, or implement only partly
>compatible systems.

Is hardly that, merely the addition of an additional recipient. Now to
do so without notice would not be a good idea. Really all that is needed 
in the standard is the ability to send to multiple recipients - *how*
or *who* they are is up to the vendor, has nothing to do with the 
transmission protocol.

Would expect that such a message would have no discernable difference from 
any other encrypted message. True a gateway or postoffice could refuse to
handle any message that did not have a specified recipient(s) but again this
has nothing to do with the transmission protocol.

Final comment - suspect that large companies will not have just one such
key, rather there are liable to be hundreds - a *different* one for each 
site/department/program.

					Warmly,
						Padgett

From: "Tony Mione" <[email-masked]>
Date: Mon, 13 Oct 1997 10:02:58 -0400
To: Adam Back <[email-masked]>, [email-masked]
Subject: Re: IETF policy on refusing to allow politics to weaken protocols (Re: Why Adam Back keeps politicizing technical issues)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Oct 13, 12:40pm, Adam Back wrote:
> Subject: Re: IETF policy on refusing to allow politics to weaken protocols
>
> Bill Frantz <[email-masked]> writes:
> > At 2:41 AM -0700 10/11/97, Adam Back wrote:
> > >
> > >5. The IETF process should be accepting proposed designs and deciding
> > >on the best ones, which PGP Inc, and the other suppliers would then go
> > >and implement.  As it is now, as William Allen Simpson just pointed
> > >out, PGP Inc is cruising ahead implementing, and deploying things
> > >without bothering with the OpenPGP process.
> >
> > Just a quick reality check here.  Frequently implementations have proceeded
> > IETF standards.  That is one of the strengths of the IETF process (as
> > compared with e.g the CCITT.)
>

	The reality is that standards generally drag long behind the need for
new technology. In any standards org worth thier weight in salt, the group will
look at existing implementations (not trial implementations but ones that have
been in use for some time). This is called 'Prior Art'. Without prior art, it
is not easy to determine which features or schemes work and which do not.

	The problem we are running into here is that PGP Inc. is marketting
about the only prior art available for this technology. In addition, business
needs will not stand still waiting for a standard to come out in 1-2 years.
This creates a somewhat dangerous situation as Adam has pointed out (Note: I am
NOT PGP-Inc.-bashing. This is merely an outcome of what happens when a vendor
tries to take their technology and 'open' it up).

	I would be concerned if this relatively new addition were being added
to the internet-drafts currently being produced by the group. I know they have
tried to wrestle with all of the issues. I just think we need some more
'experiential' evidence that it is the correct solution. In general, standards
only describe the 'bare-minimum' that an implementation must do to be
'compliant'. There is nothing wrong with leaving certain bells-and-whistles out
of the first pass at a standard. Vendors are always free to add proprietary
features to thier product. That is where the market competition comes in. PGP
Inc. implements thier CMR feature on top of the OpenPGP standard. Another
company attacks the problem a different way and adds a different 'extension'.
In about 5 years, a new standards group updates the 'OpenPGP' standard, argues
over the different schemes and adopts the one with the best technical merit.

> I must admit some ignorance of the IETF processes due to my only
> understandings being gained from intermittent following of the IPSEC
> standardisation process, and in that respect I thank you for the data
> point...
>
> However, I would defend that my understanding is, and my point was
> more that proposals with trial implementations should be used as
> discussion points, and as competing draft proposals rather than being
> used as arguments for it being necessary to build compatibility with
> just because someone has rushed off and sold copies of them, prior to
> ratification of those proposals by the standardisation process.  And
> that independently of the technical merits of those proposals, or
> arguably even in the face of evidence that there are more secure
> alternatives to these proposals.
>
> The IETF standardisation process is supposed to make decisions based
> on technical merit.  Not based on marketing clout.  Nor even based on
> reputation capital, something which PGP surely has in abundance, as
> transferred to it by Phil Zimmermann with his virtual net.god status.
>

	To Adam and others, I would say, work like mad to develop pgp-like
implementations (based on available documents of 2.6 or 5.0 formats) and add in
alternative mechanisms to do the same function (as per Adam's discussion of the
3-key system : signature, transit-encryption, and storage). To others in this
group, I would say keep it simple...especially on a first pass at a standard.

	I have noticed an interesting phenomena in a number of IETF groups. One
group develops a standard that is huge and nearly unimplementable. Another
group comes along and says "We can do it simpler than that". They start
designing and writing documents, run into the same issues the first group did
and eventually start solving them the same way leading to another large
unimplementable standard. Witness: X509 -> PKIX -> SPKI -> OpenPGP. OpenPGP was
supposed to be different because it had a large established user base. Then,
all of a sudden, everyone is arguing over the same issues as the first three
groups...global naming problems, certificate flexibility, key recovery, policy
enforcement...

>...
>
> Adam
>-- End of excerpt from Adam Back

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

Date: Mon, 13 Oct 1997 12:40:20 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IETF policy on refusing to allow politics to weaken protocols (Re: Why Adam Back keeps politicizing technical issues)
Sender: [email-masked]

Bill Frantz <[email-masked]> writes:
> At 2:41 AM -0700 10/11/97, Adam Back wrote:
> >
> >5. The IETF process should be accepting proposed designs and deciding
> >on the best ones, which PGP Inc, and the other suppliers would then go
> >and implement.  As it is now, as William Allen Simpson just pointed
> >out, PGP Inc is cruising ahead implementing, and deploying things
> >without bothering with the OpenPGP process.
> 
> Just a quick reality check here.  Frequently implementations have proceeded
> IETF standards.  That is one of the strengths of the IETF process (as
> compared with e.g the CCITT.)

I must admit some ignorance of the IETF processes due to my only
understandings being gained from intermittent following of the IPSEC
standardisation process, and in that respect I thank you for the data
point...

However, I would defend that my understanding is, and my point was
more that proposals with trial implementations should be used as
discussion points, and as competing draft proposals rather than being
used as arguments for it being necessary to build compatibility with
just because someone has rushed off and sold copies of them, prior to
ratification of those proposals by the standardisation process.  And
that independently of the technical merits of those proposals, or
arguably even in the face of evidence that there are more secure
alternatives to these proposals.

The IETF standardisation process is supposed to make decisions based
on technical merit.  Not based on marketing clout.  Nor even based on
reputation capital, something which PGP surely has in abundance, as
transferred to it by Phil Zimmermann with his virtual net.god status.

I also take exception to PGP's Will Price's attempt at silencing
negative discussion of the security and political aspects of PGP's
GAKware, in his rhetoric on this being an inappropriate forum for
discussion of political aspects of CMR.  If Will Price thinks that we
should just lie down and accept PGP fielding inferior security GAKware
systems, and accept PGP trying to impose them on the standard, he can
think again.  Crypto politics can't help but play some part in
discussion of crypto standards.  

As Tim May pointed out in an earlier post, we gave the same roasting
to companies participating in the Key Recovery Alliance Program, and
to companies like TIS, and IBM for various GAK sell out deals.  In
fact, Netscape got worse roastings for far lesser crimes than PGP's
crimes in attempting to architect GAKware into the OpenPGP standard,
or if that fails, in PGP's death wish in attempting to commit
reputational suicide by implementing and widely deploying GAKware.

My concern specifically is that some of the less desirable aspects of
the way that PGP have implemented CMR should not be adopted into the
standard for interoperability reasons alone.  I am worrying that PGP
Inc will shortly be using this line of reasoning, for backwards
compatibility with pgp5.5 functionality for similar reasons as one
might reasonably argue for backwards compatibility with pgp2.x.

I noticed that Ian Grigg (Systemics) also expressed this point about
standards process manipulation well in his article.

Systemics has a much better track record for open development, and
openness of design decisions than PGP Inc since it's incorporation, or
before that than the pgp3.0 development team of two in beetling
themselves off in a room at Sun or wherever and taking ages to develop
software.  (No offense intended to said developers technical ability,
which I respect immensely, the error was organisational.)

Systemics is also outside of the US and for that reason better placed
to compete internationally.  PGP Inc is losing reputation capital to
Systemics and other such small companies in eroding it's support from
netizens by fielding GAKware systems.

(I have no affiliation with Systemics).

Adam

Date: Mon, 13 Oct 1997 10:15:00 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: IETF OpenPGP <[email-masked]>
Subject: Re: Discussion
Sender: [email-masked]

Will Price wrote:

> The CMRK feature only provides you with the
> information that the corporation you are sending
> to will be able to read this message -- potentially
> critical information you would not otherwise
> have and have not had previously in other software
> including old PGP.

Fair enough - as Adam says, you only need a simple flag on a public key
for this purpose.

> If
> you choose to not send to the CMRK, you can remove it by simply double
> clicking the CMRK to remove it and the message will be encrypted to the
> intended recipient only.

Great. If this option is set, it is virtually guaranteed that the
recipient's organisation is running the SMTP snoop enforcer, so your
message will be bounced.

> there is an enforcement option in the Business
> version only, but there are many ways around that too including simply
> deleting the self signature of the recipient

Again, your message would simply be bounced before reaching the
recipient. And anyway, we are talking protocol design here, not user
hacks which may or may not be effective but will regardless be out of
reach of 99% of users.

Ian.

Date: Mon, 13 Oct 1997 09:53:32 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: IETF OpenPGP <[email-masked]>
Subject: Re: Discussion
Sender: [email-masked]

Will Price wrote:

> This forum is indeed narrowly technical, should remain narrowly technical,
> this discussion is inappropriate for this forum, and if you want to discuss
> it please take it to the many other lists that would be more appropriate
> such as the cypherpunks list.  We are jumping *way* ahead of ourselves by
> discussing it at all at this time on this list when we don't even have a
> draft spec yet.  There will be ample time to discuss this later in the
> context of OpenPGP when issues like this become relevant and after all the
> hypotheses about it have been cleared up and people have actually tried the
> product rather than making false assumptions.

The problem is, as Bill Frantz wrote:

> Just a quick reality check here.  Frequently implementations have proceeded
> IETF standards.

Would PGP seriously stand for 'their' standard being incompatible with
their latest product (PGP 5.5)? If the finished OpenPGP standard rejects
their GAK compliancy fields, will they remove them from the product?
Even more practically, how hard will PGP fight against proposals from
others to do so? Is it fair that they should use their reputation,
corporate weight and 'look we've already implemented it' to do so within
an IETF working group?

Will Price is right: "we don't even have a draft spec yet". Will this
draft spec include the CMR fields? Ian Grigg asked that they forget
these contentious issues for now and just release the PGP 5.0 spec,
without the CMR. I'm unclear as to whether PGP 5.0 already supports CMR.

Ian answered the question in the original post.

> I think this
> debate is raising issues that threaten the integrity of the process,
> so a fullsome and noisy debate on open-pgp is unavoidable.

This is something we need to sort out quickly. PGP Inc do as well, if
their "commitment to open standards " (J. Seybold) means they will have
to withdraw PGP 5.5 if the IETF group rejects their CMR proposals and
they want "an open and completely interoperable international standard." 

Ian.

Date: Sun, 12 Oct 1997 23:59:13 -0700
To: [email-masked]
From: Will Price <[email-masked]>
Subject: Re: Discussion
Cc: [email-masked]
Sender: [email-masked]

At 7:50 PM -0700 10/12/97, [email-masked] wrote:
>I for one view this IETF forum as narrowly technical.  But I think this
>debate is raising issues that threaten the integrity of the process,
>so a fullsome and noisy debate on open-pgp is unavoidable.  Hence I am
>responding in a political fashion where otherwise I wouldn't.

This forum is indeed narrowly technical, should remain narrowly technical,
this discussion is inappropriate for this forum, and if you want to discuss
it please take it to the many other lists that would be more appropriate
such as the cypherpunks list.  We are jumping *way* ahead of ourselves by
discussing it at all at this time on this list when we don't even have a
draft spec yet.  There will be ample time to discuss this later in the
context of OpenPGP when issues like this become relevant and after all the
hypotheses about it have been cleared up and people have actually tried the
product rather than making false assumptions.

> [big snip]
>
>What PGP 5.5 could have done was added facilities to CC outgoing messages
>to a CMR, and to forward incoming ones.  At the client level.  This is,
>IMHO, legitimate data storage, under the control of the user, who is
>*always* capable of subverting central controls, or of disregarding any
>well-meaning advice embedded within the super-privacy of PGP 2.6.

This is essentially what we have done.  There is *no time* in PGP 5.5 when
the CMRK feature is not under the sender's control -- and I don't mean by
not sending the message.  The CMRK feature only provides you with the
information that the corporation you are sending to will be able to read
this message -- potentially critical information you would not otherwise
have and have not had previously in other software including old PGP.  If
you choose to not send to the CMRK, you can remove it by simply double
clicking the CMRK to remove it and the message will be encrypted to the
intended recipient only.  (there is an enforcement option in the Business
version only, but there are many ways around that too including simply
deleting the self signature of the recipient)  The point is that this is an
informational feature for the benefit of users since companies are going to
do this whether you like it or not, better that they do it in this way so
that everyone knows what's going on.  If we had wanted to enforce this in
the client, we would have had to do something very different.

>Some very experienced people have analysed the PGP 5.5 system and found
>it wanting.

Some of these same people have since changed their minds after learning how
things really work now that some of the misinformation is clearing about
this feature -- which is one problem with discussing this on any list right
now: nobody commenting on this has actually tried this feature except those
working at PGP.

-Will

Will Price, Architect/Sr. Mgr.
Pretty Good Privacy, Inc.
Direct (415)596-1956
Main   (415)572-0430
Fax    (415)631-1033
[email-masked]
<http://www.pgp.com>

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

Date: Sun, 12 Oct 1997 22:45:05 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Bill Frantz <[email-masked]>
Subject: Re: IETF policy on refusing to allow politics to weaken protocols (Re: Why Adam Back keeps politicizing technical issues)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 2:41 AM -0700 10/11/97, Adam Back wrote:
>
>5. The IETF process should be accepting proposed designs and deciding
>on the best ones, which PGP Inc, and the other suppliers would then go
>and implement.  As it is now, as William Allen Simpson just pointed
>out, PGP Inc is cruising ahead implementing, and deploying things
>without bothering with the OpenPGP process.

Just a quick reality check here.  Frequently implementations have proceeded
IETF standards.  That is one of the strengths of the IETF process (as
compared with e.g the CCITT.)

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

From: [email-masked]
Date: 13 Oct 1997 02:50:09 -0000
To: [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Cc: [email-masked]
Sender: [email-masked]

Jonathon and others,

I for one view this IETF forum as narrowly technical.  But I think this
debate is raising issues that threaten the integrity of the process,
so a fullsome and noisy debate on open-pgp is unavoidable.  Hence I am
responding in a political fashion where otherwise I wouldn't.

For those that dissagree - stop reading now, and apologies for the length.

To declare my colours at this early point, I have read some, hopefully
enough, of the posts on the subject and I think PGP 5.5 CMR features are
a bad design from the privacy point of view.  For that reason I hope to
concentrate any IETF open-pgp debate on the narrow issue of whether to
accomodate these new features.

Jonathan Seybold wrote:
> 
> Adam, one aspect of your suggestion puzzles me:
>         One thing which concerns me most is KNOWING when a message I send
> (or receive) could be read by someone else. The PGP CMR scheme makes this
> very clear: if there is an extra CMR key, the message may be read by
> whomever controls that key, if not, only the recipient may decrypt the
> message.
>         If, however, the message is secretly re-encrypted to a corporate
> storage key AFTER it is received, I will never know that.

If I send you a message, encrypted to your key, then I know that only
your key can be used to decrypt it.  This is like saying, if I send you
a fax, then only your fax machine can print it out (ignoring line snoops).

Whoever has your key can read the encrypted message - hence, CAK.
Or, whoever has your fax machine can see your incoming faxes.  Hence
all-powerful mailroom employees.

Whoever acquires the cleartext from whoever decrypted the message has
the message - hence CMR.  And common policies to take a corporate copy
of all incoming and outgoing faxes.

I know that I have no control over what you do with that message, be it
pass it to the recovery entity or destroy it.

If you are receiving a message in a corporate context, then I always
know there is a reasonable risk of a corporate storage requirement for
any message I send.  As I cannot audit the processes of your corporate
operation, I have no easy way of turning that risk into a fact.

Adding a CMR key adds no real information to this.  It was always a risk
that you would share your assets - keys or messages - and now the risk
is somewhat solidified, but not much.  The same goes for any fax or mail
item, and any phone call.  You can share the information, or not.  The
corporate body can listen in, open mail, take copies of faxes, or not.

What PGP 5.5 could have done was added facilities to CC outgoing messages
to a CMR, and to forward incoming ones.  At the client level.  This is,
IMHO, legitimate data storage, under the control of the user, who is
*always* capable of subverting central controls, or of disregarding any
well-meaning advice embedded within the super-privacy of PGP 2.6.

To add a central point of control to *enforce* some policy is to
misunderstand the processes of the modern office and the behaviour
of modern information workers.  Notwithstanding the efforts of PGP
to address real corporate concerns, I cannot avoid thinking that the
introduction of central policy servers is definately dangerous from
a strategic point of view and probably misdirected from a technical
point of view.

> The reality is that:
>         1) Organizations have a legitimate need to recover information.

I would accept this as a reasonable working premise, within some unstated
caveats.  I think most people in this debate do accept this.

However, the existance of this need does not automatically justify
any desired attempt to meet this need, much less any given policy or
practice.  LEOs are often cited as having a legitimate need to search
for information.  This need does not generally justify them meeting
their needs in whatever way they see fit.  Sometimes we just say no.

That is to say, a 'need' does not change snooping into good behaviour.
To implement some attempt to meet the need of corporates to recover
information requires a sensitivity to many different issues.

> You
> can argue about this as much as you want. A great many organizations will
> simply NOT INSTALL systems which do not accommodate this. If businesses,
> law firms and many other organizations will not use PGP, we will not have a
> viable standard.

This may be to confuse principles of privacy with methods for corporate
data recovery with the market objectives of PGP.  Such a posture is
not really helpful.

>                 We need to find ways to satisfy this need which are as
> flexible as possible, which are easy to use and administer, which balance
> the rights of the individual against those of the organization, and which
> do not mislead people inside OR OUTSIDE of the organization.
>         This means, I believe, that they should NEVER INVOLVE HIDDEN BACK
> DOORS THAT USERS ARE NOT AWARE OF.

( Uh, sorry, uppercase is normally indicative of shouting. )

>         It also means, I believe, that we should provide systems which
> provide as much flexibility and granularity as possible, and which do not
> require a central key recovery infrastructure -- or, even worse, a
> "trusted" third party key recovery infrastructure.

Not requiring these things is good.  There are many other dangers - it
has often been pointed out that security software is difficult because
the attacker only has to find one weakness, whilst the developer has to
cover all modes of failure.

In analogous sense, those that support GAK need only find one way to
acquire the messages they want.  Putting in a system that supports
corporate message recovery whilst opposing other uses is no easy task.

Some very experienced people have analysed the PGP 5.5 system and found
it wanting.  These are people who have been working with complex security
systems for many years.  I am somewhat concerned that their central
points are going unanswered, and for this reason I want to understand
very clearly what this forum - open-pgp - intends to do concerning
these proposed new "features."

>         2) Handling privileges, access and policies is going to get very
> sophisticated and very complicated.

Yes, I too can see difficulties in the PGP 5.5 scheme that relate to
policy.

>                 The keys need to be flexible enough to contain the kinds of
> information people are going to want to put in them. But I believe that
> most of the agents which make use of this information will operate at the
> server level, not the client level.

I would advise *not* adding any of these key features into the first
working draft produced by this forum.  Stick to PGP 5.0.  This forum
is a standards forum, not a development forum, and necessarily follows
behind any practice in the field, especially when there is a hint of
contention.

> PGP Inc. has tried to work through these issues in a new way. I think that
> we have agonized through a lot of trade-offs and come up with something
> that will really work -- and work well.

I would humbly suggest that the market might be a better determinate of
workability, and the vibes have not been favourable.  I would hope that
the open-pgp forum can concentrate on the basic formats and avoid including
any contentious features such as those present in PGP 5.5, at least until
the market and the security analysts on the various security groups have
come to some good understanding as to their desireability.

[...]
>         I am very interested in seeing criticism and suggestions for
> improvement and would like to see this discussed and debated as openly as
> possible.

This is an issue.  PGP Inc. has released a product that does something
that is not respected by some vocal critics.  I wonder how debate in an
open fashion is to be handled at this point?

There appears to be only one decision - whether the IETF forum should
take on board these features as being proposed or not.

> In particular, I would be interested in how one could reconcile
> your scheme of separate transmission and storage keys with my concern that
> everyone party to an exchange always be informed about who might be able to
> read that exchange.

That's already covered, see above.

For the record - any email exchanged with me might be sent to
friends I elect to send it to.  I, or my employer, may elect to
impose a secret corporate message recovery system.  I may elect
to send your messages to an unfriendly government, without your
knowing.  No version of PGP is going to stop me.

The only choice you have left is whether you wish to favour me by
an exchange of messages.

> However, I think that some of this discussion should be separated from the
> Open PGP discussion. NO ONE wants to build any sort of mandatory message
> recovery scheme into the base Open PGP specification. PGP Inc itself is
> committed to always providing a base client software product which does not
> implement message recovery keys.
> 
> In the end, the issue we need to focus on is what should go into the Open
> PGP specification. There are going to be many different organizations
> (including PGP Inc.) which build different implementations and services on
> top of this.

This is the current issue.  In fact this is a burning issue - we need to
get this spec out there to immunise the world against any outbreak of GAK
from wheresoever it derives.

>         The key structure needs to be flexible enough to accommodate all
> kinds of uses we cannot now envisage. Yes, I believe that CMR keys should
> be supported -- as should a lot of other things we need to talk about.

I believe that the first draft - as being worked on by some - should
strictly conform to the PGP 5.0 (that's five point zero) with *no*
inclusion of any sensitive features.  CMR key should not be supported,
insofar as they are anything more than additional keys, which is
something that is supported in all popular PGP variants - 2.6 through
to 5.0.  ( Here I am guessing that this is what 5.0 does. )

This is even to the extent that the security enforcer of PGP Inc. might
be deemed non-conformant because it refuses correct messages.  So be it.
This forum is not here for the narrow purposes of matching PGP Inc. product
releases.

If anyone wishes to propose features that might or might not make
the CMR or GAK mission easier, then it should be proposed only as
modifications to the first draft - here I am assuming this is possible.

I say this because I believe that team producing the draft spec (who
are you, BTW?) should *not* be distracted by the current debate, which
is likely to need far greater analysis and much more time.
Also, no open forum of this nature should be dependant on the product
line of of PGP Inc. or any other commercial organisation.

> Finally, let's dispense with the non-productive PGP Inc- bashing. We
> founded this company to take something which was going to die because it
> had no company behind it, and push it forward. PGP Inc was the first step
> in that process. Open PGP is the next step.

The issue is not the "bashing of PGP Inc." but the bashing of the design
in PGP 5.5.  If some of the mud sticks, then so be it - PGP Inc. designed
this system, using some internal review process.  An external review
process was always to be expected.

I also have to strongly disagree with the implication that the founding
of PGP Inc was needed for some sort of a revival of a moribund format.
That sort of sales message is out of place here, and offensive to the
many hundreds (and I mean hundreds) of independant developers of PGP
core code and PGP products around the world who are not currently on
the payroll of PGP Inc.

PGP - the international defacto standard - was quietly building up a
user base that, last I heard, was in the order of a few million.  That
isn't something that "was going to die" through lack of attention.  This
was a user base that was surviving and growing even in the face of such
alternatives as the commercially supported S/MIME and other mailer
crippleware.

I grant that PGP development was quiet for a number of years, apparently
advancing little because of two factors:  the PRZ harrassment case and
the international development of PGP 3.0 that was conducted in what might
have been well-meaning secrecy, but was eventually counterproductive.

PGP was not "going to die," it simply needed some leadership or opening up.
I concede that there was a need for an effort that could lead PGP on, and
PGP Inc., with the authority that Phil lends, could fill that role.  So could
many other potential models, and it is not clear that PGP Inc. have yet
earned any rights to that role, burnt midnight oil and fine efforts by
many programmers notwithstanding.

>         Most companies are very ambivalent about "open" standards. Most of
> the time, "open" to them means something which they control and everyone
> else adheres to. PGP Inc, on the other hand, is very committed to the
> spirit of open standards. We understand very well that we will only be
> successful if there is an open and completely interoperable international
> standard.
>         I also want to assure you that all of the things we do get
> extensively debated within PGP. Thus far, we have always been able to work
> out consensus decisions which, I believe, are more sophisticated and better
> thought-out for that debate. In all of this I have never heard ANYONE at
> PGP Inc. suggest that the company add any feature or capability to the
> software in order to appease any government agency. GAK is just as scary to
> us as it is to you.

I wonder if PGP Inc. has made a mistake in conducting the review
of CMR design within the internal body, and not tapping into the
millenia of combined security experience out on the mailgroups?

Or maybe the difficulty lies in the committed approach of the
company to the design of the product - without any thought that
the market will find it wanting.  There is no real shame in going
out with a beta that has a range of features to try out - although
certainly with the vitriolic crypto market one needs to be very careful
not to upset the various participants.  This is a market where ones
corporate mindset needs to be more than normally flexible.

Certainly a committment to open standards means that any review
process is best conducted in an appropriate open forum, perhaps before
committing any new features to launch.  At the best, products will be
criticised by the community, at worst, these products may be deemed
non-conformant to the Open PGP standard, if released without regard to
the various stakeholders.

This of course raises another interesting debate: has anyone considered
the ramifications of what will happen if the IETF Open PGP forum declares
that a product of PGP Inc. is non-conformant?  If indeed there is a
difference of technical standards, does the brand of PGP remain with the
open forum or with the company?  Knowing what value a good brand and a
nice company name is, I wonder if these are questions now on the table,
given the possibility, however remote, that determination of conformance
or otherwise is an open forum issue.

Of course, PGP Inc. would probably think that the brand is worth more
in their hands, I imagine that it is their decision and theirs alone
to discuss it.  This would raise the issue of developing another name
for the international standard, so that conformance to that standard
would allow some differentiation between the two entities.

>         Nor has there ever been any any "shareholder pressure" for any
> feature or set of features. Everyone who has invested in this company knows
> what we stand for.

That's good to hear.  There is however an uncomfortable dillema between
making money by being first to market with a PGP for business, and
maintaining that which the PGP spirit stands for.  Being first to
market means compromises in all directions.  Unfortunately complexities
within the security and crypto world mean that such compromises,
normally fair practice for other companies, are not often so easy to
accept nor so quick to reward.

>         Jonathan Seybold
>         Chairman, PGP Inc.
> 
> BTW: PGP Inc. currently employs NO "PR flaks." Press releases are usually
> drafted by the people directly involved in the product or project and
> reviewed informally by anyone else who would like to contribute.

Fine, I think PGP Inc. is also benefiting from a certain amount of
understanding because of this.  You are not hearing a universal cry
of "burn the witch" or "snake-oil" yet.  This is serious debate by
committed stakeholders to the PGP format.

-- 
iang
[email-masked]

Date: Mon, 13 Oct 1997 00:18:39 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

Jonathan Seybold <[email-masked]> writes:
> 
> Adam, one aspect of your suggestion puzzles me:
> 	One thing which concerns me most is KNOWING when a message I send
> (or receive) could be read by someone else. The PGP CMR scheme makes this
> very clear: if there is an extra CMR key, the message may be read by
> whomever controls that key, if not, only the recipient may decrypt the
> message.
> 	If, however, the message is secretly re-encrypted to a corporate
> storage key AFTER it is received, I will never know that.

You will if you mark the key with this information.

This is the same approach PGP is already using to provide the GAK
compliant implementation of corporate access to stored emails.

> The reality is that:
> 	1) Organizations have a legitimate need to recover information. You
> can argue about this as much as you want. 

I'm not arguing.  Of course they do.

What I _am_ arguing is that in designing systems to provide companies
with data recovery mechanisms that you should a) not weaken security
more than necessary, and b) that it would be nice if you used a method
which doesn't introduce GAK compliancy for communications keys.

I presented I think in plenty of detail an alternate mechanism which
is both non-GAK compliant, and more secure.  So what is the problem?
Is there a technical flaw in my solution?

> A great many organizations will simply NOT INSTALL systems which do
> not accommodate this. If businesses, law firms and many other
> organizations will not use PGP, we will not have a viable standard.

Agreed 100%.  This is why I went to great pains to demonstrate
precisely how you could achieve recovery of stored messages in a more
secure and non-GAK compliant way.

> which are easy to use and administer, which balance the rights of
> the individual against those of the organization, and which do not
> mislead people inside OR OUTSIDE of the organization.

my proposed mechanism for stored email recovery copes with all that.

> 	This means, I believe, that they should NEVER INVOLVE HIDDEN BACK
> DOORS THAT USERS ARE NOT AWARE OF.

Agreed.  You can flag backdoors with either solution.

> PGP Inc. has tried to work through these issues in a new way. I think that
> we have agonized through a lot of trade-offs and come up with something
> that will really work -- and work well.

It works well enough, but it could be made much more secure, by
separating storage key functionality from transient message key
functionality.  This would also give you the chance to resolve the
articificially created need for GAK compliancy, which arises because
you are being forced by this lack of distinction between key
functionalities to use one key for both long term storage and what
should be transient communications key usage.

> 	There is always the danger that someone is going to use your tools
> in ways that you do not approve of. We are trying to make it as easy as
> possible for people to do the "right" thing, and to discourage them from
> doing the "wrong" thing (like secret snooping).
> 	 With regard to GAK, the objective should be to accommodate
> legitimate corporate needs without setting in place the foundation for GAK.

If that is PGP's aim, they failed most miserably.

> We have tried very hard to do this by creating the foundation for a highly
> flexible and decentralized approach which allows different organizations to
> do things in very different ways. We have also tried to keep everything
> very visible so that every party to a conversation knows exactly how
> "private" that conversation is.

Decentralised control is good, of course, but the pgp5.5 and SMTP
policy enforcer is a ready to roll GAK system.  

The visibility principle is good but is an entirely separable issue.

> 	I think that the sort of thing that PGP Inc is doing is the best
> defense against GAK. It knocks the pins out from under the argument being
> used in this country that corporate message recovery requires a key escrow
> infrastructure, 

Yes, it is better than a government arranged "key recovery" key
infrastructure.

> and will almost certainly lead to a wide variety of
> organization-specific implementations that will be jealously guarded
> and very difficult to corral. I cannot imagine your 80% scenario
> working in the U.S. where there are so many small and medium-sized
> organizations and so much concern about government intrusion. 

If the OpenPGP standard is to include the GAK compliancy features, and
these competing systems use this standard, as long as the sum of the
OpenPGP compliant systems gets to 80% (or whatever) it doesn't matter
whether this is mostly provided by PGP, or mostly by GAK sellout
companies like IBM, or TIS.  It is a dangerous development to have a
largely fielded compatible set of GAK compliant products, whoever the
providers are.

Email encryption needs to be standardised, otherwise people can't talk
to each other.  This suggests to me that one standard _will_ evolve as
the winner, or if there are other standards, they will be backwards
compatible to this main standard.  A very related example of this kind
of principle in action is the fact that most secured web traffic is
secured by Netscape's SSL.

> I do worry a little more about countries like France, but I have yet
> to see any guaranteed "safe" alternative (including yours) that the
> French Government is likely to accept.

The French Government used require licenses for crypto, which were
hard to come by, and crypto without licenses was illegal.  In that
framework you couldn't see them liking PGP period.

More recently they have been swaying towards allowing crypto without
licenses, but only if it is GAK compliant.  PGP 5.5 & SMTP policy
enforcer should be a sell out.  Maybe y'all should pitch it to the
French government and SCSII (their NSA).

> 	I am very interested in seeing criticism and suggestions for
> improvement and would like to see this discussed and debated as openly as
> possible. In particular, I would be interested in how one could reconcile
> your scheme of separate transmission and storage keys with my concern that
> everyone party to an exchange always be informed about who might be able to
> read that exchange.

That's simple: you already have the mechanism, just put one of those
attributes Jon described on the key stating this fact.

> However, I think that some of this discussion should be separated from the
> Open PGP discussion. NO ONE wants to build any sort of mandatory message
> recovery scheme into the base Open PGP specification. PGP Inc itself is
> committed to always providing a base client software product which does not
> implement message recovery keys.

Glad to hear it.  Can we take it from that that PGP won't be arguing
for the GAK compliancy flag Jon Callas described to be part of the
standard then?  This is needed for said non "message recovery" base
client product to also be OpenPGP compliant.

> 	The key structure needs to be flexible enough to accommodate all
> kinds of uses we cannot now envisage. Yes, I believe that CMR keys should
> be supported -- as should a lot of other things we need to talk about.

CMR keys and the way that PGP has designed their associated flags and
the SMTP policy enforcer app are what make PGP GAK compliant.  

Also there are clear security advantages to _never_ send
communications encrypted to two keys.  There are clear security
advantages to separating the functionality of storage and
communications keys.  Communications keys are the most sensitive of
all, and should have the shortest life times.  In some applications
this could be minutes.

> Finally, let's dispense with the non-productive PGP Inc- bashing. We
> founded this company to take something which was going to die because it
> had no company behind it, and push it forward. PGP Inc was the first step
> in that process. Open PGP is the next step.

The PGP bashing PGP observes is an attempt by the pro-privacy crypto
community to influence PGP to re-think the GAK compliancy, and to
point out the more secure way to implement corporate recovery of
stored email messages without GAK compliancy.

I reserve the right to bash any company which attempts to field GAK
compliant software.

> 	Most companies are very ambivalent about "open" standards. Most of
> the time, "open" to them means something which they control and everyone
> else adheres to. PGP Inc, on the other hand, is very committed to the
> spirit of open standards. We understand very well that we will only be
> successful if there is an open and completely interoperable international
> standard.
>
> 	I also want to assure you that all of the things we do get
> extensively debated within PGP. Thus far, we have always been able to work
> out consensus decisions which, I believe, are more sophisticated and better
> thought-out for that debate. In all of this I have never heard ANYONE at
> PGP Inc. suggest that the company add any feature or capability to the
> software in order to appease any government agency. GAK is just as scary to
> us as it is to you.

If PGP wants to make an additional stance against GAK here are my
recommendations:

1. remove GAK compliancy fields
2. scrap SMTP GAK compliancy policy enforcer app
3. separate storage and communications keys 
4. use shorter lived communications keys giving forward secrecy
5. implement corporate recovery of stored mail folders with escrowed
   storage keys

Forward secrecy is _the_ strongest statement you could possibly make
against GAK.

>	Jonathan Seybold
>	Chairman, PGP Inc.

Adam Back
Protocol designer, Cypherpunks list member

Date: Mon, 13 Oct 1997 01:26:04 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: negative security aspects of GAK compliance
Sender: [email-masked]

I also was pondering this question as to which purpose the current
"encryption key" could be used for; should it become the
"communications key", or should it be the "storage key".

Clearly it could be used for either; and is in fact currently used for
both, which is where the security problem arises.

What you have described (very clearly as always) is the case for
making the current "encryption key" the "communications key".  You are
forced to make this choice because there is only one key available,
and without a communications key .. well you can't communicate :-)

However this leaves the question: what do you use for a "storage key"?

To see why this argument is important, you can see that you have
painted yourself into a corner where you will be forced to admit that
you need to have separate storage and communications keys.  Probably
this doesn't bother you as you didn't react adversely to my earlier
description of how it was a good idea to separate key functionality.
Let me quote:

Hal Finney <[email-masked]> writes:
> This should facilitate more frequent changeover of encryption keys as Adam
> Back describes, which can be good security practice.  It is a significant
> improvement provided by the new key structures of PGP 5.

It is indeed.  It is also very good for another reason: it allows
corporate escrow of encryption keys without simultaneously allowing
the company to forge signatures.

However you have created a problem for your self in the following
argument which suggests that you must have two encryption keys; one
for storage and one for communication.  It also suggests that my
method for achieving corporate recovery of email is better acheived
without the GAK compliancy field (second recipient) which was my
earlier point.

> Adam wrote:
> 
> > This argues that if people are to insist on using the enforced second
> > recipient model for corporate snooping at all, they should for
> > security reasons be at least using short lived communications keys for
> > the GAK compliancy packet also.
> 
> That sounds reasonable, at least if the first recipient is also using
> short lived keys.  Presumably these kinds of policies would be established
> by the corporate security office.  But certainly if one class of keys
> uses short lived keys then it would be logical for the other class to
> do so as well.

By doing it this way you do claw back some of the security lost by
having a second crypto recipient, as you say.  However you now can't
recover communications past the expiry date of the short lived
corporate key.

As the whole point of corporate message recovery is to guarantee
message recovery of stored messages (or at least this is the user
requirement Jon Callas gave in his post explaining the need for CAK),
you have just thrown away much of that ability.  This is an extreme
pity because you are now faced with a dilemma.

Your dilemma is, do you:

a) use short lived encryption keys (for both user and corporate master
key), and have good security but limited recovery of stored encrypted
email after that short period.  Also the poor user won't be able to
even access, never mind recover his stored encrypted email!

b) or do you use a long term encryption key for the corporate master
key, and hence good recovery of stored encrypted email, but poorer
security (and as an additional disincentive end up building a GAK
compliant system.)

This dilemma highlights really very well my point as to why you really
do need separate storage and encryption keys.  Introduce them, and
both problems vanish.

You can then:

- Have short term communications keys for the employee
- Have long term storage keys for the user escrowed with the company
- Have long term key recovery storage key for the company

It's beautiful, everything falls into place, and it's more secure.

Also as a convenient side-effect the way that you build a corporate
stored message recovery scheme under this system is non-GAK compliant,
which saves you from being screamed at by cypherpunks, and from being
dissed in the NYT and other places.  Presumably given Jonathan
Seybolds clear statement of PGP's aims:

Jonathan Seybold <[email-masked]> wrote:
>        With regard to GAK, the objective should be to accommodate
> legitimate corporate needs without setting in place the foundation
> for GAK.

this side-effect of removing the GAK compliancy should therefore be
very pleasing to PGP also.

The way that you implement corporate recovery of stored encrypted
messages once you accept the clear need for separate communications
and storage keys is easily derivable from new the key purposes.  It is
basically as easy to circumvent as the previous GAK compliant method.
Several PGP employees commenting on this didn't seem to think
enforceability was that big a deal.  (I agree with them: if all it
takes is to super encrypt with PGP itself, it's not worth losing sleep
over.)

Here's how to do corporate recovery of stored encrypted messages, now
with the new separated storage and communications key functionality:

1. Corp. employee receives encrypted email, the email is encrypted to
the employee's short life time communications key.

- employee decrypts email with pgp5.6 client

- pgp5.6 client encrypts the plaintext to users long term storage
  key, and to the companies recovery key as a second
  "storage-recipient", and places in received mail folder

2. Corp. employee sends encrypted email

- The pgp5.6 mail client encrypts plaintext of email to users long
  term storage key and to the companies long term storage recovery key
  and stores in the sent email folder

- The pgp5.6 mail client encrypts the plaintext of the email to the
  recipients short lived communications key and passes on to the MTA

3. Normal user access of encrypted stored email

- user's email client decrypts stored email with users storage key

3. User forgets password, or dies, or leaves in a huff, company needs
access to stored email

- company uses company recovery key to decrypt users stored email

An alternate set up would be to escrow the users long term storage key
with the company.  Basically equivalent.  But I think it is probably
easier to use multiple recipient as it saves the headaches of having
to securely transmit 10000 users storage keys securely.  Much easier
to install the software with the department/company recovery key bound
into it, and to remote update the company recovery key by fetching the
new from the company key server when it expires.

There are lots of other issues of course, with regard to architecture
of recovery setup.  However there is a basic equivalence between key
escrow and session key recovery methods, and you can acheive all kinds
of departmental escrow jus the same as you could with the previous
system.

> Actually it's likely that the corporation will change its shared access
> keys more frequently than user keys, at least if they are using an
> access model where there are relatively few shared keys.  It will be
> easier to change a few keys which are controlled by corporate officers
> than to get every one of 10000 employees to generate a new key every week.

I can't see any reason why you would not be able to entirely automate
and hide the process of generating new communications keys every week,
every day, or _every communication_.

The process can be handled automatically by the software.

With El Gamal you have a very computationally cheap way to generate
keys other than the first key; discard the private components, and
treat the public modulus as a pre-computed prime as you currently do
for the fast key generation option on EG key generation.

I feel somewhat better about this post than previous ones; I haven't
been rude to PGP, and I feel some progress has been made in clarifying
things.  Perhaps it's just interacting with Hal, who always was one of
the most level headed people on cypherpunks; it's much harder to pick
faults in what he says, and he doesn't make ill thought out political
statements.

I think there are still some issues to resolve if we start to talk
about "per communication" communication key updates, but for per week,
or per month or whatever, I think the above is good.

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, 12 Oct 1997 13:29:26 -0700
To: Adam Back <[email-masked]>
From: Jonathan Seybold <[email-masked]>
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Cc: [email-masked]
Sender: [email-masked]

Adam, one aspect of your suggestion puzzles me:
	One thing which concerns me most is KNOWING when a message I send
(or receive) could be read by someone else. The PGP CMR scheme makes this
very clear: if there is an extra CMR key, the message may be read by
whomever controls that key, if not, only the recipient may decrypt the
message.
	If, however, the message is secretly re-encrypted to a corporate
storage key AFTER it is received, I will never know that.

The reality is that:
	1) Organizations have a legitimate need to recover information. You
can argue about this as much as you want. A great many organizations will
simply NOT INSTALL systems which do not accommodate this. If businesses,
law firms and many other organizations will not use PGP, we will not have a
viable standard.
		We need to find ways to satisfy this need which are as
flexible as possible, which are easy to use and administer, which balance
the rights of the individual against those of the organization, and which
do not mislead people inside OR OUTSIDE of the organization.
	This means, I believe, that they should NEVER INVOLVE HIDDEN BACK
DOORS THAT USERS ARE NOT AWARE OF.
	It also means, I believe, that we should provide systems which
provide as much flexibility and granularity as possible, and which do not
require a central key recovery infrastructure -- or, even worse, a
"trusted" third party key recovery infrastructure.
	2) Handling privileges, access and policies is going to get very
sophisticated and very complicated.
		The keys need to be flexible enough to contain the kinds of
information people are going to want to put in them. But I believe that
most of the agents which make use of this information will operate at the
server level, not the client level.

PGP Inc. has tried to work through these issues in a new way. I think that
we have agonized through a lot of trade-offs and come up with something
that will really work -- and work well.
	There is always the danger that someone is going to use your tools
in ways that you do not approve of. We are trying to make it as easy as
possible for people to do the "right" thing, and to discourage them from
doing the "wrong" thing (like secret snooping).
	 With regard to GAK, the objective should be to accommodate
legitimate corporate needs without setting in place the foundation for GAK.
We have tried very hard to do this by creating the foundation for a highly
flexible and decentralized approach which allows different organizations to
do things in very different ways. We have also tried to keep everything
very visible so that every party to a conversation knows exactly how
"private" that conversation is.
	I think that the sort of thing that PGP Inc is doing is the best
defense against GAK. It knocks the pins out from under the argument being
used in this country that corporate message recovery requires a key escrow
infrastructure, and will almost certainly lead to a wide variety of
organization-specific implementations that will be jealously guarded and
very difficult to corral. I cannot imagine your 80% scenario working in the
U.S. where there are so many small and medium-sized organizations and so
much concern about government intrusion. I do worry a little more about
countries like France, but I have yet to see any guaranteed "safe"
alternative (including yours) that the French Government is likely to
accept.
	I am very interested in seeing criticism and suggestions for
improvement and would like to see this discussed and debated as openly as
possible. In particular, I would be interested in how one could reconcile
your scheme of separate transmission and storage keys with my concern that
everyone party to an exchange always be informed about who might be able to
read that exchange.

However, I think that some of this discussion should be separated from the
Open PGP discussion. NO ONE wants to build any sort of mandatory message
recovery scheme into the base Open PGP specification. PGP Inc itself is
committed to always providing a base client software product which does not
implement message recovery keys.

In the end, the issue we need to focus on is what should go into the Open
PGP specification. There are going to be many different organizations
(including PGP Inc.) which build different implementations and services on
top of this.
	The key structure needs to be flexible enough to accommodate all
kinds of uses we cannot now envisage. Yes, I believe that CMR keys should
be supported -- as should a lot of other things we need to talk about.

Finally, let's dispense with the non-productive PGP Inc- bashing. We
founded this company to take something which was going to die because it
had no company behind it, and push it forward. PGP Inc was the first step
in that process. Open PGP is the next step.
	Most companies are very ambivalent about "open" standards. Most of
the time, "open" to them means something which they control and everyone
else adheres to. PGP Inc, on the other hand, is very committed to the
spirit of open standards. We understand very well that we will only be
successful if there is an open and completely interoperable international
standard.
	I also want to assure you that all of the things we do get
extensively debated within PGP. Thus far, we have always been able to work
out consensus decisions which, I believe, are more sophisticated and better
thought-out for that debate. In all of this I have never heard ANYONE at
PGP Inc. suggest that the company add any feature or capability to the
software in order to appease any government agency. GAK is just as scary to
us as it is to you.
	Nor has there ever been any any "shareholder pressure" for any
feature or set of features. Everyone who has invested in this company knows
what we stand for.

	Jonathan Seybold
	Chairman, PGP Inc.

BTW: PGP Inc. currently employs NO "PR flaks." Press releases are usually
drafted by the people directly involved in the product or project and
reviewed informally by anyone else who would like to contribute.

From: "William H. Geiger III" <[email-masked]>
Date: Sun, 12 Oct 97 12:53:57 -0500
To: Ian Brown <[email-masked]>
Cc: Adam Back <[email-masked]>, [email-masked], [email-masked]
Subject: Re: PolicyMaker & GAK compliance
Sender: [email-masked]

In <[email-masked]>, on 10/12/97 
   at 11, Ian Brown <[email-masked]> said:

>-----BEGIN PGP MESSAGE-----

[Snip]

>-----END PGP MESSAGE-----

--------------------------------------------------------------------
MR/2 PGP Decryption  12 Oct 1997 12:45:33
--------------------------------------------------------------------

File is encrypted.  Secret key is required to read it. 
This message can only be read by:
  Adam Back <[email-masked]>
  Adam Back <[email-masked]>

You do not have the secret key needed to decrypt this file.

For a usage summary, type:  pgp -h
For more detailed help, consult the PGP User's Guide.

Ian,

Did you really mean to post this message to the list??

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

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

Date: Sun, 12 Oct 1997 17:36:12 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: [email-masked]
Subject: Re: PolicyMaker & GAK compliance
Sender: [email-masked]

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

Sorry for that... plaintext follows:

Adam Back wrote:

> For these reasons I still argue that we should:
> 
> - add storage keys to the standard
> ...
> - use storage key escrow to implement PGP snoopware instead of
burdening
>   the OpenPGP standard with the stigma of GAK compliancy
> ... 
> - don't use the special sub-packet type to flag GAK compliancy
> ...
> - scrap the controversial SMTP snoopware policy enforcement app

I agree 100%. 

Hall Finney wrote:

> For a key to say "I am storage-only" means that it is not intended
to be
> used for communications.  An email program would ignore such keys
and not
> try to encrypt messages to them.
> 
> Is this your intention?  I don't see what problem it solves.  Email
keys
> would presumably be marked as communications-only.  All you would
> have accomplished is to prevent people from encrypting disk files
with
> email keys.  We can discuss this kind of feature but it would be
helpful
> to understand the specific goals better.

I think Adam answered this quite well in his post "the case for
separate
comms keys"

Ian.

Date: Sun, 12 Oct 1997 09:09:54 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: negative security aspects of GAK compliance
Sender: [email-masked]

PGP now has support for separate signing and encryption keys.  The
signing key is the "top level key", and the encryption key is what we
refer to as a "subkey" which is bundled with the top level key.

One purpose of this is to allow more frequent changing of encryption keys.
In the past, changing keys was difficult because signatures on your
old key would not carry over to your knew one, so you needed to acquire
all new signatures on your new key.  With the subkey model, third-party
signatures bind userids only to the top level key, not to the subkey.
The top level key then issues a signature on the subkey saying "this is
the encryption key to use to encrypt to me."  The third-party signatures
then implicitly validate the subkey as well as the top level key.

When it is time to retire a subkey and create a new one, the top level key
need only issue a revocation signature on the subkey, generate a new one,
and issue the special signature on it.  The new subkey is immediately
fully validated, and all of the signatures on the top level key, which
hasn't changed, carry over to it.

This should facilitate more frequent changeover of encryption keys as Adam
Back describes, which can be good security practice.  It is a significant
improvement provided by the new key structures of PGP 5.

Adam wrote:

> This argues that if people are to insist on using the enforced second
> recipient model for corporate snooping at all, they should for
> security reasons be at least using short lived communications keys for
> the GAK compliancy packet also.

That sounds reasonable, at least if the first recipient is also using
short lived keys.  Presumably these kinds of policies would be established
by the corporate security office.  But certainly if one class of keys
uses short lived keys then it would be logical for the other class to
do so as well.

The second-recipient feature supports this kind of frequent changeover
using the mechanism I described above.  The corporate access key can
have its encryption subkey replaced, and the new one will be used by
encryption software.  No change to user keys is necessary for the new
corporate encryption key to be used as the second recipient.  All that
has to happen is to distribute the new encryption subkey.

Actually it's likely that the corporation will change its shared access
keys more frequently than user keys, at least if they are using an
access model where there are relatively few shared keys.  It will be
easier to change a few keys which are controlled by corporate officers
than to get every one of 10000 employees to generate a new key every week.

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

From: Ian Brown <[email-masked]>
To: Adam Back <[email-masked]>
Organization: University College London
Date: Sun, 12 Oct 1997 17:17:49 +0100
Subject: Re: PolicyMaker & GAK compliance
X-ByProxy/Sniffer_BasicSMTP/line0: User [email-masked] added as friend
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <[email-masked]>
CC: [email-masked], [email-masked]
Sender: [email-masked]
Precedence: bulk

Date: Sun, 12 Oct 1997 14:46:42 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

Ian Miller <[email-masked]> writes:
> Adam Back <[email-masked]> wrote:-
> >Specific questions relating to the standard are perhaps:
> >
> >- Are the certificate flags informing the recipient that
> >  communications to a key is escrowed, and that email which is not
> >  encrypted to the escrow key will be bounced expected to be part of the
> >  Open PGP standard.
> 
> In my view there is absolutely NO point it attempting to prescribe what
> applications may or may not do beyond inter-operatability.  You may have
> recommendations for what users should demand and accept, but you shouldn't
> be attempting to enforce those views on users or application writers.

That's one point of view I suppose.

Hopefully I can convince you and others who hold this view of the
inherent security weakness in implementing message snooping in the way
that PGP have, and that we can then not accept the options PGP will be
shortly arguing for, for security reasons.

We have to ensure interoperability, but I think beyond
interoperability we also have the question of security.  We should
consider security, or at least include MAY options allowing people to
opt for higher security usage where a case can be made for the
important security advantages for these.

Also a question is: interoperability with _what_?  With other
conforming implementations right?  What about interoperability between
conforming implementations, and a PGP system including features which
PGP Inc has implemented outside the standardisation process (GAK
compliance fields and SMTP GAK compliance enforcer currently).

> >- Can a conforming application ignore the key escrow flags?
> 
> Yes, but if the recipient's company runs PGPInc.'s screening SMTP server
> you need an envelope that at least appears to be encrypted to the escrowed
> key.
> 
> There are two approachs:-
> 
> 1) Automatically double encrypt.  Provide a escrow key access only
> to the outer layer of encryption.
> 
> 2) Include a PKE packet for the escrow key containing the wrong value as
> session key.
> 
> I don't think that IETF should say which of the available options
> that application should present to the user.  However any software I
> write will include options for humouring escrow arrangements without
> leaking information whereever this is possible.

That suggestion has some merit, and some poetic justice :-)

But, while I agree with your sentiments in saying that you will
implement a hacked form of GAK compliance entirely, can we call this
"compliant"?  If the OpenPGP standard simultaneously accepts the
semantics of the flags which PGP Inc give for informing the user that
snoopware is in use, and the second flag which PGP would presumably
defined to inform the user that the message will bounce?

Is it therefore conforming to do as you say, and instead of informing
the use that the message will bounce if they don't use the GAK
compliancy, to display a message saying:

	"the person you are sending to works for a company which has
	PGP snoopware, but don't worry about it, we've hacked around it"

If we can keep that it's a start at least, as a competitor who is
pro-privacy, even if PGP is no longer, can cater for pro-privacy
individuals.  And to the extent that this competitor is successful,
that portion of the market won't have automatic GAK compliancy.

If PGP does achieve netscape type market domination (as I'm sure
they'd love to), well your hacked implementation won't make much
difference, other that you are allowed to call it "conforming".

Put another way, you could hack your implementation even if the
OpenPGP standard defined that you couldn't call it "conforming" for
all the difference it's likely to make.

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, 12 Oct 1997 13:58:10 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: the case for separate comms keys
Sender: [email-masked]

Ryan Anderson <[email-masked]> writes:
> At 11:31 PM 10/11/97 +0100, Adam Back wrote:
> 
> >to exchange mail with anyone without using GAK.  Sure you have a
> >"choice", you can send email to people that will bounce 100% of the
> >time, whoever you send to due to lack of GAK compliance field.
> >(Except for perhaps a few die hard cypherpunks).
> 
> My reading of Jon's post was that the SMTP policy enforcer only worked for 
> outgoing messages.  Perhaps that's wrong, but that needs to be double-
> checked.  See below as well...

I'm fairly sure this is not the case.  The reason I think that this is
not the case is because Jon described two flags which go in the GAK
compliancy sub-packet:

Flag1:  this flag is an advisory note to the person who obtains a
	public key which has the GAK compliancy self signature
	sub-packet; it tells the person about to use the key that the
	company the person who owns this public key works for would
	like it if you would "please" encrypt to the contained
	corporate snoopware master key.

Flag2:	this flag is the same as the flag1 above plus it is a big
	brotherish/little brotherish warning that if you _don't_
	encrypt to the GAK compliancy key also, that the recipient
	will not receive the message.

I understood the reason that the recipient will not receive the
message when you don't honour keys with flag2 to be that the SMTP
policy enforcer would either bounce the message, or eat it, or send it
to the company snoopware czar to who can take due note in his employee
dossier collection that this employee is receiving email from
suspicious cypherpunk persons who don't believe in snoopware.

The above functionality is the reason I'm arguing that PGP's method of
implementing corporate snoopware is GAK compliant: clearly the whole
system is ready tailored for GAK.  The only thing left to do is plug
in the governemnts key in the GAK compliancy field, and for the
government to mandate that companies, and deputised ISPs use the
software and the GAK master key.

If/when this GAK compliancy gets used as the architecture for real
live mandatory GAK, the SMTP policy enforcer may be set up to narc out
the suspicious person who doesn't believe in GAK to the Feds/NSA, and
they will then come and lock you up if they can trace your SMTP From
field to you.

This will make a mockery out remailers, because the remailer chain
will also be forced to have the GAK master key in it as enforced by
deputised ISPs running PGP's SMTP policy enforcers with GAK keys
installed as the GAK master key. 

> >> It's not even needed if you don't have that key on your ring.  (From
> >> what Jon said)
> >
> >I'm not sure what you mean here.
> 
> The snooping key.  If it doesn't exist on *my* keyring.  (Say I have your 
> key, but not the key designate as your snooping key...)  [BTW: Forgive the 
> English, I'm tired and speaking in choppy sentences]

Oh, I see what you mean.  The reason I didn't understand is that this
is not how I thought it works.  I think the key is provided right
there in the GAK compliancy field in an inseparable way.  (I could be
wrong on this, but this is the way I read Jon's message).

Even if have misunderstood the way that this key is bundled, it
doesn't really alter the fact that by "choosing" not to encrypt to
messages with the flag2 flag you will know that this is a waste of
time, because your message will not get past the SMTP policy enforcer.
So purposely stripping the key from your key ring, or separating the
key pair when someone sends you them together would just be another
way of exercising the choice PGP is claiming you have in "choosing" to
have your message bounced back at you.  A fairly meaningless "choice".

I would be interested to have this point about the way GAK compliancy
key is bound/bundled with the GAK compliancy sub-packet clarified by a
PGPer, or someone with more understanding of the draft docs, if this
much information is available yet.

> If I have your key, but not the other key that I'm also supposed to
> encrypt to, PGP (whichever versions, I'm not entirely sure how the
> feature set breaks down, but I believe this applies to all versions
> of 5.x) will not even mention that there was another key it would've
> have offered to encrypt to.

I don't think this is so because that would invalidate the semantics
of the flag1 and flag2 flags, which are what instructs PGP to warn you
of this requirement for this key.  The flag is an attribute of the key
itself, though I do suppose you might be able to strip off the
attribute in much the same way as you can remove signatures from keys
with pgp -krs.

> >Using separate storage keys allows you to:
> >
> >- escrow storage keys within your company without including GAKware
> >  compliancy
> >
> >- discard communications keys often (by giving them short life-spans)
> >  which greatly enhances your security
> 
> Greatly complicating the "web of trust" method, but..  

I don't think it complicates web of trust.  The only certification you
need of communications keys is for you to sign them with your
signature key.  Your signature key semantics, and the web of trust is
unchanged.

> You can only chain signatures so far before you run into problems,
> and getting people to continuosly recertify could be a major pain,

It will be automatic .. you won't notice because all the OpenPGP
compliant application which supports this proposed (strongly
encouraged MAY, please!) feature will do when it creates a new
communications key is to sign the communications key with your
signature key.  It won't involve third parties re-issuing
certificates.

It is the same way that certification and WoT interacts with
potentially shorter life-span dual use encryption keys at the moment.
The WoT certificates go on your longer life signature key, and it is
you who signs your encryption key.  Same argument, though now applied
to encryption keys marked as "communications only".

> >There might be some security advantages to using
> >symmetric keys even.  (Public key sizes are a faster sliding and more
> >uncertain target than symmetric key sizes.
> 
> Well, at least with RSA keys, I believe the memory requirements to
> handle current factoring algorithms are quite untenable for 2048 bit
> keys.  I think 768 is out of the range of current systems.

512 bit I think is reckoned to be feasible for an academic crack of
similar scale to the recent RSA challenge DES break.  The memory for
the final matrix crunching phase might be the only arguable point.

However, this doesn't really give me 20 years worth of assurance
because, well Rivest and friends encrypted the message "squeamish
ossifrage" back in 1977 or thereabouts, firm in the belief that it
would not be broken for 1000s of years.  Factoring advances have meant
that that ~380 bit keys (squeamish ossifrage was RSA129 digits
decimal) is now relatively easy.  Paul Leyland and friends broke a 384
bit blacknet key as a private attack without massive internet
collaboration.

I'm not sure anyones promising, or has any mathematical proof that new
factoring algorithms won't provide similar factoring speedups.  How
many years are 1024 bit RSA keys good for?  All you can use as
estimators is the current factoring algorithms.  I'm not sure how
certain these estimates are for long term purposes.

In contrast if there is nothin wrong with 3DES nor IDEA, the key space
protects you, modulo Moore's law which is easier to predict.  (Also
modulo quantum computing break-throughs, in both cases, erk!)

> I think this came up on the RC5 (Bovine) mailing list, and the
> figures for the required server was something absolutely ridiculous.
> To distribute the job using the more efficient algorithm required
> machines with 128 meg of ram, but the slower one was a bit more
> doable.

Yes.  But memory on workstations is increasing in leaps and bounds.
It is very common now for personal PCs and even laptops to have 32Meg.
A few years ago we were living below the 640k barrier.  Leave it a few
years, and people will have the required memory levels.  A few more
years on from that people will be grizzling about living below the 4Gb
barrier (restriction from using 32 bit addresses).

Anyway, one of the factoring gurus may come up with another novel
implementation or algorithm tweak to tune down memory requirements.
Or a newly discovered faster factoring alorgithm may have huge memory
advantages over current alogirthms.

> In short, I don't think 2048 RSA keys are reasonable target in the
> forseeable future.  [Remember, Moore's law is only applicable for
> another 12 years or so.  Then quantum mechanics starts to be a
> serious problems, and electrons start switching channels in the
> chips.]

The future is uncertain.  But it is marginally less uncertain for
well tried and tested symmetric keys ciphers.

> But this is a bit of a wandering topic now.  Let me continue...
> 
> >You can sign and encrypt with symmetric keys also. "pgp -cs."  Quite a
> >useful combination.
> 
> Hmm.. I must've missed that.  

Don't think it says it anywhere, but you can combine flags in lots of
logical ways which aren't documented as such, and most of which work
as you might reasonaly extrapoloate them to.  There are single letter
flags for most letters of the alphabet, the full number of
combinations must be quite large.  Quite a few of them mean
*something*.  Some of them are even phonetically pleasing: -feast etc :-)

> Well, I wasn't really encrypting anything I really cared about.  It
> was backups of autoexec.bats and config.syss, I just wanted another
> copy that I *knew* when it was made, it wouldn't get overwritten,
> and it wouldn't get modified without me knowing.  And I needed
> something to use PGP for, so...

Signature only might've been enough for backups of stuff in plaintext
on the disk like autoexecs.

> In all honesty, the public key baggage is 512 bytes ( I think,
> possibly bits.  I've forgotten now ) Quite insignificant if you're
> dealing with CAD drawings.  

Sure.  But you were also talking about autoexecs and other small files
where it could get significant.  The significant lose howver is the
performance -- say you recursively encrypt all the files in a
directory, each to 2 or 3 multiple crypto recipients.  It'll crawl.

> >It's probably simpler to just escrow storage keys.  That is just give
> >management a copy to put in the fire proof safe.  Or secret split or
> >whatever.
> 
> I was actually thinking something along the lines of creating a file
> - encrypting it to your whole workgroup, and leaving it on a server.
> Now you have the advantage of not having any security problems even
> if the server is compromised [without workstation compromise, of
> course], and all the important people can access it.  Of course, the
> last person to modify it resigns it, and it gets dropped into your
> RCS system.

I see.  Sounds reasonable.  You should be able to achieve that with
the current dual use PGP keys, or with the new "storage only" keys via
crypto recipients.

If your document is on the Internet, on the web perhaps, you'd need to
be aware of the reduced security in using long term storage keys as
opposed to short term communications keys, but other than that I can't
see a problem.

The point is that where you have a directional communication, you
should treat those keys as sensitive.  Where it is not a directional
communication, you can't, so you lose that extra security; for
applications where this is acceptable, I wouldn't argue for
restricting your ability to do it.

> you get the added advantage of being able to rotate your keys here
> as well, so even if one key is compromised, and the server is
> compromised, you don't lose the whole system.  Identical argument as
> for communications keys.

I think I understand what you're saying for shared storage keys.  But
I don't think it's an identical argument at all for communications
keys.

If you define communications keys as short lived highly sensitive
keys, as perhaps in SSL, or SSH (both of which use some forms of
forward secrecy), you can't retain the ability to recover the message
after the fact for security reasons.

However I posit that people don't really want access to the plaintext
stored inside encrypted communications for their own purposes for the
simple reason that they don't have a sendmail log including all the
message bodies.

Together with the security advantages of not being able to decrypt
communications traffic yourself after the fact, this argues that
people who do want full email archives for company legal or snooping
purposes, or just folder for their own use (I know I keep lots of
email in folders) can either store in the clear, or store encrypted
with a storage key, or store with an escrowed storage key, or store
encrypted to multiple storage keys as crypto-recipients as you
suggest.

> >There is one (quite practical) reason, however, to use symmetric
> >storage keys.  Speed.  If you're encrypting lots of files (perhaps
> >using an encrypted parition driver such as Peter Gutmann's SFS), you
> >won't have time to encrypt to public keys, never mind multiple public
> >keys.
> 
> That's a different problem.  For that you're [in this ultra-theoretical 
> world] 

I don't think it's that theoretical.  Don't PGP have such an encrypted
disk driver for the MAC?  I think this is the way forward for simpler
storage encryption: encrypt the lot.  Saves arguments about forgetting
to encrypt stuff, or forgetting you did decrypt and leaving plaintext
copies around in /tmp or whever as well.

> probably going to want something along the lines of this: Symmetric
> encryption for speed on the partition, and that key stored with
> several recipients in the same place as the Secure Partition Driver
> (SPD).

Your suggestion is one reasonable way of acheiving this.  You can also
acheive the same flexibility with an extra indirection with symmetric
storage keys (optionally held in escrow).  In fact I think this is
what later versions of Peter Gutmann's SFS do.  The reason he uses for
this is that it allows you to change your passphrase without
re-encrypting the whole disk, because the _actual_ disk encryption key
is encrypted itself with the hash of your passphrase, rather than
using the hash of the passphrase directly as the key.

> (This falls in the, "If you're going to build a system, make sure
> you think of everythign you want and make sure it fits in the
> framework somewhere" method)

Well I agree, I think it's reasonable for us to consider the major
uses, plaintext recovery demands, and security aspects of the
different types of uses for keys: transient communication keys,
storage keys, and signature keys.

> >If the company keeps it's employee's storage keys in escrow, the fact
> >that you're using a symmetric key works fine.
> 
> I'm not sure you need to escrow anything, as long as there is a way
> to share things among certain groups of people.  Jon's ideas of
> non-hierarchical recovery systems seem a lot more secure anyway,
> especially with the rest of this thread.

It doesn't really matter one way or the other.  You can build
non-hierarchical recovery systems with either method.  (You can escrow
storage keys in your department, just as easily as add second crypto
recipient within your department.  I think the security is basically
the same for escrow or multiple recipient when we're talking about
storage.

The same security equivalence argument applies if you accept the
premise that you need access to transient communications.  I don't
accept this premise.  This premise is a fallacy promulgated by the
likes of Freeh.  If you don't escrow communications keys at all you
gain extra security for the same reason that it is less secure
actually to escrow storage keys, or use multiple recipient as another
way to achieve storage key escrow than to not use storage key escrow.
However with storage you live with this because a) data availibility
is important, and b) the risk isn't as great with storage because your
attacker has to breach physical security to obtain the data from your
disks and tapes.

> Oh - for the situation with Andy Grove (Intel CEO) describe earlier on this 
> thread - let me give this suggestion:
> 
> 	AG's key w/extra encryptions to CFO (or Pres. of Board, or
> someone else with significant influence and a close working
> relationship.  Backup for problems with intransit e-mail.)
> 
> 	Similar setups for everyone else in the company.  Probably the
> top-level executives all have AG as the backup.  This elminates
> snooping entirely in the company, on the top level execs.  This
> partially hierarchical method wouldn't be horrible, and limits
> snooping to the level above you, or to peers, depending on setup.

The suggestions about snooping heirarchy -- who can read who's mail
within the company -- are independent of which architecture you choose
to use to allow access to the mail (escrow storage keys or use
multiple crypto recipient for storage keys).  (This can all be
enforced with similar levels of resistance to bypass by building the
archive and snooping features into the mail client to do this after
decryption).

Where you start to get argument from me is when you start unduly
exposing what should be transient communications keys to construct
this corporate snooping pecking order.

> >I'm sure I've given these reasons earlier in the thread, but I'll
> >summarise them again:
> 
> Yeah, you covered them fairly well, and cleared up the issues where
> I honestly thought it was a fear-mongering problem.  I still don't
> completely agree with you, but we've clarified the problem areas.
> Thanks.

That's what it's all about -- meaningful discourse so that we can
collectively improve each others understanding of the problems at
hand, pointing out flaws in each others arguments until we reach
agreement, eliminating misunderstanding.  With that a clarified
picture of the security issues and best architecture, we can then go
on to design suitable security protocols which best reflect this.

> (Too many wars get *way* too religous on the net.  Let's try and
> avoid that here, ok?)

Hey, as long as we steer clear of PGP arguments about mandatory GAK
compliancy, this is all friendly discourse :-) 

On religious arguments: I must admit to strong negative feelings about
PGP Inc or the OpenPGP standard using weaker security methods to
enable GAK compliancy.  My reason for expressing these opinions is the
hope that we can talk PGP out of this big brotherish SMTP policy
enforcer, and associated GAK compliant fields, and to give my input to
try to steer the OpenPGP process away from incorporating said GAK
compliancy field into the standard.

Also as I hope I have explained relatively clearly in my other post
titled:

	Subject: negative security aspects of GAK compliance

that GAK compliancy is independently from political arguments a
security design flaw.  And so I think that we should be able to reject
it on technical grounds alone as a design with weaker security.

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, 12 Oct 1997 12:03:02 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: negative security aspects of GAK compliance
Sender: [email-masked]

Adam Back <[email-masked]> wrote:
> As I have pointed corporate access to stored email can be acheived
> with similar amounts of snooping enforceability by having the PGP5.5
> mail client store to an escrowed communications key after decryption,
                                   ^^^^^^^^^^^^^^

Typo: that should be "storage key".

> I would be interested to see anyone refute this security argument from
> a security point of view.

And I am very interested to hear arguments against the logic of that
message.

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, 12 Oct 1997 10:44:28 +0100
To: [email-masked]
From: Ian Miller <[email-masked]>
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

Adam Back <[email-masked]> wrote:-
>Specific questions relating to the standard are perhaps:
>
>- Are the certificate flags informing the recipient that
>  communications to a key is escrowed, and that email which is not
>  encrypted to the escrow key will be bounced expected to be part of the
>  Open PGP standard.
In my view there is absolutely NO point it attempting to prescribe what
applications may or may not do beyond inter-operatability.  You may have
recommendations for what users should demand and accept, but you shouldn't
be attempting to enforce those views on users or application writers.
>
>- Can a conforming application ignore the key escrow flags?
Yes, but if the recipient's company runs PGPInc.'s screening SMTP server
you need an envelope that at least appears to be encrypted to the escrowed
key.

There are two approachs:-
1) Automatically double encrypt.  Provide a escrow key access only to the
outer layer of encryption.
2) Include a PKE packet for the escrow key containing the wrong value as
session key.

I don't think that IETF should say which of the available options that
application should present to the user.  However any software I write will
include options for humouring escrow arrangements without leaking
information whereever this is possible.

Ian

--
[email-masked]    FAI-D10204
PGP Fingerprint: 2A20 4610 E596 2740 91B1 95BA CAD3 BC14
Antworten auf Deutsch waeren mir angenehm.

Date: Sun, 12 Oct 1997 11:09:07 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Signature assertions
Sender: [email-masked]

Andrew Bromage <[email-masked]> writes:
> Slight change-of-topic: I'd like to see assertions attached to
> signatures in a machine-readable way, for example some extra string not
> part of the document being signed but still part of the signature
> hash.  Assertions could include:
> 
> 	- I sign this document.  (i.e. I agree to the contents, I
> 	  authorise the contents, whatever that means legally)
> 
> 	- I use this document to prove who I am.  (e.g. an
> 	  authentication system where I send you a file and ask you to
> 	  sign it)
> 
> 	- I have received/seen this document.
> 
> 	- It is really me who is asking you to do X to this document.

These are the kind of functionalities the extracts from the EEMA draft
I posted could be implemented well with.

The functionality would be useful.

Adam

Date: Sun, 12 Oct 1997 06:32:05 -0400
To: Adam Back <[email-masked]>
From: Ryan Anderson <[email-masked]>
Subject: Re: the case for separate comms keys
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

At 11:31 PM 10/11/97 +0100, Adam Back wrote:

>to exchange mail with anyone without using GAK.  Sure you have a
>"choice", you can send email to people that will bounce 100% of the
>time, whoever you send to due to lack of GAK compliance field.
>(Except for perhaps a few die hard cypherpunks).

My reading of Jon's post was that the SMTP policy enforcer only worked for 
outgoing messages.  Perhaps that's wrong, but that needs to be double-
checked.  See below as well...

>> It's not even needed if you don't have that key on your ring.  (From
>> what Jon said)
>
>I'm not sure what you mean here.

The snooping key.  If it doesn't exist on *my* keyring.  (Say I have your 
key, but not the key designate as your snooping key...)  [BTW: Forgive the 
English, I'm tired and speaking in choppy sentences]

If I have your key, but not the other key that I'm also supposed to encrypt 
to, PGP (whichever versions, I'm not entirely sure how the feature set breaks 
down, but I believe this applies to all versions of 5.x)  will not even 
mention that there was another key it would've have offered to encrypt to.

>> When you compalin about use of storage keys/communication keys your
>> clouding the issue.
>
>It might appear complex, but actually adding the distinction between
>communications and storage keys greatly simplifies things, and it
>allows you to make more appropriate security decisions about key life
>times, and escrow.  It also allows you to implement the message
>snooping function in a more secure way, and with less big brotherish
>overtones.
>
>Using separate storage keys allows you to:
>
>- escrow storage keys within your company without including GAKware
>  compliancy
>
>- discard communications keys often (by giving them short life-spans)
>  which greatly enhances your security

Greatly complicating the "web of trust" method, but..  You can only chain 
signatures so far before you run into problems, and getting people to 
continuosly recertify could be a major pain, but I can see the point you are 
making.   It got clearer.

>> The storage keys can be (and probably are in some cases) simply pgp
>> encrypted files, as if they were in transit.  
>
>Storage keys could be symmetric keys if they are for your own use
>only, or you could escrow them if you want to share access, or your
>company wants the extra assurance of data availability that storage
>key escrow brings.  There might be some security advantages to using
>symmetric keys even.  (Public key sizes are a faster sliding and more
>uncertain target than symmetric key sizes.

Well, at least with RSA keys, I believe the memory requirements to handle 
current factoring algorithms are quite untenable for 2048 bit keys.  I think 
768 is out of the range of current systems.  I think this came up on the RC5 
(Bovine) mailing list, and the figures for the required server was something 
absolutely ridiculous.  To distribute the job using the more efficient 
algorithm required machines with 128 meg of ram, but the slower one was a bit 
more doable.

In short, I don't think 2048 RSA keys are reasonable target in the forseeable 
future.  [Remember, Moore's law is only applicable for another 12 years or 
so.  Then quantum mechanics starts to be a serious problems, and electrons 
start switching channels in the chips.]

But this is a bit of a wandering topic now.  Let me continue...

>You can sign and encrypt with symmetric keys also. "pgp -cs."  Quite a
>useful combination.

Hmm.. I must've missed that.  

>I used to do the opposite of what you do... I used to use pgp -cs,
>because I explicitly didn't want the public key baggage, and danger
>that 1024 bit keys might be readable in 10-20 years, the then maximum
>key size.

Well, I wasn't really encrypting anything I really cared about.  It was 
backups of autoexec.bats and config.syss, I just wanted another copy that I 
*knew* when it was made, it wouldn't get overwritten, and it wouldn't get 
modified without me knowing.   And I needed something to use PGP for, so...

In all honesty, the public key baggage is 512 bytes ( I think, possibly bits. 
 I've forgotten now )  Quite insignificant if you're dealing with CAD 
drawings.  The added benefit of reducing passphrase uses is quite significant 
(with current PGP versions, the database of keys is a better idea actually).  
Possibly more portable across a range of users as well.

>> I can see this being done in a company to simplify shared storage
>> usage without security problems.  Using the multiple recipient
>> option your recovery key-id can be used to decrypt these files.  Of
>> course, if they're modified, they can't be resigned, so you'd know,
>> but...
>
>It's probably simpler to just escrow storage keys.  That is just give
>management a copy to put in the fire proof safe.  Or secret split or
>whatever.

I was actually thinking something along the lines of creating a file - 
encrypting it to your whole workgroup, and leaving it on a server.  Now you 
have the advantage of not having any security problems even if the server is 
compromised [without workstation compromise, of course], and all the 
important people can access it.  Of course, the last person to modify it 
resigns it, and it gets dropped into your RCS system.

you get the added advantage of being able to rotate your keys here as well, 
so even if one key is compromised, and the server is compromised, you don't 
lose the whole system.  Identical argument as for communications keys.

>You could use multiple crypto recipient if you wanted to -- it's
>basically just another way of acheiving the same thing.
>
>There is one (quite practical) reason, however, to use symmetric
>storage keys.  Speed.  If you're encrypting lots of files (perhaps
>using an encrypted parition driver such as Peter Gutmann's SFS), you
>won't have time to encrypt to public keys, never mind multiple public
>keys.

That's a different problem.  For that you're [in this ultra-theoretical 
world] probably going to want something along the lines of this:  Symmetric 
encryption for speed on the partition, and that key stored with several 
recipients in the same place as the Secure Partition Driver (SPD).  (This 
falls in the, "If you're going to build a system, make sure you think of 
everythign you want and make sure it fits in the framework somewhere" method)

>If the company keeps it's employee's storage keys in escrow, the fact
>that you're using a symmetric key works fine.

I'm not sure you need to escrow anything, as long as there is a way to share 
things among certain groups of people.  Jon's ideas of non-hierarchical 
recovery systems seem a lot more secure anyway, especially with the rest of 
this thread.

Oh - for the situation with Andy Grove (Intel CEO) describe earlier on this 
thread - let me give this suggestion:
	AG's key w/extra encryptions to CFO (or Pres. of Board, or someone else with 
significant influence and a close working relationship.  Backup for problems 
with intransit e-mail.)
	Similar setups for everyone else in the company.  Probably the top-level 
executives all have AG as the backup.  This elminates snooping entirely in 
the company, on the top level execs.  This partially hierarchical method 
wouldn't be horrible, and limits snooping to the level above you, or to 
peers, depending on setup.

>> Give an example of the difference between what he's doing and what
>> you would propose. Otherwise you're just rejecting this system
>> blindly.
>
>I'm sure I've given these reasons earlier in the thread, but I'll
>summarise them again:

Yeah, you covered them fairly well, and cleared up the issues where I 
honestly thought it was a fear-mongering problem.  I still don't completely 
agree with you, but we've clarified the problem areas.  Thanks.  (Too many 
wars get *way* too religous on the net.  Let's try and avoid that here, ok?)

-----------------------------------------------------------------------
Ryan Anderson - <Pug Majere>     "Who knows, even the horse might sing" 
Wayne State University - CULMA   "May you live in interesting times.."
[email-masked]         
PGP Fingerprint - 7E 8E C6 54 96 AC D9 57  E4 F8 AE 9C 10 7E 78 C9
-----------------------------------------------------------------------

Date: Sun, 12 Oct 1997 10:48:03 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: negative security aspects of GAK compliance
Sender: [email-masked]

I think there is a clear technical security case against the GAK
compliant packet, which I would like to see comments on from people
who think the political GAK compliant argument is not significant.

This ties in with using separate storage and communications keys, and
with the better security practice of having shorter lived
communications keys to provide forward secrecy from the point of
issuing new communication keys (could be once per month, once per
week, or once per message).

Once you acknowledge that it is more secure to have short lived
communication keys (which in my view it very clearly is), it should be
clear that by putting a GAK compliancy packet feature, or other second
recipient you are weakening the security because that is another door
into a message which you are trying to make forward secret -- you are
trying to ensure that after the fact, no-one, not even the recipient
can decrypt the old traffic.  (This is a very good way of ensuring
that third parties, like industrial espionage spies, people using
black mail or the Feds using rubber hoses, or supeonas or other legal
or extra legal forms of coercion, can't obtain from you keys to
decrypt it either, so they don't get plain text).  

The fact that the extra door into the message is outside the
recipients control means that his own security could be compromised by
sloppy practice on the part of that key holder.

This argues that if people are to insist on using the enforced second
recipient model for corporate snooping at all, they should for
security reasons be at least using short lived communications keys for
the GAK compliancy packet also.

Or, as I would argue, most secure of all is not using GAK compliancy
packets at all, but rather to use escrowed storage keys to retain
access to mail archives.  This is more secure because you don't keep
second doors into what should be a communication encrypted with as few
as possible (namely: one) transient communications key, with security
policy control being in the hands of the person who owns the key (the
recipient).

As I have pointed corporate access to stored email can be acheived
with similar amounts of snooping enforceability by having the PGP5.5
mail client store to an escrowed communications key after decryption,
or even to re-encrypt after decryption to a long term storage company
archive access bot within the LAN (with such encrypted messages
themselves being wrapped in an extra comms encryption envelope using
short term communications key if you like).

I would be interested to see anyone refute this security argument from
a security point of view.

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: Andrew Bromage <[email-masked]>
Subject: Signature assertions
To: [email-masked] (Hal Finney)
Date: Sun, 12 Oct 1997 10:11:32 +1000 (EST)
Cc: [email-masked]
Sender: [email-masked]

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

G'day.

Hal Finney wrote:

> Rather than getting bogged down in trying to come up with a litmus test
> for which assertions are allowed, I would rather see the group work to
> improve the data structures and language used for expressing assertions.
> What other kinds would people like to see?

Slight change-of-topic: I'd like to see assertions attached to
signatures in a machine-readable way, for example some extra string not
part of the document being signed but still part of the signature
hash.  Assertions could include:

	- I sign this document.  (i.e. I agree to the contents, I
	  authorise the contents, whatever that means legally)

	- I use this document to prove who I am.  (e.g. an
	  authentication system where I send you a file and ask you to
	  sign it)

	- I have received/seen this document.

	- It is really me who is asking you to do X to this document.

Cheers,
Andrew Bromage

Date: Sat, 11 Oct 1997 23:31:01 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: the case for separate comms keys
Sender: [email-masked]

Ryan Anderson <[email-masked]> writes on cpunks:
> Adam Back <[email-masked]> writes:
> >You should have 3 types of key:
> >
> >1. signature keys
> >2. transient encryption keys
> >3. storage keys
> >
> >The transient encryption keys are for communications, you delete them
> >immediately after use.  Yes I'm talking forward secrecy here.  If you
> >don't like forward secrecy, well at least don't escrow the encryption
> >keys.
> 
> Huh?   Okay, PGP uses IDEA for transit keys.  These are encrypted to two 
> different PGP public keys. [...]  These are only used once.

The security principle I am referring to is that by doing as PGP
currently does, and using encryption keys in place of separate
communications and storage keys you are exposing your past traffic to
undue risk.

I am not at all referring to symmetric keys, because the fact that
they are randomly generated and used once doesn't protect them from
recovery via the compromise of your long encryption key and your
attackers copy of your encrypted communications.  The reason for
randomly generating IDEA session keys is a separate one.

The argument for having separate storage and communication keys is a
similar one to the now accepted argument that it is a good idea to
have separate signature and encryption keys.  The obvious advantage of
separating signature keys from encryption keys (introduced in pgp5) is
that if you escrow keys you don't want to escrow signature keys as all
this enables is forgery.

> The signature keys (in the proposed method) are the PGP keys (either
> RSA or DH, it's not important) are the personal keypairs of each
> person.  The company doesn't keep a copy of these.  They can sign
> with this in an unforgable manner.
> 
> Is there a problem here?

No.  I wasn't discussing signature keys.

> - From the description Jon gave of the system, you can designate
> anyone as the other key-id to encrypt to in your signature block.
> (Or whatever that part of the key is called).  The guy in the next
> cube, your boss, one company-wide key, etc.

Yes.  That's half of the story.  The other half of the story is that
PGP went ahead and implemented a SMTP snoopware policy enforcer which
could just as easily be used to enforce GAK.

> So yes, in theory this could be used to implement GAK.  Supposedly
> in the version of PGP in use it's trivial to remove this extra
> recipient from the list of encryption keys.  

I'm not sure that the fact that the pgp5.0 client doesn't attempt to
force you to use the GAK compliancy key adds much to my comfort level
that the whole thing won't end up being used for mandatory GAK.  My
scepticism is derived from the fact that the enforcement of the GAK
compliancy key is provided by another marvelous PGP Inc big brother
innovation: the SMTP snoopware/GAK compliancy policy enforcement app.

The argument doesn't really become apparent until you consider the
effects of lots of people (say 80% of companies) using PGP's GAK
compliancy enforcement.  A few more thin edge of the wedge moves on
the part of the USG GAK proponents (eg deputising service providers as
GAK compliancy enforcers, something which has already been discussed
in the past with the Clipper series), and you will suddenly be unable
to exchange mail with anyone without using GAK.  Sure you have a
"choice", you can send email to people that will bounce 100% of the
time, whoever you send to due to lack of GAK compliance field.
(Except for perhaps a few die hard cypherpunks).

> It's not even needed if you don't have that key on your ring.  (From
> what Jon said)

I'm not sure what you mean here.

> When you compalin about use of storage keys/communication keys your
> clouding the issue.

It might appear complex, but actually adding the distinction between
communications and storage keys greatly simplifies things, and it
allows you to make more appropriate security decisions about key life
times, and escrow.  It also allows you to implement the message
snooping function in a more secure way, and with less big brotherish
overtones.

Using separate storage keys allows you to:

- escrow storage keys within your company without including GAKware
  compliancy

- discard communications keys often (by giving them short life-spans)
  which greatly enhances your security

> The storage keys can be (and probably are in some cases) simply pgp
> encrypted files, as if they were in transit.  

Storage keys could be symmetric keys if they are for your own use
only, or you could escrow them if you want to share access, or your
company wants the extra assurance of data availability that storage
key escrow brings.  There might be some security advantages to using
symmetric keys even.  (Public key sizes are a faster sliding and more
uncertain target than symmetric key sizes.

> I tend to encrypt some files on my hard drive with pgp, by
> encrypting to myself and signing so that onyl I can decrypt them,
> and I've got record that I did create the archive.

You can sign and encrypt with symmetric keys also. "pgp -cs."  Quite a
useful combination.

I used to do the opposite of what you do... I used to use pgp -cs,
because I explicitly didn't want the public key baggage, and danger
that 1024 bit keys might be readable in 10-20 years, the then maximum
key size.

> I can see this being done in a company to simplify shared storage
> usage without security problems.  Using the multiple recipient
> option your recovery key-id can be used to decrypt these files.  Of
> course, if they're modified, they can't be resigned, so you'd know,
> but...

It's probably simpler to just escrow storage keys.  That is just give
management a copy to put in the fire proof safe.  Or secret split or
whatever.

You could use multiple crypto recipient if you wanted to -- it's
basically just another way of acheiving the same thing.

There is one (quite practical) reason, however, to use symmetric
storage keys.  Speed.  If you're encrypting lots of files (perhaps
using an encrypted parition driver such as Peter Gutmann's SFS), you
won't have time to encrypt to public keys, never mind multiple public
keys.

If the company keeps it's employee's storage keys in escrow, the fact
that you're using a symmetric key works fine.

> This is a *simple* solution that eliminates problems with encrypting
> hard drives, etc.

I don't see that it's any more difficult to do as I outline above,
which is better security practice in any case.

> Where is the problem with this system?  This is software that
> (according to Jon's claim) at least one company has decided they
> need for their security, and it keeps the number of pass phrases
> that employees need to memorize at one - their PGP key.

Don't confuse key functionality with user ergonomics.  PGP or other
vendors could easily implement a unified interface to a secured
private key database containing all of your persistent private keys.
You need only have one key.  Or perhaps no keys -- in a secured
environment, or with keys stored on smart cards.

> >Storage keys you make damn sure you can recover.  You escrow these for
> >real.  Company safe sounds about right.  Secret splitting could be
> >nice also.
> 
> Why not just encrypt it to yourself with PGP?  Isn't that simpler?
> Add a recipient of the recovery id.  Boss, coworker, person's key in
> another division, whatever.  Everybody gets different storage keys.
> No need to worry about accidently compromising one of the storage
> keys (IDEA symmetric keys, of course).  You then just need to keep
> the secret halfs of the public keys secure.  Not a big deal if you
> have the rest of the system working.

I'm not really fussy beyond the fact that it will be less efficient in
space (extra public key packets would be significant for a disk block
level partition encrypter), and the performance issues with using
public key crypto to encrypt lots of files to multiple people. 

> >You shouldn't be recovering transient messages, you should be
> >recovering stored data.
> 
> What the hell is the difference?  Speed of recovery?

Nope speed of recovery is not the issue.

> Give an example of the difference between what he's doing and what
> you would propose. Otherwise you're just rejecting this system
> blindly.

I'm sure I've given these reasons earlier in the thread, but I'll
summarise them again:

1. It is more secure to use short lived communications keys because
communications keys are more sensitive than storage keys.  This is
because with communications your attacker has copies of your
ciphertext as you're sending it over an insecure open communications
medium.  Your storage data is on your hard disk, possibly in a secured
environment.

2. People shouldn't be able to recover the data from communications
because for security reasons it should be encrypted with transient
communication keys.  You are purposelly securely wiping the key after
some period.  Keeping extra doors into the communication weakensn this
protection.

3. given that secured communications are now defined as transient in
nature, for security reaons: the natural way to archive such
communicated data is to re-encrypt it for a storage key.

4. people don't really want access after the fact to their transient
communications, they want access to their archived email.

5. you can still implement corporate snooping, and I acknowledge that
businesses have a right to do this (though personally I may not choose
to work for a company which does this).  But you can implement message
snooping, by implementing key escrow of the storage key used to secure
your email archives.  To enforce this to the extent that you can, you
build in automatic archiving in a way which is hard to defeat in the
mail client to decrypt communication with the comms key, and then
re-encrypt with the escrowed storage key.

6. Given the marked difference in life time, security requirements,
and data availability requirements between stored data and transient
communications keys is it any wonder that you can achieve a more
flexible, more secure system by separating functionality of your keys
-- it really is a very similar argument as to the argument over why
you should have separate storage and communications keys.

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: Sat, 11 Oct 1997 22:01:05 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: new "communication key" semantics & PFS
Sender: [email-masked]

Now that we're considering (within the IETF OpenPGP standardisation
framework) the prospect of having a separate communications key, and
storage key, there are some aspects of communications keys which are
currently less than ideal because of their current misuse to also
function as storage keys.

This argues for a new functionality to be given to communication only
keys.  This is all tied up with the idea of Perfect Forward Secrecy
(PFS), which is basically the statement of the fact that
communications keys are more sensitive than storage keys, because your
attacker by definition has a copy of the encrypted communication.
(You're sending over an open network where copying all traffic is a
low cost exercise for a savvy system cracker, or spook, or industrial
espionage).  

In contrast an attacker often will have to break into your premises to
obtain the data protected by your storage keys.  Another aditional
vulnerability of communication keys is that the US government is very
interested in obtaining copies of them via their "key escrow"/"key
recovery"/GAK initiative.  The strongest anti-GAK statement you can
make is to use forward secrecy.  I've raised this point before, but
the meme doesn't seem to have penetrated yet.

Hal Finney <[email-masked]> wrote:
> Adam mentioned the idea of forward secrecy in email communications.
> I'm not sure how that would work technically, but it sounds like
> an interesting possibility.  

It ties in quite well with what is in my view proper handling of
communication keys.  If we can break the tie with one key being used
for both storage and communication, we can start to reflect in the
protocol better security practice in the handling of communication
keys.

Forward secrecy is one way of looking at it.  It doesn't have to be
real interactive forward secrecy as you might get in an SSH session,
or an SSL session, or some of the IPSEC standards, though these are
other examples which could server as examples showing that forward
secrecy is a good idea, for anyone who would like to argue against it.

The basic principle is that you want to have communication keys which
don't live for a long time.  So one form of weak forward secrecy you
could have would be to mark your El Gamal or RSA communications for
much more frequent update, by giving it a short expiry date.  Say once
per week.

Some people currently do this manually anyway.  For example see Dave
Wagner's web page (www.cs.berkeley.edu/~daw/) where he describes what
he does with keys.  (He has a long term signature only key which he
uses to sign short lived "communication only" keys which he discards
after expiry).  What I am arguing for essentially is building this
kind of improved communication key handling into the OpenPGP spec for
keys marked as "communication only".

In addition I think it would be nice to enable a new kind of
communications key which is based on discrete log so that people who
choose to use PGP protocols for more interactive email transfer
protocols than SMTP can generate keys very quickly.  I was originally
thinking that this would have to be DH, but perhaps you can simulate
DH PFS with El Gamal by securely wiping the private parameters of
expired communications keys, and keeping the public modulus and g
value.  (This has similarities with the quick method in PGP5.x of
generating El Gamal keys with precomputed shipped primes that you
already have).  The advantage being that you may be trying to generate
keys frequently, so you may not want to wait for a full new 4096 bit
El Gamal or 2048 bit RSA key generation, when you are not anticipating
the sudden delay in sending messages.

I was originally thinking it would be done by having a new DH key type
(in addition to RSA, El Gamal, DSA).  

(Incidentally Hal, you may recognise in this the reason for some of my
annoyance that PGP Inc is mislabelling El Gamal as "DH" -- with my
earlier ideas on this proposal there would have been a _real_ DH.  It
also gets around objections to do with not being able to decide what
DH keys are (as they are negotiated not randomly generated directly)
which Hal raised as a reason why PFS (at least with DH) would disallow
functionality where key capabilities are included in the public
communications key encrypted packet, the last time this was discussed.
Clearly you could work around this restriction if you had to -- just
include the information in an extra packet encrypted with the
contained key and some symmetric algoirthm for example, though this
may limit algorithm choice at least for that packet).

You can use PFS in an asynchronous "where possible" mode for
non-interactive email transport situations.  That is you would perhaps
send new communications keys parameters with each message that defines
in it's key sub-packet preferrences that it is capable of using
communications only keys, and will be able to handle "recipients comms
key as part of message".  This might make sense where comms keys are
being updated too quickly to burden a key server with, or where comms
keys are not public (an aditional use for Hal's described no-export
flag for signatures, but here applied to communications keys), but are
specific to that communicating pair. (For paranoid people who are
changing comms keys on each receipt, you would need to do this).

As soon as one party has replied to a mail from the other, you can
switch to forward secrecy.  This would lead to emails such as "hi, can
you reply to this message please".  These are kind of similar to the
"hi can you send me your public key" you get back from people when you
haven't included your public key in your mail to them, and they don't
have access to a keyserver.

You can also then use this new "communications only" key setup to cope
with fully interactive email delivery for systems using email
transports other than standard SMTP.

You should probably overlap sending communications keys if you aren't
relying on keyservers due to frequency of key update, or for
convenience for people without access to keyservers, so that the
person sending you email is less likely to have no current
communications key for you if you are using keys sent in the message.
So towards the end of the month (if you had a policy of using
communications only keys with monthly updates) replacing keys monthly
start sending the next months communications key also, marked as not
for use until it's starting date.

(The use of very transient communications keys I think would imply a
need for two communications keys: you'll need a long term
communications key which is used for initial non-PFS mail in order to
set up PFS.)

With the separation of storage and communications keys all the
architecture has much better security decisions:

- We are able to treat communications with variable amounts of
  sensitivity, by giving different key expiry time periods to comms only
  keys.

- We are also able to secure and escrow our long term data storage in
  mail box folders, or PGP encrypted files without having to live with
  a GAKware compliant implementation of snoopware.  We can storage
  escrow keys appropriately without all the name calling and bad PR
  caused by enraged crypto anarchists, and crypto consultants.

You _know_ it makes sense :-) 

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: Sat, 11 Oct 1997 22:23:04 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: PolicyMaker & GAK compliance
Sender: [email-masked]

Hal Finney <[email-masked]> writes:
> Adam Back writes:
> > I would be nice to see the topic of the recipient refusing email based
> > on policies relating to third party access to messages in transit
> > being addressed in the standard when and if PGP gets to that stage.
> >
> > [ecash processing]
> 
> This is a good example of a possible future kind of key assertion.
> Are you confident that you can decide which kinds of recipient refusal
> are morally correct and which kinds are not?

Not automatically, no, I doubt it would work.

> Is it the role of the IETF and the Open-PGP process to make this
> determination?  I would say not.  Rather, we should standardize data
> structures and conventions which allow people to express those
> conditions and assertions which are useful to them.

Yes.  I agree.

> There are a whole range of possible assertions which you might object to:
> 
>  [examples of PolicyMaker style policies]
> 
> You can take these case by case and decide for yourself whether each
> one is acceptable or not by your own standards.  But I don't think it's
> going to be possible to come up with a set of objective rules which will
> decide whether any given assertion is allowed.
> 
> Fundamentally, you are asking to make it illegal for a key to request
> encryption to an additional recipient.  That's what it comes down to.
> You want to forbid this class of assertions.

Yes.  I was getting carried away.  It would be too complex, most
likely.

The thrust of your argument seems to be that there would be little use
making pgp 5.5 non-GAK compliant, because PolicyMaker style statements
will be so flexible that they will be GAK compliant anyway.

So, when are PGP starting work on PolicyMaker?  Is it intended to
introduce this functionality in this first round standardisation?  It
seems to me that adding PolicyMaker functionality could take some
considerable time due to the huge complexity of the task.

Also, just because GAK compliance will become possible if and when
PolicyMaker style extensions are implemented, doesn't mean that PGP
can expect popular support for actually going ahead and implementing
GAK compliancy in pgp5.5; nor can it expect to gain popular support
for the uncharacteristic big brotherish mentality displayed by those
working at PGP in implementing the SMTP policy enforcer behind closed
doors to enforce other people to modify their behaviour to honour
third parties GAK or CAK requests.

I think the whole thing is a huge PR fluff up.  I'm suprised that
those at PGP were all able to agree to do it without arguments being
expressed by employees, and without those arguments leaking out of the
company (given the picture Jon Callas painted of strong privacy and
freedom biases at PGP).  If there had been open discussion of the
product's design prior to development, this feed back could have been
obtained earlier.

I presume the PGP PR person (who ought to get the sack in my opinion)
thought that a sudden press release of such marvelous new feature as
PGP snoopware and a snoopware enforcer for third parties would go down
well.  It doesn't.  The enforcer is rudely enforcing the companise
opinions on people who have no connection with the companies snoopware
policies.  You should keep such matters within the company by using
escrowed storage keys to acheive snoopware.

For these reasons I still argue that we should:

- add storage keys to the standard

   It's more secure to do this.  That should be argument enough in
   itself.  It also is much cleaner separating key functionality out
   into separate keys where those keys have vastly different recovery,
   life time, and security requirements.

- use storage key escrow to implement PGP snoopware instead of burdening
  the OpenPGP standard with the stigma of GAK compliancy

   This method ties in with the use of storage keys.  It is nearly as
   effective a snoopware design.  It also isn't GAK compliant.  It
   also doesn't result in cypherpunks shouting at you.

- don't use the special sub-packet type to flag GAK compliancy

   I think the above shows that the neither the standard, nor PGP Inc
   needs the GAK compliant sub-packet, so scrap it, and save the
   argument up for the much more defensible position of a generalised
   PolicyMaker style  key usage restriction assertions

- scrap the controversial SMTP snoopware policy enforcement app

   Use storage key escrow to implement PGP snoopware instead of
   burdening the OpenPGP standard with the stigma of GAK compliancy

It's difficult to get standards which don't reflect big brotherish
aims when the good reputation of PGP Inc and Phil Zimmermann is
apparently behind it.  Something weird is going on at PGP
headquarters.  PRZ is also silent.  Are all the people at PGP Inc in
accord in thinking that the snoopware policy enforcer is a really cool
pro-privacy app?  Some of the usually more vocal PGPers have remained
silent throughout the entire episode.  Also as Tim note's the lack of
a Zimmermann Telegram (tm) getting suspiciously overdue.  Is he
dragging his feet of snoopware and GAK compliancy?

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: Sat, 11 Oct 1997 20:19:29 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: key use sub-packets / draft EEMA standards
Sender: [email-masked]

Ian Brown <[email-masked]> writes:
> Hal Finney <[email-masked]> writes:
> > PGP now offers an extensible signature format.  This allows key
> > signatures, both self-signatures by a key on itself, and ordinary key
> > signatures by keys on other keys, to do more than before.  The extensions
> > are in the form of subpackets within the signature packet.  Various
> > subpackets have been defined, and Open-PGP would be an excellent forum
> > to propose and design new subpacket types and corresponding data formats...
> >
> > Other subpacket types are intended to be used with self-signatures,
> > allowing a key to make assertions about itself.
> 
> OK, just re-spotted this in Hal's post. This is obviously the place for
> a key to assert that it is to be used for transient message encryption,
> signing or (recovery-enabled) storage - or other purposes, as Adam's
> message about Norwegian standards suggested. Can we discuss and design
> such a sub-packet now?

Sounds like the correct place for them to go.

How are PGP's signature and encryption keys usages currently
differentiated?  Do they use the sub-packet type in the self-signature
mechanism?

One problem which will need to be worked out is what will it imply for
interoperability if some implementations can understand more
sub-packet types.

Say that some Norwegian people wanted to use OpenPGP to implement to
their standard which defines the 5 key purposes I listed, does that
mean that all PGP versions have to understand them all to interperate?

Or can we get away with some minimum set for WILL implement, with the
remainder being MAY implement, where implementations are defined to
flag keys with unrecognized key types as beyond their ken.

My vote for a minimum set would be the 3: signature, encryption and
storage.

What would be the effect on behaviour of implementations which chose
not to implement say authentication and certification keys defined in
the Norwegien standard when they received messages using such key
types.

Now that I've dug out a copy of the document I was referring to, I'll
provide you with the desired security functions they list.  (The keys
and their functionalities required to implement it aren't in this
document):

It's I think part of "EEMA", you may be able to find that with a web
search, or some may be familiar with that acronym.  The document
doesn't really identify itself properly -- it's some kind of draft
working document which was passed around at another standardisation
meeting for background.  There is more to it, I've just extracted
their summary security functions definitions:

: - Authentication
: - Authorization
: - Notarized Authorization
: - Non-Repudiation of Content Received
: - Confidentiality

Where these are defined later on as:

: - Authentication: Authentication gives the recipient guarantees of the
: accuracy of an object, the identity of it's originator and optionally,
: it can assure that the originator cannot repudiate having originated
: the object.  It shall not be used for, nor be interpreted to be a
: legally binding contractual commitment to the informatino content of
: the object.
: 
: - Authorisation: Authorisation provides all of the protection and
: guarantees defined for Authentication.  In addition, it provides a
: means for the originator to express a contractual binding to the
: information content of an object.  The meaning of the contractual
: binding is expressed by the information content of the object itself -
: eg if the information is a contract, the Authorizatino function is
: used to `sign' the contract.  If the information is a command, the
: authorization signals the recipient to carry out the command.
: 
: Notarised Authorisation provides all of the protection and guarantess
: defined for Authentication and Authorisation.  In addition, it
: provides a long term proof of origin and contractual binding of
: originator to information object.  This is achieved by using the
: services of a trusted third party (eg. a Notary) which securely
: attaches an accurate time stampt to the object.
: 
: Business Scenario - users wish to exchange a long term documents (eg
: an agreement or contract) which will outlast the validity time of the
: private key used to uathorise the document.
: 
: Non-repudiation of Content Received: this function provides a secured
: acknowledgement of receipt of a secured object.  It provides object's
: originator with:
: 
: - guarantees of intact delivery of the information object;
: - irrefutable proof of the identity of the recipient
: 
: Confidentiality: The confidentiality function allows the originator to
: conceal the information contained in an object so that only the
: indended recipients can access the original information.

Anyway, those functionalities should give y'all a flavour for the
kinds of things different countries would like to define as legally
understood security functions.  They do actually look quite useful,
and I was quite impressed with the thought that went into the argument
for notarized (time-stamped) signatures on long term contracts with
longer expected life-time than the signatories keys.

I'm not suggesting we go ahead and do anything about these functions,
as that kind of thing will surely have to come after some major
international standardisation efforts agreeing on legal definitions.

But I hope it is useful to read, and perhaps other people can throw in
some other definitions from other countries signature standards
processes to give us a feel for the kinds of signatures people might
want to use.

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: Sat, 11 Oct 1997 11:42:28 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

Adam Back writes:
> I've read Matt's PolicyMaker paper.  I can see the attraction of
> moving towards these generalisedl trust statement syntaxes.
>
> I would be nice to see the topic of the recipient refusing email based
> on policies relating to third party access to messages in transit
> being addressed in the standard when and if PGP gets to that stage.
>
> There are some nice uses for some types of recipient refusal.  Ecash
> payment for message processing, or my less $ oriented hashcash
> proposal also.  (The types of problem that can arise with real ecash
> payment for receipt, which hashcash avoids is that if applied to
> discussion forums, it can bias the forums to allowing through more of
> what rich people have to say.  A similar argument perhaps applies to
> email following up to comments made in public forums, you can only
> reply to someone if you have the money.  Busy people may set very high
> payment rates.)

This is a good example of a possible future kind of key assertion.
Are you confident that you can decide which kinds of recipient refusal
are morally correct and which kinds are not?  Is it the role of the IETF
and the Open-PGP process to make this determination?  I would say not.
Rather, we should standardize data structures and conventions which
allow people to express those conditions and assertions which are useful
to them.

> > The CMRK is one such type of assertion: "please cc to key X anything
> > encrypted for me".  The key is requesting that the specified other key
> > by an additional recipient on encryption.
>
> I can see problems with this type of assertion.  I hope when the time
> comes that a way to define a convetion or set of rules which disallows
> this as part of the standard.

There are a whole range of possible assertions which you might object to:

 - All messages not encrypted to key X will not be read (subtly different
   from what we have now, in that it does not request you to encrypt to X,
   merely informs you that the recipient won't read it unless you do)

 - Message not signed by a key certified by signer X will not be read

 - All messages encrypted to this keyholder will be automatically copied
   to the holder of key X (corporation, etc.)

 - This key has been escrowed cooperatively (private component shared with
   a third party)

 - This key has been escrowed under duress by the keyholder of key X
   (corporation, etc.)

 - Only encrypt to this key using algorithm Z (where you consider Z weak)

You can take these case by case and decide for yourself whether each
one is acceptable or not by your own standards.  But I don't think it's
going to be possible to come up with a set of objective rules which will
decide whether any given assertion is allowed.

Fundamentally, you are asking to make it illegal for a key to request
encryption to an additional recipient.  That's what it comes down to.
You want to forbid this class of assertions.

Suppose a key wanted to delegate signing authority to another key.
"Treat signatures by key X as though they are by me."  Is that also
immoral?  Suppose a key said, "instead of encrypting to me, encrypt
to this other key."  Is this acceptable?  It could be part of a key
retirement process.  These possibilities are not so different in form
from requesting an additional recipient, but they might have uses which
you would endorse.

I think this approach of forbidding assertions is fundamentally flawed.
As I wrote, I expect to see us moving towards more expressive language,
which will inherently give the power to make assertions which some
people would object to.  That's the price you pay for expressive power.
In the English language people can say bad things as well as good.
I'm sure you would oppose restrictions on what people can say in English.
Why not apply the same principle to what people can say with their keys?

Rather than getting bogged down in trying to come up with a litmus test
for which assertions are allowed, I would rather see the group work to
improve the data structures and language used for expressing assertions.
What other kinds would people like to see?

Adam mentioned the idea of forward secrecy in email communications.
I'm not sure how that would work technically, but it sounds like
an interesting possibility.  Some people have suggested features to
facilitate anonymous communications.  New kinds of signatures like
untransferrable, designated-verifier, group and threshold signatures
are worth discussing.  There are a lot of features I would like to see
us moving towards.  But artificially limiting the expressive power of
key assertions is the opposite of the direction we should be going.

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

Date: Sat, 11 Oct 1997 10:55:49 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

Ian Brown writes, quoting Hal:

> > Other subpacket types are intended to be used with self-signatures,
> > allowing a key to make assertions about itself.
>
> OK, just re-spotted this in Hal's post. This is obviously the place for
> a key to assert that it is to be used for transient message encryption,
> signing or (recovery-enabled) storage - or other purposes, as Adam's
> message about Norwegian standards suggested. Can we discuss and design
> such a sub-packet now?

I'm not sure that this would accomplish what you desire.

PGP already has sign-only and encryption-only keys, but these limitations
are implicit in the types of the keys.  I prefer making things explicit,
so allowing a key state that it is sign-only or encryption-only would
be desirable (ignoring the difficulty of making statements with a key
which can't sign!).

For a key to say "I am signature-only" means that it should not be used
for encryption.  If you were to encrypt a message to such a key then the
user would not be able to decrypt it.

For a key to say "I am encryption-only" means that it is not intended to
be used for signing.  If you do somehow run across a signature by such a
key, you should not trust it.

Extending this to communications and storage keys would suggest the
following.

For a key to say "I am communications-only" means that it is not intended
to be used for persistent storage.  A file encryption program might
not be supposed to use such a key to encrypt a disk file, for example.
(Although the user may be frustrated if the reason he was encrypting that
file with a communications-only key was because he intended to later send
it to that person!)

For a key to say "I am storage-only" means that it is not intended to be
used for communications.  An email program would ignore such keys and not
try to encrypt messages to them.

Is this your intention?  I don't see what problem it solves.  Email keys
would presumably be marked as communications-only.  All you would
have accomplished is to prevent people from encrypting disk files with
email keys.  We can discuss this kind of feature but it would be helpful
to understand the specific goals better.

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

Date: Sat, 11 Oct 1997 15:38:38 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: Hal Finney <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

> PGP now offers an extensible signature format.  This allows key
> signatures, both self-signatures by a key on itself, and ordinary key
> signatures by keys on other keys, to do more than before.  The extensions
> are in the form of subpackets within the signature packet.  Various
> subpackets have been defined, and Open-PGP would be an excellent forum
> to propose and design new subpacket types and corresponding data formats...
>
> Other subpacket types are intended to be used with self-signatures,
> allowing a key to make assertions about itself.

OK, just re-spotted this in Hal's post. This is obviously the place for
a key to assert that it is to be used for transient message encryption,
signing or (recovery-enabled) storage - or other purposes, as Adam's
message about Norwegian standards suggested. Can we discuss and design
such a sub-packet now?

Ian.

Date: Sat, 11 Oct 1997 13:34:36 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: r.e. OpenPGP document status
Sender: [email-masked]

Rodney Thayer <[email-masked]> writes:
> The message formats draft(s) are being worked on now.  We've only
> had official WG status for something like two weeks.  A little
> patience is in order, I think.

PGP Inc is the group being impatient.  They have been rushing ahead
implementing things behind closed doors which some of us are arguing
should be made non-conforming (WILL NOTs) in the standard.

If PGP doesn't backoff a bit _they'll_ have non-conforming
implementations, and will have to change them.  The danger is that in
a Netscape-like manner, they will use their implementation and
deployment as arguments to justfiy their design decisions rather than
being involved in open design decision justifications as part of the
standardisation process.

This is not how the IETF standardisation process is supposed to work.
Trial implementation of proposals is fine, closed door design and
sudden deployment and mass sale by the market dominator to pre-empt
standardisation I think is not.

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: Sat, 11 Oct 1997 12:35:46 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

Ian Brown <[email-masked]> writes:
> William Geiger wrote:
> 
> > This is a stereotypical Strawman. "Even if PGP avoids GAK some other 3rd
> > party can modify it to be Gakware." Every version of PGP had the ability
> > to encrypt to multiple recipients. As I stated in my previous posts I can
> > get PGP 2.6.x to do everything 5.5 does with a couple of scripts.
> 
> Yes, but as Adam says, the average Mr. Windows can not. In any case,
> this is not a narrow technical argument. Of course any system with
> multiple recipients can be turned into GAKware. The point is that we
> don't want to make it ANY easier for anyone to do so.

Agree.  What I am proposing is to make GAK enabled systems
non-interoperable with the OpenPGP standard on the sending end (ie to
define that when you receive a message it won't dictate to you that
you should use GAK compliancy, and to define that if flags indicating
message snooping is ocurring this won't be enforced by your mail being
bounced if you don't, and won't be implemented with encrypting to a
special snooping crypto recipient).  What PGP is proposing with PGP
5.5 is to implement enforcement on end users to send to GAK (or
corporate snooping) enabled keys using the snooping key.

They claim that it's ok, because the user is empowered, as he can
override the sending to the snooping key.  But, if you enable the
sender of a message you receive to state (in syntax defined as part of
the OpenPGP standard, or even if it is not) that if you don't encrypt
to this corporate snooping key (or technically equivalent
functionality: government GAKking key) the message will bounce, how is
this user empowerment, or choice in any meaningful way.  How is this
user empowered to choose when 80% of businesses end up using this
feature?  Or when the government mandates this feature.

> > No this is not mandatory GAK compliance. Mandatory GAK compliance would be
> > if every copy of PGP came with a government key and the program *forced*
> > the user to encrypt all his messages with it.
> 
> Again, as Adam says, how long would it take for a government to
> introduce legislation making this mandatory once PGP 5.5-type systems
> took off? Or, more insiduously, using its purchasing power - "Federal
> agencies will only buy CAK-enabled systems" - to ensure the vast
> majority of systems did so.

Bingo!

> > Ok Adam here is a challenge for you:
> > 
> > -- Explain why Corporations do not have the right to access *their*
> > documents in whatever form they may be in.
> 
> Can I take this one up ;-) 

You beat me to it ... my reply crossed in the mail :-)

> The point is, with *communication* keys, corporations will have full
> access to the plaintext because it will be decrypted by the
> recipient as soon as it arrives. I appreciate your point about
> corporations being able to read *their* documents - although doing
> so by snooping, without the sender's knowledge, is rather unethical
> to say the least - but I don't think they have the right to snoop on
> all *incoming* communications, whoever they may be from. This is the
> really scary part of PGP 5.5...

Even if you do argue that they do have the right to snoop incoming
messages (and there may be a case for this even if some of us find it
a bit little brotherish), this can still be just as easily catered
for, without building GAK compliance into the IETF OpenPGP standard by
having the user's client software decrypt and store their mail folder
in plain text, or encrypted to a company escrowed storage key.

Such a system would not be at all GAK compliant.

> William Simpson wrote:
> 
> > Let us decide _what_ the goals are, _how_ to solve the problems, and
> > _then_ decide the protocol details and formats to match the solution.
> 
> Absolutely. Can we start with Adam and William's proposal that we should
> have three separate types of key: communication, signature, and storage.

(I am glad that you managed to persuade William that this was
necessary, I didn't notice him agree :-) William should however be
credited for the useful contribution that you can just as easily
implement corporate snooping with the existing multiple crypto
recipients functions of pgp2.x.  (Without the GAK compliancy baggage).

> This would be very simple to implement; probably the easiest and most
> backward-compatible way would be to define a new packet type specifying
> a key's usage. 

I'll go for this idea.  X509 v3 certificates have such an extension,
and it seems like a very useful functionality for OpenPGP to include.

Re. the argument about separating key functionality leading to more
consistent and secure designs, if people don't like 3 keys, you should
see some of the Norwegian standards stuff which was relayed to me at a
eurpean medical messaging standarisation meeting... they reportedly
have 5 key usages defined:

  1. storage
  2. signatures
  3. encryption
  4. certificates
  5. authentication

> > Why have a communication enforcement filter, when the only usage is
> > supposed to be for recovering archival storage?
> 
> Absolutely. I can see the point, and appreciate the difficulties faced
> by PGP Inc., in most of the CAK features of PGP 5.5. But I just can
> *not* see how the twisted idea of the SMTP snooper ever came about.

It came about I suspect because the real unstated feature they are
trying to implement is message snooping, and not stored email folder
access as the "data recovery" badge used by Jon in his first post may
lead one to assume.  Of course the reason they think they are able to
use the argument that "email is both storage and communications" to
justify this is largely because they haven't yet digested the meme
that you should have separate storage keys.

I also heartily agree with William Allen Simpson's comments.

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: Sat, 11 Oct 1997 12:07:10 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

Hal Finney, now working for PGP <[email-masked]> writes:
> PGP now offers an extensible signature format.  This allows key
> signatures, both self-signatures by a key on itself, and ordinary key
> signatures by keys on other keys, to do more than before.  The extensions
> are in the form of subpackets within the signature packet.  Various
> subpackets have been defined, and Open-PGP would be an excellent forum
> to propose and design new subpacket types and corresponding data formats.

OK, that means the correct technical term for my discussion is an
argument over the GAK compliancy subpacket type.

> Some of the subpackets are modifiers of ordinary userid-binding signatures.
> These allow signatures to have expiration dates; to be marked as non-
> exportable (so that the signatures are only for your own use on the
> keyring); 

I really like this non-exportable signature option.  It is highly
useful.  I have a couple of keys on my key ring with signatures on
them that I have mentally flagged as non-exportable.  This is because
they are signatures by the True Name of nyms I happen to know the True
Name of and are intended to allow me to transfer the trust to that
Nym, but the Nym is trusting me not to make public this signature.

It would be really kind of neat to extend this functionality so that I
_couldn't_ export the key by making the certifcate a non-transferable
signature, or a designated verifier signature.

> And here there is the new corporate message recovery key (CMRK)
> subpacket.

This is the controversial object.  I have been arguing in a couple of
earlier posts today that this design is a bad idea from a security
perspective, and from the point of view that it is a form of GAK
compliancy when coupled with PGP's SMTP policy enforcer.

The reason I say this is that if we get to the situation where many
businesses are using PGP 5.5 + PGP policy enforcer, the clients
"choice" to not encrypt to the message snooping second crypto
recipient in the CMRK subpacket will have little practical meaning.
The user will be forced to comply or be unable to send messages which
don't bounce.

A better place to do corporate snooping, and to avoid the extra
security risk of sending messages over the internet encrypted to two
rather than one long term encryption keys, is to snoop the plaintext
after it has been decrypted in the PGP 5.5 mail client.

Also, the message snooping functionality is reading between the lines;
Jon's post no where mentioned this as a user requirement.  What he
said was that corporates had a need to recover encrypted email
messages stored in encrypted mail folders.  If this is truly the case,
the functionality is even easier to achieve, just encrypt the mail
folder to a company escrowed storage key after decryption.  Easy to
do, and more secure.  Same flexibility in reflecting the internal
structure of the company's trust and risk management in the storage
key escrow architecture.

> The CMRK subpacket allows a key to request that when a message is
> encrypted to it, the message should also be encrypted to a specified
> additional key.  The subpacket includes a flag byte which is designed to
> allow the key to give information about the circumstances under which this
> should be done. Only two values are presently defined, one specifying
> an optional request, and the other meaning that the message will not be
> read by the recipient if the additional encryption hasn't been done.

If PGP is going to forge ahead and try for this flawed message
snooping architecture anyway, I would urge you personally to at least
press upon them to remove the flag meaning that a message will not be
received without the use of the message snooping key, and to remove
the functionality preventing delivery in the SMTP policy enforcer.

> I won't address the controversy about this feature, as that is being
> thoroughly discussed in other forums.  Let me make two points, though:

OK.  The controversy has technical basis too -- and seems to be
starting to be discussed in this forum also.  There is also a question
of how this design interacts with the IETF policy of not allowing
political issues to weaken protocol designs to discuss.

> We would like to move towards a mechanism to allow more power for keys
> to make assertions.  Matt Blaze's (still vaporware?) PolicyMaker project
> showed how powerful such a general mechanism could be.  SPKI is also
> working along these lines, defining a certificate format which allows
> keys to make very general classes of assertions.

I've read Matt's PolicyMaker paper.  I can see the attraction of
moving towards these generalisedl trust statement syntaxes.

I would be nice to see the topic of the recipient refusing email based
on policies relating to third party access to messages in transit
being addressed in the standard when and if PGP gets to that stage.

There are some nice uses for some types of recipient refusal.  Ecash
payment for message processing, or my less $ oriented hashcash
proposal also.  (The types of problem that can arise with real ecash
payment for receipt, which hashcash avoids is that if applied to
discussion forums, it can bias the forums to allowing through more of
what rich people have to say.  A similar argument perhaps applies to
email following up to comments made in public forums, you can only
reply to someone if you have the money.  Busy people may set very high
payment rates.)

> The CMRK is one such type of assertion: "please cc to key X anything
> encrypted for me".  The key is requesting that the specified other key
> by an additional recipient on encryption.

I can see problems with this type of assertion.  I hope when the time
comes that a way to define a convetion or set of rules which disallows
this as part of the standard.

> If we move to a sufficiently powerful language to allow keys to make
> useful assertions, it seems to me that we will probably inherently
> allow keys to make assertions of a type which some people may regard as
> politically unacceptable, like this one.  But to artificially constrain
> the language so that it can only say things which are politically correct
> will make a an already-difficult design task into an intractable one,
> I'm afraid.

We'll see when we get to it.  In the mean time, PolicyMaker &
look-alikes are vapourware.

> Ultimately, a fully general and flexible system of key assertions will
> allow keys to say stupid things as well as smart ones.  I believe that
> the power gained from having such a language gives advantages which
> outweigh the problems of misuse.  (Note the similarities to the debate
> over the PICS labelling technology, which some people oppose because it
> could be misused.)

It's similar to PICs in that third party rating services are fine (for
example consumer product evaluations in various magazines), but
centrally controlled ones are objectionable to many of us.

> Secondly, with this type of assertion, as with others such as
> the preferred algorithm packet, it is inherently in the sender's
> (encryptor's) power to ignore it if he chooses.  You can request that I
> not use triple-DES, but I could still send you a message encrypted with
> that algorithm.  You would then have the choice to reject it or accept it.
> This is a point which I owe to Phil Zimmermann.

The problem with this point, which you say is PRZ's, is that it falls
down for interoperability reasons when the system is widely deployed.
Exactly how much "choice" do you have when 80% of businesses will
bounce your mail if you don't comply.  How much "choice" do you have a
few years later when 95% of individuals and companies are using the
same system, and the government is holding the master snooping keys.

[1] The long term likely value of this choice is rather low, so the
assertion that it leaves you empowered is a weak assertion.  You would
paradoxically in this case be much more empowered if the recipient did
the escrowing silently after receipt by decrypting and storing his
mail folder with an escrowed storage key.  Of course it would be nice
if this policy was advised in the public key also, to at least warn
you, in case you mistook the persons email address as a private
account.  (Some ISPs have names which look similar to some companies
names,... domain names ending in .com, if you are not familiar with
the company name).

> Likewise in PGP 5.0 the user can override the CMRK request even in
> its strongest form (although not in 5.5, because that is intended
> for business-to-business communications).

I submit for the above reasons that this overriding feature will in
the long term me fairly meaningless.  What is the practical individual
empowerment transferred in being able to override something in the
sure knowledge that it will thereby be bounced and not delivered.

> Therefore, I very much agree with Jon Callas that an implementation which
> (perhaps optionally) allows overriding the requests which a key makes
> in its self-signatures should still be considered compliant.  That is
> consistent with the nature of the sender's power to create the message.

I strongly disagree for reasons stated in paragraph [1] above.

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: Sat, 11 Oct 1997 11:17:32 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

William Geiger <[email-masked]> again:
> In <[email-masked]>, on 10/11/97 
>    at 02, Adam Back <[email-masked]> said:
> >Jon Callas <[email-masked]> writes:
> >> I am adamantly opposed to any of PGP's business features being MUST
> >> features of OpenPGP. If they were, then our freeware and personal
> >> privacy products wouldn't be conforming applications, and we have
> >> *no* intention of putting them in those products. Wouldn't that be
> >> an interesting situation?
> 
> >I may be misunderstanding something here, but could you tell me how PGP
> >freeware and PGP personal privacy can simultaneously not have recognition
> >of GAK compliant keys, and emit messages telling the users that this is a
> >GAK key (on receipt of the flag you described), and emit messages warning
> >the user that the email will not be delivered (on receipt of that other
> >flag you described).
> 
> I didn't see where Jon said that the other versions versions of PGP would
> not recognize these keys. 

Neither did I.  But the question at hand is whether the IETF OpenPGP
should recognize them.

> What Jon did say is that they would not generate these keys nor
> force compliance with encryption to a second key. I myself would
> want to know that a message encrypted with key A is also being
> encrypted with key B though haveing this info in the public key
> itself is not necessary.

I'd argue that it's more than just not necessary, having the
information in the public key is the sole reason I'm arguing that this
is a GAK compliant feature.

> >If it's defined as being compliant to ignore both of these flags, and the
> >message snooping key then users email will bounce without warning.
> 
> I don't see this as a problem. My Twit/SPAM filter bounces messages
> without warning. As a matter of fact most bounced messages are done so
> without warning. :) 

Not very intuitive to the user though is it.  Also not a very strongly
optional feature if 80% of businesses end up bouncing your mail back
at you because you're "choosing" not to be GAK compliant.

> >If it's defined to silently send to second crypto recipient, you have
> >fully interoperable GAK compliance built in to the core of PGP.  If PGP
> >Inc will remove the GAK compliance when GAK becomes mandatory, I'm sure
> >there are other companies who won't have a problem selling out to GAK (eg
> >IBM, or TIS).
> 
> This is a stereotypical Strawman. "Even if PGP avoids GAK some other 3rd
> party can modify it to be Gakware." 

Not so fast there.  That isn't the stated problem.  The problem is
that not only can some 3rd party adopt it (no modifications necessary,
that's why I'm dubing it "GAK compliant"), but that the rest of the
compliant OpenPGP standards would automatically cooperate to some
degree, and we would thereby be streamlining the migration path to
mandatory GAK.  If PGP retract the GAK compliancy feature, by removing
the functionality in the key, we won't be calling it GAK compliant.
They (and any other government or corporate message snooping feature
implementors) can achieve message snooping without adding this
functionality to the OpenPGP standard.

> Every version of PGP had the ability to encrypt to multiple
> recipients. As I stated in my previous posts I can get PGP 2.6.x to
> do everything 5.5 does with a couple of scripts. Are you no willing
> to take the position that ALL versions of PGP are GAK compliant???

No, they are not.  I've argued in reply to your other post why this is
clearly not so.  The difference is that PGP is creating a new animal:
a key which it is defined will be auto-encrypted to two keys by the
_sender_.  Variations being discussed being auto-encrypt with user
query, or auto-encrypt with user override to disable.  Regardless, the
fact that PGP is encouraging the process of enforcing this dubious
security practice via their policy enforcer means that users are
forced to use the GAK compliancy feature to get through to any
corporates who are using PGP's method of implementing corporate
message snooping.

> >If it's defined to warn but give the option to send to second crypto
> >recipient, well you've still got mandatory GAK compliance, but you've got
> >a pretty little warning that you've got mandatory GAK to rub your nose in
> >the fact for each message you send too.
> 
> No this is not mandatory GAK compliance. Mandatory GAK compliance
> would be if every copy of PGP came with a government key and the
> program *forced* the user to encrypt all his messages with it. This
> is really turning into a shameless FUD campagne on your part Adam
> worthy of David "FUD" Sternlight himself.

It's less strongly enforced GAK compliance, but I think it is still
a form of GAK compliance.

To see why this might be, consider the effects of 80% of the business
community using this feature, and you as a pro-privacy cypherpunk type
(you are pro-privacy aren't you?).  Consider also that government has
mandated that companies hand over their message snooping master key to
the Feds.

Now what happens.  In the above, you have the "option" not to use the
GAK compliance feature in that you can still send a message, but the
option won't be worth much in that the recipient will be unable to
read it.  If lots of people are using this system, that will cut you
off.  You will be unable to send email to these people.  It's all very
well to say you have the "choice" not to do business with them, but
your choices may be severely restricted.

I hope that following from this discussion you can see the advantages
of PGP switching to the use of the normal multiple crypto recipient
field to acheive this message snooping functionality.  It doesn't
apply at all to the recipient.  The snooping of received email for
those using PGP 5.6 "message snooping for businesses" is done after
decryption in the PGP5.6 "for message snooping enforcing" client.  The
snooping of sent mail for users of PGP5.6 "for message snooping
enforcement" client is done inside the corporate LAN as the message
snooping packet security leak prevention functionality built in to the
PGP 5.6 "SMTP prevention of security leaks enforcer" strips out the
second message snooping crypto recipient packet.

> As far as I am concerned you have not proven your case that PGP 5.5
> is GAK compliant. Your general argument that PGP 5.5 has the
> potential to be GAK can cover *ALL* version of PGP. Any system that
> allows encrypting to multiple recipients can easily modified into a
> GAK system.

You may have not been convinced of the case, but that is because you
have not considered the long term picture, interoperability issues,
and utility to GAKkers of having GAK compliant features in the IETF
OpenPGP standard.

The argument that pgp5.5 has mandatory GAK compliancy does not in any
way apply to older versions of PGP.

PGP 2.x can support voluntary GAK in that the user can send to a
second key that the NSA generates for thme.

It is the features which move the enforcement of this functionality
into the senders client, and the fact that the "optional" nature
becomes weakly optional (meaninglessly optional) if you consider
scenarios where most businesses are using the pgp5.5 SMTP policy
enforcer to bounce your email unless it complies, and where business
are legally required to use such policy enforcers, and businesses are
legally required to hand over the master corporate snooping key to the
GAKkers to go in the NSA database.

> >I gave lots of examples of other ways to achieve the claimed
> >functionality of recovering stored data.  Achieving hard to circumvent
> >corporate email snooping functionality is harder to achieve without CMR. 
> >You can do some, but not quite as much.  But corporate snooping wasn't on
> >your stated list of user requirements.  And it's not very savory anyway.
> 
> I think this is your real issue here. You don't like the ideal of a
> company haveing access to their documents. If that's how you feel then
> make your case so it can be judged on it's merits.

That's a separate argument entirely.  I believe that I have shown
security advantages in not doing corporate message snooping in the way
that PGP is "proposing" (by steaming ahead and implementing and
deploying it outside of the IETF OpenPGP process).  In addition I made
the point earlier that any form of message snooping is weak... there
are many ways for the determined employee to by pass it.  The only
real protection is surveillance cameras, tamper-resistant key board
logs, and body cavity searches at the door.  So if enforcement is weak
anyway, it seems sensible to trade some small percentage of this
enforceability for enhanced security.

I went to great pains to detail other more secure, and entirely
feasible methods of assuring corporate message snooping functionality
can be built.

I also clearly distinguised between stored documents and documents in
transit in transient communications mediums.

In addition I argued for key escrow of storage keys as good company
backup policy.

You have not been paying attention here, or are playing the function
of the luddite, refusing to accept that better security is obtained by
separating the functionality of encryption keys and storage keys.

A similar example might be if you were to refuse to countenance the
suggestion that having separate signature and encryption keys is
better than not doing using as an argument perhaps the fact that
pgp2.x has been using the same key for both purposes for years.

The point of the IETF OpenPGP standardisation process is to explore
the options and decide on the best technical approach, which is in the
interests of the Internet community.

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: Sat, 11 Oct 1997 10:41:36 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: IETF policy on refusing to allow politics to weaken protocols (Re: Why Adam Back keeps politicizing technical issues)
Sender: [email-masked]

Williams title being: `Why Adam Back keeps politicizing technical
issues'

I would like to comment that the reason politics are arising in
discussion of communications security issues is a natural consequence
of the fact that it's a damn political topic.  Ignore the politics and
you may implement a mandatory GAK system, or at least a GAK compliant
one.  Actually I also argue that there are technical security reasons
why the CMR approach offers weaker security.  I've gone over these
reasons already in this thread, so I won't repeat them.

IETF I think has a stated policy (at least this is the case for the
IPSEC standardisation discussions I have been intermittently
following) to not allow politics to weaken it's protocols and
algorithm choices.  PGP Inc introducing GAK compliance at the cost of
security is a clear case where this policy should be kicking in.

William Geiger <[email-masked]> writes:
> In <[email-masked]>, on 10/10/97 
>    at 08, Adam Back <[email-masked]> said:
> 
> Ok Adam here is a challenge for you:
> 
> -- Explain why Corporations do not have the right to access *their*
> documents in whatever form they may be in.

You will note that I didn't say this.  In fact I spent half of last
night detailing alternate less GAK friendly ways for PGP Inc to
provide corporate message snooping, the very functionality which is
the motivation for their CMR.  Perhas you were not reading.

What I did say, and it appears to be a meme which didn't stick with
you as I'm sure I raised this in a previous post replying to you is:

Key functionality should be separated: in the same way that you have
separate signature and encryption keys, because of the differences
between appropriate backup policies, security implications, and
life-times, you should have separate email receipt encryption keys and
storage keys.  Transient email receipt keys should not be escrowed,
but for security reasons perhaps should even be securely wiped after
use.

As an additional security bonus: storage keys can be symmetric (where
they are for your own use) which avoids the more less certain and
more quickly sliding target of public key lengths.

I will guess that the reason this meme doesn't suit you is that it's
not the way your OS/2 pgp mail client plugins work, and therefore not
yet part of your mindset.  So perhaps it's not the status quo for your
and some other apps to use separate storage keys for archiving and
receiving encrypted mail; but there are clear security advantages to
doing it this way.

> -- Failing that explain how PGP 5.5 furthers the cause of GAK and
> PGP 2.6.x does not when I can get my network to do the same thing in
> a weekend and a couple of scripts using PGP 2.6.x.

There is are some clear differences: 

1. You can visually see multiple crypto recipients in most PGP enabled
MUAs, as they usually correspond to email CC fields.

2. PGP Inc is attempting to weakly enforce this special purpose
message snooping recipient embedded into the key certificate.

3. PGP Inc even has (less clear on details here) I think from Jon
Callas first post: pgp 5.5 client which enforces inclusion on sent
mail as controlled by a remote company message snooping czar &
enforced inclusion on received mail by the SMTP policy enforcer.

4. There is a difference between what you or I may knock up in
scripts, and what PGP Inc attempts to persuade the IETF include as
conformancy requirements, and what PGP does implement ahead of the
standardisation process.

5. The IETF process should be accepting proposed designs and deciding
on the best ones, which PGP Inc, and the other suppliers would then go
and implement.  As it is now, as William Allen Simpson just pointed
out, PGP Inc is cruising ahead implementing, and deploying things
without bothering with the OpenPGP process.

Your point about using normal multiple recipient to provide snooping
is a good one.  It would be a much less GAK friendly solution for PGP
Inc to encrypt to a second recipient without any message snooping
flags encoded into the PGP standard.  That way email clients won't
reply to this second recipient, and users won't have an automated
snooping feature embeded in their PGP for personal privacy, or
competitor re-write of the same compliant OpenPGP app, for someone
else's benefit (recipient company, or government).

To snoop received email, it provides similar amounts of snooping
enforcement if the recipient's PGP 5.5 for business client when the
user decrypts re-encrypts to a storage key that the company does have
escrowed, or where there is a second crypto recipient in the storage.
(Talking mail folders here.)

> -- Failing that explain why there were no great outcries that PGP
> 2.6.x is GAKware???

See above.  The objectionable new feature in PGP5.5 (and apparently
pgp5.0 too without our realisation to this point) is enforcement in
senders clients to support message snooping, in a form which can
easily be used to interoperate with GAK, and thereby prepares
everyones OpenPGP compliant email client to enforce GAK against them.

At the very most the maximum acknowledgement that it seems reasonable
to me for OpenPGP to have of the GAK compliancy feature is to flag
this key and allow the user to send to this recipient at their option.

In addition I am arguing that PGP Inc are doing the Internet community
a major disservice by choosing to implement message snooping in this
way.  Much better, less controversial, and more secure to do the
snooping in the pgp5.5 client after decryption.  That doesn't need to
involve changes to the message spec.  PGP Inc's SMTP policy enforcer
could then be changed in functionality to stripping off the company
snooping crypto recipient field before it leaves the LAN for security
reasons.

> Now if you agree that Corporations *do* have a right to access their
> documents but you disagree with the technical aspects of how PGP 5.5
> achieves this then drop the fearmongering and spell out how you
> think this can be better achieved.

I already did this half a dozen times.  I'm not fear mongering, I'm
attempting to point out the dangers of including GAK compliancy.  And
to point out the opportunity to make PGP non-GAK compliant, and
thereby frustrate mandatory GAK proponents.  PGP is trying to discard
this opportunity, when there are clear alternate methods which can be
argued are more secure, better meet PGP's Jon Callas's stated user
requirements, don't support GAK, and don't require modifications to
the standard.

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: Sat, 11 Oct 1997 10:47:20 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: "William H. Geiger III" <[email-masked]>
CC: William Allen Simpson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

William Geiger wrote:

> This is a stereotypical Strawman. "Even if PGP avoids GAK some other 3rd
> party can modify it to be Gakware." Every version of PGP had the ability
> to encrypt to multiple recipients. As I stated in my previous posts I can
> get PGP 2.6.x to do everything 5.5 does with a couple of scripts.

Yes, but as Adam says, the average Mr. Windows can not. In any case,
this is not a narrow technical argument. Of course any system with
multiple recipients can be turned into GAKware. The point is that we
don't want to make it ANY easier for anyone to do so.

> No this is not mandatory GAK compliance. Mandatory GAK compliance would be
> if every copy of PGP came with a government key and the program *forced*
> the user to encrypt all his messages with it.

Again, as Adam says, how long would it take for a government to
introduce legislation making this mandatory once PGP 5.5-type systems
took off? Or, more insiduously, using its purchasing power - "Federal
agencies will only buy CAK-enabled systems" - to ensure the vast
majority of systems did so.

> Ok Adam here is a challenge for you:
> 
> -- Explain why Corporations do not have the right to access *their*
> documents in whatever form they may be in.

Can I take this one up ;-) The point is, with *communication* keys,
corporations will have full access to the plaintext because it will be
decrypted by the recipient as soon as it arrives. I appreciate your
point about corporations being able to read *their* documents - although
doing so by snooping, without the sender's knowledge, is rather
unethical to say the least - but I don't think they have the right to
snoop on all *incoming* communications, whoever they may be from. This
is the really scary part of PGP 5.5...

> explain why there were no great outcries that PGP 2.6.x is
> GAKware???

...because PGP 2.6.x does not include an SMTP automatic snooping agent.

William Simpson wrote:

> Let us decide _what_ the goals are, _how_ to solve the problems, and
> _then_ decide the protocol details and formats to match the solution.

Absolutely. Can we start with Adam and William's proposal that we should
have three separate types of key: communication, signature, and storage.
This would be very simple to implement; probably the easiest and most
backward-compatible way would be to define a new packet type specifying
a key's usage. 

> Why have a communication enforcement filter, when the only usage is
> supposed to be for recovering archival storage?

Absolutely. I can see the point, and appreciate the difficulties faced
by PGP Inc., in most of the CAK features of PGP 5.5. But I just can
*not* see how the twisted idea of the SMTP snooper ever came about.

Ian.

Date: Sat, 11 Oct 1997 05:37:45 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: r.e. OpenPGP document status
Cc: [email-masked]
Sender: [email-masked]

The message formats draft(s) are being worked on now.  We've only had
official WG status for something like two weeks.  A little patience is in
order, I think.

>Date: Sat, 11 Oct 97 03:12:54 GMT
>From: "William Allen Simpson" <[email-masked]>
>To: [email-masked]
>CC: [email-masked]
>Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
>Sender: [email-masked]
>
>I'm getting a bit tired of the rants on this topic to the Open-PGP
>list.  Yes, there are problems, but the whole purpose of IETF review
>is to find solutions to problems.
>
>The PGP staff have some ideas on how business message recovery can be
>done.  It seems there is a business need.  It seems that they have
>thought about it, and made some effort toward implementation.
>
>What annoys me is that the PGP formats are now supposed to be "open",
>yet no proposed formats for this new "feature" have been documented for
>our review, and other folks' suggestions for a better K-of-N mechanism
>have been ignored.
>
>We don't even have the current formats.  When will the PGP 5.0
>internet-draft be ready for review?
>
>There is already a PGP 5.0 separation between signing and
>communication keys; why not have separate message storage keys?
>
>Why not have a K-of-N system for BMR?
>
>Why have a communication enforcement filter, when the only usage is
>supposed to be for recovering archival storage?
>
>Let us decide _what_ the goals are, _how_ to solve the problems, and
>_then_ decide the protocol details and formats to match the solution.
>
>[email-masked]
>    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
>
>

From: "William H. Geiger III" <[email-masked]>
Date: Sat, 11 Oct 97 01:04:35 -0500
To: "William Allen Simpson" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

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

In <[email-masked]>, on 10/10/97 
   at 10, "William Allen Simpson" <[email-masked]> said:

>I'm getting a bit tired of the rants on this topic to the Open-PGP list. 
>Yes, there are problems, but the whole purpose of IETF review is to find
>solutions to problems.

I agree, I think the political debates can be better handled on the CP
list rather than here. In that light I have created a PGP 5.5 digest that
covers the various threads on this topic from the CP list, the open PGP
list and the PGP Users lists (for the neswgroups you are on your own). I
will also provide a daily digest as long as these threads continue
(cut-off time 5pm central time zone). Anyone wishing to receive a copy let
me know (digest, daily, or both).

>The PGP staff have some ideas on how business message recovery can be
>done.  It seems there is a business need.  It seems that they have
>thought about it, and made some effort toward implementation.

>What annoys me is that the PGP formats are now supposed to be "open", yet
>no proposed formats for this new "feature" have been documented for our
>review, and other folks' suggestions for a better K-of-N mechanism have
>been ignored.

>We don't even have the current formats.  When will the PGP 5.0
>internet-draft be ready for review?

>There is already a PGP 5.0 separation between signing and
>communication keys; why not have separate message storage keys?

>Why not have a K-of-N system for BMR?

>Why have a communication enforcement filter, when the only usage is
>supposed to be for recovering archival storage?

>Let us decide _what_ the goals are, _how_ to solve the problems, and
>_then_ decide the protocol details and formats to match the solution.

An excellent suggestion. Perhaps you could detail your ideals on these
areas so we can work on them.

- -- 
- ---------------------------------------------------------------
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: Sat, 11 Oct 97 00:24:05 -0500
To: Adam Back <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

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

In <[email-masked]>, on 10/11/97 
   at 02, Adam Back <[email-masked]> said:

>Jon Callas <[email-masked]> writes:
>> I am adamantly opposed to any of PGP's business features being MUST
>> features of OpenPGP. If they were, then our freeware and personal
>> privacy products wouldn't be conforming applications, and we have
>> *no* intention of putting them in those products. Wouldn't that be
>> an interesting situation?

>I may be misunderstanding something here, but could you tell me how PGP
>freeware and PGP personal privacy can simultaneously not have recognition
>of GAK compliant keys, and emit messages telling the users that this is a
>GAK key (on receipt of the flag you described), and emit messages warning
>the user that the email will not be delivered (on receipt of that other
>flag you described).

I didn't see where Jon said that the other versions versions of PGP would
not recognize these keys. What Jon did say is that they would not generate
these keys nor force compliance with encryption to a second key. I myself
would want to know that a message encrypted with key A is also being
encrypted with key B though haveing this info in the public key itself is
not necessary.

>If it's defined as being compliant to ignore both of these flags, and the
>message snooping key then users email will bounce without warning.

I don't see this as a problem. My Twit/SPAM filter bounces messages
without warning. As a matter of fact most bounced messages are done so
without warning. :) 

>If it's defined to silently send to second crypto recipient, you have
>fully interoperable GAK compliance built in to the core of PGP.  If PGP
>Inc will remove the GAK compliance when GAK becomes mandatory, I'm sure
>there are other companies who won't have a problem selling out to GAK (eg
>IBM, or TIS).

This is a stereotypical Strawman. "Even if PGP avoids GAK some other 3rd
party can modify it to be Gakware." Every version of PGP had the ability
to encrypt to multiple recipients. As I stated in my previous posts I can
get PGP 2.6.x to do everything 5.5 does with a couple of scripts. Are you
no willing to take the position that ALL versions of PGP are GAK
compliant???

>If it's defined to warn but give the option to send to second crypto
>recipient, well you've still got mandatory GAK compliance, but you've got
>a pretty little warning that you've got mandatory GAK to rub your nose in
>the fact for each message you send too.

No this is not mandatory GAK compliance. Mandatory GAK compliance would be
if every copy of PGP came with a government key and the program *forced*
the user to encrypt all his messages with it. This is really turning into
a shameless FUD campagne on your part Adam worthy of David "FUD"
Sternlight himself.

>> I am strongly opposed the business features being SHOULD features. If I
>> were the only one arguing against them being SHOULD features, I'd make my
>> opposition clear and then shut up.
>> 
>> I am in favor of them being MAY features, along with a big section on
>> polite use. 

>I'd be interested to see some discussion of how this will work out,
>following up to the specific examples I give above.

>No switching to genaralities this time; please answer: how is it going to
>work?  I fear you can't have your CMR setup in pgp5.5 and not be GAK
>compliant.  If you can think of a way that you can modify it to break
>this dependency, I'd be interested to hear it.  If you can't demonstrate
>such a change I would argue strongly for it not even being a MAY.  I'd
>argue for GAK compliancy not to go into the IETF OpenPGP standard.

As far as I am concerned you have not proven your case that PGP 5.5 is GAK
compliant. Your general argument that PGP 5.5 has the potential to be GAK
can cover *ALL* version of PGP. Any system that allows encrypting to
multiple recipients can easily modified into a GAK system. 

>I gave lots of examples of other ways to achieve the claimed
>functionality of recovering stored data.  Achieving hard to circumvent
>corporate email snooping functionality is harder to achieve without CMR. 
>You can do some, but not quite as much.  But corporate snooping wasn't on
>your stated list of user requirements.  And it's not very savory anyway.

I think this is your real issue here. You don't like the ideal of a
company haveing access to their documents. If that's how you feel then
make your case so it can be judged on it's merits.

- -- 
- ---------------------------------------------------------------
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: Fri, 10 Oct 97 23:36:28 -0500
To: Adam Back <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Why Adam Back keeps politicizing technical issues (Re: Why Jon Callas keeps picking nits)
Sender: [email-masked]

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

In <[email-masked]>, on 10/10/97 
   at 08, Adam Back <[email-masked]> said:

Ok Adam here is a challenge for you:

- -- Explain why Corporations do not have the right to access *their*
documents in whatever form they may be in.

- -- Failing that explain how PGP 5.5 furthers the cause of GAK and PGP
2.6.x does not when I can get my network to do the same thing in a weekend
and a couple of scripts using PGP 2.6.x.

- -- Failing that explain why there were no great outcries that PGP 2.6.x is
GAKware???

Now if you agree that Corporations *do* have a right to access their
documents but you disagree with the technical aspects of how PGP 5.5
achieves this then drop the fearmongering and spell out how you think this
can be better achieved.

- -- 
- ---------------------------------------------------------------
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, 11 Oct 97 03:12:54 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

I'm getting a bit tired of the rants on this topic to the Open-PGP
list.  Yes, there are problems, but the whole purpose of IETF review
is to find solutions to problems.

The PGP staff have some ideas on how business message recovery can be
done.  It seems there is a business need.  It seems that they have
thought about it, and made some effort toward implementation.

What annoys me is that the PGP formats are now supposed to be "open",
yet no proposed formats for this new "feature" have been documented for
our review, and other folks' suggestions for a better K-of-N mechanism
have been ignored.

We don't even have the current formats.  When will the PGP 5.0
internet-draft be ready for review?

There is already a PGP 5.0 separation between signing and
communication keys; why not have separate message storage keys?

Why not have a K-of-N system for BMR?

Why have a communication enforcement filter, when the only usage is
supposed to be for recovering archival storage?

Let us decide _what_ the goals are, _how_ to solve the problems, and
_then_ decide the protocol details and formats to match the solution.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Date: Sat, 11 Oct 1997 02:12:28 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Why Jon Callas keeps picking nits (Re: Why Corporate Message Recovery isn't Key Escrow)
Sender: [email-masked]

Jon Callas <[email-masked]> writes:
> A number of people have asserted that the Corporate Message Recovery
> feature is key escrow. From where I sit, the difference is easy to
> see. My definition of "key escrow" is that another person or
> organization keeps a copy of the user's secret key.

You are adopting a narrow technical meaning of key escrow.  Key escrow
also has another meaning in common parlance: third party access to
communications.  Now I know this common parlance isn't technically
accurate, but "key escrow" itself is a piece of newspeak, a clever
term coined by secret service / government spin doctors.  It has
entered the language like it or not (I don't like it).  This common
parlance meaning is probably more widely understood and used than the
technical meaning you are using.

With that in mind, you may start to see why people, such as Schneier,
and others over the last few days have been telling you "you're
picking nits".

Point is pgp 5.5 allows other people to have access to your
communications.  Your SMTP policy enforcer even attempts to enforce
this.  You also described a feature whereby an administrator could
remotely configure and restrict functionality in pgp 5.5 mail client
(I am unclear as to whether this allows the admin to enforce snoop
access or not).

Your own term CMR (Corporate Message Recovery) isn't that accurate a
description itself, it's a bit of a euphamism at best.  What you're
recovering is transient communications which don't need recovering
anyway.  What PGP is really up to is enforcing capability for
Corporate Message Snooping.

[line breaks were _all over_ the shop, I've reformatted]

> Here's an example, based on actual customers who use key escrow to
> manage their data:
> 
> This corporation uses PGP for a number of things. Email, engineering
> plans, CAD drawings, and so on. They've done so at least since the
> days when we were Viacrypt, and I believe they even used PGP 2.x.

First point, which I'm getting bored of repeating: keys have different
uses.  Storage keys, transient communications keys, signature keys.
You're using one key for all 2 functions; that is the root of your
problems and dilemmas.  You're using what should be a storage key to
receive transient communications, then you're proceeding to wonder why
this causes you to have the undesirable situation of having a GAK
compliant system (or more properly trying and failing to argue that
you don't have one).

> When an employee arrives at this company, they create a key pair for
> the new employee, hand it to them on a floppy, keeping a duplicate
> floppy with the keypair on it, which they toss into a
> safe. Literally. This is key escrow.  They do this because they
> can't afford to lose their files and messages. Their policies
> require them to keep the secret keys, as if they were the same as
> keys to offices or file cabinets.

You know, what they're doing: it's not so bad for data encrypted on
their disks.  They can acheive the departmental level escrow to
distribute risk just the same with this form of escrow.

You don't need to escrow transient communications keys at all anyway.

Your pgp 5.5 isn't going to help recover the actual data of value, all
those stored CAD files...  You know why?  Because they're on the disk,
not in transit in the email system.  So you haven't solved the claimed
problem.

If you want to do something about the claimed problem work out some
secret splitting solutions to better distribute trust for escrowed
storage keys.  (Now this is a real use for escrow: the company is safe
guarding it's own encrypted data on disks and tapes for it's own
benefit).

> - From our standpoint, the issue gets even touchier. They don't like
> what they're doing, and they want us to give them a better way to
> manage their data. Does anyone really believe that only moral
> response is to flinch and turn away?

Nope, your responsibility should be to solve their problems.  (Which
as I show above you have not done.)  Actually your responsibility to
live up to the reputation PRZ transfered to PGP Inc dictates that you
should also do what you can do not build systems which help GAKkers.

Instead your responsibility appears increasingly to produce systems
which smooth the way for coming mandatory GAK by implementing systems
which are GAK ready.

Or if you deny that one, at least you are weakening your
communications security for practically no gain.

> I'd like to be in a situation where I didn't have to deal with
> this. Wanna trade positions? 

Yeah, OK, you don't seem to be managing very well :-)

(Sorry, you asked for it.  I don't actually mean to be rude, I would
just like to get the points across, and to influence PGP to recover
gracefully from this tactical and reputational mistake.)

> It isn't so with a CMRK. The worst possible way to use the feature
> is to have a single, company-wide CMRK. If that gets lost, the
> thriller you can write isn't nearly as interesting. Yup, you can
> steal any of the plans, read all the mail, and so on. That's
> bad. It's deplorable, actually. But it isn't a difference that makes
> no difference. At least there isn't a gang of keys out there that
> can sign anything with anyone's ID.

This is why I was asking above about separate signing keys.  They
surely don't need to stick the signature keys in the safe!!!  In fact
it is counter-productive even for hard-nosed corporate lawyers, and
$$$ driven scruple-short company execs: if they can't prove an
employee penned something they can't use this to prove a case against
him.  If they've got a copy of the signature key, they can forge
signatures which makes signatures useless in litigation involving
company and employee.

> This is not the only way to use Corporate Message Recovery, it's
> just the worst way. Remember, it's just a notation in the
> self-signature that states, "When you encrypt to me, encrypt to X."
> That's any X. You can have a different CMRK for every department,
> every workgroup, or even every user.

It's all screwey because you've got key functionality which belongs in
different keys mixed up.

You should have 3 types of key:

1. signature keys
2. transient encryption keys
3. storage keys

The signature keys you never escrow.  You certify.  If something goes
wrong you re-issue, release revocation cert, and re-certificate.

The transient encryption keys are for communications, you delete them
immediately after use.  Yes I'm talking forward secrecy here.  If you
don't like forward secrecy, well at least don't escrow the encryption
keys.

Storage keys you make damn sure you can recover.  You escrow these for
real.  Company safe sounds about right.  Secret splitting could be
nice also.

> The significant improvement that PGP's web of trust has over a
> traditional hierarchical system is that you can set up a top-down
> system for validity, but you don't have to (and in our opinion,
> shouldn't). Analogously, the significant improvement that Corporate
> Message Recovery has over key escrow is that you can tailor a
> recovery system to your needs (including and especially deciding
> it's not for you).

There is no advantage; the systems are approximately equivalent in
flexibility of architecture.  You can acheive the exact same
architecture with key escrow; just escrow the keys with your backup
czar.

You shouldn't be recovering transient messages, you should be
recovering stored data.

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: Sat, 11 Oct 1997 02:41:51 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Why corporate message recovery IS gak compliant (Re: Why Corporate Message Recovery isn't GAK)
Sender: [email-masked]

Jon Callas <[email-masked]> writes:
> There are two things I will discuss in this missive:
> 
> (1) The assertion that Corporate Message Recovery is "just like Clipper"
> and why this is not true.

I won't even bother dealing indivdually with your arguments to this
one because you have just demonstrated again your ability to
simultaneously focus on hair splitting trivia, and ignore the whole
crux of the argument.

Suffice to say that it is not the details of the GAK (government
access to keys) system that the US government has tried to coerce
people to use that makes people not like it.  It's what it means: it
means that government will have access to keys.

We have had what some people term Clipper I through Clipper IV (or is
that V)?  The details and the names change each time.  And were you to
be their spokesperson you would be explaining in intricate detail how
"key recovery" is not "key escrow" and how therefor it is ok, and we
should all accept it.

The argument against pgp 5.5 is that it does 3 things wrong:

1. it is GAK compliant; it provides a ready to roll GAK system for the
US administration to try to leverage into place and switch on

2. it attempts to provide escrow features for transient communications

3. it doesn't differentiate between storage keys (which should be
escrowed to protect encrypted information stored on hard disks and
backup tapes) and transient communications keys which should if
anything be securely wiped after use

> Now then, the next topic is the fear that CMR will be used in some
> insidious government plot to slip in GAK everywhere.
>
> I worry about this, too. 

I'm glad that you acknowledge the very real problem.

> But I don't think it's feasible that CMR can be a stalking horse for
> GAK.

I notice that none of your reasons are technical.  I take this to be a
tacit acknowledgment that you have indeed built a GAK compliant system
with pgp5.5.

Let's have a look at these balances to see how comforting they are
given the lack of technical protection (being a cypherpunks I like
technical protections, they are so much more useful and concrete than
words of assurance):

> If the government wants to GAK-enable all PGP, they'll have to have
> a plan similar to this:
> 
> (1) Buy PGP, Inc. Since our worth is less than the black portion of the
> Federal Budget, this is not impossible. Would that it were otherwise. Heck,
> we're probably worth less than the black portion of New Zealand's budget.

Why would they have to buy the company?  They would just introduce
legislation to enforce _use_ of a feature you have already
thoughtfully included.  (A couple of people speculated that this early
GAK compliance may be the result of PGP Inc corporate investor
pressure (the share holder is god), or perhaps high level management
decision that this allows an easy route for PGP whatever the outcome
of the GAK wars: mandatory GAK PGP wins with it's early compliance, if
mandatory GAK loses, well PGP continues to cash in PRZ's reputation,
and PGP Inc's business client base).

My question to you is what is PGP Inc going to do when becomes illegal
to sell software which doesn't include mandatory GAK?  What're you all
going to do?  Break the law?  It'll be too late by then, unless you
have a corporate contingency plan of moving to Switzerland.  Do you?

> (2) Fire all the current development staff. This isn't very hard. All the
> new bosses have to do is round us up in a meeting and announce, "The next
> version of PGP will have a 40-bit export option." We'll say, "Not while
> *we're* working for the company!" They'll say, "Fine with us." Keep your
> eye on the secure resume server for clues of this event.

The company would survive with staff replacement.  Especially with
mandatory GAK as the regime.

> (3) Hire a new staff. This is one of the places that the plan might fall
> apart. We have such a hard time finding anyone who's qualified to work for
> us that we have reqs we can't seem to fill. I suppose, though, that they'll
> be able to find some people willing to relocate from Maryland.

No problem.  They'll just pay higher wages with the huge government
sell-out dividend reaped by being a early GAK adopter (via GAK
compliance).

> (4) Stop the OpenPGP process in the IETF. [...] If OpenPGP succeeds,
> then anyone can build an interoperable version of PGP, not just us,
> Highware, Systemics, etc.

Stopping the OpenPGP process doesn't sound necessary, if I read your
other post correctly PGP Inc would like to persuade the IETF to put
GAK compliance features in the OpenPGP standard as a MAY right now.
If you have your way, it'll be ratified by the time GAK comes.

You might like to consider this thought also:

Even if you personally believe that PGP Inc will stall at mandatory
GAK, and cease trading rather than do it, or even if you personally
will resign (I can't see that anyone's resignation helps us after the
fact):

	other OpenPGP implementors may not.  TIS or IBM or one of the
	other bona-fide GAKware government sell out types will take
	the opportunity to create an interoperable mandatory
	government access to key system.

This is a BAD thing.  You could prevent that.  But you're not, you're
helping it head to fruition.  You will have to live with your
conscience if GAK happens through this route.

> (5) Wait until bitrot makes all those existing copies of PGP stop
> working.  I could make a few catty remarks about how quickly
> existing software stops working on new releases of OSes, but you've
> probably thought of them yourself.

Mr linux hacker will figure it out.  Mr windows user won't.  There are
more Mr windows users.

> There are also a few details left, like shutting down all those
> international FTP sites, but hey, they're the government, they're
> omnipotent.

This game isn't about Mr crypto-anarchist, linux hacker, it's about
mass market software, about what individuals and companies are using.

The spooks know they can't stop "live free or die" types using
steganography even after mandatory GAK.

Won't make it any less painful for those who don't have the nerve or
technical expertise.

I would say that I am not trying to be vindictive, or anything here,
but you are _so_ easy to criticize, and I am trying to do what I can
to encourage PGP to salvage the situation.

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: Sat, 11 Oct 1997 02:54:17 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

Jon Callas <[email-masked]> writes:
> I am adamantly opposed to any of PGP's business features being MUST
> features of OpenPGP. If they were, then our freeware and personal
> privacy products wouldn't be conforming applications, and we have
> *no* intention of putting them in those products. Wouldn't that be
> an interesting situation?

I may be misunderstanding something here, but could you tell me how
PGP freeware and PGP personal privacy can simultaneously not have
recognition of GAK compliant keys, and emit messages telling the users
that this is a GAK key (on receipt of the flag you described), and
emit messages warning the user that the email will not be delivered
(on receipt of that other flag you described).

If it's defined as being compliant to ignore both of these flags, and
the message snooping key then users email will bounce without warning.

If it's defined to silently send to second crypto recipient, you have
fully interoperable GAK compliance built in to the core of PGP.  If
PGP Inc will remove the GAK compliance when GAK becomes mandatory, I'm
sure there are other companies who won't have a problem selling out to
GAK (eg IBM, or TIS).

If it's defined to warn but give the option to send to second crypto
recipient, well you've still got mandatory GAK compliance, but you've
got a pretty little warning that you've got mandatory GAK to rub your
nose in the fact for each message you send too.

> I am strongly opposed the business features being SHOULD features. If I
> were the only one arguing against them being SHOULD features, I'd make my
> opposition clear and then shut up.
> 
> I am in favor of them being MAY features, along with a big section on
> polite use. 

I'd be interested to see some discussion of how this will work out,
following up to the specific examples I give above.

No switching to genaralities this time; please answer: how is it going
to work?  I fear you can't have your CMR setup in pgp5.5 and not be
GAK compliant.  If you can think of a way that you can modify it to
break this dependency, I'd be interested to hear it.  If you can't
demonstrate such a change I would argue strongly for it not even being
a MAY.  I'd argue for GAK compliancy not to go into the IETF OpenPGP
standard.

I gave lots of examples of other ways to achieve the claimed
functionality of recovering stored data.  Achieving hard to circumvent
corporate email snooping functionality is harder to achieve without
CMR.  You can do some, but not quite as much.  But corporate snooping
wasn't on your stated list of user requirements.  And it's not very
savory anyway.

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: Andrew Bromage <[email-masked]>
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
To: [email-masked]
Date: Sat, 11 Oct 1997 11:27:32 +1000 (EST)
Sender: [email-masked]

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

G'day.

Jon Callas wrote:

> I am adamantly opposed to any of PGP's business features being MUST
> features of OpenPGP. If they were, then our freeware and personal privacy
> products wouldn't be conforming applications, and we have *no* intention of
> putting them in those products. Wouldn't that be an interesting situation?

Now that I think of it, message recovery in a personal encryption system
can actually work for you.  The problem is that at the moment, your
encryption key is the same as your signing key.  If you were to create
a recovery key and store it with your private key, the recovery key
could not be used to sign any messages.

Now.  Suppose you are raided by the federal authorities in your area.
(I'm assuming that you live in a federation here.  Insert appropriate
agencies depending on your country.)  They nab your hard disk and then
demand "hand over your private key so we can read these files and see if
you're engaged in the international terrorism that the Scientologists
told us you are."  You do so, then then the agency uses this to sign some
files which say "I never eat at McDonald's.  I hate democracy.  McCarthy
was a fool.  I have seen Dr Zhivago many times."

INAL, I don't know if authorities can force you to hand over your key
like this, as opposed to, say, requiring you to decrypt everything that
they ask, or recovering and handing over the session key for any file
that they ask (my preferred solution, because the authority can check
that the session key is the right one very easily).

If they _can_ force you to hand over your key, then a private recovery
key would be good because you can just hand over that.

Disclaimer: Of course, I personally never intend to get myself in a
situation where this is even a semi-likely scenario. :-)

Cheers,
Andrew Bromage
- -- 
Andrew Bromage  <[email-masked]>            In Christo sumus unum
PGP RSA fingerprint:  56 FB B6 29 62 45 76 88  C6 D2 02 3C CE 43 E0 18
Note: My PGP key is stored on a system connected to the Internet,
      therefore it is not perfectly secure.

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 10 Oct 97 19:39:57 -0500
To: Ian Brown <[email-masked]>
Cc: Lutz Donnerhacke <[email-masked]>, [email-masked]
Subject: Re: Key Escrow Issues
Sender: [email-masked]

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

In <[email-masked]>, on 10/10/97 
   at 03, Ian Brown <[email-masked]> said:

>> PGP 5.5 does not distingush between communication keys and storage keys.
>> Communication keys MUST NOT GAK.

>Absolutely. I thought this was one thing we *had* managed to establish.
>Was PGP Inc. getting overwhelming feedback from customers that this
>wasn't the case?

I have to disagree on different levels here.

1) E-mail is not just communication but is document storage too. Wether
this is a good thing or a bad thing is not an issue but the fact that it
is being used in this manner is.

2) Corporate Access to Plain Text. This seems to be the issue that rubs
people the most. They don't like the ideal of a company reading it's
employees mail. Well documents generated in a e-mail system are company
documents. Plain and simple, I have yet to see a convincing argument that
a company does not have a right to access it's own document.

3) PGP 5.5's Corporate Access to Plain Text is not GAK, and it is not Key
Escrow. No one is getting access to a users private keys. GAK is
"Government Access to Keys", Key Escrow is the escrowing of keys. Neither
of these things are happening here. What is happening here is Corporate
Access to Plain Text. If you don't like CAPT then one needs to provide a
reasonable argument why a company does not have the right to it's own
documents. If you don't like technical details of how PGP 5.5 provides
CAPT then you should drop the politicization of what should be a technical
discussion.

- -- 
- ---------------------------------------------------------------
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: Fri, 10 Oct 1997 16:54:38 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

Adam Back writes:

> Are PGP Inc's CAK features intended to be part of the now IETF
> controlled Open-PGP standard?

Let me explain briefly what the new features are, then say something about
the directions in which we may want to go.

In older versions of PGP, key signatures were used for just a few things.
They could bind a userid to a key, or they could revoke such a binding.
They were also used for a user to revoke his own key by issuing a revocation
self-signature.

PGP now offers an extensible signature format.  This allows key
signatures, both self-signatures by a key on itself, and ordinary key
signatures by keys on other keys, to do more than before.  The extensions
are in the form of subpackets within the signature packet.  Various
subpackets have been defined, and Open-PGP would be an excellent forum
to propose and design new subpacket types and corresponding data formats.

Some of the subpackets are modifiers of ordinary userid-binding signatures.
These allow signatures to have expiration dates; to be marked as non-
exportable (so that the signatures are only for your own use on the
keyring); to be "meta-signatures", which delegate to other keys the power
to choose trusted introducers; and to specify a regular expression which
restricts the power of signing keys.

Other subpacket types are intended to be used with self-signatures,
allowing a key to make assertions about itself.  We have moved the
key's expiration date into this location, for example.  There is also
the preferred-algorithms subpacket, which allows a key to specify
which conventional encryption algorithms it can accept and which it
would prefer.  And here there is the new corporate message recovery key
(CMRK) subpacket.

The CMRK subpacket allows a key to request that when a message is
encrypted to it, the message should also be encrypted to a specified
additional key.  The subpacket includes a flag byte which is designed to
allow the key to give information about the circumstances under which this
should be done. Only two values are presently defined, one specifying
an optional request, and the other meaning that the message will not be
read by the recipient if the additional encryption hasn't been done.

I won't address the controversy about this feature, as that is being
thoroughly discussed in other forums.  Let me make two points, though:

We would like to move towards a mechanism to allow more power for keys
to make assertions.  Matt Blaze's (still vaporware?) PolicyMaker project
showed how powerful such a general mechanism could be.  SPKI is also
working along these lines, defining a certificate format which allows
keys to make very general classes of assertions.

The CMRK is one such type of assertion: "please cc to key X anything
encrypted for me".  The key is requesting that the specified other key
by an additional recipient on encryption.

If we move to a sufficiently powerful language to allow keys to make
useful assertions, it seems to me that we will probably inherently
allow keys to make assertions of a type which some people may regard as
politically unacceptable, like this one.  But to artificially constrain
the language so that it can only say things which are politically correct
will make a an already-difficult design task into an intractable one,
I'm afraid.

Ultimately, a fully general and flexible system of key assertions will
allow keys to say stupid things as well as smart ones.  I believe that
the power gained from having such a language gives advantages which
outweigh the problems of misuse.  (Note the similarities to the debate
over the PICS labelling technology, which some people oppose because it
could be misused.)

Secondly, with this type of assertion, as with others such as
the preferred algorithm packet, it is inherently in the sender's
(encryptor's) power to ignore it if he chooses.  You can request that I
not use triple-DES, but I could still send you a message encrypted with
that algorithm.  You would then have the choice to reject it or accept it.
This is a point which I owe to Phil Zimmermann.

There could eventually be other kinds of requests made by keys in their
self-signatures beyond preferred algorithms and additional recipients.
Keys could request that you don't use certain signing or hash algorithms,
for example.  We could even have packets allowing keys to state that
they won't decrypt messages unless you include $1 in ecash in the header,
and similar unusual requests.

Because of the sender's power of choice, which is inherent in the
nature of communication, in my opinion the requests of a receiving
key should at best be considered advisory.  In fact, in PGP 5.5 we
will now sometimes override the preferred algorithm subpacket and use
an algorithm which the recipient has stated that he will not accept.
(This is done when there are multiple recipients, and no algorithm is
acceptable to all parties.)  Likewise in PGP 5.0 the user can override
the CMRK request even in its strongest form (although not in 5.5, because
that is intended for business-to-business communications).

Therefore, I very much agree with Jon Callas that an implementation which
(perhaps optionally) allows overriding the requests which a key makes
in its self-signatures should still be considered compliant.  That is
consistent with the nature of the sender's power to create the message.

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

Date: Fri, 10 Oct 1997 15:12:06 -0700
To: [email-masked], [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Why Corporate Message Recovery isn't GAK
Sender: [email-masked]

There are two things I will discuss in this missive:

(1) The assertion that Corporate Message Recovery is "just like Clipper"
and why this is not true.
(2) The fear a number of people have expressed that Corporate Message
Recovery (CMR) could be used by the US government to slide in GAK. 

I think we're agreed that CMR isn't itself GAK and I'll talk some about why
it isn't with (1).

CMR isn't like Clipper:

* Clipper was a 64-bit key. CMR symmetric keys are full-strength keys (128
bits or more), backed with a full-strength public key.

* Clipper's key was set in hardware by the manufacturer, and users were
required to use it. A CMR key is a software-enabled key, no user is ever
required to use it. There are cases in which a user might "volunteer" to
use a CMR because they work for someone who requires it, but that's a
problem we'll address with the PGP Secure Resume Server which allows
headhunters to securely and anonymously find people who've made bad career
decisions.

As a corollary of of the previous paragraph, there's no reasonable
guarantee with a Clipper device that you haven't been black-bagged with an
insecure key. Using a CMR may be unwise, but at least you knowingly did it
to yourself.

* A CMR key can be revoked, reissued, or changed. You can periodically
change it as a matter of policy. You can even stop using it. Clipper's was,
again, set in hardware, with no option of not using it. 

* The Clipper symmetric algorithm was secret; CMR keys use publicly
available algorithms.

* With Clipper, there was always a concern that an outside agency had the
keys. This is true with a number of other systems (the so-called key
recovery systems), and is the reason that a number of them are lumped
together with the term GAK. Note that the user-organization creates a CMR
key, and the end-user enables it. If any government gets access to this
key, it is because either (1) they solved the Discrete Logarithm Problem,
(2) they broke the public CMR key, (3) they black-bagged your CMR key, or
(4) they are using a subpoena, warrant, or discovery to get the key. We're
working on a way around (1), we can't do anything about (2) or (3), but
these are fine reasons not to use CMR! If you're beset by (4), you need
lawyers, not cryptographers.

* With Clipper, there was a central repository of all the keys. With CMR,
there is not. I discussed that in detail in my message, "Why Corporate
Message Recovery isn't Key Escrow."

I have noticed that a number of people have the tacit assumption that
business people and corporations are in cahoots with the FBI, waiting to
hand over everyone's secret key. As in all parts of life, there are many,
many businesspeople and corporate execs who are not particularly moral. But
I don't think that their immorality takes this form. If we could examine
the dark, secret thoughts of a corporate scumwaffle -- the ones that he
*really* hopes don't hit the papers -- I sincerely doubt that, "Oh, Louis,
I love it when you rummage my drawers" is among them.

Now then, the next topic is the fear that CMR will be used in some
insidious government plot to slip in GAK everywhere.

I worry about this, too. But I don't think it's feasible that CMR can be a
stalking horse for GAK. If the government wants to GAK-enable all PGP,
they'll have to have a plan similar to this:

(1) Buy PGP, Inc. Since our worth is less than the black portion of the
Federal Budget, this is not impossible. Would that it were otherwise. Heck,
we're probably worth less than the black portion of New Zealand's budget.

(2) Fire all the current development staff. This isn't very hard. All the
new bosses have to do is round us up in a meeting and announce, "The next
version of PGP will have a 40-bit export option." We'll say, "Not while
*we're* working for the company!" They'll say, "Fine with us." Keep your
eye on the secure resume server for clues of this event.

(3) Hire a new staff. This is one of the places that the plan might fall
apart. We have such a hard time finding anyone who's qualified to work for
us that we have reqs we can't seem to fill. I suppose, though, that they'll
be able to find some people willing to relocate from Maryland.

(4) Stop the OpenPGP process in the IETF. Some people think that we did
this as part of our Evil Plan to Take Over the World by Giving Away
Software (hey, it almost worked for Netscape). Other people think it's part
of our Evil Plan to Take Over Crypto by Using Unpatented Algorithms. I can
neither confirm nor deny these, but I *will* tell you that it's part of our
Sniveling Plan To Convince the Feds They Can't Kill PGP by Killing Us,
which the source code books also fall into. If OpenPGP succeeds, then
anyone can build an interoperable version of PGP, not just us, Highware,
Systemics, etc.

(5) Wait until bitrot makes all those existing copies of PGP stop working.
I could make a few catty remarks about how quickly existing software stops
working on new releases of OSes, but you've probably thought of them yourself.

There are also a few details left, like shutting down all those
international FTP sites, but hey, they're the government, they're omnipotent.

	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)

-----
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, 10 Oct 1997 14:53:53 -0700
To: [email-masked], [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Why Corporate Message Recovery isn't Key Escrow
Sender: [email-masked]

A number of people have asserted that the Corporate Message Recovery
feature is
key escrow. From where I sit, the difference is easy to see. My definition of
"key escrow" is that another person or organization keeps a copy of the user's
secret key.

Here's an example, based on actual customers who use key escrow to manage
their
data:

This corporation uses PGP for a number of things. Email, engineering plans,
CAD
drawings, and so on. They've done so at least since the days when we were
Viacrypt, and I believe they even used PGP 2.x.

When an employee arrives at this company, they create a key pair for the new
employee, hand it to them on a floppy, keeping a duplicate floppy with the
keypair on it, which they toss into a safe. Literally. This is key escrow.
They
do this because they can't afford to lose their files and messages. Their
policies require them to keep the secret keys, as if they were the same as
keys
to offices or file cabinets.

I don't know about you, but I'm appalled. Nonetheless, they're our
customers. In
spite of inheriting them, we have a responsibility as businesspeople to at
least
listen to their concerns. 

- From our standpoint, the issue gets even touchier. They don't like what
they're
doing, and they want us to give them a better way to manage their data. Does
anyone really believe that only moral response is to flinch and turn away?

I'd like to be in a situation where I didn't have to deal with this. Wanna
trade
positions? I'll sit over there and cluck my tongue about how adding an extra
recipient weakens security while you figure out how to help these folks out of
the mess they're in. While you're at it, I'll pen a few lines about how giving
clean needles to addicts undermines society, and handing out condoms
encourages
kids to have sex. Trust me, it's less nerve-wracking than what we have to
do to
solve this problem, which involves running through hypothetical scenario after
hypothetical scenario, balancing the user's privacy against the organizations
property rights, the privacy and property rights of one organization against
that of another, and so on.

Corporate Message Recovery isn't key escrow for a number of reasons. First, it
doesn't involve keeping a copy the end-user's secret key. I hope that's
obvious
now. Second, the system behaves very differently. 

With a key escrow system, there is a superb McGuffin (which is what Alfred
Hitchcock called the crux of a mystery, like the falcon in The Maltese
Falcon) -
 it's the safe. Break into the safe, or lend its contents out, and all Hell
breaks loose. Whoever has those keys (which easily fit on a single Zip
disk) has
the company at its mercy. They can decrypt or sign anything they care to.
There
is a great thriller to be written here.

It isn't so with a CMRK. The worst possible way to use the feature is to
have a
single, company-wide CMRK. If that gets lost, the thriller you can write isn't
nearly as interesting. Yup, you can steal any of the plans, read all the mail,
and so on. That's bad. It's deplorable, actually. But it isn't a difference
that
makes no difference. At least there isn't a gang of keys out there that can
sign
anything with anyone's ID.

This is not the only way to use Corporate Message Recovery, it's just the
worst
way. Remember, it's just a notation in the self-signature that states,
"When you
encrypt to me, encrypt to X." That's any X. You can have a different CMRK for
every department, every workgroup, or even every user.

A sophisticated policy might be that every user sets their supervisor's key to
be their CMRK. Another is that everyone in Department X sets their office
mate,
or lab partner, or other person. You can have anything that suits your group,
from Recovery Central, to Recovery Hierarchy, to Recovery Buddy System.

The significant improvement that PGP's web of trust has over a traditional
hierarchical system is that you can set up a top-down system for validity, but
you don't have to (and in our opinion, shouldn't). Analogously, the
significant
improvement that Corporate Message Recovery has over key escrow is that you
can
tailor a recovery system to your needs (including and especially deciding it's
not for you). 

	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, 10 Oct 1997 14:50:05 -0700
To: Adam Back <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
Cc: [email-masked]
Sender: [email-masked]

I am adamantly opposed to any of PGP's business features being MUST
features of OpenPGP. If they were, then our freeware and personal privacy
products wouldn't be conforming applications, and we have *no* intention of
putting them in those products. Wouldn't that be an interesting situation?

I am strongly opposed the business features being SHOULD features. If I
were the only one arguing against them being SHOULD features, I'd make my
opposition clear and then shut up.

I am in favor of them being MAY features, along with a big section on
polite 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)

Date: Fri, 10 Oct 1997 22:08:33 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: PGP CAKware & IETF controlled Open-PGP standard
Sender: [email-masked]

One aspect of PGP's controversial CAK system in pgp5.5 that I have not
seen discussed is the standardisation aspects.

How does the introduction of corporate access to keys (CAK), and
government access to keys (GAK) features fit into the IETF framework?

Are PGP Inc's CAK features intended to be part of the now IETF
controlled Open-PGP standard?

What is the IETF's stance on politics having influence on security?

A weakly comparable example might be perhaps the IPSEC standardisation
process, and the effect of export regulations on key sizes.  Are IPSEC
key sizes allowed to be restricted in the standards so that IPSEC
products can be exportable?

Now some would argue, and with some justification, that emails sent
using company equipment are the property of that company.  However
there are other considerations also.  Expectation of privacy is one.
The negative aspects of a society in which most companies have become
little brother institutions, becoming small versions of what many of
us are fighting: mandatory government access to keys, big brother
wanting the ability to read all traffic.

I would be somewhat concerned if PGP Inc's recently announced the key
escrow functionality becomes part of the Open-PGP standard, because it
will set a bad precedent, and possibly force others who would
otherwise wish to implement to the open-PGP standard to also implement
features useful to secret service special interests in enforcing
mandatory domestic government access to keys, or implement only partly
compatible systems.

I need hardly comment that such an eventuality is not in the interests
of the internet community.

Specific questions relating to the standard are perhaps:

- Are the certificate flags informing the recipient that
  communications to a key is escrowed, and that email which is not
  encrypted to the escrow key will be bounced expected to be part of the
  Open PGP standard.

- Can a conforming application ignore the key escrow flags?

- Or must a conforming application display a suitable warning perhaps
  such as:

    WARNING: the person whose key you are using has the misfortune of
    being forced to use software supplied by a company which has sold
    out to key escrow, therefore you data may be read by others than
    your intended recipient.

  and perhaps a note tacked on to the email for the recipient to read:

    SAY NO TO KEY ESCROW.  Boycot little brother and big brother.
    Don't buy PGP Inc software.

  or must conforming applications be more polite.

Aside from the snide remarks about key escrow, I am concerned about
PGP's actions harming internet privacy, and helping indirectly the
introduction of mandatory key escrow which the US administration and
UK secret service and department of trade and industry are pushing.

A system which implements all the features necessary for mandatory key
escrow as a business solution may indirectly help the mandatory key
escrow proponents.  Plausible events which might happen in such an
event might be:

- companies encouraged to use (or penalised for not using) open-PGP
  corporate escrow compatible systems

- service providers also encouraged to use such systems

- companies legally required to use such systems, and hand copies of
  corporate master keys to government (corporate escrow then becomes
  government escrow for business communications)

- ISPs and individuals legally required to use such systems, and hand
  copies of corporate master keys to government (full blown mandatory
  key escrow)

I am concerned about the possibility that the IETF might be steered by
PGP Inc into putting features into the Open-PGP standard which are not
in the interests of the internet community.

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: Ian Brown <[email-masked]>
To: Lutz Donnerhacke <[email-masked]>
Organization: University College London
Date: Fri, 10 Oct 1997 09:54:10 +0100
Subject: Re: Key Escrow Issues
X-ByProxy/Sniffer_BasicSMTP/line0: User [email-masked] added as friend
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
Content-Type: text/plain; charset=us-ascii Fri, 10 Oct 1997 00: 47:42 -0700  (PDT) id JAA31835; Fri, 10 Oct 1997 09: 50:32 +0200  <[email-masked]>
Content-Transfer-Encoding: 7bit
References: <[email-masked]>
CC: [email-masked]
Sender: [email-masked]
Precedence: bulk

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

> PGP 5.5 does not distingush between communication keys and storage keys.
> Communication keys MUST NOT GAK.

Absolutely. I thought this was one thing we *had* managed to establish.
Was PGP Inc. getting overwhelming feedback from customers that this
wasn't the case?

Ian.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Key Escrow Issues
Date: 10 Oct 1997 07:50:32 GMT
Organization: IKS GmbH Jena
Lines: 19
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Jeffrey Gold wrote:
>2. It is critical for those same businesses to be independent of
>   the loss of any one employee - if he is the ONLY ONE who knows
>   the password for a critical file.  Key Escrow is a valid
>   solution to guard against this circumstance.  PGP version 5.5
>   which has this feature is likely to be a "hot seller".

PGP 5.5 does not distingush between communication keys and storage keys.
Communication keys MUST NOT GAK.

>3. PGP 5.5 appears to allow a single individual with a "Master"
>   key access to ALL encrypted files.  IMHO, this gives that
>   employee too much power.  It also leaves the business vulnerable
>   to improper behavior by that employee.  Say, jumping ship with
>   all the secrets.

And for all messages in the past and future. This does not match the courts
wiretrap desicion.

Date: Thu, 09 Oct 1997 23:48:29 -0400 (EDT)
From: Jeffrey Gold <[email-masked]>
Subject: Key Escrow Issues
To: ietf-open-pgp <[email-masked]>
Sender: [email-masked]

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

The release of PGP v5.5 has again make Key Escrow a hot topic.
For those who do not already know Key Escrow allows anyone with 
a "Master" key to decrypt any message you may encrypt.  A few 
general comments about Key Escrow issues - IMHO

1. It is essential for many businesses to maintain trade secrets.
   Encryption is a valid way for them to do so.

2. It is critical for those same businesses to be independent of
   the loss of any one employee - if he is the ONLY ONE who knows
   the password for a critical file.  Key Escrow is a valid
   solution to guard against this circumstance.  PGP version 5.5
   which has this feature is likely to be a "hot seller".

3. PGP 5.5 appears to allow a single individual with a "Master"
   key access to ALL encrypted files.  IMHO, this gives that
   employee too much power.  It also leaves the business vulnerable
   to improper behavior by that employee.  Say, jumping ship with
   all the secrets.

4. Packages other then PGP (I forget the name) require 3-5 select
   employees COOPERATE in order to activate the Key Escrow feature.
   Sort of like the self-destruct sequence in the original Star Trek.

5. Employees should retain the RIGHT to encrypt PERSONAL information
   with a Non-Escrow system like PGP 5.0, but may expect to be
   REQUIRED to use the Key Escrow system to encrypt sensitive
   business related information.

6. There is an outstanding legal question of wether a business may
   prohibit an employee from ANY PERSONAL use of his computer at 
   work, since this computer is the property of the business. 
   This question may prove to be AS IMPORTANT as Key Escrow.

7. It is unwise to allow the government to have these powers.
   This is for the simple reason that, all statements to the
   contrary, it is IMPOSSIBLE to prevent widespread ABUSE.

8. The similarities to government opening your snail mail are very
   close. There are strong laws against this practice. Unfortunately,
   the law has not yet caught up with the technology of the Internet.

9. However, the practice of the government opening foreign mail and
   tapping overseas phone calls still exists.  So, there is a legal
   precedent, regardless of its morality, to support government Key
   Escrow when applied to foreign/overseas traffic.  The problem
   here is how to protect domestic correspondence vs. international
   correspondence.  I do not have that answer.

10. The Clinton Administration is moving VERY AGGRESSIVELY to put
    some form of Key Escrow in place.  They have not and will not
    stop - despite many setbacks.  It is unlikely that even a 
    change to a Republican administrations in 2000 would affect 
    this effort.

11. Regardless of where you stand on these issues, if you wish to
    be heard, contact your elected representatives.  Support the
    political action groups with which you agree.

The above is my personal opinion.  Feel free to disagree 
or otherwise comment either on-list or off-list.

Date: Thu, 9 Oct 1997 06:14:41 -0700
To: Ben Escoto <[email-masked]>
From: "John W. Noerenberg" <[email-masked]>
Subject: Re: Announce: Mapil v0.0 PGP mail utility
Cc: [email-masked]
Sender: [email-masked]

--PGPplugin/Eudora-5.0-4124729370-1335706877
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 1:10 PM -0700 10/4/97, Ben Escoto wrote:
>
>	I'm not sure if messages of this type are permitted on the
>list, but I think this may be of interest to list readers.  Sorry if
>this is misplaced.

Ben, as one reader of this list, I am certainly interested in
implementations of 2015.  Demonstrations of and problems with
interoperability of the protocols developed within this group are certainly
in bounds of our discussion.

To that end, Eudora 4.0a26 + PGP 5.0 was able to successfully parse your
message and verified the key's identity. So what you've done with exmh and
Mapil at least interoperates with our and PGP Inc's implementations of 2015.

That is good news, indeed.

>
>	Right now only PGP 2.x is supported, but now that PGP 5.0 for
>linux is out I will add 5.0 support soon.

I'll be eager to see that.

john  w noerenberg, ii
[email-masked]
pager: [email-masked]
 --------------------------------------------------------------------
  "A beautiful idea has a much greater chance of being a correct idea
   than an ugly one."
 -- Roger Penrose, "The Emperor's New Mind", 1989
 --------------------------------------------------------------------

--PGPplugin/Eudora-5.0-4124729370-1335706877
Content-Type: application/pgp-signature

--PGPplugin/Eudora-5.0-4124729370-1335706877--

From: Ben Escoto <[email-masked]>
To: [email-masked]
Subject: Announce: Mapil v0.0 PGP mail utility
Date: Sat, 04 Oct 1997 13:10:00 -0700
Sender: [email-masked]

--=_Mapil-0.0_3079116385

	I'm not sure if messages of this type are permitted on the
list, but I think this may be of interest to list readers.  Sorry if
this is misplaced.

	Mapil is a utility for unix that should be called from a
mailer and then calls PGP to encode or decode messages.  It supports
the PGP/MIME protocol as well as unformatted PGP messages.  It is very
configurable and has a number of useful features, like a 'policies'
file that lets you automatically process messages in different ways
depending on the recipient.

	Right now only PGP 2.x is supported, but now that PGP 5.0 for
linux is out I will add 5.0 support soon.

	For more information see the mapil home page at:
http://www-leland.stanford.edu/~bescoto/mapil

--
Ben Escoto
PGP/MIME mail welcome - finger [email-masked] for key

--=_Mapil-0.0_3079116385
Content-Type: application/pgp-signature

--=_Mapil-0.0_3079116385--

Date: Thu, 2 Oct 1997 21:39:54 -0700
To: [email-masked] (David P. Kemp), [email-masked]
From: Bill Frantz <[email-masked]>
Subject: Re: Principles and Principals
Sender: [email-masked]

At 9:41 AM -0700 10/2/97, David P. Kemp wrote:
>SPKI principals are keys.  If Alice's private key is compromised, then both
>Alice (the good guy) and Bob (the bad guy) are now keyholders corresponding
>to the single principal that you might refer to as alice, and there is no
>way to distinguish between them.   If "alice" creates an "I'm-gonna-be"
>certificate delegating to a new principal, you have no idea whether that
>certificate was actually created by the good keyholder or the bad keyholder.
>
>...
>
>In either case, key-centric models such as SPKI fail catastrophically -
>if the key is revoked/expired, the principal has expired too, since
>they are one in the same.  You can't get around this simple fact by
>delegating, because the key signing the delegation has (potentially
>or actually) been compromised.

SPKI allows long lived keys (acting as principals) to issue certificates
for short lived signing keys, transferring all their authority to those
keys for a period of time.  (SPKI does not support certificate revocation
because of the difficultly of ensuring that you have a current copy of the
revocation list.)

Note that this model is very similar to the model used by SET for its
certificate authority keys.

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

From: Andrew Bromage <[email-masked]>
Subject: Key quorum
To: [email-masked]
Date: Fri, 3 Oct 1997 07:36:03 +1000 (EST)
Sender: [email-masked]

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

G'day.

I have a suggestion for an addition to the open PGP standard.

I'd like to introduce a key quorum system.  Informally, an (n,k) key
quorum system is where a file is split into n parts, and can be
reconstructed from any k of these parts.  Having only k-1 parts will
tell you nothing about the original file.

The most obvious use for this is in authentication, but it could
potentially be quite useful for file encryption too.  (Incidentally, it
is not necessary to have a quorum-based digital signature system, since
a file can be signed by multiple signators.  The onus is on the person
checking the file to ensure that the required quorum of signators have
correctly signed the file.)

The way that it would be implemented is to take a conventional
encryption key and to split it according to some algorithm such as
Shamir's [1] or Blakely's [2] (Shamir's is better, since it's precisely
as secure as your random number generator) into n components, each of
which is then encrypted using public-key encryption, or no encryption.
A simple way to implement this would be to define the algorithm number
"0" to mean "nothing" wherever it occurs, for example in a public key
encryption field, algorithm=1 means RSA is used, algorithm=0 means the
conventional encryption key is stored unencrypted.  This is a bad
example because it's almost completely useless, but it would be useful
for, say, the compressed data packet if you didn't want a file to be
compressed because it already had been or because it was random data.
This means you wouldn't need to lose any sleep over losing the literal
data packet. :-)

The implementation that I suggest is to add a new kind of "string to
key" object.  (Disclaimer: I'm not familiar with this field since it
is not documented in the latest draft.)  It would include the following
information:

	- Key split algorithm ID
	- The number of components that the file was split into
	- The quorum size
	- The number of this component
	- Algorithm-specific info

Any thoughts?

References:

[1]  Adi Shamir, "How to Share a Secret", CACM (22) 11, pp 612--613,
	Nov 1979.

[2]  G. R. Blakley, "Safeguarding cryptographic keys", Proc. AIFPS 1979
	NCC (48), pp 313--317, June 1979.

Cheers,
Andrew Bromage
- -- 
Andrew Bromage  <[email-masked]>            In Christo sumus unum
PGP RSA fingerprint:  56 FB B6 29 62 45 76 88  C6 D2 02 3C CE 43 E0 18
Note: My PGP key is stored on a system connected connected to the
      Internet, therefore it is not perfectly secure.

Date: Thu, 2 Oct 1997 15:10:34 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Principles and Principals
Sender: [email-masked]

> From: Ian Brown <[email-masked]>
> 
> > you can have one cert 
> > that just binds permanent info like a name or perhaps a 
> > lifetime identification (i.e., SSN) number to a key.
> 
> Good points, but I think one consideration we must keep in mind is that
> we may not *want* a 'permanent' key or binding, for privacy reasons.
> Even if the binding is anonymous, long-term use allows profiles to be
> built up which may then be re-connected with a user at some later date. 
> 
> Just a thought...
> 
> Ian.

Note, I didn't write the above 2nd-level > > quote, although I agree with it.

Obviously, if you don't want a permanent identity, then don't use
one.  There is nothing preventing a particular human from obtaining and
using an arbitrarily large number of certificates (in the limit, a
new cert with a new key and/or new name for each message/transaction/
connection/etc.), regardless of the certificate format being used.

The problem only comes in when users need a permanent identity that lasts
longer then their common name, email address, or public key.  *If* such
permanent identifiers are needed, then the requirement can be satisfied
as indicated in the quote, or as I suggested, by using a large random
number as the permanent identity.  Name-centric certificates such
as PGP and X.509 are amenable to this usage; it is much more inconvenient
to accommodate names that last longer than principals (keys) when
using key-centric certificates.

Date: Thu, 2 Oct 1997 12:41:07 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Principles and Principals
Sender: [email-masked]

> From: Jon Callas <[email-masked]>
> 
> At 11:05 PM 9/24/97 -0700, Patrick Richard wrote:
> 
> >   If you develop a system that goes around this, then the key is
> >   not the principal...
>    
> I disagree. One of the things that I want to see in PGP is an
> "I-used-to-be" certificate. With proper setup of one of those, you have a
> key-as-principal system, but delegation of authority with transfer of
> authority, it all flows.
> 
> 	Jon

An interesting assertion, but it's incorrect.  Pat is correct that if you
develop a system that allows key revocation, then the system does not use
keys as principals.  Proof by inspection.

SPKI principals are keys.  If Alice's private key is compromised, then both
Alice (the good guy) and Bob (the bad guy) are now keyholders corresponding
to the single principal that you might refer to as alice, and there is no
way to distinguish between them.   If "alice" creates an "I'm-gonna-be"
certificate delegating to a new principal, you have no idea whether that
certificate was actually created by the good keyholder or the bad keyholder.

(Going in the opposite direction, creating an "I-used-to-be" cert signed
by the new principal, makes no sense.  Anyone could make up one of those.
What sort of mechanism do you mean by "transfer of authority"?  Does it
involve a trusted third party - i.e. an identity CA?)

> From: "Bonatti Chris" <[email-masked]>
> > 
> > Key revocation due to compromise is far less common that normal
> > periodic key expiration in some environments.  Those of us who
> > are paranoid about security :-) change keys *more* often than
> > we change names/jobs/email-addresses/whatever.
> 
> You're quite right, of course.  However, I guess one of 
> my unstated assumptions was that this would not be something 
> that we would use a revokation mechanism for.  Normal cert 
> expiration dates are usually used to reflect planned rekeying.

Planned rekeying is done for a reason - you assume that the liklihood
of undetected key compromise increases with time, and at some time that
liklihood rises above your threshold of pain.  In that sense, key
revocation and key expiration/update are done for the same reason.  In
one case you know that the key was compromised, and in the other you
assume it has been.

In either case, key-centric models such as SPKI fail catastrophically -
if the key is revoked/expired, the principal has expired too, since
they are one in the same.  You can't get around this simple fact by
delegating, because the key signing the delegation has (potentially
or actually) been compromised.

Comments: Authenticated sender is <ieca2@[205.252.27.1]>
From: "Bonatti Chris" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked] (David P. Kemp)
Date: Thu, 2 Oct 1997 09:42:38 -0500
Subject: Re: Principles and Principals
Reply-to: [email-masked]
CC: [email-masked]
Sender: [email-masked]

On Wed, 1 Oct 1997 16:22:11 -0400, [email-masked] (David P. Kemp) wrote:

<snip>

> > Pat,
> > 
> >      This is certainly not a major problem in the environments 
> > with which I am most familiar.  Certificate revokation (due to 
> > invalidation of one of the pieces of information bound into 
> > the certificate) is far more common than key revokation (due to 
> > loss or compromise of the key).  The former occurs when jobs, 
> > mailboxes, roles, or sometimes even authorizations change.  This 
> > happens at a much higher rate than key loss.
> 
> Key revocation due to compromise is far less common that normal
> periodic key expiration in some environments.  Those of us who
> are paranoid about security :-) change keys *more* often than
> we change names/jobs/email-addresses/whatever.

You're quite right, of course.  However, I guess one of 
my unstated assumptions was that this would not be something 
that we would use a revokation mechanism for.  Normal cert 
expiration dates are usually used to reflect planned rekeying.

Chris

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

Date: Thu, 02 Oct 1997 10:50:05 +0100
From: Ian Brown <[email-masked]>
Organization: University College London
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Principles and Principals
Sender: [email-masked]

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

> you can have one cert 
> that just binds permanent info like a name or perhaps a 
> lifetime identification (i.e., SSN) number to a key.

Good points, but I think one consideration we must keep in mind is that
we may not *want* a 'permanent' key or binding, for privacy reasons.
Even if the binding is anonymous, long-term use allows profiles to be
built up which may then be re-connected with a user at some later date. 

Just a thought...

Ian.

Date: Wed, 1 Oct 1997 21:50:19 -0700
To: [email-masked]
From: "John W. Noerenberg" <[email-masked]>
Subject: Fwd: WG Action: An Open Specification for Pretty Good Privacy (openpgp)
Sender: [email-masked]

It's official, we're a WG.

Now, to work. (as if you haven't been already. <g>)

Congrats!

>To: IETF-Announce: ;
>Subject: WG Action: An Open Specification for Pretty Good Privacy (openpgp)
>From: The IESG <[email-masked]>
>Date: Tue, 30 Sep 1997 18:09:06 -0400
>Sender: [email-masked]
>
>A new working group has been formed in the Security Area of the IETF.
>For additional information, contact the Area Director or the WG Chairs.
>
>An Open Specification for Pretty Good Privacy (openpgp)
>-------------------------------------------------------
>
>Charter
>
> Chair(s):
>     John Noerenberg <[email-masked]>
>     Charles Breed <[email-masked]>
>
> Security Area Director(s):
>     Jeffrey Schiller  <[email-masked]>
>
> Mailing Lists:
>     General Discussion:[email-masked]
>     To Subscribe:      [email-masked]
>         In Body:       Only the word subscribe
>     Archive:           http://www.imc.org/ietf-open-pgp/mail-archive/
>
>
>Description of Working Group:
>
>PGP, or Pretty Good Privacy, first appeared on the Internet in 1991.
>It has enjoyed significant popularity amongst the Internet Community.
>
>PGP is used both for protecting E-mail and File Storage. It presents
>a way to digitally sign and encrypt information "objects." As such
>it is well suited for any store and forward application.
>
>The goal of the OpenPGP working group is to provide IETF standards for
>the algorithms and formats of PGP processed objects as well as providing
>the MIME framework for exchanging them via e-mail or other transport
>protocols.
>
>Because there is a significant installed base of PGP users, the
>working group will consider compatibilty issues to avoid
>disenfranchising the existing community of PGP users.
>
>Security Issues:
>
>The whole purpose of Open-PGP is to provide security services.
>
> Goals and Milestones:
>
>   Oct 97       Submit Internet-Draft for PGP Key Format & Message
>                Specification
>
>
>   Mar 98       Issue WG Last Call for PGP Key Format & Message Specification
>                Internet-Draft documents
>
>
>   May 98       Submit PGP Key Format & Message Specification
>Internet-Draft to
>                IESG for consideration as a Proposed Standard.
>
>

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

Date: Wed, 1 Oct 1997 16:22:11 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Principles and Principals
Sender: [email-masked]

> From: "Bonatti Chris" <[email-masked]>
> 
> > Ian Brown wrote :
> > > > The PGP public-key is the principal.
> > > 
> > > I think this is a great way to look at it. Using the public key, its
> > > hash or fingerprint as *the* DN allows all sorts of important
> > > functionality like authorisations.
> > 
> > The major problem with 'key-principal' architectures is the
> > revocation problem.
> > 
> > When my key is revoked/changed/upgraded/whathaveyou all
> > bindings are lost.
> 
> Pat,
> 
>      This is certainly not a major problem in the environments 
> with which I am most familiar.  Certificate revokation (due to 
> invalidation of one of the pieces of information bound into 
> the certificate) is far more common than key revokation (due to 
> loss or compromise of the key).  The former occurs when jobs, 
> mailboxes, roles, or sometimes even authorizations change.  This 
> happens at a much higher rate than key loss.

Key revocation due to compromise is far less common that normal
periodic key expiration in some environments.  Those of us who
are paranoid about security :-) change keys *more* often than we change
names/jobs/email-addresses/whatever.

"Key-principal" architectures such as the one Ron Rivest calls
"spooky/sudsy" make it very difficult to practice good key management.
The traditional model where keys are attributes of a principal, not
the principal itself, allows changing keys to be no more difficult
than changing jobs :-).

>      This was one of the reasons that the attribute certificate 
> emerged in X.509.  (There were other reasons too.)  It allowed a 
> wide range of this "non-principal" binding data to be abstracted 
> from the main structure.  This help to facilitate separate 
> certificates for various functions.  Thus you can have one cert 
> that just binds permanent info like a name or perhaps a 
> lifetime identification (i.e., SSN) number to a key.

Excellent point.  Those who dislike global names (Distinguished Names,
DNS names, RFC-822 names, etc) could use "key-like" permanent names
(1024-bit random integers) in X.509 or PGP certificates without giving
up the ability for principals to update their keys.  Key-principal
architectures do not have this flexibility.

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

Absolutely.