Re: [pkix] Amendment to CABF Baseline Requirements

Carl Wallace <carl@redhoundsoftware.com> Mon, 10 April 2017 21:31 UTC

Return-Path: <carl@redhoundsoftware.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 8A7D8126C22 for <pkix@ietfa.amsl.com>; Mon, 10 Apr 2017 14:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 UE-Ohc7GLhoI for <pkix@ietfa.amsl.com>; Mon, 10 Apr 2017 14:31:44 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 B0B2D126BF7 for <pkix@ietf.org>; Mon, 10 Apr 2017 14:31:43 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id d131so11972239qkc.3 for <pkix@ietf.org>; Mon, 10 Apr 2017 14:31:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VphNL8D64UXJ7JzYoFIM9BVRWlDuHHJTd+PCDfr1XMU=; b=Zj8PmbJMMCxVEq7IZ/BLkRWILzEp+8YLBI0+rf58qRXBAjGrqBqjYiIEyHbNXdaKoX gTlNDF6XsiU7u+S+HKbaDETraSuLnv/mfC4aSvcfn2LfH4cIjo3jVAqSn6IfWoMRu9mT t09jYHB2M8Mx06qaPkSu3q8ApdW3bwc1l13MU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VphNL8D64UXJ7JzYoFIM9BVRWlDuHHJTd+PCDfr1XMU=; b=g7Lr/S0BmGM5X6s6+uWW1jDslyKBbp9cMvhoB4x13ewJ6nhMHsHTvBFqNc0m01NPTP 5VHih5/IpvuvTqvXZqZM7cvW2prjGAiPmHBaUHgEBDGyIsZkdG5oZtBvGSws8ZOVLUKQ lJNhNjETpW9p96fYO/KTxqKeyvw9hAeqe8dObMXo6DoO/L4YwbAb66x4ENmiUGiDgtUS p59SvsvH2UeG2t608qHQO2o7r7wb+40LuRBhORdjjkwPbHvXnJyPwhyILxW0YPFJ6p8t tDbwvjCcq9jlyBIgz1YbGLEel7fIeM0jL2mXjjIp5IN+k7ewB/12B6xwv7Sft5uDpBRm RP2A==
X-Gm-Message-State: AFeK/H0H4i7BqdXFzUa4jXQOJiGotlhn3JEajjhw9hJU1qCZfbW4fMeP6WxXAl4niYkc5g==
X-Received: by 10.55.134.2 with SMTP id i2mr52308547qkd.43.1491859902757; Mon, 10 Apr 2017 14:31:42 -0700 (PDT)
Received: from ?IPv6:2600:1000:b020:5545:8d3d:deb4:3c8c:18c8? ([2600:1000:b020:5545:8d3d:deb4:3c8c:18c8]) by smtp.gmail.com with ESMTPSA id x33sm3080948qtc.22.2017.04.10.14.31.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Apr 2017 14:31:42 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-AA83D147-C8E9-4878-A43F-DDDF3DD65D22
Mime-Version: 1.0 (1.0)
From: Carl Wallace <carl@redhoundsoftware.com>
X-Mailer: iPhone Mail (14B100)
In-Reply-To: <002b01d2b224$28ff4330$7afdc990$@augustcellars.com>
Date: Mon, 10 Apr 2017 17:31:41 -0400
Cc: Jeremy Rowley <jeremy.rowley@digicert.com>, Russ Housley <housley@vigilsec.com>, Erik Andersen <era@x500.eu>, IETF PKIX <pkix@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <A2802EE5-666B-432B-92EE-6CD939AC85A7@redhoundsoftware.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> <CAK6vND9-oxL_acNk21D36UeXHqUM0Rz57cpB_zpCJaTJMPeZ2g@mail.gmail.com> <CA+i=0E5Bh=_b1ZK2T_Y9bj6GivtOJq2Y23i071=wS=jph68tog@mail.gmail.com> <09BE38C5-7B5B-45B0-BC5F-5FCB1164F864@vigilsec.com> <000001d2b041$050c2310$0f246930$@x500.eu> <2D820AC4-81D0-44AC-BBE8-B8C74BD43BB0@vigilsec.com> <b3547c2da5394c23ae5971e4d1b0f1d3@EX2.corp.digicert.com> <002b01d2b224$28ff4330$7afdc990$@augustcellars.com>
To: Jim Schaad <ietf@augustcellars.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/EIocvnkqRJCWm6kw3Leexml_pj4>
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: Mon, 10 Apr 2017 21:31:47 -0000

