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

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

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

[Ballot discuss]
There is significant confusion in terminology in this document, with "transport" used in cases where we would normally use "transfer" to be more clear and consistent with the existing body of RFCs.  HTTP is a transfer protocol; TCP is a transport protocol.  If the document was scrubbed to fix this terminology, I would have no problem with it going forward.

[Ballot discuss]
(1) Today, using HTTP/TLS is not hard. If CMP messages are
visible over a public network, then there may be a number of
high-level DoS-type attacks possible, e.g. bad-guy sees a
certification request for example.com and knows that that will
take ~1 day to process so bad-guy goes to another (not so
careful) CA and get a cert for example.com denying service to
the correct example.com and damaging the CA to whom the
original certification request was directed. On this basis, I
think this document really needs to make use of HTTP/TLS a
MUST-use messages go over any untrusted network, and hence TLS
would need to be mandatory-to-implement. I'd also say that
IPsec isn't really very relevant here (but would work fine), so
I'd suggest that the spec be changed along the lines of:

OLD:

  "Therefore users of the HTTP transport for CMP might want to
  consider using HTTP over TLS according to [RFC2818] or
  virtual private networks created e.g. by utilizing Internet
  Protocol Security according to [RFC4301]."

NEW:

  "HTTP over TLS [RFC2818] MUST be supported by all nodes
  implementing this protocol.  TLS with strong confidentiality
  SHOULD be used in all cases, with the only exception being
  when CMP messages are sent over fully trusted networks,
  which doesn't happen very often."


(2) How is RFC 1945 a MUST but not a normative reference and is
that then a downref? Is http/1.0 *really* needed as a MUST
these days? I'd say s/MUST support/might support/ for http/1.0
and leave 1945 as an informative reference and avoid the
messing with new last calls etc.

[Ballot comment]

3.3 - is the 200 vs 201/202 point here consistent, seems like
not. 3.5 also seems to say what's needed and better, so I'd
suggest deleting 3.3 entirely

3.3 - what are the 3xx "security implications"? Either 4210 is
ok or not, so I'm really not sure what's meant here.

[Ballot discuss]
Section 1., paragraph 4:

>    Before this document was published as an RFC, the draft version
>    underwent drastic changes during the long-lasting work process.  The
>    "TCP-Based Management Protocol" was enhanced and a TCP-Messages-over-
>    HTTP transport specification appeared.  As both proved to be needless
>    and cumbersome, implementers preferred to use plain HTTP transport
>    following [RFC1945] or [RFC2616].  This document now reflects that by
>    exclusively describing HTTP as transport protocol for CMP.

The sentence "TCP-Based Management Protocol" was enhanced and a
TCP-Messages-over-HTTP transport specification appeared." hit my eye as Transport AD.
Is there any meat to have this sentence in here? I would suggest to remove it, in order to not
give a wrong impression that the IETF has worked at any time on a TCP over HTTP protocol.
The "TCP-Based Management Protocol"  is also sort of unknown to me.

Section 3.7., paragraph 1:

>    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.

How can a HTTP server push data to the client with HTTP?
HTTP is a request/response protocol where the client is sending out
the requests.
I assume that the CMP server is located at the HTTP server.
However, the draft isn't completely clear about whether the CMP server
is necessarily located at the HTTP server.


Section 3.7., paragraph 7:

>    CMP Announcement messages do not require any CMP response.  However,
>    the recipient MUST acknowledge receipt with a HTTP response having an
>    appropriate status code and an empty body.  When not receiving such
>    response it MUST be assumed that the delivery was not successful and
>    if applicable the sending side may retry sending the Announcement
>    after waiting for an appropriate time span.

  What is this time span?
  Replace "may" with "MAY"?

Section 3.7., paragraph 10:

>    A receiver MUST answer with a suitable 4xx or 5xx HTTP error code
>    when a problem occurs.

  This MUST here contradicts this statement "All applicable
"Client Error 4xx" or "Server Error 5xx" status codes
may be used to inform the client about errors."  out of Section 3.3,
as 4xx/5xx codes may be support, but this requires that they are supported.

[Ballot comment]

Section 3.3., paragraph 2:

>    While "Redirection 3xx" status codes MAY be supported by
>    implementations, clients should only be enabled to automatically
>    follow them after careful consideration of possible security
>    implications.

  It would be good to link to your security section about the
the discussion of this.

Section 3.4., paragraph 0:

>    All applicable "Client Error 4xx" or "Server Error 5xx" status codes
>    may be used to inform the client about errors.

  Replace "may" with "MAY"? But see also my DISUCSS about 4xx/5xx codes.



Section 3.4., paragraph 1:

>    The Internet Media Type "application/pkixcmp" MUST be set in the HTTP
>    header when conveying a PKIMessage.

  to be precise: MUST be set in the Content-Type header.

- Section 4: In support of Brian's comment, i.e., what is the purpose of this section?

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

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

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

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP) to Proposed Standard


The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-05-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes how to layer the Certificate Management
  Protocol over HTTP.  It is the "CMPtrans" document referenced in RFC
  4210 and therefore updates the reference given therein.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pkix-cmp-transport-protocols/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pkix-cmp-transport-protocols/ballot/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document?
Has the Document Shepherd personally reviewed this version of
the document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Stephen Kent is the document shepherd.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has received review by some WG members, but it is not
considered central to PKI technology in general. The document was
created by the authors to enable use of CMP in the 3GPP environment, as
called for by a 3GPP document from 2009. It fills in a gap from RFC 4210
(CMP).

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I look forward to an APPLICATION area review, since this document
discusses how to use HTTP for transport, and the PKIX WG does not have
HTTP expertise.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no specific concerns to highlight to the AD or IESG. No IPR
disclosures have been filed related to this document.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Most WG members don't care about this, because it is 3GPP-specific. But,
to be good SDO neighbors we ought to progress it. No WG members have
expressed opposition to any technical aspects of this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

ID nits OK, no MIB.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References have been split into normative and informative sections.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The I-D has an IANA Considerations section that indicates there are no
IANA considerations, and cites the extant MIME type registration.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There is no use of formal languages in this document, other than lists
of ASN.1 explicit tags for the CMP message types that MUST be supported.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:


Technical Summary

CMP was designed [RFC 2510] to be carried over various transport
protocols, and the initial specification described how to do so for TCP,
HTTP, FTP, and MIME (at varying levels of detail). The current version
of CMP [RFC 4210] included an informative reference to a document that
was supposed to define how to carry CMP over various transport
protocols. That document expired in 2000, leaving no updated, detailed
description for how to transport CMP messages. This document was
prepared to replace that old one. The authors of this document
resurrected the HTTP part of that document, after the original authors
indicated that they were not available to work on this document.

Working Group Summary

As noted above, this document attracted little interest in the WG,
because it focuses on use of CMP (which is not popular) in the 3GPP
environment (which is equally uninteresting to most WG members).

Document Quality

The document is reasonably well written and fairly clear (modulo some
spelling errors), especially considering that the authors are not native
English speakers.