Re: [pkix] Amendment to CABF Baseline Requirements

[Erwann Abalea <[e-mail]>]

Bonjour,

2017-04-06 22:39 GMT+02:00 Peter Bowen <[e-mail]>:

>
> On Thu, Apr 6, 2017 at 12:24 PM Russ Housley <[e-mail]> wrote:
>
>> The comment in the UpperBounds ASN.1 module (the 8th edition) says:
>>
>> -- EXPORTS All
>> -- The types and values defined in this module are exported for use in
>> the other ASN.1
>> -- modules contained within these Directory Specifications, and for the
>> use of other
>> -- applications which will use them to access Directory services. Other
>> applications
>> -- may use them for their own purposes, but this will not constrain
>> extensions and
>> -- modifications needed to maintain or improve the Directory service.
>>
>> X.509 is part of the Directory Specifications, so they are not advisory.
>>
>> It looks like ITU-T increased the length of the organizational unit name
>> in the most recent edition.
>>
>> RFC 5280 says:
>>
>> ub-organization-name-length INTEGER ::= 64
>> ub-organizational-unit-name-length INTEGER ::= 32
>>
>> The UpperBounds ASN.1 module (the 8th edition) says:
>>
>> ub-organization-name                       INTEGER ::= 64
>> ub-organizational-unit-name                INTEGER ::= 64
>>
>> So, we may already be in a place where implementations conforming to
>> X.509 will produce a certificate that cannot be decoded by an
>> implementation that conforms to RFC 5280.
>>
>> I wish we gad gotten a heads-up …
>
>
> It is even worse. 7th and 8th (and maybe prior releases) removed the usage
> of ub- from the schema. The schema itself no longer bounds DirectoryStrings
> and X.509 explicitly says they are unbounded.
>

X.520 2005 defines the attributes using the DirectoryString{} parameterized
type, while the 2008 edition uses the UnboundedDirectoryString type.

RFC5912, which proposes ASN.1 modules for certificates and other related
things, still uses the DirectoryString{} variant.

-- 
Erwann.