PGP 5.5 CMR/GAK: a possible solution

[Posted to cypherpunks, cc:-ed to Jon Callas]

You know, in the last few days I've read a lot of messages on both sides
of this debate, and I've umm-ed and ahh-ed and slowly gone from thinking
that what PGP are doing is evil to thinking that it's just bad. While I
believe that Adam Back's suggestions for alternate systems are good and
neccesary ideas for the long-term, I'm coming to the conclusion that PGP
are heading in the right direction for the short-term, but have things
backwards. 

The current system sends out a user's personal key, with a tag to say that
if I don't encrypt to the company as well, my mail will bounce. But think
about this: how often do I want to send email to a particular person in a
company, and ensure that only they see it? And how often do I want to send
mail to a particular group inside a company? All I want is to ensure that
I get a response from the company, I usually don't care who I talk to in the
process.

So PGP's "everything private unless you choose to make it public" system
seems backwards. Surely what we really need to meet these customer demands
is an "everything public (within the company) unless you choose to make it
private" system? That is, all mail to my department inside the company
should be encrypted to a department key, shared by all members, *unless*
it is confidential, in which case it should *only* be encrypted to me. 

Here's how I see this working: when Joe Blow joins Foo-Bah Cryptosystems,
he creates his own personal PGP key. He also gets a copy of the department
key, which he can use to decrypt any mail which is encrypted to his
department; or this decryption could be handled automatically by a
department email server to ensure that individuals never have access to the
department's private key. PGP then creates a public key for 'Joe Blow
<joe.blow@foo-bah.com>', which would be the department key with a signed tag
linking it to his personal public key. This is the tagged corporate public
key which he would give out to any customers. 

When a customer wishes to send email to Joe, he would use this public key.
When encrypting, PGP would detect the tag and put up a dialog box pointing
out that this is a corporate key and if they click on the 'confidential'
button it will be encrypted to the user's personal key prior to encrypting
to the corporate key (by which I mean superencryption, to avoid traffic
analysis). The default would be not to superencrypt; and as a side effect
this system would be compatible with any version of PGP for
non-confidential mail (assuming that version understands the encryption
algorithms in use). 

The effect of this is that if someone wants to send email about an urgent
bug and I'm out at lunch, any of my co-workers can read that mail. But if
they want to send *me* mail about confidential inter-company negotiations,
the co-workers could decrypt the outer layer of the message, but would be
blocked by the inner layer encryption to my personal key. 

As I see it, this system is simple, solves the problems which PGP claim
they need to solve without creating the snooping problems Tim and others
have discussed, cannot easily be adapted to GAK ('This message is to be
encrypted to the FBI public key. If it is confidential, click here to
superencrypt to the recipient's personal key'), and won't require a
massive change to the PGP source code. 

There are some obvious security issues with having the department key
shared amongst the members of the department, but I don't see that they
are any worse than PGP's current CMR implementation, which has already
discussed the use of department keys; it's certainly better than using
plaintext. There are also problems with encrypting confidential mail to
multiple recipients, but they're surmountable; an easy solution, if you
don't care about traffic analysis, is to only encrypt confidential mail
to the personal key rather than superencrypt with the corporate key. In most 
cases such mail wouldn't be sent to multiple recipients anyway. 

So here's how I'd see the simple system working:

A PGP CMR key would consist of

1. A corporate key; this might be company-wide, department-wide, or
   an individual escrowed key; this choice is a seperate key-management
   issue for the corporation.
2. Optionally a personal key, which could only be decrypted by the
   individual.
3. A signature from the corporate key linking the personal key to it
   and the specified User Id.
4. Optional flag to indicate which key to encrypt to by default.
5. User Id, signatures, etc

When PGP was asked to encrypt to such a key, it would check for the
optional personal key. If it wasn't there, it would put up a warning
box to tell the user that the message can be read by people other than
the recipient. If it is, then it would put up a dialog box allowing the
user to choose whether to encrypt to the corporate key or the individual
key, normally defaulting to the corporate key. This system could not easily
become GAK because it will only encrypt to one of the keys and not both;
the FBI could create FBI CMR keys from all our public keys, but then PGP
would either encrypt to the FBI and I wouldn't be able to read it, or
encrypt to me and the FBI wouldn't be able to read it.

Anyone care to pick any holes?

        Mark

|-----------------------------------------------------------------------|
|Mark Grant M.A., U.L.C.                       EMAIL: mark@unicorn.com  |
|WWW: http://www.unicorn.com/                  MAILBOT: bot@unicorn.com |
|-----------------------------------------------------------------------|

At 03:02 AM 10/22/97 -0700, mark@unicorn.com wrote:
   
Thanks. I want to add that what's in 5.5 is hardly what we think is
perfect. The system is designed simply to be preferable to key escrow. We
have some improvements we're planning for it in the future. So you're right
-- it's a short-term solution.
   
   The current system sends out a user's personal key, with a tag to say that
   if I don't encrypt to the company as well, my mail will bounce. But think
   about this: how often do I want to send email to a particular person in a
   company, and ensure that only they see it? And how often do I want to send
   mail to a particular group inside a company? All I want is to ensure that
   I get a response from the company, I usually don't care who I talk to in
