Subject: [Spasm] X.509 plans for eai-address

From: "Erik Andersen" <[email-masked]>
Date: Sun, 11 Dec 2016 13:04:52 +0100

The 2016 edition of X.509 has been finally approved and published by ITU-T.
We can now formally start working on new extensions.

We actually have a plan for extending the rfc822Name of the GeneralName in
line with the dNSName as shown below.

-     the dNSName alternative shall be a fully qualified domain name (FQDN).
The domain name 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 one of two 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 an 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. The U-label is as also defined in IETF
RFC 5890.

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

We could consider to extend the GeneralName construct to allow also
U-labels. We believe that the otherName construct adds unnecessary
complexity requiring some, although small, additional processing
requirements, including keeping track of yet another OID,  in a constrained
environment, such as a battery driven sensor.

There is no reason that the LAMPS and the X.509 solutions cannot be
simultaneously available.

We also defined a new attribute type, which is now part of X.520, allowing
unique distinguished name to be to consists of just a single name component.
We plan to create a similar attribute type for internationalized email
addresses.  This may eliminate the need for the subjectAltName extension in
some instances.

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

Erik

---

From: Wei Chuang <[email-masked]>
Date: Mon, 12 Dec 2016 10:08:15 -0800

Hi Erik,

On Sun, Dec 11, 2016 at 4:04 AM, Erik Andersen <[email-masked]> wrote:

> The 2016 edition of X.509 has been finally approved and published by
> ITU-T. We can now formally start working on new extensions.
>
>
>
> –     the dNSName alternative shall be a fully qualified domain name
> (FQDN). The domain name 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.
>
> b)    It is an A-label as defined in IETF RFC 5890, i.e., it starts with
> the "xn--" and is an 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. The U-label is as also defined
> in IETF RFC 5890.
>
> NOTE 1 – An A-label is normally not human readable.
>
>
>
These arguments were discussed on the S/MIME mailing in April.  The
starting point is Sean's arguments which matches yours:
https://www.ietf.org/mail-archive/web/smime/current/msg19129.html

The primary counter argument to the above approach is that will likely
break existing deployed software as mentioned here:
https://www.ietf.org/mail-archive/web/smime/current/msg19130.html
https://www.ietf.org/mail-archive/web/smime/current/msg19131.html

While we can look at some subset of deployed software, it would be next to
impossible to be sure that all software is compatible with the above
approach.

> This would be confusing to implementers.

-Wei

> unique distinguished name to be to consists of just a single name
> component. We plan to create a similar attribute type for internationalized
> email addresses.  This may eliminate the need for the subjectAltName
> extension in some instances.
>
>
> 6.2.15      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.
>
> 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.
>
> 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.
>
> 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.
>
> Erik
>
>
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>
>

---

From: Jim Schaad <[email-masked]>
Date: Mon, 12 Dec 2016 21:39:48 -0800

From: Spasm [mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Sunday, December 11, 2016 4:05 AM
To: LAMPS <[email-masked]>
Subject: [Spasm] X.509 plans for eai-address

[JLS] I would be far more worried about the problems that are going to show
up if you allow a field which only allowed IA5 characters to suddenly accept
UTF8 characters.  This does not happen with the DNS extension that is
currently documented above as it is restricted due to the fact that the puny
code transformation is done first.  However, if you do decide to allow
U-labels to appear in the option of GeneralNames, then any code which does
not know that is going to have potential problems show up.  

I will also note that the approach of keeping only ASCII characters is
possible and was document, but has sense been obsoleted.  This means that
one either needs to change the definition of GeneralNames or use the
extension point.  As above, doing the first is going to potentially lead to
the problems with existing code.

[JLS] I cannot say that I am the least bit happy to see this attribute
appear.  Some of us have been trying to push domain names to always appear
in one place - in GeneralNames and adding a new attribute which can hold
domain names is not helpful.  

Jim

6.2.15      Domain name

dnsName ATTRIBUTE ::= {

  WITH SYNTAX             DomainName

  LDAP-NAME               {"DNS name"}

  ID                      id-at-dnsName }

 

Erik

---

From: "Erik Andersen" <[email-masked]>
Date: Mon, 19 Dec 2016 10:15:47 +0100

Hi Wei Chuang,

I looked into the links you provided, and I am not sure, I understand Jim’s comment. An implementation that might know the otherName, but not the OID for the included name, may also crash. His comment also assumes that applications in general do not understand extension marks.

It is understandable that SMIME people is quite concerned about the integrity of the email address and that has to be taken into account, but it also has to be realised that we are moving into new areas where traditional PKI thinking is not sufficient. We cannot impose a PKI build for an online banking system onto small IoT entities. The same goes to some degree for smart grid. Fat has to be trimmed. As few externals as possible, minimum processing requirements, more efficient and faster validations, etc.

The main thing right now seems to create a new attribute type for e-mail addresses and possibly also covering JIDs, as specified in RFC 6122, to allow short, but unique distinguished names.

Kind regards, 

Erik

Fra: Wei Chuang [mailto:[email-masked]] 
Sendt: 12 December 2016 19:08
Til: Erik Andersen <[email-masked]>
Cc: LAMPS <[email-masked]>
Emne: Re: [Spasm] X.509 plans for eai-address

Hi Erik,

On Sun, Dec 11, 2016 at 4:04 AM, Erik Andersen <[email-masked] <mailto:[email-masked]> > wrote:

The 2016 edition of X.509 has been finally approved and published by ITU-T. We can now formally start working on new extensions.

We actually have a plan for extending the rfc822Name of the GeneralName in line with the dNSName as shown below.

–     the dNSName alternative shall be a fully qualified domain name (FQDN). The domain name 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)    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 an 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. The U-label is as also defined in IETF RFC 5890.

