Subject: Inconsistencies between RFC 3280 and X.509/X.520

From: "David A. Cooper" <[email-masked]>
Date: Thu, 24 Aug 2006 17:42:10 -0400

All,

In researching the confusion related to RFC 3280's description of the 
encoding of attributes that use the DirectoryString type, I encountered 
two places in the ASN.1 modules in RFC 3280 (and 3280bis) that are 
inconsistent with either X.509 or X.520.  (I have not thoroughly 
compared these documents, so I cannot guarantee that there are not any 
other inconsistencies.)

First, in X.520 the value of ub-name is 64 whereas in RFC 3280 the value 
of ub-name is 32768.  ub-name is used to specify the maximum length of 
the following attributes: name, surname, givenName, initial, and 
generationQualifier.

Second, X.509 defines EDIParty as:

      EDIPartyName ::= SEQUENCE {
          nameAssigner [0] DirectoryString {ub-name} OPTIONAL,
          partyName      [1] DirectoryString {ub-name} }

whereas RFC 3280 defines EDIParty as

      EDIPartyName ::= SEQUENCE {
           nameAssigner          [0]     DirectoryString OPTIONAL,
           partyName               [1]     DirectoryString }

So, in X.509 there is a size constraint on both the nameAssigner and 
partyName strings (they must be between 1 and 64 characters).  In RFC 
3280, there is no constraint on the length of the strings.

I would like to modify 3280bis so that it is consistent with X.509 and 
X.520.  However, since the ASN.1 that appears in 3280bis is the same as 
the ASN.1 in RFC 3280 and RFC 2459, I want to ensure that changing these 
items to be consistent with X.509 and X.520 will not cause any backwards 
compatibility issues.

So, I would like to know if changing the ASN.1 in 3280bis would cause 
problems for any existing implementations.  For example, if there are 
systems that use the attributes mentioned above with string lengths that 
violate length constraints in X.520.

Thanks,

Dave

---

From: Steven Legg <[email-masked]>
Date: Fri, 25 Aug 2006 09:47:53 +1000

David,

The annex of X.520 in which ub-name and the other upper bounds are defined has
always been non-normative. The particular values to which the upper bounds are
set are merely suggestions, and implementations are free to set whatever upper
bounds they like. Thus RFC 3280 is not incorrect in setting ub-name to
something other than 64.

Regards,
Steven