IETF Logo Mail Archive

Re: [pkix] [Editorial Errata Reported] RFC5280 (4274)

mrex@sap.com (Martin Rex) Fri, 20 February 2015 16:03 UTC

Return-Path: <mrex@sap.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47921A8789 for <pkix@ietfa.amsl.com>; Fri, 20 Feb 2015 08:03:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.151
X-Spam-Level:
X-Spam-Status: No, score=-5.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
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 dNcET6n3SSSi for <pkix@ietfa.amsl.com>; Fri, 20 Feb 2015 08:03:21 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B801A854B for <pkix@ietf.org>; Fri, 20 Feb 2015 08:03:21 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3716F2AF41; Fri, 20 Feb 2015 17:03:18 +0100 (CET)
X-purgate-ID: 152705::1424448199-000007DF-77195847/0/0
X-purgate-size: 1023
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
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 11D3542F06; Fri, 20 Feb 2015 17:03:18 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 094B11B1C3; Fri, 20 Feb 2015 17:03:18 +0100 (CET)
In-Reply-To: <D10C4A99.A78CB%stefan@aaa-sec.com>
To: Stefan Santesson <stefan@aaa-sec.com>
Date: Fri, 20 Feb 2015 17:03:18 +0100
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: <20150220160318.094B11B1C3@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/mSSCZR89imjL1gvMDM3REU6L6dQ>
X-Mailman-Approved-At: Mon, 23 Feb 2015 07:20:52 -0800
Cc: stefans@microsoft.com, i.matveychikov@securitycode.ru, pkix@ietf.org, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (4274)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: <http://www.ietf.org/mail-archive/web/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, 20 Feb 2015 16:03:23 -0000

Stefan Santesson wrote:
>
> These size limitations are gone in the current edition of X.520
> 
> In X.520 2001 edition, surname as example was defined as:
> 
> Where Directory string is size limited by the upper bound ub-surname
> 
> ub-surname         
> INTEGER      ::=       64
> 
> In the current edition of X.520 (102012) the definition is instead:
> 
> Where UnboundedDirectoryString no longer is bounded to the old ub-surname
> size limit.
> 
> The same is true for all attributes listed in this errata.


This change in X.520 (2012) seems to be entirely irrelevant to PKIX.
PKIX (rfc5280, 2008) is based on X.509 (2005).

I remember when I asked for a correction of an obvious flaw in
PKIX that was based on the same flaw in X.509 (2005) in the same
fashion that this flaw had already been fixed in X.509 (2008),
but there was pretty violent opposition to "fixing" it -- potentially
because this would make implementations of this flaw retroactively
incompliant with PKIX.


-Martin

v2.23.0 | Report a Bug | By Email