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

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