Re: [pkix] Amendment to CABF Baseline Requirements

["Erik Andersen" <[e-mail]>]

Hi Ben and others,

I responded to the upper bound issue before reading Ben’s question. I have a
comment not related to the commonName attribute type. The commonName is
being (mis)used for all kind of things, so you cannot know what the syntax
really is, which should cause interworking problems. The use of commonName
should possibly be deprecated.

As to use the commonName for holding an FQDN, it is a little problematic.
The matching rule for FQDNs is a little more complicated than the one for
commonName. X.520 has a dsnName attribute type and as it is rather new it
has not upper bound specification. It is defined as:


6.2.15      Domain name


A value of attribute type dnsName is used for holding a DNS domain name,
which may be an internationalized domain name (IDN).

 

dnsName ATTRIBUTE ::= {

  WITH SYNTAX             DomainName

  EQUALITY MATCHING RULE  dnsNameMatch

  LDAP-SYNTAX             dnsString.&id

  LDAP-NAME               {"DNS name"}

  ID                      id-at-dnsName }

 

DomainName ::= UTF8String (CONSTRAINED BY { -- Conforms to the format of a
(internationalized) domain name. -- })

A value of the DomainName data type shall be in the syntax, as specified by
section 2.3.1 of IETF RFC 5890 meaning that a domain name is a sequence of
labels in the letters, digits, hyphen (LDH) format separated by dots.

A label may be in three formats:

a)     All characters in the label are from the Basic Latin collection as
defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D,
0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". The
maximum length is 63 octets.

b)     It is an A-label as defined in IETF RFC 5890, i.e., it starts with
the "xn--" and is a U-label converted to valid ASCII characters as in item
a) using the Punycode algorithm defined by IETF RFC 3492. The converted
string shall be maximum 59 octets. To be valid, it shall be possible for an
A-label to be converted to a valid U-label.

NOTE 1 – An A-label is normally not human readable.

c)     It is a U-label as defined in IETF RFC 5890, i.e., it contains
characters outside the Basic Latin collection. A valid U-label shall not
include any characters that are not included in the restricted Unicode
repertoire as defined by IETF RFC 5892 and it shall be convertible to a
valid A-label as defined in item b). A valid U-label may be more than 63
octets.

NOTE 2 – In a constraint environment, it is recommended to use a domain name
whenever possible, according to item a).

NOTE 3 – When used as a naming attribute, a unique distinguished name may be
constructed using only this attribute type.

An attribute of type dnsName to be used as a distinguished name in a
public-key certificate or in an attribute certificate shall be a
fully-qualified domain name (FQDN), i.e., it shall identify a particular
entity. An FQDN may have an asterisk ('*') as an additional leftmost label,
which is a substitute (wildcard) for all labels at the next levels of
subdomains of the domain identified by the FQDN without the asterisk. An
attribute of type dnsName holding an FQDN with a wildcard label may in some
cases be used in the subject component of an end-entity public-key
certificate.

The corresponding matching rule is defined as:


8.9.2        DNS name match


The dnsNameMatch compares two values of type dnsName for equality and is
defined as:

 

dnsNameMatch MATCHING-RULE ::= {

  SYNTAX       DomainName

  LDAP-SYNTAX  dnsString.&id

  LDAP-NAME    {"dnsNameMatch"}

  ID           id-mr-dnsNameMatch }

The equality matching is performed label for label. If the number of the
labels in the two attribute values are different, the rule shall return
FALSE. The rule shall return TRUE for each pair of labels matched for the
rule to return TRUE for the two values. Otherwise, it shall return FALSE.
The matching of the individual labels shall be performed as follows:

a)     If one of the labels to be compared is of the type defined in item a)
of clause 6.2.15 and the other label is either an A-label or a U-label as
defined in IETF RFC 5890, the rule shall return FALSE.

b)     If the two labels are of the same type, they shall be compared
following the rules for caseIgnoreMatch.

c)     If one the labels is of type A-label and the other one is of type
U-label, the latter shall be converted to an A-label before comparison
following the rules for caseIgnoreMatch.

In addition, the following applies if one or both of the values have
wildcard ('*') labels:

d)     If at least one of the values contains more than one wildcard label
or if a wildcard label is not the leftmost label, the rule shall return
FALSE.

e)     If one or both the values has a wildcard as the leftmost label, the
remaining labels shall be matched as stated in a) to c) above and shall
return TRUE or FALSE accordingly.

NOTE – The effect of the wildcard match is that *.example.com will match
a.example.com and b.example.com but not a.b.example.com nor example.com.

 

Erik

Fra: pkix [mailto:[e-mail]] På vegne af Ben Wilson
Sendt: 06 April 2017 18:24
Til: [e-mail]
Emne: [pkix] Amendment to CABF Baseline Requirements

 

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