Re: Openness, change control, future protocol revisions

Dennis Glatting writes:

[should an API be in the TLS standard?]
> 
> The CAT WG developed and maintains the Generic Security
> Service API (GSS-API). I have written more than one
> implementation of the GSS-API and I participate in the
> CAT WG. (Oh, BTW, I don't speak for my employer. :)) The
> GSS-API can be considered a success, a failure, or
> mediocre, depending on your point of view.

[..]

> Certainly we can argue forever in the day the points of an
> IETF sponsored API. We can do the same for a protocol too.
> I'm not convinced there is a difference between an API
> standard and a protocol standard. The market is looking
> for both.

While I think that an API standard might be useful, I'd like to
see it done as another RFC, or some sort of supplimentary RFC to
the eventual TLS one.  I think that the TLS standard should be
as simple as possible given reasonable flexibilty and the
inherent complexity of cryptographic protocols.   Simple standards
are the ones that get implemented; complex ones get printed out
and thrown in the back corners of people's offices, never again
to see the light of day.  Complex standards also take longer to
become standards, and I'd hate for the TLS process to take so long
that it winds up becoming irrelevant.


-- 
Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF

Received on Saturday, 11 May 1996 07:39:36 UTC