Technical Description of PGP 5.5

Jon Callas presented a technical description of PGP5.5 at this 
month's Bay Area Cypherpunks meeting, as well as flak catching on the 
politics discussion; Phil Zimmermann and other PGP folks also helped.
This posting is an attempt to summarize the technical parts
and leave the politics for other messages.  Perhaps there's been some
technical discussion on OpenPGP, but feel free to forward this there if not.

1) PGP 5.5 API Toolkit -  It's the core of the PGP5.5 GUI and SMTP tools.
	It'll be out Real Soon Now.  It's a major change from the 
	PGP 5.0 Toolkit, which is based on ViaCrypt's older code.
	The toolkit knows about all the features in the message
	formats, so even if the application programs from PGP
	don't provide a given friendly or hostile feature,
	you can still write it yourself, and so can the Bad Guys.

2) PGP 5.* message format - unchanged - uses the multiple recipients,
	without any indication of or dependence on relationships
	between the recipients.  The format is approximately
		Recipient Record 1 - KeyID1, E(sessionkey, PubKey1)  ....
		Recipient Record N - KeyIDN, E(sessionkey, PubKeyN)
		Message - E(Message, sessionkey)
	KeyID is the 32-bit KeyID, rather than a fingerprint.
	I don't know if the format or the PGP 5.x software can 
	generate or accept messages with recipient records for
	two different keys with the same keyid (or whether it matters
	if the keys are for DH*, RSA, or both.)
		* DH can be spelled "E L  G A M A L" -- Blame Cylink :-)

	While 5.0 did introduce new data formats, they're not stealthy,
	and features like the SMTP filters depend on being able to
	know how many recipient-key records a message contains,
	where their boundaries are, and what their KeyIDs are.

