Re: [pkix] Amendment to CABF Baseline Requirements<

mrex@sap.com (Martin Rex) Fri, 07 April 2017 13:01 UTC

Return-Path: <mrex@sap.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 81676127977 for <pkix@ietfa.amsl.com>; Fri, 7 Apr 2017 06:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.42
X-Spam-Level:
X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 3_-20eCTP4MO for <pkix@ietfa.amsl.com>; Fri, 7 Apr 2017 06:01:48 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C274B1201F8 for <pkix@ietf.org>; Fri, 7 Apr 2017 06:01:32 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3w008C0Y5jz25w7; Fri, 7 Apr 2017 15:01:31 +0200 (CEST)
X-purgate-ID: 152705::1491570091-00003836-172B3310/0/0
X-purgate-size: 1689
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3w008B4CkpzGq1S; Fri, 7 Apr 2017 15:01:30 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 87CC81A684; Fri, 7 Apr 2017 15:01:30 +0200 (CEST)
In-Reply-To: <CAK6vND9-oxL_acNk21D36UeXHqUM0Rz57cpB_zpCJaTJMPeZ2g@mail.gmail.com>
To: Peter Bowen <pzbowen@gmail.com>
Date: Fri, 7 Apr 2017 15:01:30 +0200 (CEST)
CC: Ben Wilson <ben.wilson@digicert.com>, Russ Housley <housley@vigilsec.com>, IETF PKIX <pkix@ietf.org>
Reply-To: mrex@sap.com
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20170407130130.87CC81A684@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/icAhX49EDqT3AJADiRWckr1teTk>
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:01:50 -0000

Peter Bowen wrote:
>
> Russ Housley <housley@vigilsec.com> wrote:
>>
>> 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.


It's actually worse than that.  What newer revisions of X.509 and X.520 say
is explicitly irrelevant for rfc5280.  rfc5280 is firmly bolted
onto the limits of the 08/2005 edition of X.509 !

A while ago I wanted rfc5280-update to adopt the X.509 11/2008 fix
for the CRL processing semantics of what is a formally provable
specification defect in X.509 08/2005 and rfc5280 -- and I was faced
with violent oppostion in PKIX WG (potentially by implementors of
the broken semantics), which insisted on the broken semantics to
remain wedlocked to the defect in X.509 08/2005.


With respect to the suggested change of lifting the limitations:
I'm violently opposed to removing these limits, because subject DNames
exceeding these limits are likely going to face interop problems with the
installed base of our (non-browser) software.


-Martin