Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)
draft-ietf-pkix-cmp-transport-protocols-20

Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:

I agree with Brian Haberman's comments #3 and #4.  On #3: there is a short note in the Security Considerations about using 301 Moved Permanently, but, in general, this should say more about the security implications of using HTTP redirection.  Otherwise, "careful consideration of possible security implications" isn't likely.  On #4, I think you either need to remove the section or explain it quite a bit better.


========
Other comments; no need to respond to these:

A note to the doc shepherd: Thank you for being clear about the low level of WG interest in the document and the reasons for publishing it despite that.  Too often, shepherd writeups try to give what they think are "the right answers", rather than the true and accurate ones.

A note on Brian Haberman's comment #1: In contrast, I think the "history" in the introduction is useful.  After reading Brian's comment I considered each paragraph for removal or abridgment, and found that each one was useful in explaining why the document is making the choices it's making and going in the direction it's going.

I have no issues with the publication of this document.  I only have some non-blocking comments:

1. Part of the Introduction sounds more like a history lesson and does not bolster the content of the document.  I would suggest paring it down and focusing on introducing the functionality.

2. Terms like "PKIMessage" and "DER-encoded" are not defined anywhere before they are used.

3. The 2nd paragraph of section 3.3 seems incomplete.  It would be useful if some example security implications were discussed.

4. What purpose does section 4 serve?  Are there interoperability functions that could be described?  I would suggest providing guidance on how the potential interactions can be handled.

5. While I appreciate the impact of having unresponsive authors, I don't think the explanatory text in section 7 (paragraph 1) is needed.  Simply list those people as previously contributing authors.

Thanks for addresing my points and only this agreed change didn't make it in the -20 version:


> Section 3.7., paragraph 1: 
************************************
In that case the CMP server is acting as an HTTP client.  Does it make it clear when I add a sentence explaining that:

OLD:
   A CMP server may create event-triggered announcements or generate
   them on a regular basis.  It MAY utilize HTTP transport to convey
   them to a suitable recipient.  As no request messages are specified
   for those announcements they can only be pushed to the recipient.

NEW:
   A CMP server may create event-triggered announcements or generate
   them on a regular basis.  It MAY utilize HTTP transport to convey
   them to a suitable recipient.  In this use case the CMP server acts
   as an HTTP client and the recipient needs to utilize an HTTP server.
   As no request messages are specified

In 3.8:

   While implementations MAY make use of all defined features of the
   HTTP protocol, they SHOULD keep the protocol utilization as simple as
   possible.

I find this potentially confusing. If the directive to implementers is that they are allowed to use (and therefore the other side needs to be aware of) all defined HTTP features, the MAY should be uppercased and the SHOULD should not. If the directive to implementers is that they SHOULD keep the protocol use simple, then the first part of the sentence is at best confusing. If the latter is the intent, try:

   While all defined features of the HTTP protocol are available to
   implementations, they SHOULD keep the protocol utilization
   as simple as possible.

cleared my DISCUSS