Re: [pkix] Strings in certificates

Peter Bowen <pzbowen@gmail.com> Tue, 26 January 2016 01:46 UTC

Return-Path: <pzbowen@gmail.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 D5F721ACD5F for <pkix@ietfa.amsl.com>; Mon, 25 Jan 2016 17:46:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 hihqFLgIj-7l for <pkix@ietfa.amsl.com>; Mon, 25 Jan 2016 17:46:27 -0800 (PST)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E35E1A700E for <pkix@ietf.org>; Mon, 25 Jan 2016 17:46:27 -0800 (PST)
Received: by mail-pa0-x232.google.com with SMTP id cy9so89866655pac.0 for <pkix@ietf.org>; Mon, 25 Jan 2016 17:46:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=v+4OfF6Wk/wIUHJ/hJuCksMw0OSNHvqHAfvG44VJHx4=; b=oVy7uyDDHWWDks+8VtEpI0dYZtM3oW8RzQG9aXimOFk0DqtLQTCBx3nN0JX1aeW60P IKAGckXaVXa9us5q0i32/kPMvj8cAPX+Ia7LqpndeZzS2zN5Zmk0I2nLOWULb7Ks3JBJ LQZvGRcOaxbrpjgfB8mEZ/PR2ZI0dgmqlJ6OqXiEE4yRPOOhlq3CB3Seo1Q6KtYmouzE HIfHl343MbG0FKA6SoyFEg0badcSxAS9nUoE52mHIqXF/ufmDl+eD7atRmNCYKn83unI dUyBOODD65VB9UGxlOORghIN61jnT5R4o6By1lB+loyCo6OrHWmbfxIjN1QBxOx0rn1e ArTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=v+4OfF6Wk/wIUHJ/hJuCksMw0OSNHvqHAfvG44VJHx4=; b=WfPfyHHRZ9I725nxkRaHd4jRtF8Obt+VDgm+4y1b3NZrqe+YlJhDTJZJuE6hpc6Ccm c7A2p4rhD6uO1obVDWJPXHSJAdsA0Lq50gAmihHkhkykOkY4HWRZcS07KPn7c1FqUGhF HufTcIzhGTdDK1P5gWvAn7YsY/0JzNap06COVWMHJQ7J5GLI0i7iMmxnKl8kGEC38FCU zwHdHiM9aBxdn8CnP7euqmxUGxEIXeOuNUOVxUzF4E8kkTJygJT109F0RcvQn0RVw0yE kgDgQNr5IqzHn+Hen89D7mKXa9hnWfIDyU8XUBMBzu2wbGFBjptHG1i1uqiWDTp8ZikD f56w==
X-Gm-Message-State: AG10YORZKxZh3U0iyzDGpStw4S2AkYEmFrW20OM7mCQrsnu5gKU+0+iS2lGhrZLrNB/ulmR66UUws8rM/Di3mw==
MIME-Version: 1.0
X-Received: by 10.66.122.97 with SMTP id lr1mr29884120pab.68.1453772786778; Mon, 25 Jan 2016 17:46:26 -0800 (PST)
Received: by 10.66.142.193 with HTTP; Mon, 25 Jan 2016 17:46:26 -0800 (PST)
In-Reply-To: <A9FBB43B-47E7-4144-91EA-F5013A41BEA7@sn3rd.com>
References: <CAK6vND-NRgJVW9Qjg+vktv5s0TGhGtMBB76f5hQ77nvsqz9JXw@mail.gmail.com> <A9FBB43B-47E7-4144-91EA-F5013A41BEA7@sn3rd.com>
Date: Mon, 25 Jan 2016 17:46:26 -0800
Message-ID: <CAK6vND-73A7XSpPgb=or9NZCUYY0s0ADHU50j06-c5jayoaMNw@mail.gmail.com>
From: Peter Bowen <pzbowen@gmail.com>
To: Sean Turner <sean@sn3rd.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/FepYNy_o_2iL8GkE17-1vJ2n-ic>
Cc: "<pkix@ietf.org>" <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: Tue, 26 Jan 2016 01:46:29 -0000

Sean,

Thanks for providing your thoughts.

On Mon, Jan 25, 2016 at 2:25 PM, Sean Turner <sean@sn3rd.com> wrote:
> My two cents …
>
> On Jan 18, 2016, at 22:10, Peter Bowen <pzbowen@gmail.com> wrote:
>>
>> In writing certlint (https://github.com/awslabs/certlint), I ran
>> across several items related to strings in certificates that are
>> slightly unclear.  I’m hoping that someone might be able to help
>> clarify a few things:
>>
>>
>> 1) TeletexString, BMPString, and UniversalString types of DirectoryStrings
>>
>> RFC 5280 says CAs should not use TeletexString, BMPString, and
>> UniversalString types for DirectoryStrings.  As early as 1999 (RFC
>> 2459) these were flagged as deprecated.
>>
>> Is there anything that has moved these to SHALL NOT/MUST NOT or are we
>> still at SHOULD NOT?
>
> I’d love to hear that CAs haven’t generated these string types for the last decade ….

You won't hear that from me.  I've seen hundreds (if not thousands) of
certificates issued in the last week that use these string types.

>> 2) VisibleString and BMPString types of DisplayText
>>
>> RFC 5280 says:
>>      Conforming CAs SHOULD use the
>>      UTF8String encoding for explicitText, but MAY use IA5String.
>>      Conforming CAs MUST NOT encode explicitText as VisibleString or
>>      BMPString.
>>
>> However the organization field of noticeref also uses DisplayText.  Do
>> the same rules apply?
>
> I remember something about this … ah yeah @ IETF 74:
> https://ietf.org/proceedings/74/slides/pkix-3.pdf
>
> I think it was just meant to apply to explicitText because that’s what was seen in the wild given the following statement in s4.2.1.4:
> "Conforming CAs SHOULD NOT use the noticeRef option.”

Yes, I was pointed to RFC 6818 which changed this rule.

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

Thanks,
Peter