Re: [pkix] Amendment to CABF Baseline Requirements

Russ Housley <housley@vigilsec.com> Fri, 07 April 2017 20:43 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832691200C1 for <pkix@ietfa.amsl.com>; Fri, 7 Apr 2017 13:43:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 YOlT-BQmSszm for <pkix@ietfa.amsl.com>; Fri, 7 Apr 2017 13:43:32 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5461289B0 for <pkix@ietf.org>; Fri, 7 Apr 2017 13:43:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 38A3A30043B for <pkix@ietf.org>; Fri, 7 Apr 2017 16:43:26 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id r-8bdEDXi1_u for <pkix@ietf.org>; Fri, 7 Apr 2017 16:43:24 -0400 (EDT)
Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 91D64300261 for <pkix@ietf.org>; Fri, 7 Apr 2017 16:43:24 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DA4BBDC2-B8B7-49D7-A677-EBD199198BDE"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 7 Apr 2017 16:43:24 -0400
References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <a24a24b9-542c-a619-3445-47e812f9c46b@nthpermutation.com> <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> <CAK6vND9-oxL_acNk21D36UeXHqUM0Rz57cpB_zpCJaTJMPeZ2g@mail.gmail.com> <CA+i=0E5Bh=_b1ZK2T_Y9bj6GivtOJq2Y23i071=wS=jph68tog@mail.gmail.com>
To: IETF PKIX <pkix@ietf.org>
In-Reply-To: <CA+i=0E5Bh=_b1ZK2T_Y9bj6GivtOJq2Y23i071=wS=jph68tog@mail.gmail.com>
Message-Id: <09BE38C5-7B5B-45B0-BC5F-5FCB1164F864@vigilsec.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/C5xYdYAGkJKQtBB18E38IVf_6Zo>
Subject: Re: [pkix] Amendment to CABF Baseline Requirements
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.22
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, 07 Apr 2017 20:43:37 -0000

The ASN.1 modules that were posted by Erik confirm that the upper bounds have been removed for all of the naming attributes in the SelectedAttributeTypes module.

UnboundedDirectoryString ::= CHOICE {
  teletexString    TeletexString(SIZE (1..MAX)),
  printableString  PrintableString(SIZE (1..MAX)),
  bmpString        BMPString(SIZE (1..MAX)),
  universalString  UniversalString(SIZE (1..MAX)),
  uTF8String       UTF8String(SIZE (1..MAX)) }

Russ


> On Apr 7, 2017, at 3:15 AM, Erwann Abalea <eabalea@gmail.com> wrote:
> 
> Bonjour,
> 
> 2017-04-06 22:39 GMT+02:00 Peter Bowen <pzbowen@gmail.com <mailto:pzbowen@gmail.com>>:
> 
> On Thu, Apr 6, 2017 at 12:24 PM Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:
> The comment in the UpperBounds ASN.1 module (the 8th edition) says:
> 
> -- EXPORTS All
> -- The types and values defined in this module are exported for use in the other ASN.1
> -- modules contained within these Directory Specifications, and for the use of other
> -- applications which will use them to access Directory services. Other applications
> -- may use them for their own purposes, but this will not constrain extensions and
> -- modifications needed to maintain or improve the Directory service.
> 
> X.509 is part of the Directory Specifications, so they are not advisory.
> 
> It looks like ITU-T increased the length of the organizational unit name in the most recent edition.
> 
> RFC 5280 says:
> 
> ub-organization-name-length INTEGER ::= 64
> ub-organizational-unit-name-length INTEGER ::= 32
> 
> The UpperBounds ASN.1 module (the 8th edition) says:
> 
> ub-organization-name                       INTEGER ::= 64
> ub-organizational-unit-name                INTEGER ::= 64
> 
> So, we may already be in a place where implementations conforming to X.509 will produce a certificate that cannot be decoded by an implementation that conforms to RFC 5280.
> 
> I wish we gad gotten a heads-up …
> 
> It is even worse. 7th and 8th (and maybe prior releases) removed the usage of ub- from the schema. The schema itself no longer bounds DirectoryStrings and X.509 explicitly says they are unbounded. 
> 
> X.520 2005 defines the attributes using the DirectoryString{} parameterized type, while the 2008 edition uses the UnboundedDirectoryString type.
> 
> RFC5912, which proposes ASN.1 modules for certificates and other related things, still uses the DirectoryString{} variant.
> 
> -- 
> Erwann.