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

Jeremy Rowley <jeremy.rowley@digicert.com> Tue, 10 March 2015 17:07 UTC

Return-Path: <jeremy.rowley@digicert.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 B84EF1A0277 for <pkix@ietfa.amsl.com>; Tue, 10 Mar 2015 10:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.212
X-Spam-Level:
X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 QPlq5PLlqhsK for <pkix@ietfa.amsl.com>; Tue, 10 Mar 2015 10:07:15 -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 02EC51A00D6 for <pkix@ietf.org>; Tue, 10 Mar 2015 10:07:14 -0700 (PDT)
From: Jeremy Rowley <jeremy.rowley@digicert.com>
To: Carl Wallace <carl@redhoundsoftware.com>, Stefan Santesson <stefan@aaa-sec.com>, "mrex@sap.com" <mrex@sap.com>
Thread-Topic: [pkix] [Editorial Errata Reported] RFC5280 (4274)
Thread-Index: AQHQTLDziNJ9Mq+yGEeIq10XjkMKL5z6KXIAgAUcEgCAFsZroIAAZ3SA//+cCGA=
Date: Tue, 10 Mar 2015 17:07:13 +0000
Message-ID: <e2dbd37a649d41589799c09183e3a472@EX2.corp.digicert.com>
References: <D10C4A99.A78CB%stefan@aaa-sec.com> <20150220160318.094B11B1C3@ld9781.wdf.sap.corp> <D1116051.A7AFC%stefan@aaa-sec.com> <d22851aaeb4c4e7f85ade832165ec3df@EX2.corp.digicert.com> <D1249B16.2FA28%carl@redhoundsoftware.com>
In-Reply-To: <D1249B16.2FA28%carl@redhoundsoftware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [107.0.5.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/lBxAVJUMXuvVF41lsbjXvMMAK3E>
Cc: "pkix@ietf.org" <pkix@ietf.org>, "stefans@microsoft.com" <stefans@microsoft.com>, "i.matveychikov@securitycode.ru" <i.matveychikov@securitycode.ru>
Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (4274)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
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: <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: Tue, 10 Mar 2015 17:07:19 -0000

Yeah - I withdraw that request and support.  I realized after I sent it just how badly the change would affect interoperability. 

Jeremy

-----Original Message-----
From: Carl Wallace [mailto:carl@redhoundsoftware.com] 
Sent: Tuesday, March 10, 2015 11:03 AM
To: Jeremy Rowley; Stefan Santesson; mrex@sap.com
Cc: pkix@ietf.org; stefans@microsoft.com; i.matveychikov@securitycode.ru
Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (4274)

Many applications are built with ASN.1 encoders/decoders generated by
ASN.1 compilers that honor the constraints expressed in the ASN.1 modules.
Removing the size constraints would immediately create new interoperability problems for these applications. You could achieve what you are after by using one org attribute for DBA name and one org attribute with the org name. There is no limit on how many org attributes you express in a DN. A pair of org attributes may even be more readable for the user than a single oversized value.

On 3/10/15, 12:57 PM, "Jeremy Rowley" <jeremy.rowley@digicert.com> wrote:

>For SSL, the indication of 5280 compliant is through use of OIDs 
>asserting compliance with the CAB Forum baseline requirements, which 
>requires conformity to 5280.
>
>I'd be interested in seeing the size limit for names removed.  If you 
>look at the CAB Forum's EV Guidelines, the O field is used to convey 
>both DBA and org name info about a subject. Squeezing in this 
>information (or a Romanized version of an international name) is 
>difficult, often resulting in a truncation of the name.  Including the 
>entire name would provide greater insight on the certificate holder.
>
>
>-----Original Message-----
>From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson
>Sent: Monday, February 23, 2015 3:05 PM
>To: mrex@sap.com
>Cc: pkix@ietf.org; stefans@microsoft.com; 
>i.matveychikov@securitycode.ru
>Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (4274)
>
>Hi Martin,
>
>My post was just a reflection of the apparent reality.
>
>There is no sign in a certificate that declares it to be RFC 5280 
>conformant.
>RFC 5280 compliance is an agreement between systems, using the profile 
>for interop.
>
>The size limitations on attributes is however severely broken, and 
>highly unmotivated.
>
>For these reasons they are usually ignored and replaced with common sense.
>
>We might not want to go through the pain to correct this, but the facts 
>stays the same.
>
>/Stefan
>
>
>On 20/02/15 17:03, "Martin Rex" <mrex@sap.com> wrote:
>
>>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
>>
>>_______________________________________________
>>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