the
   process.

You have it mostly right. There's a tag in a self-signature that says,
"please encrypt to this other key, too." The only time you are required to
encrypt to Alice's other key is if you and Alice share the same additional
key (and not always even then).
   
   So PGP's "everything private unless you choose to make it public" system
   seems backwards. Surely what we really need to meet these customer demands
   is an "everything public (within the company) unless you choose to make it
   private" system? That is, all mail to my department inside the company
   should be encrypted to a department key, shared by all members, *unless*
   it is confidential, in which case it should *only* be encrypted to me. 

This is certainly possible with the system, and in fact easier to implement
than anything else.
   
   Here's how I see this working: when Joe Blow joins Foo-Bah Cryptosystems,
   he creates his own personal PGP key. He also gets a copy of the department
   key, which he can use to decrypt any mail which is encrypted to his
   department; or this decryption could be handled automatically by a
   department email server to ensure that individuals never have access to the
   department's private key. PGP then creates a public key for 'Joe Blow
   <joe.blow@foo-bah.com>', which would be the department key with a signed
tag
   linking it to his personal public key. This is the tagged corporate public
   key which he would give out to any customers. 
   
   When a customer wishes to send email to Joe, he would use this public key.
   When encrypting, PGP would detect the tag and put up a dialog box pointing
   out that this is a corporate key and if they click on the 'confidential'
   button it will be encrypted to the user's personal key prior to encrypting
   to the corporate key (by which I mean superencryption, to avoid traffic
   analysis). The default would be not to superencrypt; and as a side effect
   this system would be compatible with any version of PGP for
   non-confidential mail (assuming that version understands the encryption
   algorithms in use). 
   
   The effect of this is that if someone wants to send email about an urgent
   bug and I'm out at lunch, any of my co-workers can read that mail. But if
   they want to send *me* mail about confidential inter-company negotiations,
   the co-workers could decrypt the outer layer of the message, but would be
   blocked by the inner layer encryption to my personal key. 
   
   As I see it, this system is simple, solves the problems which PGP claim
   they need to solve without creating the snooping problems Tim and others
   have discussed, cannot easily be adapted to GAK ('This message is to be
   encrypted to the FBI public key. If it is confidential, click here to
   superencrypt to the recipient's personal key'), and won't require a
   massive change to the PGP source code. 

This is exactly CMR. The only thing that Business 5.5 does is automatically
add the department for you, and put up the recipient dialog so it can be
taken off. Congrats.
   
   There are some obvious security issues with having the department key
   shared amongst the members of the department, but I don't see that they
   are any worse than PGP's current CMR implementation, which has already
   discussed the use of department keys; it's certainly better than using
   plaintext. There are also problems with encrypting confidential mail to
   multiple recipients, but they're surmountable; an easy solution, if you
   don't care about traffic analysis, is to only encrypt confidential mail
   to the personal key rather than superencrypt with the corporate key. In
most 
   cases such mail wouldn't be sent to multiple recipients anyway. 
   
   So here's how I'd see the simple system working:
   
   A PGP CMR key would consist of
   
   1. A corporate key; this might be company-wide, department-wide, or
      an individual escrowed key; this choice is a seperate key-management
      issue for the corporation.
   2. Optionally a personal key, which could only be decrypted by the
      individual.
   3. A signature from the corporate key linking the personal key to it
      and the specified User Id.
   4. Optional flag to indicate which key to encrypt to by default.
   5. User Id, signatures, etc
   
   When PGP was asked to encrypt to such a key, it would check for the
   optional personal key. If it wasn't there, it would put up a warning
   box to tell the user that the message can be read by people other than
   the recipient. If it is, then it would put up a dialog box allowing the
   user to choose whether to encrypt to the corporate key or the individual
   key, normally defaulting to the corporate key. This system could not easily
   become GAK because it will only encrypt to one of the keys and not both;
   the FBI could create FBI CMR keys from all our public keys, but then PGP
   would either encrypt to the FBI and I wouldn't be able to read it, or
   encrypt to me and the FBI wouldn't be able to read it.
   
   Anyone care to pick any holes?

Looks good from here. You've redesigned PGP 5.5. Thanks.

	Jon



-----
Jon Callas                                  jon@pgp.com
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 <jon@pgp.com> writes:
> At 03:02 AM 10/22/97 -0700, mark@unicorn.com wrote:
>   [CMR tagged keys description]
> 
> You have it mostly right. There's a tag in a self-signature that says,
> "please encrypt to this other key, too." The only time you are required to
> encrypt to Alice's other key is if you and Alice share the same additional
> key (and not always even then).

"Not required to encrypt to CMR key" but "mail will bounce which
doesn't encrypt to CMR key" seems like a fairly small distinction to
me.  So you don't have to encrypt to the CMR key, but if you don't the
message won't get there?  (Of course only when strict flag is set on
policy enforcer, and user id on key you are sending to has CMR request
tag).

