Brian:
I support progress as Informational RFC. This is the approach that
has been used in other Security Area WGs when the IPR status of the
algorithm is unclear or unfavorable.
RFC 3278 is an example. This document also deals with ECC, and it
was produced by the S/MIME WG.
RFC 3058 is another example. This document also deals with IDEA,
which is clearly covered by a patent.
The idea is to document use of these algorithms in the context of a
particular protocol to permit interoperability between any parties
that choose to implement them. However, the IETF is not advocating
their implementation by keeping them off of the standards track.
Russ
At 10:10 AM 1/15/2006, Joel M. Halpern wrote:
This document is not quite ready for publication as an informational RFC.
My concern is the status of the document. It is normal for Cipher
Suites (algorithm definitions) to be informational RFCs. I have no
argument with that.
However, this document is not an algorithm definition.
Rather, it is the definition of a set of TLS extensions and the
format of the information in those TLS extensions.
As such, it is a definition for bits on a wire, not for a
computational algorithm.
(I was curious to see how the algorithm would be described, having
only seen exponential algorithms described in RFCs before. The
algorithm is not described in this document.)
Note: I will take as given that the descriptions of enums and
structures here is sufficient that in conjunction with the base TLS
documents and the extension description document an implementor can
determine how to form the proper messages. The description
consisting of the words "structure of the message" followed by the
definition of an enum (to be used somewhere?) followed sometimes by
a struct defintion (presumably to be included in a message
somewhere, with some context identifier, if the values of the enum
are used somewhere?) is not clear to one who is not immersed in TLS
extension work. (Presumably, this definition structure is used
because giving the rest of the information would be both long and duplicative.)
I also presume that the definition of the lagnuage used for the
structure definition, and the mapping of that definition to bits on
the wire, is included in the TLS extensions document?
nit: idnits notes that the Copyright statement is not verbatim as specified.
Yours,
Joel M. Halpern
----
SEC ECC Cipher Suites for TLS (Informational) - 3 of 4
<http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-12.txt>draft-ietf-tls-ecc-12.txt
Note: Proto shepherd is Eric Rescorla <[EMAIL PROTECTED]>.
Token: <mailto:[EMAIL PROTECTED]>Russ Housley
Reviewer: Joel Halpern
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
