[Standards-JIG] Re: The Great Encryption Debate
ian.paterson at clientside.co.uk
Mon Aug 8 15:08:28 UTC 2005
Hi Nolan, thanks for your input.
> I was wondering if the requirement some businesses and industries
> for logging emails and IMs is being taken into account?
Yes, in a limited way.
Before explaining I should say: the point of e2e is that you don't trust
the server(s). Enabling server-side logging of messages is a non-goal of
However, the working version of the JEP (to be published in the next day
or two) makes encryption optional. So corporations with full disclosure
requirements can still take advantage of the e2e authentication and
non-tampering. You can see the latest version here:
> Can any of the proposals meet this requirement?
> I'm sure some exec will be asking for it.
Good point. I'm sure many execs will...
Where logging of messages is necessary, the corporation may configure
its server to only start encrypted c2s and s2s streams (as specified in
RFC 3920). Where Bob is using an external server, the corporate employee
Alice could use a to-be-defined JEP-0155 field to confirm with Bob that
his connection to his server is secure and that he trusts his server.
(This approach is enabled by JEP-0116's authentication and non-tampering
features mentioned above.)
> With the e2e RFC, PGP, and other straight forward PK crypto
S/MIME and PGP only appear to be "straight forward" because
implementations already exist.
*If/when* a library for something like JEP-0116 is implemented it will
appear far more straight forward because it will have been designed
specifically for IM clients.
The S/MIME (e2e RFC) and PGP protocols were not designed for IM and
consequently are not easily adapted to the needs of IM. They also offer
significantly reduced security (no Perfect Forward Secrecy, inelegant
More information about the Standards