3) PGP 5.* public key format - The 5.5 features are actually present 
	in the 5.0 key record formats, but there wasn't any 
	implementation that used the extra fields.  
	The record for keys is about like this, though I may have some
	of the details wrong.  The record for the RSA Keys uses the 
	old format; this format is for newer keys.

	Key Record type 
	KeyID
	UserName
	Algorithm ID - the interesting combo is ElGamal and DSA
	Encryption Key
	OptionalCMRK_1: (Mandatory/Optional flag1, Msg Recovery KeyID1)
	 .....
	OptionalCMRK_N: (Mandatory/Optional flagN, Msg Recovery KeyIDN)  
		(Note: the format allows multiple records, PGP5.5 only 
		generates one, though it might accept and use multiple.
		Nobody indicated whether more than one CMRK indicates
		that the sender should encrypt to all CMRKs, pick one,
		or do something interesting like secret-share.)
		(Note: the KeyID is a 32-bit KeyID, not the full 
		fingerprint, 	which has amusing deadbeef attacks. 
		(Unless I remembered wrong.))
	Signature Key 
	Self-Signature on (Encryption Key, Signature Key, UserName)
		(I don't know if the self-signature includes the CMRKs,
		but I think it includes the user names.)
	Optional_Signature_1: (Signature KeyID1, Signature1)  .....
	Optional_Signature_N: (Signature KeyIDN, SignatureN) 
		(I don't remember if it's just the KeyID or the 
		full fingerprint.)
		(Note: Signatures are only on the signature key,
		so you can change the encryption key and keep your
		collection of web of trust signatures; this is secure
		because the encryption key is signed with YOUR sig key,
		and your sig key is signed by your friends' sig keys.)

	The signature structure is interesting, since it lets you
	implement forward secrecy somewhat conveniently - 
	just change your encryption key.  	I don't know if the 
	5.0 / 5.5 implementations can easily handle multiple
	records for the same KeyID, so there may be some 
	transition issues, but that's an implementation question, 
	not a data format question.

	The CMRK** is obviously the new and controversial feature.
	The key is attached to the recipient's key, not the 
	sender's program, which has some implications in who 
	has to participate in any message escrow activities 
	and where they take place.  To some extent this is planned, 
	and to some extent it's just the consequences of what parts 
	of the system you have control over and what you don't.
	This approach has the recipient publish a CMRK KeyID,
	and has the sender decide whether to use it,
	rather than having the sender's system specify who 
	gets the CMR copy.  
	- Since this is the data format, it doesn't have any control 
	over what the sender really does; 	any enforcement is in the 
	sender's or recipient's client or in the SMTP mail filters.  
	- The format just contains the CMR KeyID, not the key itself;
	looking up the key is a separate job.
		(** Corporate Message Recovery Key?  Cover My Rear Key?)

	NOT TALKED ABOUT, but possibly relevant: www.pgp.com says:
		"Using PGP's Administrative Wizard, for example, 
		administrators can set key generation configurations; 
		require encryption for all email messages sent by a set 
		of users; enable corporate message recovery; and 
		limit the ability of users 	to perform certain actions, 
		such as key generation."
	I assume the parts about key generation are limitations on the
	client, either generating PGP Crippleware?  It can't be 
	that heavy a restriction, since users could use PGP5.0,
	or 2.6.2 if the rest of the company can accept RSA keys,
	but it's sounds disturbing and it would be nice to see 
	documentation.  Could it be limits in the keyserver instead?

	Also not talked about - CERTIFICATE SERVER, and 
		CERTIFICATE SERVER REPLICATION ENGINE
	which has lots of cool LDAP directory lookup stuff.  
	The web page didn't say anything about policy administration 
	on the server, but it's another obvious hook, assuming people 
	in a company use it (e.g. a key server could only store keys 
	with CMRKey set to Mandatory, though I don't know if the 
	initial PGP CS version does that sort of thing.)

4) PGP 5.5 Implementation and GUI - 
	- When you generate a 5.5 DH key, you have the option of 
	specifying a CMRK and setting the Mandatory/Optional flag.
	I don't remember if there's an option to force you to use the 
	CMRK, or to set a default CMRK or default value for the 
	Mandatory flag, but the PGP folks kept saying things about 
	always asking you things and always letting you know 
	when it's going to do things.
	- The PGP 5.5 implementation puts at most one CMRK in the 
	record, though it doesn't choke on receiving multiples.
	- If you receive a key record containing CMRKs, PGP 5.5 stores
	them; I don't remember if it alerts the user at that point or
	only when the user uses the key later on.
	- If you encrypt a message using 5.0, it ignores the CMRK.
	- When you are encrypting a message, the GUI lets you pick 
	what keys to encrypt to.  If one of the keys has a CMRK, 
	if the Mandatory flag is not set, it asks if you want to 
	set the CMRK as a recipient.
	If the Mandatory flag is set, it puts the CMRK as a recipient.
	Either way, you can delete the recipient, and it doesn't 
	enforce it, and it also makes the CMR keys show up in red etc.
	It will nag you if you delete a mandatory, but won't stop you.
	(I think I got those details right.....)
	Also, if there's a CMRK KeyID, and your keyring doesn't 
	contain the key for that KeyID, it asks if you want to fetch 
	it from the keyserver.

	- As far as I remember, if you have a CMRK Mandatory set on 
	one of your keys, and you receive a message addressed to 
	your key, it doesn't check if the message was also addressed 
	to your CMRK.
	A Bad Guy could build an implementation that did this, but
	the messages are interoperable with PGP 5.0 and don't contain
	any indication that any recipients use or are CMRKs, so it's
	easy to work around if they do.  And a Bad Guy could also build
	in Passphrase Leakage or other evil things anyway.

	Again, the CMRK belongs to the recipient, not the sender,
	and deciding to encrypt to it belongs to the recipient.
	The ViaCrypt BusinessGAK version had a feature that let you
	compile in a Message Recovery Key that the sender was forced to
	use (which was a clone of the Always-Encrypt-To-Self code.)
	This is #defined out in both 5.0 and 5.5; the PGP folks 
	tried to see what happened if they #defined it in when 
	compiling, and it nicely dumped core when they used it.

