[apps-discuss] AppsDir review of draft-ietf-pkix-est-07

Tobias Gondrom <tobias.gondrom@gondrom.org> Tue, 25 June 2013 08:29 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E9F21E8086 for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 01:29:33 -0700 (PDT)
X-Quarantine-ID: <9YS4N9K1fiob>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): To: ....org, draft-ietf-pkix-est\342\200\213.all@tools.ie[...]
X-Spam-Flag: NO
X-Spam-Score: -95.061
X-Spam-Level:
X-Spam-Status: No, score=-95.061 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YS4N9K1fiob for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 01:29:29 -0700 (PDT)
Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1944F21F9E1E for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 01:29:24 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=q37AnQ4Dl9d4cIFgqR/PS6ZX2AAzSLA3aDuZLiP6ImA7E8kN4Kdmqjy6Kgs4dVSjHoCqSnV7M0YnhuoKPqK2dF2/sUKyZT45DeEkOHKSRYPGh/HXQO7ZFHa28GehTRPM; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type;
Received: (qmail 19494 invoked from network); 25 Jun 2013 10:29:17 +0200
Received: from softdnserror (HELO ?183.199.6.81?) (183.199.6.81) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 25 Jun 2013 10:29:17 +0200
Message-ID: <51C954C5.4060401@gondrom.org>
Date: Tue, 25 Jun 2013 16:28:53 +0800
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: apps-discuss@ietf.org, draft-ietf-pkix-est​.all@tools.ietf.org
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative; boundary="------------010305010302060502040702"
Cc: iesg@ietf.org
Subject: [apps-discuss] AppsDir review of draft-ietf-pkix-est-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 25 Jun 2013 08:29:33 -0000

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-est-07
Title: Enrollment over Secure Transport
Reviewer: Tobias Gondrom
Review Date: 25.6.2013

Summary: The draft looks fine.
It is heading for STD track and mostly describes Simple PKI over TLS
(and using the protected channel mechanisms for mutual authentication as
well (beyond simple confidentiality)).

comments:


1. section 2.2.2 and 2.2.3
( client verification.)
(Certificate-less TLS (e.g., with a shared credential distributed
out-of-band);
and HTTP-based with a username/password distributed out-of-band.)

make sure to avoid information leakage. E.g. in case of certificate-less
TLS, if cookies are used, make sure that are not transmitted over the
normal unprotected HTTP band.
(section 3.2.3 already specifies that "HTTP Basic and Digest
authentication MUST only be performed over TLS 1.1 [RFC4346] or later
versions." which is good.)



2. section 3.2.4:
when registering  "application/csrattrs" with IANA in section 6
I see you have no Magic number or file extension.
Is there a chance that this request might at some point be made without
direct HTTP and might want some of the two?



3. section 3.2.2:
as you want to offer to use HTTP POST and GET.
I am not so happy about the HTTP GET parts. How do you consider the risk
of information leakage with HTTP GET when you have e.g. labels?
e.g. in case of    "2. 
https://www.example.com/.well-known/est/arbitraryLabel1/cacerts"

Second you may consider to note URI length limitations in GET requests. 


nits:
page 32
s/to use the the secp384r1 elliptic curve/to use the secp384r1 elliptic
curve


Oh and you should clean up idnits:
 ** Downref: Normative reference to an Informational RFC: RFC 2986
  ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)


Best regards, Tobias