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

From: Sharon Boeyen <[email-masked]>
Date: Wed, 4 Mar 2015 13:21:41 +0000

I agree Carl. I see no reason to remove the size limits and believe doing so would cause interop problems.

-----Original Message-----
From: Carl Wallace [mailto:[email-masked]]
Sent: Thursday, February 19, 2015 9:31 PM
To: Stefan Santesson; RFC Errata System; [email-masked]; [email-masked]; [email-masked]; Sharon Boeyen; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (4274)

Is this really an errata? Seems more like an invitation to interoperability problems.  Same issues will apply to 5912 too is this route is pursued.

On 2/19/15, 8:33 PM, "Stefan Santesson" <[email-masked]> wrote:

>These size limitations are gone in the
>current edition of X.520
>
>In X.520 2001 edition, surname as example was defined as:
>
>surname ATTRIBUTE  ::=  {
>SUBTYPE OF    name
>WITH SYNTAX   DirectoryString{ub-surname}
>ID            id-at-surname
>}
>
>
>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:
>
>surname ATTRIBUTE ::= {
>SUBTYPE OF    name
>WITH SYNTAX   UnboundedDirectoryString
>LDAP-SYNTAX   directoryString.&id
>LDAP-NAME     {"sn"}
>ID                       id-at-surname
>}
>
>
>Where UnboundedDirectoryString no longer is bounded to the old 
>ub-surname size limit.
>
>The same is true for all attributes listed in this errata.
>
>/Stefan
>
>
>
>On 19/02/15 11:43, "RFC Errata System" <[email-masked]> wrote:
>
>>The following errata report has been submitted for RFC5280, "Internet
>>X.509 Public Key Infrastructure Certificate and Certificate Revocation 
>>List (CRL) Profile".
>>
>>--------------------------------------
>>You may review the report below and at:
>>http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=4274
>>
>>--------------------------------------
>>Type: Editorial
>>Reported by: Ilya V. Matveychikov <[email-masked]>
>>
>>Section: A.1
>>
>>Original Text
>>-------------
>>-- Naming attributes of type X520CommonName:
>>--   X520CommonName ::= DirectoryName (SIZE (1..ub-common-name))
>>
>>...
>>
>>-- Naming attributes of type X520LocalityName:
>>--   X520LocalityName ::= DirectoryName (SIZE (1..ub-locality-name))
>>
>>...
>>
>>-- Naming attributes of type X520StateOrProvinceName:
>>--   X520StateOrProvinceName ::= DirectoryName (SIZE (1..ub-state-name))
>>
>>...
>>
>>-- Naming attributes of type X520OrganizationName:
>>--   X520OrganizationName ::=
>>--          DirectoryName (SIZE (1..ub-organization-name))
>>
>>...
>>
>>-- Naming attributes of type X520OrganizationalUnitName:
>>--   X520OrganizationalUnitName ::=
>>--          DirectoryName (SIZE (1..ub-organizational-unit-name))
>>
>>...
>>
>>-- Naming attributes of type X520Title:
>>--   X520Title ::= DirectoryName (SIZE (1..ub-title))
>>
>>...
>>
>>-- Naming attributes of type X520Pseudonym:
>>--   X520Pseudonym ::= DirectoryName (SIZE (1..ub-pseudonym))
>>
>>
>>Corrected Text
>>--------------
>>-- Naming attributes of type X520CommonName:
>>--   X520CommonName ::= DirectoryString (SIZE (1..ub-common-name))
>>
>>...
>>
>>-- Naming attributes of type X520LocalityName:
>>--   X520LocalityName ::= DirectoryString (SIZE (1..ub-locality-name))
>>
>>...
>>
>>-- Naming attributes of type X520StateOrProvinceName:
>>--   X520StateOrProvinceName ::=
>>--          DirectoryString (SIZE (1..ub-state-name))
>>
>>...
>>
>>-- Naming attributes of type X520OrganizationName:
>>--   X520OrganizationName ::=
>>--          DirectoryString (SIZE (1..ub-organization-name))
>>
>>...
>>
>>-- Naming attributes of type X520OrganizationalUnitName:
>>--   X520OrganizationalUnitName ::=
>>--          DirectoryString (SIZE (1..ub-organizational-unit-name))
>>
>>...
>>
>>-- Naming attributes of type X520Title:
>>--   X520Title ::= DirectoryString (SIZE (1..ub-title))
>>
>>...
>>
>>-- Naming attributes of type X520Pseudonym:
>>--   X520Pseudonym ::= DirectoryString (SIZE (1..ub-pseudonym))
>>
>>
>>Notes
>>-----
>>Appendix B.  ASN.1 Notes says that:
>>
>>   For many of the attribute types defined in [X.520], the
>>   AttributeValue uses the DirectoryString type.  Of the attributes
>>   specified in Appendix A, the name, surname, givenName, initials,
>>   generationQualifier, commonName, localityName, stateOrProvinceName,
>>   organizationName, organizationalUnitName, title, and pseudonym
>>   attributes all use the DirectoryString type.  X.520 uses a
>>   parameterized type definition [X.683] of DirectoryString to specify
>>   the syntax for each of these attributes.  The parameter is used to
>>   indicate the maximum string length allowed for the attribute.  In
>>   Appendix A, in order to avoid the use of parameterized type
>>   definitions, the DirectoryString type is written in its expanded form
>>   for the definition of each of these attribute types.  So, the ASN.1
>>   in Appendix A describes the syntax for each of these attributes as
>>   being a CHOICE of TeletexString, PrintableString, UniversalString,
>>   UTF8String, and BMPString, with the appropriate constraints on the
>>   string length applied to each of the types in the CHOICE, rather than
>>   using the ASN.1 type DirectoryString to describe the syntax.
>>
>>There is nothing about DirectoryName type here. So comments in ASN.1 
>>in
>>A.1 are wrong and DirectoryName should be fixed to DirectoryString.
>>
>>Instructions:
>>-------------
>>This erratum is currently posted as "Reported". If necessary, please 
>>use "Reply All" to discuss whether it should be verified or rejected.
>>When a decision is reached, the verifying party (IESG) can log in to 
>>change the status and edit the report, if necessary.
>>
>>--------------------------------------
>>RFC5280 (draft-ietf-pkix-rfc3280bis-11)
>>--------------------------------------
>>Title               : Internet X.509 Public Key Infrastructure
>>Certificate and Certificate Revocation List (CRL) Profile
>>Publication Date    : May 2008
>>Author(s)           : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R.
>>Housley, W. Polk
>>Category            : PROPOSED STANDARD
>>Source              : Public-Key Infrastructure (X.509)
>>Area                : Security
>>Stream              : IETF
>>Verifying Party     : IESG
>>
>
>
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: Stephen Kent <[email-masked]>
Date: Thu, 05 Mar 2015 12:23:38 -0500

Even though the current version of X.520 removes the size bounds, 5280 
has not always tracked the most recent versions of corresponding X.5xx 
series specs, intentionally.

The interoperability concerns cited by several long-time contributors to 
PKIX make me believe that we should reject this errata.

Steve