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

From: "David A. Cooper" <[email-masked]>
Date: Wed, 04 Oct 2006 14:18:17 -0400

Steven,

Thanks for pointing this out.  It does appear that while X.509 and X.520 
include ASN.1 in normative annexes that make use of the upper bounds 
that are defined in the UpperBounds module from annex C in X.520, annex 
C is informative.  Annex C in X.520 begins with the following sentence:

        This annex includes all of the suggested upper bound value 
constraints used in
        these Directory Specifications, in the form of the ASN.1 module 
UpperBounds.

So, the upper bounds in X.520 are only suggested values.

I still do not understand why RFCs 2459 and 3280 use a value of 32768 
for ub-name instead of 64 when all of the other upper bounds are the 
same as in X.520, although I have found that RFC 2256 (Lightweight 
Directory Access Protocol (LDAP): Schema for User Applications) also 
specifies an upper bound of 32768 for name.  In RFC 4519, which 
obsoleted RFC 2256, all upper bounds were removed.

In any case, given that the upper bounds in X.520 are not normative, I 
will not change the upper bounds in 3280bis.

Dave

Steven Legg wrote:
>
> 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
>
> David A. Cooper wrote:
>>
>> 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