- From: Rodney Thayer <rodney@sabletech.com>
- Date: Wed, 26 Jun 1996 07:02:43 -0400
- To: ietf-tls@w3.org
- Cc: rodney@sabletech.com
I would like to make a suggestion on how we might approach the conflicting goals of quick-time-to-market and using a standards process to develop a standard. Here's my idea: 1. take the SSL3 spec, as-s plus errata, and make that a "best current practice" or "informational" RFC. This would produce the following: - it would get something out IMMEDIATELY which would satisfy the vendors that are sqeaking about quick results - it would document throught the IETF RFC process the current protocol - it would require (relatively) little work, since only the editing for RFC formatting rules would have to be done. Note that since there are said to be 8 known current implementation we could ask those 8 implementors to review the doc and that we we'd know that this document really is best current practice. 2. follow a more conventional standards process to develop a TLS standard, rather than simply running as fast as possible to get "SSL3.0bis" which is what seems to be happening now. By a more conventional process I mean: - develop a set of requirements (for example enumerating interests in non-web applications, pre-encryption, specific crypto options, passwords, etc.) - develop an architecture (i.e. decide and document how this would relate to key management schemes, public key infrastructure schemes, ipsec, ppp sec, etc.) - develop a protocol. This would take a while. However, since a bunch of smart people put a lot of work into SSL3, SSH, PCT, etc. I think there is a fair chance that what comes out the other end will look a lot like the current protocols. Rodney Thayer :: rodney@sabletech.com Sable Technology Corp :: +1 617 332 7292 246 Walnut St :: Fax: +1 617 332 7970 Newton MA 02160 USA :: http://www.shore.net/~sable "Developers of communications software"
Received on Wednesday, 26 June 1996 07:03:11 UTC