rfc/lint_subject_given_name_max_length / rfc/lint_subject_surname_max_length use the incorrect upper bound

[sleevi]

Originally noted by @dzacharo in sleevi/cabforum-docs#36 (comment)

Current Behavior

rfc/lint_subject_given_name_max_length errors if more than 16 characters present
rfc/lint_subject_surname_max_length errors if more than 40 characters present

Expected Behavior

rfc/lint_subject_given_name_max_length and rfc/lint_subject_surname_max_length should only error if more than 32768 characters are present.

Supporting References

From RFC 5280, Appendix A.1

-- attribute data types

Attribute               ::= SEQUENCE {
      type             AttributeType,
      values    SET OF AttributeValue }
            -- at least one value is required

AttributeType           ::= OBJECT IDENTIFIER

AttributeValue          ::= ANY -- DEFINED BY AttributeType

AttributeTypeAndValue   ::= SEQUENCE {
        type    AttributeType,
        value   AttributeValue }

-- suggested naming attributes: Definition of the following
--   information object set may be augmented to meet local
--   requirements.  Note that deleting members of the set may
--   prevent interoperability with conforming implementations.
-- presented in pairs: the AttributeType followed by the
--   type definition for the corresponding AttributeValue

-- Arc for standard naming attributes

id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }

-- Naming attributes of type X520name

id-at-name                AttributeType ::= { id-at 41 }
id-at-surname             AttributeType ::= { id-at  4 }
id-at-givenName           AttributeType ::= { id-at 42 }
id-at-initials            AttributeType ::= { id-at 43 }
id-at-generationQualifier AttributeType ::= { id-at 44 }

-- Naming attributes of type X520Name:
--   X520name ::= DirectoryString (SIZE (1..ub-name))
--
-- Expanded to avoid parameterized type:
X520name ::= CHOICE {
      teletexString     TeletexString   (SIZE (1..ub-name)),
      printableString   PrintableString (SIZE (1..ub-name)),
      universalString   UniversalString (SIZE (1..ub-name)),
      utf8String        UTF8String      (SIZE (1..ub-name)),
      bmpString         BMPString       (SIZE (1..ub-name)) }

What this section is saying is that the AttributeType of id-at-surname and id-at-givenName are of type X520name, which is a DirectoryString of maximum length ub-name, which is defined later as:

--  specifications of Upper Bounds MUST be regarded as mandatory
--  from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
--  Upper Bounds

-- Upper Bounds
ub-name INTEGER ::= 32768

The current lints are bsed on ub-given-name-length and ub-surname-length, but these lengths are not used by the AttributeTypeAndValue field of the DN, but by the PersonalName /TeletexPersonalName of BuiltInStandardAttributes of an ORAddress

The revised module, in RFC 5912, Section 14 makes this clearer, with the following ASN.1 module:

  id-at-surname           AttributeType ::= { id-at 4 }
  at-surname ATTRIBUTE ::= { TYPE X520name IDENTIFIED BY id-at-surname }

  id-at-givenName         AttributeType ::= { id-at 42 }
  at-givenName ATTRIBUTE ::=
      { TYPE X520name IDENTIFIED BY id-at-givenName }

  -- Directory string type --

  DirectoryString{INTEGER:maxSize} ::= CHOICE {
      teletexString    TeletexString(SIZE (1..maxSize)),
      printableString  PrintableString(SIZE (1..maxSize)),
      bmpString        BMPString(SIZE (1..maxSize)),
      universalString  UniversalString(SIZE (1..maxSize)),
      uTF8String       UTF8String(SIZE (1..maxSize))
  }

  X520name ::= DirectoryString {ub-name}

[CBonnell]

After discussing this further (see sleevi/cabforum-docs#36 (comment)), it was determined that a 64-character limit for givenName and surname is the path forward.

[christopher-henderson]

Thanks folks!

If I'm understanding this conversation right, the decision for a 64 character length is hinged on the idea that the 32k value from 5280 is informative and that the 64 value from the ITU is normative, thus overriding 5280s informative 32k?

@CBonnell @sleevi did I read that right (just want to make sure that any code changes that I make I actually understand 😛 )?

[sleevi]

@christopher-henderson Close! 5280 is normative at 32K. In parallel, X.509 was originally normative at 64, then informative at 32K. So the CABF side settled on the smallest normative value, even though the requirements didn’t chronologically overlap, as a way of minimizing compat risks.

[christopher-henderson]

Thank you @sleevi !

hmmm then perhaps the rfc_lint should check for 32k and there should be a new cabfbr_lint added that checks 64? For citation/effective date purposes, is it in the BR?

[sleevi]

@christopher-henderson No. I would still think we want a warning for >64, since that dates to X.509/88, which probably means fixing this and adding a new lint for the new level. Alternatively, deferring fixing this lint until it’s in the BRs is an alternative 😅😇

[christopher-henderson]

@sleevi Hmmm then how about in the RFC lint we have today we...

// Argh, I can't remember if (1..limit) is inclusive or not and I can't find it in the appendix
if <= 64 {
    pass
} else if <= 32768 {
   warn
} else {
   why is your name "John the Fisherman" repeated ten thousand times?
}

And then once it's in BRs we can add that lint as a straight forward must be <= 64 under the right category.