Subject: [apps-discuss] APPSDIR review of draft-ietf-pkix-cmp-transport-protocols

From: Mark Nottingham <[email-masked]>
Date: Mon, 5 Mar 2012 14:25:37 +1100

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see  <http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate>).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-pkix-cmp-transport-protocols-16
Title: Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP
Reviewer: Mark Nottingham
Review Date: March 4, 2012

Summary: This draft is not ready for publication as a Proposed Standard and should be revised before publication.

Major Issues: 

* This draft describes a HTTP-based protocol that exclusively uses POST; i.e., it effectively tunnels.

This is widely recognised as bad practice, and should be avoided where possible. A good use of HTTP is one that defines resources with particular behaviours, formats with associated semantics, and then uses links to navigate / manipulate the state of the application. GET should be used for retrieval (it's not even clear if it's allowed / used in this draft).

Preferably, the draft should be re-worked to use HTTP well, rather than tunnelling. 

Alternatively, there should be a notice inserted that explains this draft is tunnelling over HTTP, and this practice should not be emulated.

Minor Issues:

* Section 3.1 "HTTP Versions" - the wording here doesn't reflect how HTTP versioning works; see RFC2145. Suggest: "Clients MUST support HTTP/1.0 [RFC1945], and SHOULD support HTTP/1.1 [RFC2616]."

* Section 3.2 "Persistent Connections" effectively re-specifies part of HTTP; this section should be removed.

* Section 3.6 "HTTP Request-URI" -- What does "depicting a directly" mean? HTTP and URIs say nothing about directories.

* Section 3.8 "HTTP Considerations" -- Pragma: no-cache is not meaningful in responses, and shouldn't be limited to just HTTP/1.0, as versioning is hop-by-hop, not end-to-end. In any case, this paragraph can be dropped, because POST isn't cacheable by default, and is never cached in practice.

* Section 3.8 "HTTP Considerations" -- The paragraphs on connection management and content-codings are re-specifying HTTP, and should be removed.

* Section 9 "Security Considerations" #2 -- "There is no security at the HTTP protocol level" is a gross misstatement.

* Section 9 "Security Considerations" #2 -- "The client SHOULD NOT support the "301 Moved Permanently status code" is ambiguous. Do you mean that it should never be followed, or that it should not be stored as a permanent redirect? A statement merely warning of the effects of a MITM would be more useful here.

--
Mark Nottingham   http://www.mnot.net/