Subject: [pkix] Amendment to CABF Baseline Requirements

From: Ben Wilson <[email-masked]>
Date: Thu, 6 Apr 2017 16:24:11 +0000

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

---

From: Michael StJohns <[email-masked]>
Date: Thu, 6 Apr 2017 12:54:59 -0400

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.
>
> 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.)
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Ben Wilson <[email-masked]>
Date: Thu, 6 Apr 2017 18:55:32 +0000

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-masked]] On Behalf Of Michael StJohns
Sent: Thursday, April 6, 2017 10:55 AM
To: [email-masked]
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

mailto:[email-masked]

---

From: Russ Housley <[email-masked]>
Date: Thu, 6 Apr 2017 15:24:34 -0400

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-masked]> wrote:
> 
> Does anyone want to comment on my draft amendment to the CA/Browser Forums
> Certificates subjectAltName extension (see Section 7.1.4.2.1).
> the Subjects name or DBA as verified under Section 3.2.2.2. The CA may
> abbreviations; e.g., if the official record shows Company Name
> Incorporated, the CA MAY use Company Name Inc. or Company Name. 
> Subjects name or DBA.

---

From: Peter Bowen <[email-masked]>
Date: Thu, 06 Apr 2017 20:39:08 +0000

On Thu, Apr 6, 2017 at 12:24 PM Russ Housley <[email-masked]> wrote:

> 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.
>

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.

> Forum’s
> either

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 7 Apr 2017 09:15:25 +0200

Bonjour,

2017-04-06 22:39 GMT+02:00 Peter Bowen <[email-masked]>:

>> 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.
>>

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.

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 7 Apr 2017 10:11:06 +0200

Hi Russ,

We have not changed upper bounds. I just checked the second edition (1993). It has 64 octets in both cases. RFC 5280 must have made a copy mistake.

We removed upper bounds from the directory specifications to be compatible with LDAP that does not have upper bounds. Either we are compatible with LDAP or with RFC 5280, but with both is not possible.

Erik

-----Oprindelig meddelelse-----
Fra: pkix [mailto:[email-masked]] På vegne af Russ Housley
Sendt: 06 April 2017 21:25
Til: Ben Wilson <[email-masked]>
Cc: IETF PKIX <[email-masked]>
Emne: Re: [pkix] Amendment to CABF Baseline Requirements

-- EXPORTS All

RFC 5280 says:

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

Russ

