I don't see an IPR disclosure against this draft (not even a 3rd party
one). I take it that the concern is related to the disclosure at
http://www.ietf.org/ietf/IPR/CERTICOM-IPSEC-ECC ?
As Russ said, there are precedents for this way to deal with
IPR - in fact if we have failed to get an IPR disclosure offering
at least RAND conditions we don't actually have any other solution
except not publishing at all.
Brian
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
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
