Jon Callas <jon@pgp.com> 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`