Re: [pkix] Amendment to CABF Baseline Requirements

Russ Housley <housley@vigilsec.com> Fri, 07 April 2017 20:51 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 6968D120454 for <pkix@ietfa.amsl.com>; Fri, 7 Apr 2017 13:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1GDlv7x8bn1L for <pkix@ietfa.amsl.com>; Fri, 7 Apr 2017 13:51:28 -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 60D5F1200C1 for <pkix@ietf.org>; Fri, 7 Apr 2017 13:51:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A2EE130043B for <pkix@ietf.org>; Fri, 7 Apr 2017 16:51:27 -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 ZsR61CbQ0KHT for <pkix@ietf.org>; Fri, 7 Apr 2017 16:51:25 -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 5CD7F300261; Fri, 7 Apr 2017 16:51:25 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <1c4a4745-1865-a142-fc25-514b37c602d3@comodo.com>
Date: Fri, 7 Apr 2017 16:51:24 -0400
Cc: Ben Wilson <ben.wilson@digicert.com>, IETF PKIX <pkix@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D5F7575C-22D0-4B64-B042-0A457E38CEE4@vigilsec.com>
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> <1c4a4745-1865-a142-fc25-514b37c602d3@comodo.com>
To: Rob Stradling <rob.stradling@comodo.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/ChKT9bb3dNRt1JYwxBz2EWXZ-dw>
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:51:30 -0000

Rob:

You are absolutely correct!  Thanks for posting the correction.

Russ


> On Apr 7, 2017, at 8:54 AM, Rob Stradling <rob.stradling@comodo.com> wrote:
> 
> Russ, RFC5280 includes all of the following:
> 
> ub-organization-name INTEGER ::= 64
> ub-organizational-unit-name INTEGER ::= 64
> ub-organization-name-length INTEGER ::= 64
> ub-organizational-unit-name-length INTEGER ::= 32
> 
> The *-name upper bounds apply to X.500 DNs, whereas IINM the *-name-length upper bounds apply to the x400Address GeneralName type.
> 
> On 06/04/17 20:24, Russ Housley 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 …
>> 
>> Russ
>> 
>> 
>> 
>>> On Apr 6, 2017, at 2:55 PM, Ben Wilson <ben.wilson@digicert.com> wrote:
>>> 
>>> Thanks, Michael.    Is it relevant that Annex C to X.520 (2012) states,
>>> "(This annex does not form an integral part of this Recommendation |
>>> International Standard.)" whereas before (1988) it stated,  "This Annex is
>>> part of the Recommendation."?
>>> 
>>> From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Michael StJohns
>>> Sent: Thursday, April 6, 2017 10:55 AM
>>> To: pkix@ietf.org
>>> Subject: Re: [pkix] Amendment to CABF Baseline Requirements
>>> 
>>> Hi Ben -
>>> 
>>> IETF 5280 et al are profiles of the X.509 documents.  The upper length
>>> bounds for orgnaizationName and commonName fields in 5280 is no different
>>> than the upper bounds specified in X.509 (at least as of the 2014
>>> document).  I would suggest that you will pretty much break any and all
>>> implementations of X.509 clients that rely or enforce this limit as well as
>>> any code that generates certificate requests.
>>> 
>>> I will note that overloading text fields with structured data is generally
>>> not a good idea - as you've found.
>>> 
>>> Mike
>>> 
>>> 
>>> 
>>> On 4/6/2017 12:24 PM, Ben Wilson wrote:
>>> Does anyone want to comment on my draft amendment to the CA/Browser Forum’s
>>> Baseline Requirements for SSL/TLS Certificates which would remove the
>>> 64-character limit on the commonName and organizationName,  as an exception
>>> to RFC 5280?  The text of the relevant Baseline Requirement provision is
>>> found below with the proposed additional language in ALL CAPS.  The reason
>>> for the first change (commonName) is there are FQDNs (in Subject Alternative
>>> Names) that are longer than 64 characters.  The reason for the second change
>>> (organizationName) is that there are organizations with names longer than 64
>>> characters.
>>> 
>>> 7.1.4.2.2.             Subject Distinguished Name Fields
>>> a.            Certificate Field: subject:commonName (OID 2.5.4.3)
>>> Required/Optional: Deprecated (Discouraged, but not prohibited)
>>> Contents: If present, this field MUST contain a single IP address or
>>> Fully-Qualified Domain Name that is one of the values contained in the
>>> Certificate’s subjectAltName extension (see Section 7.1.4.2.1).
>>> MAXIMUM LENGTH:  NO STIPULATION.  (THIS IS AN EXCEPTION TO RFC 5280 WHICH
>>> SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.)
>>> b.            Certificate Field: subject:organizationName (OID 2.5.4.10)
>>> Optional.
>>> Contents: If present, the subject:organizationName field MUST contain either
>>> the Subject’s name or DBA as verified under Section 3.2.2.2. The CA may
>>> include information in this field that differs slightly from the verified
>>> name, such as common variations or abbreviations, provided that the CA
>>> documents the difference and any abbreviations used are locally accepted
>>> abbreviations; e.g., if the official record shows “Company Name
>>> Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”.
>>> Because Subject name attributes for individuals (e.g. givenName (2.5.4.42)
>>> and surname (2.5.4.4)) are not broadly supported by application software,
>>> the CA MAY use the subject:organizationName field to convey a natural person
>>> Subject’s name or DBA.
>>> MAXIMUM LENGTH:  256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 WHICH
>>> SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.)
>>> 
>>> Thanks,
>>> Ben Wilson
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>