Transport Layer Security (TLS) Authorization Using KeyNote
Note: This ballot was opened for revision 07 and is now closed.
(Tim Polk) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Lars Eggert) No Objection
(Adrian Farrel) No Objection
(Russ Housley) No Objection
Alexey Melnikov (was Discuss) No Objection
By mistake I made my comments a DISCUSS. I just now realized that this is an Independent Submission through RFC Editor, so my comments can't be blocking. This is a bit trivial, but I think the following issues should be fixed before the document is approved for publication (Apart from these 2 issues, I have no objections to the publication of this document.): 3. KeyNote Credential Assertion List URL Implementations that support keynote_assertion_list_url MUST support URLs that employ the http scheme [UPGRADE]. where [UPGRADE] is defined as: [UPGRADE] Khare, R., and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. I don't believe this is the correct reference here. If you truly meant "http", then you should use RFC 2616 here. If you meant "https", then RFC 2818 is the correct reference. I believe the following 2 references are Normative, as they are needed to implement this spec: 7. Informative References [KEYNOTE] Blaze, M., Feigenbaum, J., Ioannidis, J., and A. Keromytis, "The KeyNote Trust-Management System, Version 2", RFC 2704, September 1999. [AUTHZ] Brown, M., and R. Housley, "Transport Layer Security (TLS) Authorization Extensions", RFC 5878, May 2010 1. Introduction A list of KeyNote credentials (e.g., forming a delegation chain) may be sent as part of the same payload. Alternatively, a URL RFC 3986 should be sited here (as an Informative reference). pointing to the location of such a list of KeyNote credentials may be provided.