Re: [saag] Comment added to draft-gutmann-scep history

[Peter Gutmann <[e-mail]>]

I wrote:

>I could perhaps add a note somewhere at the start saying that SCEP, like any
>number of other PKI protocols, uses HTTP as a universal substrate, and that
>you shouldn't expect that doing something HTTP-ish like setting a Content-
>type will actually have any effect?  A reference to RFC 3205/BCP 56 should
>probably accompany that.

How about this:

-- Snip --

Like many other Internet protocols, SCEP uses HTTP as a universal substrate,
for more on the implications of this see <xref target="BCP56">BCP 56</xref>.
While SCEP messages are carried over HTTP transport, neither the client nor
the server is likely to be a conventional HTTP-speaking web server or client,
providing only the minimum functionality required for HTTP transport, see the
"HTTP Considerations" section of <xref target="RFC6712">RFC 6712</xref> for
more on this.  Implementations SHOULD NOT use complex HTTP mechanisms such as
chunked encoding, Expect/Continue, HTTP redirects, and similar facilities.

To guard against establishing an erroneous connection to any of the myriad
other devices and services that speak HTTP, SCEP servers MAY choose to respond
to non-SCEP requests, for example a GET from a web browser, with an HTML
diagnostic message notifying the client that they're talking to the wrong
server or service.  Similarly, clients MAY check for an HTML response from the
server and report a configuration error, for example that the client is
connecting to the wrong server or port on a server.

-- Snip --

The latter is particularly useful, my code has been doing that for quite some
time to deal with "the client/server is broken, it's not getting
certificates".  The problem invariably is that they've specified the wrong
server name/IP address, or forgotten to specify a port so the default 80 is
used, or there's a proxy in the way that redirects the connection to a web
server on 80 rather than a SCEP server on 80, or something similar.

Maybe we need an updated BCP 56 that provides info on the general use of HTTP
as a substrate and how to deal with it that every other HTTP-as-substrate-
using RFC can refer to (no, I'm not volunteering to write it :-).

Peter.