5) SMTP filters - PGP Policy Management Agent for SMTP
	is really separate programs for Incoming and Outgoing mail.
	None of the PGP 5.5 features do more than nag you about using 
	them; they don't have an enforcement mechanism.  The 
	SMTP filters, on the other hand, are designed for enforcement,
	and some of the interesting security and control issues
	come from the interaction between the filters and the PGP5.5.
	The PGP folks said that their particular implementation
	was a quick and basic job using the toolkit -
	so even though it's not particularly draconian or intrusive,
	it's easy for people to write their own that are more hostile.

	Neither filter, for instance, saves copies or forwards copies
	of mail to an archive or corporate enforcers or runs scripts -
	all they do is pass or bounce the mail (with configurable message).  
	But you could write one that did, if you were that type of company.
	Source is not provided ("Look, we have to have _something_ to sell"),
	but some of the toolkit example code will be fairly similar.

	The filters don't look inside encrypted packets (so they
	don't have to manage private keys or other dangerous things).
	This does mean that they can check for encryption or signatures,
	but can't check if there's a signature inside an encrypted message.

6) Incoming SMTP filter - Really simple
	Remember - CMRKs are attached to the recipient, not the sender;
	this is the only place you can enforce that for your employees.
	Incoming mail is checked to see if it's acceptable, and either
	passed to a "real" SMTP server or bounced with a message
	(typically includes a policy statement or URL and/or
	a pointer to a key server handling the CMRKs.)
		Note that all the filtering is based on KeyIDs - 
		not email senders or email recipients or transport info.
	Messages can be rejected if they're unencrypted, or rejected if 
	the encryption recipients don't include one of a set of keys.
	Unless I'm remembering wrong if the list of keys was not
	dependent on the recipients, so you can't do things like
	"If Recipient=PurchasingClerk Require PurchasingBoss", 
	though you can require "One Recipient in set 
		PurchasingBoss, SalesBoss, EngrBoss", etc.
	Unfortunately, this pushes the company toward using one CMRkey,
	since it's not very flexible, though it can easily handle 
	multiples.

	There may have been an option to accept signed mail,
	or that may have only been in the Outgoing SMTP server.

	There wasn't an option to reject unencrypted mail.  
	(You could probably fake this by accepting unencrypted messages 
	while also requiring encrypted messages to include a recipient 
	whose key is not published anywhere and not publishing that 
	keyid so nobody runs a deadbeef attack on it.  
	I haven't verified this...)

	There wasn't an option to email a copy to the archive;
	you could write your own, but presumably any site that wants to
	save copies of all encrypted messages is already saving copies
	of all unencrypted messages already.  Or they're really
	only making sure there's a CMRKed copy of the session key
	so they can decrypt the message on the late recipient's disk
	after he gets hit by a bus or a subpoena.

7) Outgoing SMTP filter - more complex.
	IF Sender_IPaddr in LIST, Evaluate RULE (parameter KeyIDList) ->
	-> Accept (fwd to SMTP server)  OR Reject with parameterized 
	bouncemessage.  You only get one list of IP addresses, and you 
	can only accept/reject, but the rulesets are flexible, and you 
	can chain multiple filters together (the filter can run on 
	Port 25 but can also run on other ports, and can forward to 
	an SMTP server on other ports, so you can stack a bunch of 
	these on a single box and chain them together.)
		Note that this doesn't look at the sender's or 
		recipients' email addresses, just the sender's 
		IP address.  This is sometimes limiting 
		(consider mail servers with multiple users, or 
		multi-user machines, or people who do multiple 
		functions from one machine), but it's more secure than 
		trusting easily forged information like the sender and 
		sender's address.  A fancier system would include these 
		in filtering capability.  That capability may have been
		left out on purpose, or it may just be limited 
		development time.
	(I don't remember if you can use multiple rulesets, 
	but you can stack.)  I also don't remember 
	all the possible rules, but this is close:
	- Require Encryption  (yeah!)
	- Require Encryption to Key on KeyIDList 
		-- remember that CMRKs are attached to recipients' keys,
		not to senders' keys or mail packages, so the senders 
		have to include any required keys themselves unless the 
		recipients' CMRK keys are administered jointly with 
		the SMTP server.  (Sending them enough bounce messages 
		may give them a hint, but the sender's PGP5.5 system 
		won't do it automatically.)
		Thus, it's easy for CompanyA BuildingA to make sure that
		messages to CompanyA BuildingB employees are encrypted 
		to one of CompanyA's CMRKs, but it doesn't have a clue 
		about CompanyB's CMRKs or RandomRecipient's CMRKs, 
		though if the recipients put their keys and CMRKs on 
		some public keyserver a more sophisticated (and slower)
		SMTP gateway could check.
	- Require Signature (Remember that it can't look inside 
		encrypted messages, so it only does this for 
		unencrypted signed messages.)
	- Require Signature from KeyIDList - since this ruleset is 
		used along with IP address lists, you could require 
		things like
		"All email from Purchasing's machines are signed by 
			Purchasing"
		"All email from the PR department is signed by the 
			Marketroid Key"
		"All email from PR users is also signed by 
			someone technical" :-)
		"All email from technical people is signed by 
			Corporate Security" :-(
		"All email from the company president's key is signed by 
			PR and Legal" (Note that this doesn't let you say 
			"All email purporting to be from the company 
				president" 
			since it doesn't read email headers.)
		"All mail from the company president's real key is 
			signed by the company president or her secretary"
	- Block encrypted mail, block signed mail (I think both of 
		these were there, and if they weren't, you could 
		implement them by some combination of features.)
	- Clear Text	- you can allow this or block it.

Storage Keys vs. Signature Keys vs. Message Encryption Keys -
	As described above, PGP5.* does use separate keys & algorithms
	for signatures and encryption, except for the old RSA keys.
	Storage Keys are a different issue - the main distinctions
	between storage keys and message encryption keys are
	- storage keys are used by the owner, while message encryption 
		keys are used by someone other than the owner for 
		items that will be given to the owner.
	- storage keys are useful when you have the storage media,
		message encryption keys are useful when you have a
		copy of the message, either legitimate or eavesdropped.
	- message encryption cyphertext gets mailed; stored
		cyphertext just sits there :-)

	PGPdisk is a pure storage key system, and perhaps there 
	would have been less political furor if PGP had done 
	Corporate Storage Recovery Keys, but it's not a mainstream 
	product for PGP Inc., and only runs on Macs.  
	Doing the storage job right means integrating with
	backup servers (disk drives get crashed or scribbled
	far more often than employees get hit by trucks...)
	which isn't PGPInc's specialty.

	In reality, users often use PGP for storage, including for
	messages they've received (depending on their mail GUI)
	and for files on disks (encrypted to themselves.)
	File-by-file encryption is easier to back up securely than
	whole-disk encryption, which requires either dumping the whole 
	disk to backup media or copying to the backup in the clear.
	The latter is especially useful if the backup server is also
	an encrypted storage system, but the copying may be a security
	risk, unless you do really fancy things, 	and there's the 
	whole question of whether the backup storage is encrypted 
	with the same keys as the primary (hit-by-truck risk) or with 
	a different key (corporate message access equivalence risk.)

