Document: draft-lee-tls-seed-01.txt
Title: "Addition of SEED Ciphersuites to Transport Layer Security (TLS)"
Intended Status: Proposed Standard
Reviewer: Suzanne Woolf
Review Date: 16 February 2004
New item


This is pretty brief but I think that means it's doing something that
should be pretty simple-- if the framework is well-defined, it's easy
to add new algorithms and options.

A couple of reservations:

1) A web page is included as a normative reference. I'm not sure
that's legal.

2) Two drafts are included as references. One is now an RFC and should
maybe be normative. (? If I'm reading this correctly, the KISA web
page is the normative reference to the protocol, but the new RFC,
referred to here as a draft, isn't.) The other draft, on SMIME
applicability for SSED, isn't published yet. But that's an RFC-Editor
issue more than a substantive one.

3) "IANA Considerations" asserts there are none because there is no
registry for TLS-related numbers. However, numbering new algorithms is
one of the classic reasons for creating a new registry. Is that
appropriate here?

4) A scarcity of MUSTs and MAYs and SHOULDs for Standards track. Are
there variants on SEED, factor size choices to make, etc. that
implementors should know about? This is probably covered by the SEED
RFCs (protocol and applicability) that were just published but perhaps
should be noted as specifically applicable to TLS.

The last point (more guidance for implementors) seems like the most
substantive one and I suggest someone with more knowledge specifically
of SEED than I have consider the question. 

Otherwise, I think this is ready to advance.