Sort of like: you can dial the phone number wrongly if you want, it's
your choice (to avoid phone tap).

And yes you can bypass it, if you're technical, but most people
aren't.  And the bypass can be detected if anyone is checking.

>    So PGP's "everything private unless you choose to make it public" system
>    seems backwards. Surely what we really need to meet these customer demands
>    is an "everything public (within the company) unless you choose to make it
>    private" system? That is, all mail to my department inside the company
>    should be encrypted to a department key, shared by all members, *unless*
>    it is confidential, in which case it should *only* be encrypted to me. 
> 
> This is certainly possible with the system, and in fact easier to implement
> than anything else.

Sounds like a simpler interim solution, if that's what CMR reportedly is?

>    The effect of this is that if someone wants to send email about an urgent
>    bug and I'm out at lunch, any of my co-workers can read that mail. But if
>    they want to send *me* mail about confidential inter-company negotiations,
>    the co-workers could decrypt the outer layer of the message, but would be
>    blocked by the inner layer encryption to my personal key. 
>    
>    As I see it, this system is simple, solves the problems which PGP claim
>    they need to solve without creating the snooping problems Tim and others
>    have discussed, cannot easily be adapted to GAK ('This message is to be
>    encrypted to the FBI public key. If it is confidential, click here to
>    superencrypt to the recipient's personal key'), and won't require a
>    massive change to the PGP source code. 
> 
> This is exactly CMR. The only thing that Business 5.5 does is automatically
> add the department for you, and put up the recipient dialog so it can be
> taken off. Congrats.

It's close, but not quite the same.