Business environment and documentation - [Mostly non-technical]
	PGP is a real business.  They've got deadlines, 
	they've got accountants, they've got people beating them up 
	to ship code by the end of the quarter so they can bill people,
	they've got customers telling them they won't buy stuff until 
	they get Feature X added or removed, all the usual stuff.
	The design consultants who used to do their export controlled 
	web site left them a maze of twisty little CGI scripts, 
	all different, so getting actual technical documentation out 
	has taken far more work than anybody had time to do before 
	a release date.  (Some documentation is claimed to exist :-)
	Their SMTP packages could have had far more features, but they
	felt this at least minimally met their requirements, and there
	was some thought toward extensibility.

	While 5.0 did introduce new data formats, they're not stealthy,
	because they haven't seen much (any?) paying-customer demand,
	and features like the SMTP filters depend on being able to
	know how many recipient-key records a message contains,
	where their boundaries are, and what their KeyIDs are.
	So they recommend that people who want stealth go work OpenPGP
	and build formats that work to pressure PGP Inc. into using it.

	One of Phil's goals had been to design a system that provided 
	the business message recovery features their customers were 
	asking for without providing access to users' private or 
	signature keys, as a counter-argument to the GAK advocates 
	who claim they need it.	[ As might be expected, 
	much heated discussion occurred on this issue.  :-) ]

	Some things that time pressure makes it difficult to
	think about, or at least implement, beside stealth, 
	are features like secret-sharing the session keys to CMRKs
	(it's not possible to do this cleanly, without affecting
	a bunch of other things), or making session key recovery
	a difficult and slow process so it doesn't get done often
	(e.g. zeroing the bottom N ~ 32-40 bits of session key
	so recovery requires some brute force as well as the keys.)
	Building in the ability to crack messages using a single
	master key is really bad (though at least it can be a
	different master key per user or per message); perhaps when
	5.6 or 6.0 handles multiple CMRKs it will implement them
	by secret-sharing rather than making them each full recipients.