Defining new OIDs for the new jumbo values seems like the right thing to do. 

> On Apr 10, 2017, at 1:59 PM, Jim Schaad <ietf@augustcellars.com> wrote:
> 
>  
> Jeremy,
>  
> My expectation is that this would be a relaxation on the issuing of certificates for web servers.
>  
> I would worry that the relaxation would be general rather than just focused on web servers.  Additionally, things other than browsers will attempt to contact these servers
>  
> Jim
>  
> From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Jeremy Rowley
> Sent: Monday, April 10, 2017 9:41 AM
> To: Russ Housley <housley@vigilsec.com>om>; Erik Andersen <era@x500.eu>
> Cc: IETF PKIX <pkix@ietf.org>
> Subject: Re: [pkix] Amendment to CABF Baseline Requirements
>  
> Hi Russ - Considering the CA/Browser Forum rules only applies to browser user agents, are you aware of any actual interoperability issues?
>  
> From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley
> Sent: Saturday, April 8, 2017 11:47 AM
> To: Erik Andersen <era@x500.eu>
> Cc: IETF PKIX <pkix@ietf.org>
> Subject: Re: [pkix] Amendment to CABF Baseline Requirements
>  
> Erik:
>  
> The CA/Browser Forum seems to be finding the upper bounds in the X.500 5th edition and RFC 5280.  I’m not sure how to relax them without introducing interoperability concerns.
>  
> Russ
>  
>  
> On Apr 8, 2017, at 4:20 AM, Erik Andersen <era@x500.eu> wrote:
>  
> The change was made in the sixth edition of X.520 (2008). It was primarily driven by Hoyt Kesterson and by some X.500/LDAP vendors. Hoyt was generally against such limitations, as the future is difficult to predict. X.500/LDAP vendors were concerned about interworking between X.500 and LDAP (that does not have upper bounds). You may have noticed that ASN.1 information objects now also contains LDAP specific fields allowing also new attribute types to be usable also in an LDAP environment without the need for additional specifications.
>  
> I insisted that the upper bounds should be kept in an informative annex to be used by those having a requirement to limit the sizes.
>  
> I could, if you feel it relevant, try to suggest a Defect Report to X.509 saying that it is strongly recommend to observe the upper bounds specified in X.520. I will also try to get such a statement into any smart grid security standard that references X.509.
>  
> Erik
> Fra: pkix [mailto:pkix-bounces@ietf.org] På vegne af Russ Housley
> Sendt: 07 April 2017 22:43
> Til: IETF PKIX <pkix@ietf.org>
> Emne: Re: [pkix] Amendment to CABF Baseline Requirements
>  
> The ASN.1 modules that were posted by Erik confirm that the upper bounds have been removed for all of the naming attributes in the SelectedAttributeTypes module.
>  
> UnboundedDirectoryString ::= CHOICE {
>   teletexString    TeletexString(SIZE (1..MAX)),
>   printableString  PrintableString(SIZE (1..MAX)),
>   bmpString        BMPString(SIZE (1..MAX)),
>   universalString  UniversalString(SIZE (1..MAX)),
>   uTF8String       UTF8String(SIZE (1..MAX)) }
>  
> Russ
>  
>  
> On Apr 7, 2017, at 3:15 AM, Erwann Abalea <eabalea@gmail.com> wrote:
>  
> Bonjour,
>  
> 2017-04-06 22:39 GMT+02:00 Peter Bowen <pzbowen@gmail.com>om>:
>  
> On Thu, Apr 6, 2017 at 12:24 PM Russ Housley <housley@vigilsec.com> 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 …
>  
> It is even worse. 7th and 8th (and maybe prior releases) removed the usage of ub- from the schema. The schema itself no longer bounds DirectoryStrings and X.509 explicitly says they are unbounded. 
>  
> X.520 2005 defines the attributes using the DirectoryString{} parameterized type, while the 2008 edition uses the UnboundedDirectoryString type.
>  
> RFC5912, which proposes ASN.1 modules for certificates and other related things, still uses the DirectoryString{} variant.
>  
> -- 
> Erwann.
>  
> _______________________________________________
> 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