Mark Grant <mark(_at_)unicorn(_dot_)com> writes:
I have no great problem with defining the neccesary flags and tags
as 'implementation defined' so that non-CMR applications won't barf
when they see them, but I certainly do not want to have to build
snoopware into my applications in order to comply with the standard.
Another option is to define in the standard correct behaviour for
personal use software on receipt of ARR requests is to fill them in
with random numbers as Bodo Moeller described.
I can't see this worrying PGP Inc as they like to describe how easy it
is to bypass anyway.
This just makes the semantics that ARR is a `request' as the name
suggests.
And that the sender has the choice either to comply or not with that
request.
(Where not complying is filling random numbers in the requested
extra crypto recipient.)
The purpose of this group is to provide a strong message encryption
standard.
Good; so let's create that standard and leave snoopware, message
recovery and key escrow to individual implementors.
Sounds good to me.
I think that having multiple long term keys (up to 4 with pgp5.5!)
able to decrypt messages transmitted over open communications channels
is an unnecessary security risk.
William stated that the discussion should be kept apolitical -- the
CMR security risk is apolitical to the extent that the parties who
might try to exploit the added CMR risks could be anyone: corporate
espionage, disgruntled ex-employee, French secret service (long
history of corporate espionage giving info to French competitors to US
and other companies), etc.
The point is why bother incurring the security risks, when there are
simpler and more secure alternatives?
I repeat: I'd like to see those who want CMR justify why they think it
is necessary that it should go in the standard.
Adam