[secdir] Secdir review of draft-ietf-pkix-rfc5280-clarifications-08

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 10 September 2012 14:11 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DCCD221F8694; Mon, 10 Sep 2012 07:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.376
X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hZSeYE2HhTkx; Mon, 10 Sep 2012 07:11:06 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com []) by ietfa.amsl.com (Postfix) with ESMTP id 18CB321F867E; Mon, 10 Sep 2012 07:11:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1347286265; d=isode.com; s=selector; i=@isode.com; bh=i8vxhcq36UaHP/WfTq6nXBZvMv2HjiwuBqLD1RWdFGU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=qoJZ51eN7++CtYrUydabez59b5E+HEwCwscEfl8jNtDE7GWnOy0Nsi7faLavmHbjCzYHZj 7qfUa8ZMwLS/Z3BsyJkZRb/NFDdyRIhwLG96saQhijXQi4pBThtBvSwPpLlkkD1sKcLbI0 ZSpEnXjVFdXPm71PKzdsdVbQ+NQmGPU=;
Received: from [] (shiny.isode.com []) by statler.isode.com (submission channel) via TCP with ESMTPSA id <UE30-AAv33D7@statler.isode.com>; Mon, 10 Sep 2012 15:11:04 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <504DF506.5090107@isode.com>
Date: Mon, 10 Sep 2012 15:11:18 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-pkix-rfc5280-clarifications.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [secdir] Secdir review of draft-ietf-pkix-rfc5280-clarifications-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Sep 2012 14:11:07 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
  These comments were written primarily for the benefit of the security 
area directors.  Document editors and WG chairs should treat these 
comments just like any other last call comments.

This document updates RFC 5280, the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL)
Profile.  This document changes the set of acceptable encoding
methods for the explicitText field of the user notice policy
qualifier and clarifies the rules for converting internationalized
domain name labels to ASCII.  This document also provides some
clarifications on the use of self-signed certificates, trust anchors,
and some updated security considerations.

The Security Considerations section is basically a patch to the Security 
Considerations in RFC 5280. I think the new text is a good addition and 
the whole section is adequate.

I think the document is basically fine as far as SEC Area is concerned, 
but there are some related Apps issues:

In Section 3

    The explicitText string SHOULD NOT include any control
    characters (e.g., U+0000 to U+001F and U+007F to U+009F)

I think you should really properly define what you are talking about 
here. Are you talking about Unicode Control characters? If yes, please 
say so. Suggested replacement:

    The explicitText string SHOULD NOT include any Unicode Control
    characters (i.e., U+0000 to U+001F and U+007F to U+009F)

You should also consider whether you should reference RFC 5198 here 
(which restricts the set even further).

Section 5 only talks about IDNA 2003. What about IDNA 2008?