Re: [pkix] Amendment to CABF Baseline Requirements

Michael StJohns <msj@nthpermutation.com> Fri, 07 April 2017 13:23 UTC

Return-Path: <msj@nthpermutation.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 746A6129487 for <pkix@ietfa.amsl.com>; Fri, 7 Apr 2017 06:23:16 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 V9B05Ti9OcqR for <pkix@ietfa.amsl.com>; Fri, 7 Apr 2017 06:23:13 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE82127010 for <pkix@ietf.org>; Fri, 7 Apr 2017 06:23:12 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id v3so10700247qtd.3 for <pkix@ietf.org>; Fri, 07 Apr 2017 06:23:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=RTaUSovGmLuR+knQJUc7QFy/T7Jzr9vyIN05GM3YkOM=; b=oB9/V3VWl72fnQlpGvjdvumPSebab+12juYVqqu+BI+teDmf8ypDG/DigAAKyQLeT6 PRtch3RvPH/0y2zVnrlqYjdZDQNooCbXAgpGaeKgTNQ1JdDeLj3y+zmU+wpbJZ8KYOjl BEfjhUZNGTRcil3e5g0PulXb9UqmZdVMBoFhLjMaravFOzQ+ZeDQDMauw3Y5FzU7pdln TMVJKCrBquENS1lDPDqjsAJA24pI9/Bn+/eY8t/VPmQKeO0Z/hZAc7pmv1Dsk9X00z4b YZ3Wyc5vuYCyRl4GA4sr4JbTiOgEUrMmrW/B+6JuOblmKnaHkX88XFGFZTKgqW9JODjr UqBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RTaUSovGmLuR+knQJUc7QFy/T7Jzr9vyIN05GM3YkOM=; b=aPyNYhingh2CDdc1qIn9LjPWV0hIW+LZJsgratlrrhpW0sbJlWwXD9LZmtbfjNKseU SA7ZEWx/xtAPjKF1l6hhfXe88lKz9chUlkQg+hZFsSIuV/x/2poVasGdfwS7Kuocci7r BLioKs2N0skX3BrjcT8wTIYkS8PkoywA3IppCYdz4qBTPa2n5xMmEIaUhJCPns2gtJep mLfIFkO/rpMazYV+5r+T+OhMp01TY5d1hs4N7flje33GkwSZt+B9Zo+T+yU/CTuJ1yj3 8sCkzd0hltJzW59YPKYp3ckfIeVxi/0aUW00JH7H2zg2SkQG1Q1rrwPfTozwtenHYiiu J3Ig==
X-Gm-Message-State: AFeK/H3UE9R5pRK+tPIjhTEdbYcubmi/Cv1osUhLWDrzl1DVxLKXyfxcDwn+jsuUNU07Wg==
X-Received: by 10.237.62.234 with SMTP id o39mr42272733qtf.87.1491571391160; Fri, 07 Apr 2017 06:23:11 -0700 (PDT)
Received: from ?IPv6:2601:152:4400:a2e0::159b? ([2601:152:4400:a2e0::159b]) by smtp.gmail.com with ESMTPSA id 1sm3017926qty.69.2017.04.07.06.23.09 for <pkix@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 06:23:10 -0700 (PDT)
To: pkix@ietf.org
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> <000001d2af76$824be7a0$86e3b6e0$@x500.eu>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <66170894-a0e0-34af-1089-f2c9db4464da@nthpermutation.com>
Date: Fri, 7 Apr 2017 09:23:29 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <000001d2af76$824be7a0$86e3b6e0$@x500.eu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/leYU0sVu_GWe6goeaIeJ7Gf-5t0>
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 13:23:16 -0000

On 4/7/2017 4:11 AM, Erik Andersen wrote:
> Hi Russ,
>
> We have not changed upper bounds. I just checked the second edition (1993). It has 64 octets in both cases. RFC 5280 must have made a copy mistake.
>
> We removed upper bounds from the directory specifications to be compatible with LDAP that does not have upper bounds. Either we are compatible with LDAP or with RFC 5280, but with both is not possible.

That's not actually a correct statement.   You can store a compliant 
X.509 certificate in a non-compliant LDAP directory without any 
problems.   It's storing a non-compliant (e.g. 256 byte commonName) 
X.509 certificate in a compliant LDAP or X.500 directory using the 
common name as part of the key that might be the problem.

I.e., a compliant X.509 or PKIX certificate is compatible with LDAP 
regardless of LDAPs waiving of the limits.

Mike


>
> Erik
>
> -----Oprindelig meddelelse-----
> Fra: pkix [mailto:pkix-bounces@ietf.org] På vegne af Russ Housley
> Sendt: 06 April 2017 21:25
> Til: Ben Wilson <ben.wilson@digicert.com>
> Cc: IETF PKIX <pkix@ietf.org>
> Emne: Re: [pkix] Amendment to CABF Baseline Requirements
>
> 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
>>
>>
>>
>> _______________________________________________
>> pkix mailing list
>> mailto:pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix