Ian Miller <Ian_Miller(_at_)bifroest(_dot_)demon(_dot_)co(_dot_)uk> writes:
Adam Back <aba(_at_)dcs(_dot_)ex(_dot_)ac(_dot_)uk> wrote:-
Specific questions relating to the standard are perhaps:
- Are the certificate flags informing the recipient that
communications to a key is escrowed, and that email which is not
encrypted to the escrow key will be bounced expected to be part of the
Open PGP standard.
In my view there is absolutely NO point it attempting to prescribe what
applications may or may not do beyond inter-operatability. You may have
recommendations for what users should demand and accept, but you shouldn't
be attempting to enforce those views on users or application writers.
That's one point of view I suppose.
Hopefully I can convince you and others who hold this view of the
inherent security weakness in implementing message snooping in the way
that PGP have, and that we can then not accept the options PGP will be
shortly arguing for, for security reasons.
We have to ensure interoperability, but I think beyond
interoperability we also have the question of security. We should
consider security, or at least include MAY options allowing people to
opt for higher security usage where a case can be made for the
important security advantages for these.
Also a question is: interoperability with _what_? With other
conforming implementations right? What about interoperability between
conforming implementations, and a PGP system including features which
PGP Inc has implemented outside the standardisation process (GAK
compliance fields and SMTP GAK compliance enforcer currently).
- Can a conforming application ignore the key escrow flags?
Yes, but if the recipient's company runs PGPInc.'s screening SMTP server
you need an envelope that at least appears to be encrypted to the escrowed
key.
There are two approachs:-
1) Automatically double encrypt. Provide a escrow key access only
to the outer layer of encryption.
2) Include a PKE packet for the escrow key containing the wrong value as
session key.
I don't think that IETF should say which of the available options
that application should present to the user. However any software I
write will include options for humouring escrow arrangements without
leaking information whereever this is possible.
That suggestion has some merit, and some poetic justice :-)
But, while I agree with your sentiments in saying that you will
implement a hacked form of GAK compliance entirely, can we call this
"compliant"? If the OpenPGP standard simultaneously accepts the
semantics of the flags which PGP Inc give for informing the user that
snoopware is in use, and the second flag which PGP would presumably
defined to inform the user that the message will bounce?
Is it therefore conforming to do as you say, and instead of informing
the use that the message will bounce if they don't use the GAK
compliancy, to display a message saying:
"the person you are sending to works for a company which has
PGP snoopware, but don't worry about it, we've hacked around it"
If we can keep that it's a start at least, as a competitor who is
pro-privacy, even if PGP is no longer, can cater for pro-privacy
individuals. And to the extent that this competitor is successful,
that portion of the market won't have automatic GAK compliancy.
If PGP does achieve netscape type market domination (as I'm sure
they'd love to), well your hacked implementation won't make much
difference, other that you are allowed to call it "conforming".
Put another way, you could hack your implementation even if the
OpenPGP standard defined that you couldn't call it "conforming" for
all the difference it's likely to make.
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(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`