> International Standard.)" whereas before (1988) it stated,  "This 
> Annex is part of the Recommendation."?
> 
> 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.
> 
> there are FQDNs (in Subject Alternative
> (organizationName) is that there are organizations with names longer 
> than 64 characters.
>  
> 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.

---

From: Rob Stradling <[email-masked]>
Date: Fri, 7 Apr 2017 13:54:20 +0100

Russ, RFC5280 includes all of the following:

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

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

---

From: [email-masked] (Martin Rex)
Date: Fri, 7 Apr 2017 15:01:30 +0200 (CEST)

Peter Bowen wrote:
>
> Russ Housley <[email-masked]> wrote:
>>
>> RFC 5280 says:
>>
>> I wish we gad gotten a heads-up ?
> 

It's actually worse than that.  What newer revisions of X.509 and X.520 say
is explicitly irrelevant for rfc5280.  rfc5280 is firmly bolted
onto the limits of the 08/2005 edition of X.509 !

A while ago I wanted rfc5280-update to adopt the X.509 11/2008 fix
for the CRL processing semantics of what is a formally provable
specification defect in X.509 08/2005 and rfc5280 -- and I was faced
with violent oppostion in PKIX WG (potentially by implementors of
the broken semantics), which insisted on the broken semantics to
remain wedlocked to the defect in X.509 08/2005.

With respect to the suggested change of lifting the limitations:
I'm violently opposed to removing these limits, because subject DNames
exceeding these limits are likely going to face interop problems with the
installed base of our (non-browser) software.

-Martin

---

From: Michael StJohns <[email-masked]>
Date: Fri, 7 Apr 2017 09:23:29 -0400

> We removed upper bounds from the directory specifications to be compatible with LDAP that does not have upper bounds. Either we are compatible with LDAP or with RFC 5280, but with both is not possi…

That's not actually a correct statement.   You can store a compliant 
X.509 certificate in a non-compliant LDAP directory without any 
problems.   It's storing a non-compliant (e.g. 256 byte commonName) 
X.509 certificate in a compliant LDAP or X.500 directory using the 
common name as part of the key that might be the problem.

I.e., a compliant X.509 or PKIX certificate is compatible with LDAP 
regardless of LDAPs waiving of the limits.

Mike

---

From: Russ Housley <[email-masked]>
Date: Fri, 7 Apr 2017 16:43:24 -0400

The ASN.1 modules that were posted by Erik confirm that the upper bounds have been removed for all of the naming attributes in the SelectedAttributeTypes module.

UnboundedDirectoryString ::= CHOICE {
  teletexString    TeletexString(SIZE (1..MAX)),
  printableString  PrintableString(SIZE (1..MAX)),
  bmpString        BMPString(SIZE (1..MAX)),
  universalString  UniversalString(SIZE (1..MAX)),
  uTF8String       UTF8String(SIZE (1..MAX)) }

Russ

> On Apr 7, 2017, at 3:15 AM, Erwann Abalea <[email-masked]> wrote:
> 
> Bonjour,
> 
> 2017-04-06 22:39 GMT+02:00 Peter Bowen <[email-masked] <mailto:[email-masked]>>:
> 
> On Thu, Apr 6, 2017 at 12:24 PM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> 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.

---

From: Russ Housley <[email-masked]>
Date: Fri, 7 Apr 2017 16:51:24 -0400

Rob:

You are absolutely correct!  Thanks for posting the correction.

Russ

> On Apr 7, 2017, at 8:54 AM, Rob Stradling <[email-masked]> wrote:
> 
> The *-name upper bounds apply to X.500 DNs, whereas IINM the *-name-length upper bounds apply to the x400Address GeneralName type.
>

---

From: "Erik Andersen" <[email-masked]>
Date: Sat, 8 Apr 2017 10:20:44 +0200

The change was made in the sixth edition of X.520 (2008). It was primarily driven by Hoyt Kesterson and by some X.500/LDAP vendors. Hoyt was generally against such limitations, as the future is difficult to predict. X.500/LDAP vendors were concerned about interworking between X.500 and LDAP (that does not have upper bounds). You may have noticed that ASN.1 information objects now also contains LDAP specific fields allowing also new attribute types to be usable also in an LDAP environment without the need for additional specifications.

I insisted that the upper bounds should be kept in an informative annex to be used by those having a requirement to limit the sizes.

I could, if you feel it relevant, try to suggest a Defect Report to X.509 saying that it is strongly recommend to observe the upper bounds specified in X.520. I will also try to get such a statement into any smart grid security standard that references X.509.

Erik

Fra: pkix [mailto:[email-masked]] På vegne af Russ Housley
Sendt: 07 April 2017 22:43
Til: IETF PKIX <[email-masked]>
Emne: Re: [pkix] Amendment to CABF Baseline Requirements

Russ

On Apr 7, 2017, at 3:15 AM, Erwann Abalea <[email-masked] <mailto:[email-masked]> > wrote:

Bonjour,

2017-04-06 22:39 GMT+02:00 Peter Bowen <[email-masked] <mailto:[email-masked]> >:

On Thu, Apr 6, 2017 at 12:24 PM Russ Housley <[email-masked] <mailto:[email-masked]> > wrote:

-- EXPORTS All

RFC 5280 says:

-- 

Erwann.

---

From: Russ Housley <[email-masked]>
Date: Sat, 8 Apr 2017 13:46:42 -0400

Erik:

The CA/Browser Forum seems to be finding the upper bounds in the X.500 5th edition and RFC 5280.  I’m not sure how to relax them without introducing interoperability concerns.

Russ

> On Apr 8, 2017, at 4:20 AM, Erik Andersen <[email-masked]> wrote:
> 
> Fra: pkix [mailto:[email-masked] <mailto:[email-masked]>] På vegne af Russ Housley
> Til: IETF PKIX <[email-masked] <mailto:[email-masked]>>
>> On Apr 7, 2017, at 3:15 AM, Erwann Abalea <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Bonjour,
>>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/pkix <https://www.ietf.org/mailman/listinfo/pkix>

---

From: "Erik Andersen" <[email-masked]>
Date: Mon, 10 Apr 2017 17:13:11 +0200

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:[email-masked]] På vegne af Ben Wilson
Sendt: 06 April 2017 18:24
Til: [email-masked]
Emne: [pkix] Amendment to CABF Baseline Requirements

Optional.  

Thanks,

Ben Wilson

---

From: Jeremy Rowley <[email-masked]>
Date: Mon, 10 Apr 2017 16:41:01 +0000

Hi Russ - Considering the CA/Browser Forum rules only applies to browser user agents, are you aware of any actual interoperability issues?