- Customers -
	Some of the customers do want to "recover" all their users' 
	traffic. Others wanted to make sure that mail to a customer 
	service rep got encrypted to the other customer service reps 
	also, or at least to the rep's boss, so someone could handle
	the business if the original recipient was away.

	One of the more obnoxious customers was implementing CAK by
	having the Corporate Security department generate keys and
	hand them to the users on floppies; this gives them a less
	obnoxious approach that they're willing to try.

	One of the customers was really paranoid about making sure
	their employees didn't leave their CAD drawings encrypted
	and then steal them or extort money from the company for
	decrypting the plaintext when they quit; apparently the
	idea of using a document management system like programmers
	use for source code control had never occurred to them....
				Thanks!
					Bill
Bill Stewart, stewarts@ix.netcom.com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

At 07:12 AM 10/15/97 -0700, Kent Crispin wrote:
>Correct me if I'm wrong, but this seems to imply that the CMR fields 
>in the key structure are really just a convenience -- if PGP, Inc. 
>didn't write an smtp filter that enforced a CMR key, someone else
>(say a firewall vendor) could do so easily, defining whatever 
>relationship between keys they wanted.

Anybody with half a brain, a copy of perl, and the PGP 5.0 source from
http://www.pgpi.com/ could write a similar filter in a matter of hours.

I am going to install PGP's SMTP filter on my box. To make it impossible to
accidentally send unencrypted mail to certain people. :-)

>To make that a bit stronger, it seems like *any* model that uses 
>persistent encryption keys essentially enables CMR-like functionality 
>in a smtp filter -- it could be done using pgp 2.6.

Correct. But this isn't going to stop people from complaining.

PGP 5.5 is considerably better than PGP 5.0. The LDAP support alone is
reason to upgrade. The UI is improved and if you don't want to use message
recovery, just don't turn it on.

--Lucky Green <shamrock@netcom.com>
  PGP encrypted mail preferred.
  DES is dead! Please join in breaking RC5-56.
  http://rc5.distributed.net/

Lucky Green <shamrock@netcom.com> writes:
> Anybody with half a brain, a copy of perl, and the PGP 5.0 source from
> http://www.pgpi.com/ could write a similar filter in a matter of hours.

Agreed.  But PGP Inc may be able to deploy their system better than
some lone hacker is able to deploy a perl hack.  And deployment of
pgp5.5 / 5.0 is required to provide automatic interoperability for
this.

(Yes I know you could bounce the mail, and demand a Cc: snoop@acme.com
to go with all mails to fred@acme.com, and use a lot of pgp2.x setups
to auto-encrypt to those recipients with pgp2.x crypto recipients, but
this is not as convenient).

> I am going to install PGP's SMTP filter on my box. To make it impossible to
> accidentally send unencrypted mail to certain people. :-)

Fine, a good, entirely separable functionality.

> >To make that a bit stronger, it seems like *any* model that uses 
> >persistent encryption keys essentially enables CMR-like functionality 
> >in a smtp filter -- it could be done using pgp 2.6.
> 
> Correct. But this isn't going to stop people from complaining.