We could consider to extend the GeneralName construct to allow also U-labels. We believe that the otherName construct adds unnecessary complexity requiring some, although small, additional processing requirements, including keeping track of yet another OID,  in a constrained environment, such as a battery driven sensor.

These arguments were discussed on the S/MIME mailing in April.  The starting point is Sean's arguments which matches yours:

The primary counter argument to the above approach is that will likely break existing deployed software as mentioned here:

While we can look at some subset of deployed software, it would be next to impossible to be sure that all software is compatible with the above approach. 

There is no reason that the LAMPS and the X.509 solutions cannot be simultaneously available.

-Wei

We also defined a new attribute type, which is now part of X.520, allowing unique distinguished name to be to consists of just a single name component. We plan to create a similar attribute type for internationalized email addresses.  This may eliminate the need for the subjectAltName extension in some instances.

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 names (IDN).

dnsName ATTRIBUTE ::= {

  WITH SYNTAX             DomainName

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

Erik

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 19 Dec 2016 15:50:56 -0500

> I looked into the links you provided, and I am not sure, I understand Jim’s comment. An implementation that might know the otherName, but not the OID for the included name, may also crash. His comm…

Erik, in my experience, implementation handle an unknown OID mire gracefully than an unexpected tag within a CHOICE.  In this particular case, you need to remember that earlier versions of X.509 did not include extension marks in the syntax for GeneralName.  So, and implementation did not expect the structure to be extended in this fashion.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Mon, 19 Dec 2016 17:32:30 -0800

From: Spasm [mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Monday, December 19, 2016 1:16 AM
To: 'Wei Chuang' <[email-masked]>
Cc: 'LAMPS' <[email-masked]>
Subject: Re: [Spasm] X.509 plans for eai-address

Hi Wei Chuang,

[JLS] An implementation that knows otherName should never crash because it does not know the OID for the included name.  The rules in this case say that you ignore what you do not understand here (with the caveat of criticality).  Given that namy of the IETF documents do not have any of the extension marks in the ASN.1, I would expect that many implementations do not either understand or implement them.

[JLS] Given that currently most of the IoT world looks like URIs, I am not sure where you would think this new stuff goes.  It might be of relevance for jabber ids, but again that is not generally an IoT world.  

[JLS] And saying things like name constraints are no longer of interest.  I have very little confidence in the entire concept of unqiue distinguished names especially in the world of attackers who are trying to impersonate.

Jim

Kind regards, 

Erik

Fra: Wei Chuang [mailto:[email-masked]] 
Sendt: 12 December 2016 19:08
Til: Erik Andersen <[email-masked] <mailto:[email-masked]> >
Cc: LAMPS <[email-masked] <mailto:[email-masked]> >
Emne: Re: [Spasm] X.509 plans for eai-address

Hi Erik,

-Wei

6.2.15      Domain name

dnsName ATTRIBUTE ::= {

  WITH SYNTAX             DomainName

  LDAP-NAME               {"DNS name"}

  ID                      id-at-dnsName }

Erik

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 20 Dec 2016 10:14:06 +0100

We will take Russ’ and Jim’s comments into account. We will put the idea about a new choice in GeneralName on hold, as it does not currently have high priority. However, it seems like we cannot never add a new alternative to a CHOICE until the sun burns out. This could result in many new copy specifications, like a new version of GeneralName, e.g, GeneralNameExt.

It seems a general problem, if progress is made difficult due to backward implementations.

Erik

Fra: Spasm [mailto:[email-masked]] På vegne af Jim Schaad
Sendt: 20 December 2016 02:33
Til: 'Erik Andersen' <[email-masked]>; 'Wei Chuang' <[email-masked]>
Cc: 'LAMPS' <[email-masked]>
Emne: Re: [Spasm] X.509 plans for eai-address

From: Spasm [mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Monday, December 19, 2016 1:16 AM
To: 'Wei Chuang' <[email-masked] <mailto:[email-masked]> >
Cc: 'LAMPS' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Spasm] X.509 plans for eai-address

Hi Wei Chuang,

Jim

Kind regards, 

Erik

Hi Erik,

-Wei

6.2.15      Domain name

dnsName ATTRIBUTE ::= {

  WITH SYNTAX             DomainName

  LDAP-NAME               {"DNS name"}

  ID                      id-at-dnsName }

Erik