From: pkix [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Saturday, April 8, 2017 11:47 AM
To: Erik Andersen <[email-masked]>
Cc: IETF PKIX <[email-masked]>
Subject: Re: [pkix] Amendment to CABF Baseline Requirements

Erik:

Russ

On Apr 8, 2017, at 4:20 AM, Erik Andersen <[email-masked] <mailto:[email-masked]> > wrote:

Erik

Fra: pkix [ <mailto:[email-masked]> mailto:[email-masked]] På vegne af Russ Housley
Sendt: 07 April 2017 22:43
Til: IETF PKIX < <mailto:[email-masked]> [email-masked]>
Emne: Re: [pkix] Amendment to CABF Baseline Requirements

Russ

On Apr 7, 2017, at 3:15 AM, Erwann Abalea < <mailto:[email-masked]> [email-masked]> wrote:

Bonjour,

2017-04-06 22:39 GMT+02:00 Peter Bowen < <mailto:[email-masked]> [email-masked]>:

On Thu, Apr 6, 2017 at 12:24 PM Russ Housley < <mailto:[email-masked]> [email-masked]> wrote:

-- EXPORTS All

RFC 5280 says:

-- 

Erwann.

_______________________________________________
pkix mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/pkix> https://www.ietf.org/mailman/listinfo/pkix

---

From: Carl Wallace <[email-masked]>
Date: Mon, 10 Apr 2017 12:54:43 -0400

Is mutual auth (even server to server) of no concern?

> On Apr 10, 2017, at 12:41 PM, Jeremy Rowley <[email-masked]> wrote:
>

---

From: "Sill, Alan" <[email-masked]>
Date: Mon, 10 Apr 2017 17:55:03 +0000

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 <[email-masked]<mailto:[email-masked]>> 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

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.

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:[email-masked]] På vegne af Ben Wilson
Sendt: 06 April 2017 18:24
Til: [email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pkix

---

From: Jim Schaad <[email-masked]>
Date: Mon, 10 Apr 2017 10:59:09 -0700

Jeremy,

My expectation is that this would be a relaxation on the issuing of certificates for web servers.

I would worry that the relaxation would be general rather than just focused on web servers.  Additionally, things other than browsers will attempt to contact these servers

Jim

From: pkix [mailto:[email-masked]] On Behalf Of Jeremy Rowley
Sent: Monday, April 10, 2017 9:41 AM
To: Russ Housley <[email-masked]>; Erik Andersen <[email-masked]>
Cc: IETF PKIX <[email-masked]>
Subject: Re: [pkix] Amendment to CABF Baseline Requirements

From: pkix [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Saturday, April 8, 2017 11:47 AM
To: Erik Andersen <[email-masked] <mailto:[email-masked]> >
Cc: IETF PKIX <[email-masked] <mailto:[email-masked]> >
Subject: Re: [pkix] Amendment to CABF Baseline Requirements

Erik:

Russ

Erik

Russ

Bonjour,

-- EXPORTS All

RFC 5280 says:

-- 

Erwann.

---

From: Carl Wallace <[email-masked]>
Date: Mon, 10 Apr 2017 17:31:41 -0400

Defining new OIDs for the new jumbo values seems like the right thing to do. 

> On Apr 10, 2017, at 1:59 PM, Jim Schaad <[email-masked]> wrote:
> 
>  
> Jeremy,
>

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 11 Apr 2017 16:40:58 +0200

Hi Alan,

I have no intention to deprecate commonName. It was a kind of provocation, but I could consider recommending it not to be used in specific environments.

The basic ideas for an attribute specification was that it has a specific syntax and in particular, an associated semantics independent of the environment. By using commonName for all kind of syntaxes and all kind of semantics, this principle has been violated.

Erik

Fra: Sill, Alan [mailto:[email-masked]] 
Sendt: 10 April 2017 19:55
Til: Erik Andersen <[email-masked]>
Cc: Sill, Alan <[email-masked]>; [email-masked]
Emne: Re: [pkix] Amendment to CABF Baseline Requirements

Erik, 

Thanks,

Ala

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

Hi Ben and others,

6.2.15      Domain name

dnsName ATTRIBUTE ::= {

  WITH SYNTAX             DomainName

  LDAP-NAME               {"DNS name"}

  ID                      id-at-dnsName }

8.9.2        DNS name match

  SYNTAX       DomainName

  ID           id-mr-dnsNameMatch }

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

Erik

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

Optional.  

Thanks,

Ben Wilson