[apps-discuss] apps-team review of draft-ietf-sidr-rescerts-provisioning-09

Carsten Bormann <cabo@tzi.org> Sat, 09 April 2011 20:29 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id A92803A6972; Sat, 9 Apr 2011 13:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.049
X-Spam-Status: No, score=-105.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id XBiV0K3c0SJX; Sat, 9 Apr 2011 13:29:11 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id E078E3A694F; Sat, 9 Apr 2011 13:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de []) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p39KUjNL021905; Sat, 9 Apr 2011 22:30:46 +0200 (CEST)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4DFD83CC; Sat, 9 Apr 2011 22:30:45 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1084)
From: Carsten Bormann <cabo@tzi.org>
Date: Sat, 09 Apr 2011 22:30:44 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <9780CDCD-0C08-4D19-B63F-240D8FDA6425@tzi.org>
To: draft-ietf-sidr-rescerts-provisioning.notify@tools.ietf.org
X-Mailer: Apple Mail (2.1084)
Cc: The IESG <iesg@ietf.org>, Apps Discuss <apps-discuss@ietf.org>
Subject: [apps-discuss] apps-team review of draft-ietf-sidr-rescerts-provisioning-09
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2011 20:29:12 -0000

I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see
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-sidr-rescerts-provisioning-09
Title: A Protocol for Provisioning Resource Certificates
Reviewer: Carsten Bormann
Review Date: 2011-04-09


This document is ready for publication after a number of relatively
simple changes have been performed.  A slightly larger set of
potentially desirable improvements have also been identified.


The draft describes a protocol for provisioning resource certificates.
A resource in this context is an Internet Number Resource (INR), i.e.,
IP Address or Autonomous System (AS) Number.
The protocol is used between a client "Subject" (such as an ISP) and a
server "Issuer" (such as a registry, acting as a CA).

The protocol will thus be used between in a very specialized setting
between members of two closely-knit communities; there is little
danger of properties of this protocol spilling over into mainstream
application protocols.


Several properties of this protocol represent current practice, but
not necessarily best practice, in application protocol design.
The message transport used is an HTTP POST request, which is used as a
request-response vehicle for carrying around CMS objects which in turn
carry XML-encoded messages that are the subject of this protocol.
Given the specialized status of this protocol, this may be acceptable.

Major Issues:

1.  The media type used for requests and responses cannot be
registered under the name 'application/x-rpki' (section 4.2 of RFC
4288).  Unless significant deployment makes this prohibitive, a
permanent name SHOULD be chosen and the media type be registered
according to RFC 4288 (BCP 13).

2.  There is an explicit mandate for serializing the processing of all
requests between one server/client pair, without it being fully clear
what exactly constitutes that pair (i.e., when are two requests from
the *same* client)?  Similarly, it is not quite clear how to "Check
that the XML sender and recipient attributes reference a known client
and this server's system respectively" (the underlying data type is an


3.  There is no such thing as a "HTTP 400 Bad Data" response to an
HTTP POST.  Status code 400 stands for "Bad Request".

4.  It may be worthwhile to mention the use of the Retry-After: HTTP
header with a 503 status.

5.  My ASN.1 is a bit rusty, but the content of looks
strange to me and is rejected by asn1c.  Has this been validated?
Same comment for Appendix A.  Remove duplicate definition of
ContentType as well.

6.  re 3.2 Common Message format: The reader's mind should be put at
ease here by quickly pointing to the Relax-NG spec in Annex B.  It
should be clarified that the text in 3.2 is specifying the message
format by way of examples, and that the actual (also normative) format
is specified in Appendix B.

7.  re 3.2 Common Message format: please remove the spaces around the
'=' in 'recipient = "recipient name"' to minimize confusion.

8.  The use of a comma-separated list of URIs (which in turn requires
escaping commas in the URIs themselves) in the attribute "cert_url" in
the context of a class or certificate element is suboptimal.  Allowing
one or more cert_url elements nested in the class element would be
more natural XML.

9.  It is unclear why a new convention for the representation for IPv6
addresses needs to be invented. One should simply make use of RFC
5952.  The example given in the text for resource_set_ipv6 does not
conform to either RFC 5952 (it uses upper case, as seems to be
recommended by the somewhat opaque reference to
http://www.w3.org/TR/xmlschema-2/#hexBinary and its canonical form)
nor the new convention (it uses leading zeros).  (The reference to RFC
3779 seems to point to section in that RFC?)

10.  re 3.4: I have trouble understanding:

   If any of the req_resource_set attributes are specified in the
   request, then any missing req_resource_set attributes are to be
   interpreted as specifying the complete set of the corresponding
   resource type that match the client's current resource allocation.
   If the value of any req_resource_set attributes is the null value
   (""), then this indicates that no resources of that resource type are
   to be certified with this request.

What is the semantics if none of the req_resource_set attributes are

11.  What are the circumstances under which the following SHOULD is
not required, and what can the client rely on to happen in this case?

   o  If the resource class is not defined by the server, then the
      server SHOULD return error code 1201.

12.  (The reviewer got curious why ski is using base64url and all
other binary data are encoded in base64.)

13.  What is the point of limiting the error_response status code to
one quadrillion minus one?  The set of status codes ever standardized
is likely to be smaller, not requiring a 50 bit number.  Right now,
they are all four-digit numbers, which might be a hint to a more
reasonable upper limit.

14.  There is no way in the schema to include a second description
element, as is require in the description of "description" in 3.6.

15.  The schema allows zero-length certificates throughout -- this
will be caught at the semantic level, but it is probably worthwhile
spending a couple of minLength constraints on the xsd:base64Binary.
Similar comment for the xsd:token in class_name.

16.  (There are some indentation idiosyncrasies in the schema, e.g. in
issue_request and in revocation.  The schema might also be improved by
factoring out some common types such as

                 xsd:base64Binary { maxLength="512000" }
                 xsd:token { maxLength="1024" }

as was done e.g. in draft-ietf-sidr-publication.)