Re: Amendment to CABF Baseline Requirements

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.



>
> Russ
>
>
>
> > On Apr 6, 2017, at 2:55 PM, Ben Wilson <[email protected]> wrote:
> >
> > Thanks, Michael.    Is it relevant that Annex C to X.520 (2012) states,
> > "(This annex does not form an integral part of this Recommendation |
> > International Standard.)" whereas before (1988) it stated,  "This Annex
> is
> > part of the Recommendation."?
> >
> > From: pkix [mailto:[email protected]] On Behalf Of Michael StJohns
> > Sent: Thursday, April 6, 2017 10:55 AM
> > To: [email protected]
> > Subject: Re: [pkix] Amendment to CABF Baseline Requirements
> >
> > Hi Ben -
> >
> > IETF 5280 et al are profiles of the X.509 documents.  The upper length
> > bounds for orgnaizationName and commonName fields in 5280 is no different
> > than the upper bounds specified in X.509 (at least as of the 2014
> > document).  I would suggest that you will pretty much break any and all
> > implementations of X.509 clients that rely or enforce this limit as well
> as
> > any code that generates certificate requests.
> >
> > I will note that overloading text fields with structured data is
> generally
> > not a good idea - as you've found.
> >
> > Mike
> >
> >
> >
> > On 4/6/2017 12:24 PM, Ben Wilson wrote:
> > Does anyone want to comment on my draft amendment to the CA/Browser
> Forum’s
> > Baseline Requirements for SSL/TLS Certificates which would remove the
> > 64-character limit on the commonName and organizationName,  as an
> exception
> > to RFC 5280?  The text of the relevant Baseline Requirement provision is
> > found below with the proposed additional language in ALL CAPS.  The
> reason
> > for the first change (commonName) is there are FQDNs (in Subject
> Alternative
> > Names) that are longer than 64 characters.  The reason for the second
> change
> > (organizationName) is that there are organizations with names longer
> than 64
> > characters.
> >
> > 7.1.4.2.2.             Subject Distinguished Name Fields
> > a.            Certificate Field: subject:commonName (OID 2.5.4.3)
> > Required/Optional: Deprecated (Discouraged, but not prohibited)
> > Contents: If present, this field MUST contain a single IP address or
> > Fully-Qualified Domain Name that is one of the values contained in the
> > Certificate’s subjectAltName extension (see Section 7.1.4.2.1).
> > MAXIMUM LENGTH:  NO STIPULATION.  (THIS IS AN EXCEPTION TO RFC 5280 WHICH
> > SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.)
> > b.            Certificate Field: subject:organizationName (OID 2.5.4.10)
> > Optional.
> > Contents: If present, the subject:organizationName field MUST contain
> either
> > the Subject’s name or DBA as verified under Section 3.2.2.2. The CA may
> > include information in this field that differs slightly from the verified
> > name, such as common variations or abbreviations, provided that the CA
> > documents the difference and any abbreviations used are locally accepted
> > abbreviations; e.g., if the official record shows “Company Name
> > Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”.
> > Because Subject name attributes for individuals (e.g. givenName
> (2.5.4.42)
> > and surname (2.5.4.4)) are not broadly supported by application software,
> > the CA MAY use the subject:organizationName field to convey a natural
> person
> > Subject’s name or DBA.
> > MAXIMUM LENGTH:  256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 WHICH
> > SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.)
> >
> > Thanks,
> > Ben Wilson
> >
> >
> >
> > _______________________________________________
> > pkix mailing list
> > mailto:[email protected]
> > https://www.ietf.org/mailman/listinfo/pkix
> >
> > _______________________________________________
> > pkix mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/pkix
>
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix
>

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix