Re: Amendment to CABF Baseline Requirements

Rob Stradling <[email protected]>
Newsgroups gmane.ietf.x509
Message-ID <[email protected]>
Russ, RFC5280 includes all of the following:

ub-organization-name INTEGER ::= 64
ub-organizational-unit-name INTEGER ::= 64
ub-organization-name-length INTEGER ::= 64
ub-organizational-unit-name-length INTEGER ::= 32

The *-name upper bounds apply to X.500 DNs, whereas IINM the 
*-name-length upper bounds apply to the x400Address GeneralName type.

On 06/04/17 20:24, Russ Housley 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 …
>
> 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

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.