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

From: RFC Errata System <[email-masked]>
Date: Thu, 19 Feb 2015 02:43:38 -0800 (PST)

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

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 20 Feb 2015 02:33:08 +0100

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:

>Title               : Internet X.509 Public Key Infrastructure
>Certificate and Certificate Revocation List (CRL) Profile

---

From: [email-masked] (Martin Rex)
Date: Fri, 20 Feb 2015 17:03:18 +0100 (CET)

Stefan Santesson wrote:
>
> These size limitations are gone in the current edition of X.520
> 

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

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 23 Feb 2015 23:05:04 +0100

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:

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

---

From: "Erik Andersen" <[email-masked]>
Date: Wed, 25 Feb 2015 09:25:02 +0100

The upper bound was removed from X.520 from 2008. The upper bound were added
to X.520 already in the first edition from 1988, despite quite strong
opposition. Hard coded upper band could impair future use of the attribute
types.

The major reason for removing the upper bounds was compatibility with LDAP,
which does not have such upper bounds. There was no opposition to the change
within the X.500 community, as X.500 vendors typically also have LDAP
implementations.

If there is a need to refer to a specification without upper bounds, then
refer to X.509 instead of RFC 5280.

Erik

-----Oprindelig meddelelse-----
Fra: pkix [mailto:[email-masked]] På vegne af Martin Rex
Sendt: 20. februar 2015 17:03
Til: Stefan Santesson
Cc: [email-masked]; [email-masked]; [email-masked];
RFC Errata System
Emne: Re: [pkix] [Editorial Errata Reported] RFC5280 (4274)

Stefan Santesson wrote:
> Where UnboundedDirectoryString no longer is bounded to the old 
> ub-surname size limit.
> 

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