- From: Andreas Kuckartz <A.Kuckartz@ping.de>
- Date: 11 Feb 2013 11:34:40 +0100
- To: "Glenn Adams" <glenn@skynav.com>
- Cc: "Henri Sivonen" <hsivonen@iki.fi>, "Mark Watson" <watsonm@netflix.com>, "public-html-admin@w3.org" <public-html-admin@w3.org>
Glenn Adams:
> If so, then would you place the same restriction on implementations of TLS,
> which already supports extensible key and bulk encryption systems [1]?
>
> [1] http://www.rfc-editor.org/rfc/rfc5246.txt
>From that document, please note the order of priority:
---
The goals of the TLS protocol, in order of priority, are as follows:
1. Cryptographic security: TLS should be used to establish a secure
connection between two parties.
2. Interoperability: Independent programmers should be able to
develop applications utilizing TLS that can successfully exchange
cryptographic parameters without knowledge of one another's code.
3. Extensibility: TLS seeks to provide a framework into which new
public key and bulk encryption methods can be incorporated as
necessary. This will also accomplish two sub-goals: preventing
the need to create a new protocol (and risking the introduction of
possible new weaknesses) and avoiding the need to implement an
entire new security library.
4. Relative efficiency: Cryptographic operations tend to be highly
CPU intensive, particularly public key operations. For this
reason, the TLS protocol has incorporated an optional session
caching scheme to reduce the number of connections that need to be
established from scratch. Additionally, care has been taken to
reduce network activity.
---
Cheers,
Andreas
Received on Monday, 11 February 2013 15:58:12 UTC