Re: [pkix] Strings in certificates

Russ Housley <housley@vigilsec.com> Fri, 05 February 2016 23:41 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FC21B2FBF for <pkix@ietfa.amsl.com>; Fri, 5 Feb 2016 15:41:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level:
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB5A6yI2vZiP for <pkix@ietfa.amsl.com>; Fri, 5 Feb 2016 15:41:06 -0800 (PST)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7BA1B2FBE for <pkix@ietf.org>; Fri, 5 Feb 2016 15:41:06 -0800 (PST)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 08913F24064; Fri, 5 Feb 2016 18:41:06 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id gEHPUAzO3dcW; Fri, 5 Feb 2016 18:39:48 -0500 (EST)
Received: from [192.168.2.104] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7221CF24013; Fri, 5 Feb 2016 18:40:55 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary="Apple-Mail-57--332914702"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CAAFsWK0iph93ZAga=k+O_O1d3CJ4gmmwzNn7_NbJJPBRXQBqyA@mail.gmail.com>
Date: Fri, 05 Feb 2016 18:40:54 -0500
Message-Id: <EF420DBE-E86C-4B8C-9A87-86937C99D4E2@vigilsec.com>
References: <CAK6vND-NRgJVW9Qjg+vktv5s0TGhGtMBB76f5hQ77nvsqz9JXw@mail.gmail.com> <A9FBB43B-47E7-4144-91EA-F5013A41BEA7@sn3rd.com> <CAK6vND-73A7XSpPgb=or9NZCUYY0s0ADHU50j06-c5jayoaMNw@mail.gmail.com> <CAAFsWK0iph93ZAga=k+O_O1d3CJ4gmmwzNn7_NbJJPBRXQBqyA@mail.gmail.com>
To: Wei Chuang <weihaw@google.com>
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/e6gz4NxXKlR_NbNlPUXL_kPKq3A>
Cc: IETF PKIX <pkix@ietf.org>
Subject: Re: [pkix] Strings in certificates
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2016 23:41:08 -0000

On Feb 5, 2016, at 6:10 PM, Wei Chuang wrote:

> >> 3) Unicode normalization
> >>
> >> A number of fields in certificates can take unicode strings.  Is there
> >> any specification as to how (or if) they should be normalized?
> >
> > I thought there were references in s7 of RFC 5280 (and some tweaks in s5 of RFC 6818).  There’s also some additional information in RFC 6125.  In a perfect world, the output of precis (https://datatracker.ietf.org/wg/precis/documents/) would be adopted the world over.  I’m not going to hold my breath though.
> 
> I don't see anything there that specifies a specific normalization
> form for storage, except for the one thing about explicitText.  I'll
> assuming anything (including mixed) is good.
> 
> Just piling on.  May be I'm misreading those two section (s7 of RFC5280 and s5 of RFC6818), while there's IDN support, there's no mention of handling Unicode in email address rfc822Name local-part or URL uniformResourceIdentifier path or query parts.  It seems like an important loophole that should be fixed.  Would folks here be willing to help in standardizing some in certificate encoding for these types?

I'm willing to help with a clarifications document.  I do not need to revisit the decisions recorded in every section of RFC 5280 all over again.

Russ