Transport Layer Security (TLS) Authorization Using KeyNote
draft-keromytis-tls-authz-keynote-07

[Ballot comment]
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.

[Ballot discuss]
Section 3 states:

  Implementations that support keynote_assertion_list_url MUST
  support URLs that employ the http scheme [UPGRADE].

Does this mean that the KeyNote credential assertion MUST be retrieved
only if HTTPS or HTTP-TLS is used and MUST NOT be retrieved if only
unencrypted HTTP is available? This needs to be clarified.

[Ballot comment]
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.

[Ballot discuss]
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

[Ballot comment]
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.

[Ballot discuss]
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

IANA comments:

IANA understands that there are two actions that need to be completed
upon approval of this document.

First, in the TLS Authorization Data Formats registry located at:
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
the following entry will be added

Value Description Reference
===== --======================= ===============
TBD keynote_assertion_list TBD

The value will be selected from the Specification Required range (64-223).


Second, also in the TLS Authorization Data Formats registry located at:
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
the following entry will be added

Value Description Reference
===== --======================= ===============
TBD keynote_assertion_list_url TBD

The value will be selected from the Specification Required range (64-223).


IANA understands that these are the only actions required upon approval
of the document.