Re: Amendment to CABF Baseline Requirements
Erwann Abalea <[email protected]>
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <CA+i=0E5Bh=_b1ZK2T_Y9bj6GivtOJq2Y23i071=wS=jph68tog@mail.gmail.com> |
Bonjour, 2017-04-06 22:39 GMT+02:00 Peter Bowen <[email protected]>: > > On Thu, Apr 6, 2017 at 12:24 PM Russ Housley <[email protected]> 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. _______________________________________________ pkix mailing list [email protected] https://www.ietf.org/mailman/listinfo/pkix