Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1
draft-nystrom-ct-kip-02

[Ballot discuss]
The discussion of the HTTP 1.1 binding has a number of issues.  The cache-control header description, for example, says:

o  If the value of the Cache-Control header field is not set to no-
      store, then the CT-KIP server must not include the Cache-Control
      header field in the response.

  o  If a Cache-Control header field with a value of no-store does not
      disable the Expires response header field, then the Expires field
      should not be included.

I believe that the first bullet means to say "Always include a cache-control directive with no-store as its value", but the wording is odd; it seems that the second means "Omit the expires header, unless the cache-control header is missing".  If that is the case, what is the expected setting when cache-control is missing?  This does ignore the case of an HTTP 1.0 proxy in-between the client and server, but this does not seem likely in this case (adding a pragma: no-cache would otherwise be necessary). 

The draft says:

    No support for HTTP/1.1 authentication is assumed.

Does this just mean that any HTTP/1.1 authentication is not part of the CT-KIP mapping?

The "initialization message" in 4.2.7 (and in the example in 4.2.8) do not mention or reflect a client POST, as 4.2.4 indicates.

The draft says:

  In all other cases, the CT-KIP HTTP responder must respond with 200
  (OK) and a suitable CT-KIP message (possibly with CT-KIP-related
  error information) in the HTTP body.

Does this mean that the CT-KIP message can take the place of the 3xx series of messages?



The examples use non-standard domain names ("tokens-r-us.com").

[Ballot comment]
Points from Gen-ART review by Eric Gray that could
usefully be clarified:

In section 3.7.1 - you say:

"The XML format for CT-KIP messages have been designed to be
extensible.  However, it is possible that the use of extensions will
harm interoperability and therefore any use of extensions should be
carefully considered."

Can we say anything about what "harm interoperability" or "carefully
considered" means?  What are the risks?  How can they be avoided?
Is there a reference you can point to that talks about the issues?

---------------------------------------------------------------------

In section 3.8.6 (CT-KIP server's second PDU), on pages 27 and 28,
I am having trouble matching message fields (shown on page 27) with
descriptions (given on pages 27 and 28).

---------------------------------------------------------------------

NITs:
----

In section 5.2.1, the last sentence would be better worded as:

"Sections 5.2.2 through 5.2.7 analyze these attack scenarios."

---------------------------------------------------------------------

In section 6 (IANA Considerations), you say:

"None at this point; the MIME type is already registered."

The document mentions several MIME types.  I assume you meant:
"application/vnd.otps.ct-kip+xml" in this case (as opposed to
- for instance - "image/jpeg" or "image/gif").

I would change the section to read either -

"None at this point; the MIME type (section 4.2.2) is already
registered."

OR

"IANA has no action with respect to this document."

[Ballot discuss]
Abstract:
  This document represents a republication of CT-KIP Version 1.0 from
  RSA Laboratories' One-Time Password Specifications (OTPS) series, and
  change control is retained within the OTPS process.

To my understanding this note has no impact on having the OTPS maintain change controll over their specification. The primary way of achieving that for them would have been to include Statement a in section 5.2 of RFC 3978:

  a. "This document may not be modified, and derivative works of it may
      not be created, except to publish it as an RFC and to translate it
      into languages other than English."

There is need for some clarification on this issue. If it is intended that OTPS should maintain change control the correct statement needs to be included. If that can be fixed with RFC-editor note or not I don't know.


7.  Intellectual property considerations

  RSA Security has filed an IETF IPR Disclosure for IPR related to this
  document.  The IETF IPR Disclosure number is 714 and it can be found
  at the IETF IPR Disclosure page.  RSA Security makes no
  representations regarding intellectual property claims by other
  parties.  Such determination is the responsibility of the user.

  RSA, RSA Security and SecurID are registered trademarks or trademarks
  of RSA Security Inc. in the United States and/or other countries.
  The names of other products and services mentioned may be the
  trademarks of their respective owners.

This section is included contrary to Section 11 of RFC 3979 (BCP 79).