Well, those are clearly relevant prior uses.
It seems to me that this sort of publication in practice does not help the
implementors understand the problem or the lack of recommendation.
But its up to you two, not mee.
Yours,
Joel
At 06:12 PM 1/15/2006, Russ Housley wrote:
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
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
