[cabfpub] Data Request on Internal Names used in CNs or SANs of SSL/TLS Certificate

Tue Jun 18 18:34:03 UTC 2013

On last Friday, each CA should have received the following message.  In
fact, many of you have already responded to ICANN.  In case you were missed,
here is the email message:

If you’ve been following recent discussions on the CAB Forum email list,
then you might be aware that the CA/Browser Forum is working with ICANN to
obtain CA responses to the following questions and request for data about
certificates issued to non-public names (a practice that is being phased out
by the CA/Browser Forum’s Baseline Requirements).  Your response to ICANN
BEFORE THE END OF NEXT WEEK – BY JUNE 21st will be greatly appreciated, and
information will be aggregated with that of all other CAs to inform ICANN’s
gTLD delegation process.  ICANN has explained that individual CAs will NOT
be named with any specific response to any of the questions below.  Further
explanation about this request appears further below.

Questions:

1.       Are any of your publicly trusted CAs allowed to issue certificates
to non-public domain names?

(Y/N)        Additional response, if desired:  

2.       Do you allow external third parties (subordinate/cross-signed CAs,
registration agents, etc.) to approve issuance of these type of certificates
under your publicly trusted root CA?  

(Y/N)        Additional response, if desired:  

3.       Do you have policies or procedures that define or restrict the
issuance of certificates with non-public domain names? 

(Y/N)        Additional response, if desired:  

4.       What issues are of concern from your CA operation's perspective
with regard to the introduction of new TLDs at the root of the public DNS?

5.       Who from your CA will communicate with people in ICANN to discuss
these issues from your perspective and that of your customers/constituents?

Name:  

Title:

Email Address:

Telephone number:

6.       What recommendations can be offered for how to introduce new TLDs
at the public DNS root?

7.       How can further coordination between ICANN and CA operators occur?

8.       Do you currently issue SSL/TLS certificates with
non-public/Internal names in the CN or SAN?   

(Y/N)        Additional response, if desired:  

9.       If you have issued any of these internal name SSL/TLS certificates,
how many (total) of these certificates do you have outstanding?  

10.   For these certificates, please provide a spreadsheet, table, or
delimited text file with at least the following three fields:  full string
of the non-public name in the CN or SAN; year of expiry; and number/count of
each.  The following table is provided as an example.

Non-public name in CN or SAN

Certificate Expiration Year

Count

(Optional)

Certificate type [See note]

www.foo.bar

2013

8

SSL/TLS

www.foo.bar

2014

6

SSL/TLS

*.bar

2013

37

SSL/TLS

foo.bar

2014

14

SSL/TLS

bar

2013

856

SSL/TLS

mail.foo.bar

2015

3

S/MIME

[NOTE:  Additional information about other types of certificates will be
helpful.  For instance, how many publicly trusted S/MIME / client
certificates with internal (RFC-822-type) names do you have currently issued
and for what names?]

Further Explanation About this Information Request

Please reply to Francisco Arias and Tomofumi Okubo from ICANN with this
information.  They are copied on this email and are in charge of ICANN’s
study of the potential security impacts of the applied-for new-gTLD strings
in relation to namespace collisions with non-delegated TLDs that may be in
use in private namespaces, including their use in X.509 digital
certificates.  It is critical that they have empirical data to determine how
widespread the use of internal name certificates is and how likely they are
to collide with the names in new gTLD applications, including the risks
associated with delegating new gTLDs with names that could appear in
internal name certificates issued to someone not related to the new gTLD.
By the end of next week (June 21), they need anonymous statistical data to
begin ascertaining how many certificates with non-public domain names have
been issued and how many are still valid in the following categories:

+        internal names used

+        certificate lifetimes

+        certificate type

+        country-of-origin

+        organization

Although it may be difficult to provide specifics in the last of these two
categories, it is imperative that you provide the internal names and
expiration dates for any SSL/TLS certificates issued with internal names.  

For clarification, the certificate types of primary concern:

§  are publicly trusted--for example, they chain up to a public key that has
been embedded or delivered as a self-signed trust anchor in any of several
widely distributed OS software, browsers, such as Windows, Apple OS/iOS,
Mozilla, Opera, Google, etc.  This includes certificates issued by entities
who you have cross-signed by your root to provide greater ubiquity among
older versions of OS and web browser software;

§  have not been revoked, or expired (especially if they do not contain any
CDP or AIA OCSP URI), or for any other reason might be considered “valid” by
an OS or similar Internet-DS-aware software; 

§  are used for SSL/TLS communication.  For example, they

o   have the basic SSL certificate profile

o   have EKUs for client and server TLS,  etc.

o   are issued to encrypt communication between web servers, mail servers,
etc. or

o   otherwise indicate that the corresponding key pair may be used for such
purposes;

§  contain a non-public name in the CN or in one of the SAN fields.  Such as
names:

o   outside of the currently defined delegated namespace that is managed  by
ICANN

o   not routable by the externally routable, public DNS

o   not considered to be a fully qualified domain name (FQDN)

o   a single, dot-less, word string, e.g. “serv1” 

o   some alphanumeric value as the CN or SAN name that is considered a
hostname, netbios name, used for internal routing, etc. 

If you have any further questions or concerns, contact information for
Francisco Arias is as follows:

Francisco Arias

gTLD Registry Technical Liaison, ICANN

Mobile: +1 310 880 6112

Skype: farias555

Jabber: farias at jabber.org, francisco.arias at jabber.icann.org

PGP: 1FDE 819F 7BEC 1CB2 127E EE54 9A4D 337B D510 E397

ICANN will contact you next week about the status of your response. 

We look forward to your firm and prompt support of this important effort.

Yours sincerely,

Ben Wilson

Chair, CA/Browser Forum

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130618/ea193259/attachment-0002.html>