- From: David P. Kemp <dpkemp@missi.ncsc.mil>
- Date: Tue, 17 Dec 1996 10:47:54 -0500
- To: ietf-tls@w3.org
> >
> >I believe it, but is there an RFC one can quote to reference these
> >guidelines?
>
> I don't know. I was previously advised that RC2 and RC4 were OK, as long as
> there were alternatives, but that Fortezza was right out. I'm going to go
> and check with Jeff Schiller.
RFC 2026 is the current description of the Internet Standards Process.
The POISSON working group also plans to have new drafts out sometime
around Memphis.
One applicable paragraph from RFC 2026:
10.2 Confidentiality Obligations
No contribution that is subject to any requirement of confidentiality
or any restriction on its dissemination may be considered in any part
of the Internet Standards Process, and there must be no assumption of
any confidentiality obligation with respect to any such contribution.
As far as I know, RSA still claims that RC2 and RC4 are trade secrets.
The TLS draft states that there is no published reference for the
algorithms. I disagree that it's OK for a standards track document
to include algorithms for which one has to purchase a sole source
implementation, but it certainly seems OK to document how to use
them with TLS, as long as it's done in a separate non-standards-track
document.
It would be ideal to have documentation of additional algorithms for
use with TLS, both publicly available (Blowfish, SAFER SK-128, etc)
and proprietary, patented, unpublished, or otherwise encumbered
(IDEA, RC2, RC4, Fortezza, etc) and let market demand, performance,
quality of protection, and cost decide what gets implemented in
Netscape, MSIE, and SSLeay-based products.
But the standard, mandatory-to-implement, universally-interoperable
algorithm cannot be proprietary. It's always helpful to remember
that this working group is not rubber-stamping an existing
implementation, it's defining a specification based on both best
existing practice and new requirements.
dpk
Received on Tuesday, 17 December 1996 10:48:56 UTC