- 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