You are right, it's not.

Just because things are possible, doesn't mean you should _do_ them,
nor attempt to massively deploy them.

If the pgp5.5 functionality is designed to provide companies with a
disaster recovery procedure (forgotten passphrase, or dead employee),
there are much better ways to do it.  We're not arguing against the
user requirement, just against the methodology.

> PGP 5.5 is considerably better than PGP 5.0. The LDAP support alone
> is reason to upgrade. The UI is improved and if you don't want to
> use message recovery, just don't turn it on.

Sure, that works.  For 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`

On 25 Oct 97 at 11:03, Lucky Green wrote:

> At 03:25 PM 10/24/97 +0100, Adam Back wrote:
> 
> >If the pgp5.5 functionality is designed to provide companies with a
> >disaster recovery procedure (forgotten passphrase, or dead employee),
> >there are much better ways to do it.  We're not arguing against the
> >user requirement, just against the methodology.
> 
> There have been numerous proposals on the list to accomplish the above
> goals in a way other than the method employed by PGP. I have read the
> proposals and I am not convinced that said proposals are less intrusive.
> IMO the vast majority of the proposals I saw are more intrusive.

How about *no* recovery, eh?  Is that not less intrusive?

Recovery of messages in transit is a complete red herring.  Such
messages are not recoverable now except by means that are complete
no-brainers ("Joe, I never got your reply to my request for
blah-blah, did you send it?  If so, please resend.")  Isn't the mere
fact that such messages might be encrypted both incidental and
inconsequential?  Add to that the *fact* that Internet email is
nowhere as unreliable as so many seem to suggest.  The only losses
of email that I've ever seen were attributable to user error or ISP
outage, not to failure of delivery attributable to the network. I've 
maintained threads of back and forth email exceeding 600 message 
cycles without the thread being broken by failure of a message to 
arrive at its intended destination.

Recovery of messages in transit is entirely a snooping issue, 
methinks.

Recovery of stored messages and files also seems to me to be a
solution to a largely imaginary problem.  As I wrote before, there
are more ways and more likely ways to lose data than through keeping
encrypted files.  People live with it.  If they wish to address it,
either individually or institutionally, they can do so without
special features in PGP.  A feature in mail clients to store the 
decrypted message in place of the original would do more to avoid 
loss of stored encrypted messages than anything else I've seen 
proposed.

This reminds me a lot of the objections of a few to sending EDI 
traffic over the Internet.  When I proposed this in recent years I 
got a wail from some people over the loss of third-party time 
stamping and message delivery verification that can occur in the 
simpler scenarios of bypassing the cash-cow Value Added Networks.  
But, um, didn't everyone print those documents on *paper* and drop 
them into USPS *mail boxes* just a few short years ago?  What 
reliable third party time stamping and message delivery verification 
did they have then?  Am I mistaken or didn't the entire economy 
function on the basis of snail-mailed invoices and other documents? 
How on earth did people manage under those primitive circumstances?

How on earth can people manage email and disk files without the 
ability to "recover" data that can be lost in a thousand other ways 
that no encryption package can protect against.  Geez.  Let's get 
real here.

Regards,

Thomas Junker
tjunker@phoenix.net

On Mon, Oct 27, 1997 at 02:26:27AM -0500, Thomas Junker wrote:
> 
> Recovery of messages in transit is entirely a snooping issue, 
> methinks.

Actually, it's snooping of messages in transit on a network OWNED BY 
THE COMPANY.

> Recovery of stored messages and files also seems to me to be a
> solution to a largely imaginary problem.  As I wrote before, there
> are more ways and more likely ways to lose data than through keeping
> encrypted files.  People live with it.  If they wish to address it,
> either individually or institutionally, they can do so without
> special features in PGP.  A feature in mail clients to store the 
> decrypted message in place of the original would do more to avoid 
> loss of stored encrypted messages than anything else I've seen 
> proposed.
[and]
> How on earth can people manage email and disk files without the 
> ability to "recover" data that can be lost in a thousand other ways 
> that no encryption package can protect against.  Geez.  Let's get 
> real here.

Given the frequency of "I've forgotten my password" incidents at
company help desks, widespread use of cryptography would cause this to
become *the* prime cause of lost data.  As has been pointed out, 
email is actually very reliable.  Hard disks are very reliable, tapes 
are very reliable.  Loss of data through these media has become very 
rare, and with intelligent practice, non-existent for all practical 
purposes. 

> This reminds me a lot of the objections of a few to sending EDI 
> traffic over the Internet.  When I proposed this in recent years I 
> got a wail from some people over the loss of third-party time 
> stamping and message delivery verification that can occur in the 
> simpler scenarios of bypassing the cash-cow Value Added Networks.  
> But, um, didn't everyone print those documents on *paper* and drop 
> them into USPS *mail boxes* just a few short years ago?  What 
> reliable third party time stamping and message delivery verification 
> did they have then?  Am I mistaken or didn't the entire economy 
> function on the basis of snail-mailed invoices and other documents? 
> How on earth did people manage under those primitive circumstances?

This is a bad argument for you to use.  From a privacy perspective,
didn't people send all kinds of very private stuff on *paper* and
through *mailboxes* just a few short years ago?  How did they survive 
without strong encryption?!  "Geez.  Let's get real here."

The physical mail analogy to PGP's implementation of CMR is as 
follows:  Company policy is that it does not accept private pmail for 
individuals.  All mail for individuals must be addressed

XYZ Company
attn: Indi Vidual
Address1
Address2

Mail addressed like this:

Indi Vidual
Address1
Address2

will be returned, because the company doesn't accept private mail.  
Company mail is to be used for company business.  You don't receive 
Playboy at work, you receive it at home.

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			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

Kent Crispin <kent@bywater.songbird.com> writes:
> Given the frequency of "I've forgotten my password" incidents at
> company help desks, widespread use of cryptography would cause this to
> become *the* prime cause of lost data.

pgp5.5 doesn't cope with this very well -- it requires all of the
stored emails to be decrypted by the holder of the recovery key and
re-encrypted to the users new key.  Same thing for tape archives,
write once CD archives, etc., etc.

Password memory lapses are likely to be the major problem.

It would suggest that smart cards might be a valuable ergonomics
investment.  I understand dumb card readers are dirt cheap (~$10 in
volume) and can be plugged inline into keyboard cables.  Reckon you
could swallow the cost in the product price even ($159 or whatever the
business edition is).

> The physical mail analogy to PGP's implementation of CMR is as 
> follows:  Company policy is that it does not accept private pmail for 
> individuals.  All mail for individuals must be addressed
> 
> XYZ Company
> attn: Indi Vidual
> Address1
> Address2
> 
> Mail addressed like this:
> 
> Indi Vidual
> Address1
> Address2
> 
> will be returned, because the company doesn't accept private mail.  
> Company mail is to be used for company business.  You don't receive 
> Playboy at work, you receive it at home.

Reasonable analogy of what's going on wrt strictly company use
addresses, and with companies which may allow private use addresses.

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`

