Re: [pkix] Amendment to CABF Baseline Requirements

["Sill, Alan" <[e-mail]>]

Erik,

Before proceeding with any attempt to deprecate the use of commonName, may I recommend that you read the contents of the OGF’s “Interoperable Certificate Profile” that focuses on non-browser applications of use of directory names, attributes, and extensions in X.509 certificates, such that they are usable by the majority of scientific cyber-infrastructures as supported by the IGTF?

This document is available in its most recent form at https://www.ogf.org/documents/gfd.225.pdf

In particular, commonName is a required component of certificates used in such infrastructures and deprecation would cause a great deal of damage to deployed infrastructures for large-scale grid and cloud computing.

Thanks,
Ala


On Apr 10, 2017, at 10:13 AM, Erik Andersen <[e-mail]<mailto:[e-mail]>> wrote:

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<http://example.com/> will match a.example.com<http://a.example.com/> and b.example.com<http://b.example.com/> but not a.b.example.com<http://a.b.example.com/> nor example.com<http://example.com/>.


Erik
Fra: pkix [mailto:[e-mail]] På vegne af Ben Wilson
Sendt: 06 April 2017 18:24
Til: [e-mail]<mailto:[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
_______________________________________________
pkix mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pkix