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

From: Jeremy Rowley <[email-masked]>
Date: Tue, 10 Mar 2015 16:57:15 +0000

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

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Carl Wallace <[email-masked]>
Date: Tue, 10 Mar 2015 13:03:13 -0400

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" <[email-masked]> 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.
>
>

---

From: Jeremy Rowley <[email-masked]>
Date: Tue, 10 Mar 2015 17:07:13 +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:[email-masked]] 
Sent: Tuesday, March 10, 2015 11:03 AM
To: Jeremy Rowley; Stefan Santesson; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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" <[email-masked]> wrote:

>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.
>
>