Re: [pkix] Amendment to CABF Baseline Requirements
Ben Wilson <ben.wilson@digicert.com> Thu, 06 April 2017 18:55 UTC
Return-Path: <ben.wilson@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 2F89C128DF6 for <pkix@ietfa.amsl.com>; Thu, 6 Apr 2017 11:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com
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 RxYTZP4abrXt for <pkix@ietfa.amsl.com>; Thu, 6 Apr 2017 11:55:35 -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 84E1A129469 for <pkix@ietf.org>; Thu, 6 Apr 2017 11:55:34 -0700 (PDT)
From: Ben Wilson <ben.wilson@digicert.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1491504934; bh=oisDzNJKaz+Nn61cpdX4tn7zjNuTOw4U1L5fIfPaPhU=; h=From:To:Subject:Date:References:In-Reply-To; b=yQ3eBOhKd79VvTNRhmiimK+0tD58iT7wxiyAQ4ATj7fYoEsxwHE+W7sjtfRxgTJ3o Q8iIz83a9SUJNk0QfOgXzSvWcCWIYF4K9u20PQxwqKTmweW7oDz09ifp/X6+8FBfIc fBBgb5LITigrf6Ym+2Xtd65NGp4KZYtSThcMFIuE=
To: Michael StJohns <msj@nthpermutation.com>, "pkix@ietf.org" <pkix@ietf.org>
Thread-Topic: [pkix] Amendment to CABF Baseline Requirements
Thread-Index: AdKu7+4NHc0VCiezSMq6lazH8C48qgAOOMeAAAjFYFA=
Date: Thu, 06 Apr 2017 18:55:32 +0000
Message-ID: <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com>
References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <a24a24b9-542c-a619-3445-47e812f9c46b@nthpermutation.com>
In-Reply-To: <a24a24b9-542c-a619-3445-47e812f9c46b@nthpermutation.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.8]
Content-Type: multipart/signed; boundary="----=_NextPart_000_0019_01D2AED5.131A6650"; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/EXFgGTVDU-ZBuxVoFFlr6ydp92s>
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 18:55:39 -0000
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 _______________________________________________ pkix mailing list mailto:pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix
- 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