The major distinction is that Mark wasn't proposing leaving recovery
information sticking out on email traffic going over the Internet in
the form of CMR extra recipients.  (Also Mark wasn't proposing
bouncing mail which didn't meet requirements)

I you have a policy enforcer set to allow all mails through (no strict
setting), then what Mark described does sound similar at first glance,
but there is actually a very significant difference: there is no
message recovery concept: just emails are encrypted to who they're
meant to be sent to.  (In one case the individual, in the other case
the department).

The outer encryption layer I don't think actually adds anything in
this case (other than potentially extra security if the individual's
passphrase is poor).


Given that, couldn't the same be achieved with 0 modifications?  Have
different keys, some shared, some not.

sales@acme.com
fred@acme.com
jane@acme.com

with sales@acme.com key shared between sales manager and sales
persons?

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`

This whole "company key", "department key", and "personal key" business seems
strangely similar to the hierarchical structure of an LDAP server.  I wonder where
we could store that information...  :-)

Just my 2¢.

John E. Mayorga





Jon Callas wrote:

> At 03:02 AM 10/22/97 -0700, mark@unicorn.com wrote:
>
> Thanks. I want to add that what's in 5.5 is hardly what we think is
> perfect. The system is designed simply to be preferable to key escrow. We
> have some improvements we're planning for it in the future. So you're right
> -- it's a short-term solution.
>
>    The current system sends out a user's personal key, with a tag to say that
>    if I don't encrypt to the company as well, my mail will bounce. But think
>    about this: how often do I want to send email to a particular person in a
>    company, and ensure that only they see it? And how often do I want to send
>    mail to a particular group inside a company? All I want is to ensure that
>    I get a response from the company, I usually don't care who I talk to in
> the
>    process.
>
> You have it mostly right. There's a tag in a self-signature that says,
> "please encrypt to this other key, too." The only time you are required to
> encrypt to Alice's other key is if you and Alice share the same additional
> key (and not always even then).
>
>    So PGP's "everything private unless you choose to make it public" system
>    seems backwards. Surely what we really need to meet these customer demands
>    is an "everything public (within the company) unless you choose to make it
>    private" system? That is, all mail to my department inside the company
>    should be encrypted to a department key, shared by all members, *unless*
>    it is confidential, in which case it should *only* be encrypted to me.
>
> This is certainly possible with the system, and in fact easier to implement
> than anything else.
>
>    Here's how I see this working: when Joe Blow joins Foo-Bah Cryptosystems,
>    he creates his own personal PGP key. He also gets a copy of the department
>    key, which he can use to decrypt any mail which is encrypted to his
>    department; or this decryption could be handled automatically by a
>    department email server to ensure that individuals never have access to the
>    department's private key. PGP then creates a public key for 'Joe Blow
>    <joe.blow@foo-bah.com>', which would be the department key with a signed
> tag
>    linking it to his personal public key. This is the tagged corporate public
>    key which he would give out to any customers.
>
>    When a customer wishes to send email to Joe, he would use this public key.
>    When encrypting, PGP would detect the tag and put up a dialog box pointing
>    out that this is a corporate key and if they click on the 'confidential'
>    button it will be encrypted to the user's personal key prior to encrypting
>    to the corporate key (by which I mean superencryption, to avoid traffic
>    analysis). The default would be not to superencrypt; and as a side effect
>    this system would be compatible with any version of PGP for
>    non-confidential mail (assuming that version understands the encryption
>    algorithms in use).
>
>    The effect of this is that if someone wants to send email about an urgent
>    bug and I'm out at lunch, any of my co-workers can read that mail. But if
>    they want to send *me* mail about confidential inter-company negotiations,
>    the co-workers could decrypt the outer layer of the message, but would be
>    blocked by the inner layer encryption to my personal key.
>
>    As I see it, this system is simple, solves the problems which PGP claim
>    they need to solve without creating the snooping problems Tim and others
>    have discussed, cannot easily be adapted to GAK ('This message is to be
>    encrypted to the FBI public key. If it is confidential, click here to
>    superencrypt to the recipient's personal key'), and won't require a
>    massive change to the PGP source code.
>
> This is exactly CMR. The only thing that Business 5.5 does is automatically
> add the department for you, and put up the recipient dialog so it can be
> taken off. Congrats.
>
>    There are some obvious security issues with having the department key
>    shared amongst the members of the department, but I don't see that they
>    are any worse than PGP's current CMR implementation, which has already
>    discussed the use of department keys; it's certainly better than using
>    plaintext. There are also problems with encrypting confidential mail to
>    multiple recipients, but they're surmountable; an easy solution, if you
>    don't care about traffic analysis, is to only encrypt confidential mail
>    to the personal key rather than superencrypt with the corporate key. In
> most
>    cases such mail wouldn't be sent to multiple recipients anyway.
>
>    So here's how I'd see the simple system working:
>
>    A PGP CMR key would consist of
>
>    1. A corporate key; this might be company-wide, department-wide, or
>       an individual escrowed key; this choice is a seperate key-management
>       issue for the corporation.
>    2. Optionally a personal key, which could only be decrypted by the
>       individual.
>    3. A signature from the corporate key linking the personal key to it
>       and the specified User Id.
>    4. Optional flag to indicate which key to encrypt to by default.
>    5. User Id, signatures, etc
>
>    When PGP was asked to encrypt to such a key, it would check for the
>    optional personal key. If it wasn't there, it would put up a warning
>    box to tell the user that the message can be read by people other than
>    the recipient. If it is, then it would put up a dialog box allowing the
>    user to choose whether to encrypt to the corporate key or the individual
>    key, normally defaulting to the corporate key. This system could not easily
>    become GAK because it will only encrypt to one of the keys and not both;
>    the FBI could create FBI CMR keys from all our public keys, but then PGP
>    would either encrypt to the FBI and I wouldn't be able to read it, or
>    encrypt to me and the FBI wouldn't be able to read it.
>
>    Anyone care to pick any holes?
>
> Looks good from here. You've redesigned PGP 5.5. Thanks.
>
>         Jon
>
> -----
> Jon Callas                                  jon@pgp.com
> 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)







begin:          vcard
fn:             John Mayorga
n:              Mayorga;John
org:            Netscape Communications Corp.
adr;dom:        ;;501 E. Middlefield Road, Mountain View, CA 94043, USA;9;;;
email;internet: jmayorga@netscape.com
tel;work:       4556
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

At 01:46 PM 10/22/97 +0100, Adam Back wrote:
   
   Mark Grant <mark@unicorn.com> writes:
   > The current system sends out a user's personal key, with a tag to say
that
   > if I don't encrypt to the company as well, my mail will bounce. But think
   > about this: how often do I want to send email to a particular person in a
   > company, and ensure that only they see it? And how often do I want to
send
   > mail to a particular group inside a company? All I want is to ensure that
   > I get a response from the company, I usually don't care who I talk to
in the
   > process.
   
   The CMR feature in pgp5.5 isn't so far intented to cope with this
   scenario I think.  That's because pgp5.5 I understand can only
   generate keys with one CMR request field.

Well, Adam, you are yet again describing it wrong. You can put in N of
them. You are right that the 5.5 UI isn't general. Something had to slip.
Also, there's another thing you're not describing correctly. This is not a
feature of the key -- it's a feature of the user name, and included in a
user name's self signature. It can be changed at any time, and you can even
have an ambivalent key that has a username with the CMR packet
(salesdweeb@foobar.com) and a without it (jblow@foobar.com).
   
   Problem for both approaches is re-keying: what happens when Fred
   leaves the sales team to work for a competitor.  Revoke the shared key
   and start over?  Or with the CMR method, revoke just the CMR request
   for Fred, and allow key servers to remove CMR requests when presented
   with a suitable CMR request revocation cert?  (How often will senders
   check key servers for revocation certs?)  Or have short expiries on
   encryption-only keys (one per day?), so that they key update happens
   soon enough anyway.  (pgp5.x allows for short lived encryption keys
   directly because of the separation of signature and encryption keys,
   the WoT applies to the signature key).

This is why any sort of shared or escrowed keys suck. But in most cases
it's good enough, because when Fred leaves sales, he loses access to the
sales computers. In most of these cases, when someone decrypts something
with the sales key, it ends up going into the order system in plaintext
anyway.

However, one of the features of the new PGP key format is that you can
change encryption keys easily. If you
   
   Really it seems to me that actually having half a dozen sales droids
   sharing a key, or being able to decrypt a message because they are all
   CMR enforced multiple crypto recipients is a security nightmare either
   way :-)
   
   Reckon it would be arguably more secure to have the SMTP policy
   enforcer decrypt it for them, even.

Really? You think the SMTP agent should be decrypting? Wow. I don't. I
think that's *really* intrusive, and worse than what we did. Interestingly
enough, there are a number of people (like Bruce Schneier) who have no
problem with the additional encryption part, but think that the SMTP agent
is the work of the devil. Expect pushback.
   
   Another method of authenticating TLS is to base the authentication on
   the user's PGP WoT.  Include authentication information to the
   delivery agent which is capable of TLS, which is also exchanged inside
   the encryption envelope.  (Eg. transfer an authentication symmetric
   key k1 inside the encryption envelope; send the local TLS capable SMTP
   hub / SMTP policy enforcer the key k1.  The TLS forward secret key
   negotiation can then be authenticated using this key.  The remote TLS
   system can tack the authentication information on to the delivered
   message, in a header, or otherwise, and the recipient can check the
   authentication).

Note that the user's WoT is stored in the user's keyring. There's an
operational problem here. This means that the MTA has to have access to all
users' pubrings. This is not a good thing, to my mind.
   
   > So PGP's "everything private unless you choose to make it public" system
   > seems backwards. Surely what we really need to meet these customer
demands
   > is an "everything public (within the company) unless you choose to
make it
   > private" system? That is, all mail to my department inside the company
   > should be encrypted to a department key, shared by all members, *unless*
   > it is confidential, in which case it should *only* be encrypted to me. 
   
   I think what PGP are arguing for is ability to recover stored messages
   even if they are intended for one recipient only.  As I think has been
   established this can be acheived by storage recovery, without exposing
   communications traffic to the associated risks.  It is possible that
   there is an unstated perceived user requirement, that the messaging
   standard be able to allow third party access to the communications
   traffic directly.

Nope, that's not what we're arguing for. What we're arguing for is an
alternative to key escrow -- the kind where your employer keeps your secret
key just in case they need it.

	Jon





-----
Jon Callas                                  jon@pgp.com
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 <jon@pgp.com> writes:
>    The CMR feature in pgp5.5 isn't so far intented to cope with this
>    scenario I think.  That's because pgp5.5 I understand can only
>    generate keys with one CMR request field.
> 
> Well, Adam, you are yet again describing it wrong. You can put in N of
> them. You are right that the 5.5 UI isn't general. 

I did understand that even pgp5.0 standard allows multiple CMR keys,
but I thought that the pgp5.5 UI doesn't allow generation of keys with
more than CMR packet per userid... so sounds like we agree?

One thing I never did get clear is: does pgp5.0 know how to reply to
the CMR denoted extra recipients?

> Also, there's another thing you're not describing correctly. This is not a
> feature of the key -- it's a feature of the user name, and included in a
> user name's self signature. It can be changed at any time, and you can even
> have an ambivalent key that has a username with the CMR packet
> (salesdweeb@foobar.com) and a without it (jblow@foobar.com).

Excuse me, yes, I have been tending to talk about the CMR being
attached to the key, while it is actually attached to the userid, of
which there can be many.  I tended to view this as a valid
simplification, because, if I understood correctly, the pgp5.5
business suite allows an administrator to configure the pgp5.5 client
which employees will be using to enforce that there _will_ be a CMR
packet on all userids?  And also most users are likely to have just
one userid.

In other words, I am not denying any of the functionality that it does
have, in being able to be used in privacy respecting ways, but rather
I am describing the most strict settings that the software attempts to
enforce if so configured.  This is still interesting because one
suspects some companies will use it this way, otherwise the
functionality wouldn't have been provided.

>   [...]
> 
> This is why any sort of shared or escrowed keys suck. But in most cases
> it's good enough, because when Fred leaves sales, he loses access to the
> sales computers.

It's not that good because even though he loses access to the
computers, if he retains a copy of the private key, he (or the
competitor he has left to join) can fairly easily obtain the
ciphertext of emails.

Proxy encryption is a good solution to this, if it works for the EG
keys you are using.  Or super encryption or TLS to protect the company
internal multiple crypto recipients.  I am not so much against CMR
crypto recipients per se, as I am against allowing these to show
outside the LAN -- too tempting for governments.

>    Really it seems to me that actually having half a dozen sales droids
>    sharing a key, or being able to decrypt a message because they are all
>    CMR enforced multiple crypto recipients is a security nightmare either
>    way :-)
>    
>    Reckon it would be arguably more secure to have the SMTP policy
>    enforcer decrypt it for them, even.
> 
> Really? You think the SMTP agent should be decrypting? Wow. I don't. 

It clearly could be more secure in some environments, with crypto
illiterate users who can't remember good passwords, or who have
tendency to write them down.  If they're all sharing keys because
they're all part of the same sales team, and the traffic is fairly low
security, I wouldn't discount it out of hand.

> I think that's *really* intrusive, and worse than what we did.

I think that is where we differ ... you focus on privacy principles,
and end up having less security and less resistance to government
abuse.

The above is merely an ergonomics trade off for some environments.  It
doesn't overly help governments snoop, and can be used where
appropriate.

You can still have individual personal use keys, or any other privacy
respecting architecture.  If we were to argue about how systems could
be abused (either government or company abuse) CMR could be abused
with an enforced CMR key on all company keys, and some software to
read all mail before delivery, and approve all mail on the way out.
CMR could also be potentially be abused by governments in passing laws
saying communications keys must have government as a CMR recipient,
and in being able to enforce this by spot checking emails in transit,
and/or via deputised ISPs with binding cryptography used to allow
untrusted fourth parties to check session keys match.

> Interestingly enough, there are a number of people (like Bruce
> Schneier) who have no problem with the additional encryption part,
> but think that the SMTP agent is the work of the devil.

The enforcement part of it is :-)

Multiple encryption over done with too many long term keys also tends
to be a security risk.  Basing recovery procedures on storage recovery
avoids this trend, and avoids the need to have recovery of
communications keys at all for the defined corporate user requirement.

>    Another method of authenticating TLS is to base the authentication on
>    the user's PGP WoT.  Include authentication information to the
>    delivery agent which is capable of TLS, which is also exchanged inside
>    the encryption envelope.  (Eg. transfer an authentication symmetric
>    key k1 inside the encryption envelope; send the local TLS capable SMTP
>    hub / SMTP policy enforcer the key k1.  The TLS forward secret key
>    negotiation can then be authenticated using this key.  The remote TLS
>    system can tack the authentication information on to the delivered
>    message, in a header, or otherwise, and the recipient can check the
>    authentication).
> 
> Note that the user's WoT is stored in the user's keyring. There's an
> operational problem here. This means that the MTA has to have access to all
> users' pubrings. This is not a good thing, to my mind.

No, I think you misunderstood the above.

MUA sends X-MTA-authentication only if the MTA is TLS aware, then it
sends:

To: fred@acme.com
X-MTA-auth: 12345678

-----BEGIN PGP MESSAGE-----
blah blah
-----END PGP MESSAGE-----

the local MTA strips out X-MTA-auth info.  Local MTA does a DH key
exchange with the remote MTA.  Local MTA encrypts with symmetric
cipher (say IDEA or something) the hash of DH parameters and
negotiated DH key with X-MTA-auth key, and puts back in header:

X-MTA-auth: abcd1234abcd1234abcd1324abcd

The receiving MTA leaves that alone, but adds a line telling the MUA
the DH key hash:

X-MTA-key: 567856785678

The MUA hands the X-MTA-auth line to the pgp implementation, together
with the encrypted message.  You have another packet inside the pgp
encryption layer which tells the receiving MUA the sending client's
info... and PGP can check the authenticate the DH key exchange after
the fact.  If there is a MITM you will know about it.

Neat because it doesn't require separate key infrastructure which
always ends up having less meaning to the user being down at the mail
hub level.  And yet you have real interactive perfect forward secrecy.

>    It is possible that
>    there is an unstated perceived user requirement, that the messaging
>    standard be able to allow third party access to the communications
>    traffic directly.
> 
> Nope, that's not what we're arguing for. 

OK, thanks.  I'll stop speculating on that one then.

> What we're arguing for is an alternative to key escrow -- the kind
> where your employer keeps your secret key just in case they need it.

Please read:

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

It also avoids key escrow for communication keys, and allows separate
personal and company use storage keys, makes recommendations for
sender and receiver statement of intent about plaintext handling, has
more ergonomic recovery options, and allows more secure more frequent
communication key updates.

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`

* Adam Back wrote:
>One thing I never did get clear is: does pgp5.0 know how to reply to
>the CMR denoted extra recipients?

Yes. (AFAI read the source). It uses ALL these keys optional or required to
encrypt an answer to. I a keys is missing encryption fails.

>It also avoids key escrow for communication keys, and allows separate
>personal and company use storage keys, makes recommendations for

Included in the current Open PGP draft.

At 3:02 AM -0700 10/22/97, mark@unicorn.com wrote:

>The current system sends out a user's personal key, with a tag to say that
>if I don't encrypt to the company as well, my mail will bounce. But think
>about this: how often do I want to send email to a particular person in a
>company, and ensure that only they see it? And how often do I want to send
>mail to a particular group inside a company? All I want is to ensure that
>I get a response from the company, I usually don't care who I talk to in the
>process.

Our mileages apparently vary. When _I_ send a message to, say, Jon Callas
at PGP, Inc., it is to Jon Callas, not to others. It might be a job offer,
it might be an invitationf for him to help monkeywrench CMR, it might be a
stock tip, it might be a comment about a conversation we had a party, it
might be a lot of things.

If I was sending it to "Jon's coworkers in Department Z," I probably either
wouldn't encrypt it at all, or would (if the option existed) encrypt to
some departmental or group key.

In fact, addressing your "how often do I want to send email to a particular
person in a company, and ensure that only they see it?" point, I'd say that
virtually all I've sent is of this "to one person and not to others" sort.
Sure, sometimes I send bug reports to software vendors and to my ISP, and
then I don't know, or care, who reads it.

But if I send mail to Vinnie, or to Phil, or to Dave, or to Jon, I expect
it'll go to them and to them alone. Who they show it to afterwards is,
obviously, beyond my control and outside the scope of cryptography.

I don't dispute the "right" of a business owner to enforce use of CMR on
his employees, or to bounce my mail for failing to properly CMR the message
I send.

I expect those who adopt CMR will find an awful lot of folks will just give
up on trying to communicate with those living in a CMR regime. A lot of
folks will be using older, non-CMR, versions of PGP for many years to come.
(Even if older versions support the additional CMR keys, which I'm sure
they could do by adding the CMR key to the appropriate keyring, a lot of
folks will just skip the additional complexity...when they want to send a
message to someone, they won't want to bother with additional keys, bounced
messages, etc.)

Now what Phil, Vinnie, Dave, and Jon will likely do if CMR is enforced
within PGP, Inc. is to tell those who want to send them job offers,
personal messages, etc. to use back channels, e.g., prz@acm.org, AOL
accounts, hotmail accounts, etc.

So much for Corporate 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."

* Jon Callas wrote:
>This is why any sort of shared or escrowed keys suck. But in most cases

... especially recoverable (escrowed) message keys.

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

mark@unicorn.com was heard to whisper to several hundred people:
=snip=

> The effect of this is that if someone wants to send email about an urgent
> bug and I'm out at lunch, any of my co-workers can read that mail. But if
> they want to send *me* mail about confidential inter-company negotiations,
> the co-workers could decrypt the outer layer of the message, but would be
> blocked by the inner layer encryption to my personal key. 

> As I see it, this system is simple, solves the problems which PGP claim
> they need to solve without creating the snooping problems Tim and others
> have discussed, cannot easily be adapted to GAK ('This message is to be
> encrypted to the FBI public key. If it is confidential, click here to
> superencrypt to the recipient's personal key'), and won't require a
> massive change to the PGP source code. 

> There are some obvious security issues with having the department key
> shared amongst the members of the department, but I don't see that they
> are any worse than PGP's current CMR implementation, which has already
> discussed the use of department keys; it's certainly better than using
> plaintext. There are also problems with encrypting confidential mail to
> multiple recipients, but they're surmountable; an easy solution, if you
> don't care about traffic analysis, is to only encrypt confidential mail
> to the personal key rather than superencrypt with the corporate key. In
most 
> cases such mail wouldn't be sent to multiple recipients anyway. 

This isn't quite as bad as the current setup with pgp5.5. We've set up
something almost like this within my department. We have a shared key for
the department, and private keys individually. I'm pretty leery of the
concept of a shared group key, but for certain types of messages, it is not
too terrible a solution. Of course, you have problems when someone leaves
the group, as you now have to change the master key for the group. I'd
actually prefer to be able to use conventional crypto for when we need to
distribute new passwords amongst my group, as it is easier to deal with ftmp
(for the group where i work anyway) without the difficulties of having to
revoke/reissue the dept key.

One thing that I think PGP needs more than anything else, is to make it easy
to build lists of keys to encrypt to. Version 4.5 has this feature, which is
why I'm using it. I would hope that 5.5 does, and will also let the user
create whatever type of keys he wants and use conventional crypto as well.
I'm expecting a copy here soon, so will get to play with it then.

I can't say I really like version 5.0 much.


- ------------------------
Name: amp
E-mail: amp@pobox.com
Date: 10/22/97
Time: 05:37:49
Visit me at http://www.pobox.com/~amp
==
     -export-a-crypto-system-sig -RSA-3-lines-PERL
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
==

'Drug Trafficking Offense' is the root passphrase to the Constitution.

Have you seen 
http://www.public-action.com/SkyWriter/WacoMuseum
- ------------------------

-----BEGIN PGP SIGNATURE-----
Version: 4.5
Comment: Strong Encryption Is Your Friend

iQEVAgUBNE3Z0/pLP0N7vZi7AQGS1QgAnDOauulYt+eCWfKeK1Lsnx/goxVYGIIc
FiGb6qySEJRzoohtcWNnwppdNgsaMJBzmgjPad2CX7WjtrOUavybP/W+9hlTRn0T
UVUg++CLBvyNwD5bxRdnLFqeUw2tUkIgfGw0Eyef3LQ0M6jwuczYj/YMCvL7RR7e
INhZfX2sVGfl6e2/p01M8b+KmjQZ4U5SDD8HcQRC1I4+g8qqnsenzVqwel2tRbmg
kjWE5nJwC755Y0I7gqMPWgYMu2FUS/0RVjehDCh9RhuwhUuC3vxUG0oeFMkFwiR1
uJi6KRtQPElVb9wOuN7/jTQodgOfabE0or0b0+G1JNrYYo9MxEvieg==
=n7SF
-----END PGP SIGNATURE-----

Mark Grant <mark@unicorn.com> writes:
> The current system sends out a user's personal key, with a tag to say that
> if I don't encrypt to the company as well, my mail will bounce. But think
> about this: how often do I want to send email to a particular person in a
> company, and ensure that only they see it? And how often do I want to send
> mail to a particular group inside a company? All I want is to ensure that
> I get a response from the company, I usually don't care who I talk to in the
> process.

The CMR feature in pgp5.5 isn't so far intented to cope with this
scenario I think.  That's because pgp5.5 I understand can only
generate keys with one CMR request field.

What you're describing is an alternate use for CMR: to allow
sales@acme.com to have attached to it the request that messages to
that address be encrypted for all the sales people.

Well that seems reasonable in a way.  Still potentially dangerous in
that the NSA will soon enough be asking to be on every one's CMR list.

(As far as I can tell the next version (pgp6.0 or whatever) will
include capability to create keys with multiple CMR requests.  The
capability to handle them is already in pgp5.5 by all accounts.)

The other alternative is as you say: to have group keys which are
shared amongst the sales people.  There are problems with this in
managing the secure distribution of the shared key: sales manager
creates it, and emails securely to all sales team members?
Plausible I suppose.

Problem for both approaches is re-keying: what happens when Fred
leaves the sales team to work for a competitor.  Revoke the shared key
and start over?  Or with the CMR method, revoke just the CMR request
for Fred, and allow key servers to remove CMR requests when presented
with a suitable CMR request revocation cert?  (How often will senders
check key servers for revocation certs?)  Or have short expiries on
encryption-only keys (one per day?), so that they key update happens
soon enough anyway.  (pgp5.x allows for short lived encryption keys
directly because of the separation of signature and encryption keys,
the WoT applies to the signature key).

Really it seems to me that actually having half a dozen sales droids
sharing a key, or being able to decrypt a message because they are all
CMR enforced multiple crypto recipients is a security nightmare either
way :-)