At 03:25 PM 10/24/97 +0100, Adam Back wrote:

[Busy week. Expect increased response time].

>If the pgp5.5 functionality is designed to provide companies with a
>disaster recovery procedure (forgotten passphrase, or dead employee),
>there are much better ways to do it.  We're not arguing against the
>user requirement, just against the methodology.

There have been numerous proposals on the list to accomplish the above
goals in a way other than the method employed by PGP. I have read the
proposals and I am not convinced that said proposals are less intrusive.
IMO the vast majority of the proposals I saw are more intrusive. One
subscriber even argued, make that screamed, that PGP 5.5 was evil because
it didn't automatically cc: the email to the corporate recovery agent. The
mind boggles.


--Lucky Green <shamrock@netcom.com>
  PGP encrypted mail preferred.
  DES is dead! Please join in breaking RC5-56.
  http://rc5.distributed.net/

On Wed, Oct 15, 1997 at 12:43:22AM -0700, Bill Stewart wrote:
> Jon Callas presented a technical description of PGP5.5 at this 
> month's Bay Area Cypherpunks meeting, as well as flak catching on the 
> politics discussion; Phil Zimmermann and other PGP folks also helped.
> This posting is an attempt to summarize the technical parts
> and leave the politics for other messages.  Perhaps there's been some
> technical discussion on OpenPGP, but feel free to forward this there if not.

