Re: [pkix] Amendment to CABF Baseline Requirements

Jeremy Rowley <jeremy.rowley@digicert.com> Thu, 06 April 2017 16:40 UTC

Return-Path: <jeremy.rowley@digicert.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 C6857129542 for <pkix@ietfa.amsl.com>; Thu, 6 Apr 2017 09:40:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 1plOOwCWV82B for <pkix@ietfa.amsl.com>; Thu, 6 Apr 2017 09:40:06 -0700 (PDT)
Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF08129541 for <pkix@ietf.org>; Thu, 6 Apr 2017 09:40:04 -0700 (PDT)
Received: from email.digicert.com (ex1-sgu [10.12.1.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPS id A1E4E8FA71E; Thu, 6 Apr 2017 16:40:04 +0000 (GMT)
From: Jeremy Rowley <jeremy.rowley@digicert.com>
To: Carl Wallace <carl@redhoundsoftware.com>, Ben Wilson <ben.wilson@digicert.com>, "pkix@ietf.org" <pkix@ietf.org>
Thread-Topic: [pkix] Amendment to CABF Baseline Requirements
Thread-Index: AQHSrvLwlOcKuMKIFkKDVdh9teKwhKG4itDA
Date: Thu, 06 Apr 2017 16:40:03 +0000
Message-ID: <cf94d4038d594b8c9e929e9b4e215bac@EX2.corp.digicert.com>
References: <D50BE42A.85E25%carl@redhoundsoftware.com>
In-Reply-To: <D50BE42A.85E25%carl@redhoundsoftware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [67.137.52.7]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0137_01D2AEC2.25900690"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/a2ccQvwxYn-Ym4f6ny5VBFzgzCw>
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: Thu, 06 Apr 2017 16:40:09 -0000

Can you point to any browser software that cares about these limits?  I can’t find any.

 

From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Carl Wallace
Sent: Thursday, April 6, 2017 10:28 AM
To: Ben Wilson <ben.wilson@digicert.com>; pkix@ietf.org
Subject: Re: [pkix] Amendment to CABF Baseline Requirements

 

Given these ASN.1 upper bounds are automatically enforced by ASN.1 compiler generated code, how do we hand wave this away? These changes are a recipe for interoperability pain. 

 

From: pkix <pkix-bounces@ietf.org <mailto:pkix-bounces@ietf.org> > on behalf of Ben Wilson <ben.wilson@digicert.com <mailto:ben.wilson@digicert.com> >
Date: Thursday, April 6, 2017 at 12:24 PM
To: "pkix@ietf.org <mailto:pkix@ietf.org> " <pkix@ietf.org <mailto:pkix@ietf.org> >
Subject: [pkix] Amendment to CABF Baseline Requirements

 

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

_______________________________________________ pkix mailing list pkix@ietf.org <mailto:pkix@ietf.org>  https://www.ietf.org/mailman/listinfo/pkix