[apps-discuss] APPDIR review of draft-ietf-pkix-est-03

Mark Nottingham <mnot@mnot.net> Thu, 15 November 2012 07:44 UTC

From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 15 Nov 2012 18:44:20 +1100
Message-Id: <060AEB60-8E59-4AB2-A178-5874BE36AF71@mnot.net>
To: draft-ietf-pkix-est.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Cc: Apps Discuss <discuss@apps.ietf.org>
Subject: [apps-discuss] APPDIR review of draft-ietf-pkix-est-03
Precedence: list

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

Document: draft-ietf-pkix-est-03
Title: Enrollment over Secure Transport
Reviewer: Mark Nottingham
Review Date: 15-Nov-2012

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

Major Issues: 

As written, this draft violates BCP56, "On the use of HTTP as a Substrate:"

>    2. New protocols - including but not limited to those using HTTP -
>       should not attempt to circumvent users' firewall policies,
>       particularly by masquerading as existing protocols.
>       "Substantially new services" should not reuse existing ports.
> 
>    3. In general, new protocols or services should not reuse http: or
>       other URL schemes.


While there has been longstanding discussion about obsoleting BCP56, because it's acknowledged that HTTP is useful for other protocols, that document has not yet been published. 

However, when it is, it's very likely to embody the intent behind RFC5785 -- that the HTTP URI namespace of hosts is under their individual control, and that standards ought not impinge upon it in any way, except in the limited ways described by that document.

In other words, IETF standards should not define URIs or patterns of URIs, because servers may wish to provide other services (implying the possibility of collision), or deploy resources in an alternate way, for implementation or operational reasons. 

This is a fundamental concept in the Web architecture; see <http://www.w3.org/TR/webarch/>. 

Possible remedies include:

1) Specifying a "home document" format that links (in the RFC5988 sense) to the various resources as appropriate. 
2) Specifying a well-known URI to root the interaction. Note that this is suboptimal; while it avoids collisions, it does not allow alternate deployments, or multiple deployments on the same host.

Regards,

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

[apps-discuss] APPDIR review of draft-ietf-pkix-e… Mark Nottingham