No, there has been little technical discussion.  Maybe I've missed 
it, but I haven't seen from Adam a succint writeup of what his design 
actually is -- most of what he writes is so inflated with steaming 
anti-GAK rhetoric that it's hard to get a coherent picture.  Perhaps 
he will take your example to heart, and post a strawman design, and 
leave the politics to other messages.

> 1) PGP 5.5 API Toolkit -  It's the core of the PGP5.5 GUI and SMTP tools.
> 	It'll be out Real Soon Now.  It's a major change from the 
> 	PGP 5.0 Toolkit, which is based on ViaCrypt's older code.
> 	The toolkit knows about all the features in the message
> 	formats, so even if the application programs from PGP
> 	don't provide a given friendly or hostile feature,
> 	you can still write it yourself, and so can the Bad Guys.
> 
> 2) PGP 5.* message format - unchanged - uses the multiple recipients,
> 	without any indication of or dependence on relationships
> 	between the recipients.  The format is approximately
> 		Recipient Record 1 - KeyID1, E(sessionkey, PubKey1)  ....
> 		Recipient Record N - KeyIDN, E(sessionkey, PubKeyN)
> 		Message - E(Message, sessionkey)
> 	KeyID is the 32-bit KeyID, rather than a fingerprint.
> 	I don't know if the format or the PGP 5.x software can 
> 	generate or accept messages with recipient records for
> 	two different keys with the same keyid (or whether it matters
> 	if the keys are for DH*, RSA, or both.)
> 		* DH can be spelled "E L  G A M A L" -- Blame Cylink :-)
> 
> 	While 5.0 did introduce new data formats, they're not stealthy,
> 	and features like the SMTP filters depend on being able to
> 	know how many recipient-key records a message contains,
> 	where their boundaries are, and what their KeyIDs are.

Correct me if I'm wrong, but this seems to imply that the CMR fields 
in the key structure are really just a convenience -- if PGP, Inc. 
didn't write an smtp filter that enforced a CMR key, someone else
(say a firewall vendor) could do so easily, defining whatever 
relationship between keys they wanted.

To make that a bit stronger, it seems like *any* model that uses 
persistent encryption keys essentially enables CMR-like functionality 
in a smtp filter -- it could be done using pgp 2.6.

And therefore, PGP Inc might as well get the business, because if 
there is demand, someone will.

In the meantime they can work on perfect forward secrecy.
[...]

> - Customers -
> 	Some of the customers do want to "recover" all their users' 
> 	traffic. Others wanted to make sure that mail to a customer 
> 	service rep got encrypted to the other customer service reps 
> 	also, or at least to the rep's boss, so someone could handle
> 	the business if the original recipient was away.
> 
> 	One of the more obnoxious customers was implementing CAK by
> 	having the Corporate Security department generate keys and
> 	hand them to the users on floppies; this gives them a less
> 	obnoxious approach that they're willing to try.
> 
> 	One of the customers was really paranoid about making sure
> 	their employees didn't leave their CAD drawings encrypted
> 	and then steal them or extort money from the company for
> 	decrypting the plaintext when they quit; apparently the
> 	idea of using a document management system like programmers
> 	use for source code control had never occurred to them....

Things aren't that simple.

In any case, in large organizations (corporate or government) one of
the biggest motivations for snooping is prevention of management
embarassment.  It's seriously embarassing, for example, to read in the
paper in the morning that one of your employees has been maintaining a
public ftp porn archive on the company computers....you can fire the
employee, but the damage has been done.  

It's a cold fact that some employees are stupid, and others are bad. 
Snooping is more a result of this fact than it is innate evil on the
part of management. Of course it is nicer to work in a trusting 
environment, but the problems go both ways.

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			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