[TLS] Review of draft-ietf-tls-rfc4366-bis-02
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[TLS] Review of draft-ietf-tls-rfc4366-bis-02
1. Abstract should be updated
It should point to the TLS 1.2 RFC. Perhaps it should also include a
list of extensions defined in the document.
2. We lost the list of extension types defined in this document, this is
not is RFC4346bis, so we should add some text back around
In section 1.1 we should add:
"
The extension types defined in this document are:
enum {
server_name(0), max_fragment_length(1),
client_certificate_url(2), trusted_ca_keys(3),
truncated_hmac(4), status_request(5), (65535)
} ExtensionType;
"
3. Section 3
The first paragraph after the structure and the seventh paragraph after
the structure are essentially the same, one should be removed.
4. Section 4
Pending working group discussion, the certificate hash may be made
mandatory.
Also the MIME type pkix-pkipath is not defined in 4346-bis so the
references need to be fixed. Perhaps the MIME type registration
information should be included in an appendix.
5. Section 9
The text describing the new alerts has been moved into its respective
sections. It would be good to either to provide a pointer to the
sections where the alert is defined or to add the definitions into this
section as well.
6. Section 10
IANA should be explicitly requested to re-parent the extensions
registered by RFC 4366 to this document.
Issue 99 - http://trac.tools.ietf.org/wg/tls/trac/ticket/99
7. Section 11.1
The server name extension no longer allows internationalized names so
the considerations around this can be removed.
8. Section 11.3
This may need to be updated based on the resolution of mandatory hash in
certificate URL
9. Additional editorial comments
Issue 98 - http://trac.tools.ietf.org/wg/tls/trac/ticket/98 - provides
additional editorial comments.
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.