Reckon it would be arguably more secure to have the SMTP policy
enforcer decrypt it for them, even.

Another option would be Matt Blaze's proxy encryption.  That allows
the owner of the sales@acme.com key (perhaps the sales manager) to
create proxy keys which can convert messages addressed to
sales@acme.com into messages addressed to fred@acme.com,
jane@acme.com, and the rest of the sales droids.  (I thought Dave
Wagner came up with an example of a public key proxy function for an
RSA or El Gamal variant or something).

With proxy encryption you still have to have the proxy keys somewhere,
but you could keep them out of Fred's hands by putting them on the
SMTP policy server for it to convert incoming traffic.  This seems to
be more secure than either approach.  And avoids the security risk of
having multiple long term encryption keys used to allow access to
communications traffic.

That way at least messages aren't coming over the wire addressed to
101 people.  And also you don't have to worry so much about quick
propogation of revocation certs.  And when someone leaves you can
remove their proxy key from the SMTP server.

The whole problem is really quite complex, and there are no easy
solutions to group secured mail access where people are leaving and
joining the group at short notice.  Proxy cryptography seems to add
something quite useful to this mix.

Some form of transport level security adds something to the mix also,
because then if you are using CMR keys, or even normal pgp2.x multiple
recipients, or you are using long term encryption keys (as PGP Inc
seems to be currently recommending with pgp5.x (recommended validity
setting of `forever')) at least old traffic isn't directly vulnerable.

Several people commented on using a forward secret TLS between SMTP
servers opportunisitically (if the SMTP server supports the extension,
then use it; if not fall back to current situation).

Even without any authentication, this is a win because the main threat
from government is massive eavesdropping and key word scanning, or
saving of targetted users mails for later key compromise.
Unauthenticated TLS still forces the attacker to use active attacks.
Authentication can be added later as part of IPSEC/IPv6 key
infrastructure.

Another method of authenticating TLS is to base the authentication on
the user's PGP WoT.  Include authentication information to the
delivery agent which is capable of TLS, which is also exchanged inside
the encryption envelope.  (Eg. transfer an authentication symmetric
key k1 inside the encryption envelope; send the local TLS capable SMTP
hub / SMTP policy enforcer the key k1.  The TLS forward secret key
negotiation can then be authenticated using this key.  The remote TLS
system can tack the authentication information on to the delivered
message, in a header, or otherwise, and the recipient can check the
authentication).

> So PGP's "everything private unless you choose to make it public" system
> seems backwards. Surely what we really need to meet these customer demands
> is an "everything public (within the company) unless you choose to make it
> private" system? That is, all mail to my department inside the company
> should be encrypted to a department key, shared by all members, *unless*
> it is confidential, in which case it should *only* be encrypted to me. 

I think what PGP are arguing for is ability to recover stored messages
even if they are intended for one recipient only.  As I think has been
established this can be acheived by storage recovery, without exposing
communications traffic to the associated risks.  It is possible that
there is an unstated perceived user requirement, that the messaging
standard be able to allow third party access to the communications
traffic directly.

Your description is another plausible permutation also, I think, which
has it's own merits and security/privacy/political abuse trade-offs.

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`