Re: [pkix] Amendment to CABF Baseline Requirements
Rob Stradling <rob.stradling@comodo.com> Fri, 07 April 2017 12:54 UTC
Return-Path: <rob.stradling@comodo.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 E5E77127010 for <pkix@ietfa.amsl.com>; Fri, 7 Apr 2017 05:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level:
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01, 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 TdOnJ16EQ27o for <pkix@ietfa.amsl.com>; Fri, 7 Apr 2017 05:54:24 -0700 (PDT)
Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B5A129478 for <pkix@ietf.org>; Fri, 7 Apr 2017 05:54:23 -0700 (PDT)
Received: (qmail 1271 invoked by uid 1004); 7 Apr 2017 12:54:20 -0000
Received: from rmdccgwarp1.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.82) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 07 Apr 2017 13:54:20 +0100
Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201704071354207110; Fri, 07 Apr 2017 13:54:20 +0100
To: Russ Housley <housley@vigilsec.com>, Ben Wilson <ben.wilson@digicert.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>
Cc: IETF PKIX <pkix@ietf.org>
From: Rob Stradling <rob.stradling@comodo.com>
Message-ID: <1c4a4745-1865-a142-fc25-514b37c602d3@comodo.com>
Date: Fri, 07 Apr 2017 13:54:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/n39ch4gAUAJdzEAf_Cue0Rfv5Hs>
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 12:54:31 -0000
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 Forums >> 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 >> Certificates 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 Subjects 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 >> Subjects 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
- Re: [pkix] Amendment to CABF Baseline Requirements Russ Housley
- Re: [pkix] Amendment to CABF Baseline Requirements Russ Housley
- Re: [pkix] Amendment to CABF Baseline Requirements Russ Housley
- Re: [pkix] Amendment to CABF Baseline Requirements Erik Andersen
- Re: [pkix] Amendment to CABF Baseline Requirements Erik Andersen
- Re: [pkix] Amendment to CABF Baseline Requirements Carl Wallace
- Re: [pkix] Amendment to CABF Baseline Requirements Jeremy Rowley
- Re: [pkix] Amendment to CABF Baseline Requirements Jim Schaad
- Re: [pkix] Amendment to CABF Baseline Requirements Sill, Alan
- Re: [pkix] Amendment to CABF Baseline Requirements Carl Wallace
- Re: [pkix] Amendment to CABF Baseline Requirements Erik Andersen
- [pkix] Amendment to CABF Baseline Requirements Ben Wilson
- Re: [pkix] Amendment to CABF Baseline Requirements Carl Wallace
- Re: [pkix] Amendment to CABF Baseline Requirements Jeremy Rowley
- Re: [pkix] Amendment to CABF Baseline Requirements Michael StJohns
- Re: [pkix] Amendment to CABF Baseline Requirements Carl Wallace
- Re: [pkix] Amendment to CABF Baseline Requirements Ben Wilson
- Re: [pkix] Amendment to CABF Baseline Requirements Russ Housley
- Re: [pkix] Amendment to CABF Baseline Requirements Peter Bowen
- Re: [pkix] Amendment to CABF Baseline Requirements Erwann Abalea
- Re: [pkix] Amendment to CABF Baseline Requirements Erik Andersen
- Re: [pkix] Amendment to CABF Baseline Requirements Rob Stradling
- Re: [pkix] Amendment to CABF Baseline Requirement… Martin Rex
- Re: [pkix] Amendment to CABF Baseline Requirements Michael StJohns