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

[Carl Wallace <[e-mail]>]

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" <[e-mail]> 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:[e-mail]] On Behalf Of Stefan Santesson
>Sent: Monday, February 23, 2015 3:05 PM
>To: [e-mail]
>Cc: [e-mail]; [e-mail]; [e-mail]
>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" <[e-mail]> 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
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/pkix
>
>
>_______________________________________________
>pkix mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pkix
>
>_______________________________________________
>pkix mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pkix