Hal Finney <hal@rain.org> writes:
Adam Back writes:
I would be nice to see the topic of the recipient refusing email based on policies relating to third party access to messages in transit being addressed in the standard when and if PGP gets to that stage.
[ecash processing]
This is a good example of a possible future kind of key assertion. Are you confident that you can decide which kinds of recipient refusal are morally correct and which kinds are not?
Not automatically, no, I doubt it would work.
Is it the role of the IETF and the Open-PGP process to make this determination? I would say not. Rather, we should standardize data structures and conventions which allow people to express those conditions and assertions which are useful to them.
Yes. I agree.
There are a whole range of possible assertions which you might object to:
[examples of PolicyMaker style policies]
You can take these case by case and decide for yourself whether each one is acceptable or not by your own standards. But I don't think it's going to be possible to come up with a set of objective rules which will decide whether any given assertion is allowed.
Fundamentally, you are asking to make it illegal for a key to request encryption to an additional recipient. That's what it comes down to. You want to forbid this class of assertions.
Yes. I was getting carried away. It would be too complex, most likely. The thrust of your argument seems to be that there would be little use making pgp 5.5 non-GAK compliant, because PolicyMaker style statements will be so flexible that they will be GAK compliant anyway. So, when are PGP starting work on PolicyMaker? Is it intended to introduce this functionality in this first round standardisation? It seems to me that adding PolicyMaker functionality could take some considerable time due to the huge complexity of the task. Also, just because GAK compliance will become possible if and when PolicyMaker style extensions are implemented, doesn't mean that PGP can expect popular support for actually going ahead and implementing GAK compliancy in pgp5.5; nor can it expect to gain popular support for the uncharacteristic big brotherish mentality displayed by those working at PGP in implementing the SMTP policy enforcer behind closed doors to enforce other people to modify their behaviour to honour third parties GAK or CAK requests. I think the whole thing is a huge PR fluff up. I'm suprised that those at PGP were all able to agree to do it without arguments being expressed by employees, and without those arguments leaking out of the company (given the picture Jon Callas painted of strong privacy and freedom biases at PGP). If there had been open discussion of the product's design prior to development, this feed back could have been obtained earlier. I presume the PGP PR person (who ought to get the sack in my opinion) thought that a sudden press release of such marvelous new feature as PGP snoopware and a snoopware enforcer for third parties would go down well. It doesn't. The enforcer is rudely enforcing the companise opinions on people who have no connection with the companies snoopware policies. You should keep such matters within the company by using escrowed storage keys to acheive snoopware. For these reasons I still argue that we should: - add storage keys to the standard It's more secure to do this. That should be argument enough in itself. It also is much cleaner separating key functionality out into separate keys where those keys have vastly different recovery, life time, and security requirements. - use storage key escrow to implement PGP snoopware instead of burdening the OpenPGP standard with the stigma of GAK compliancy This method ties in with the use of storage keys. It is nearly as effective a snoopware design. It also isn't GAK compliant. It also doesn't result in cypherpunks shouting at you. - don't use the special sub-packet type to flag GAK compliancy I think the above shows that the neither the standard, nor PGP Inc needs the GAK compliant sub-packet, so scrap it, and save the argument up for the much more defensible position of a generalised PolicyMaker style key usage restriction assertions - scrap the controversial SMTP snoopware policy enforcement app Use storage key escrow to implement PGP snoopware instead of burdening the OpenPGP standard with the stigma of GAK compliancy It's difficult to get standards which don't reflect big brotherish aims when the good reputation of PGP Inc and Phil Zimmermann is apparently behind it. Something weird is going on at PGP headquarters. PRZ is also silent. Are all the people at PGP Inc in accord in thinking that the snoopware policy enforcer is a really cool pro-privacy app? Some of the usually more vocal PGPers have remained silent throughout the entire episode. Also as Tim note's the lack of a Zimmermann Telegram (tm) getting suspiciously overdue. Is he dragging his feet of snoopware and GAK compliancy? Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`