Subject: [certid] fyi: assessment of present compatibility of CN-ID, DNS-ID (SAN:dNSName) by Paul Tiemann (digicert) (was: Need to define "most specific RDN")

From: =JeffH <[email-masked]>
Date: Sun, 03 Oct 2010 17:45:03 -0700

[ forwarding with permission of the author (I didn't write the below) in order 
that we have this info publicly available in the archives ]

Subject: Fwd: [certid] Need to define "most specific RDN"
From: Paul Tiemann <[email-masked]>
Date: Fri, 16 Jul 2010 11:56:11 -0600 (10:56 PDT)
To: Jeff Hodges <[email-masked]>, Kaspar Brand 
<[email-masked]>

(Here's what I think I... oops, I sent it only to Kaspar -- I'll fix that
and send it to certid)

---------- Forwarded message ----------
From: Paul Tiemann <[email-masked]>
Date: Fri, Jul 16, 2010 at 9:07 AM
Subject: Re: [certid] Need to define "most specific RDN"
To: Kaspar Brand <[email-masked]>

On Wed, Jul 14, 2010 at 11:07 PM, Kaspar Brand <[email-masked]> wrote:

 > On 14.07.2010 17:47, Nelson B Bolyard wrote:
 >
 > I'm doubtful if adding a MUST NOT for CN-IDs (vs. a SHOULD NOT) would
 > have a considerable impact on future CA practices. Most of them probably
 > don't want to risk compatibility issues with legacy implementations
 > (which don't recognize the subjectAltName extension).
 >
 >
You're right.  CAs are most likely to want maximum compatibility, and there
are still enough devices and clients in circulation that only do Common Name
matching.

See this page for a few devices that are known not to handle SANs:

http://www.digicert.com/subject-alternative-name-compatibility.htm

According to my research, and DigiCert's experience issuing certificates
with and without SAN extensions, here is a simple hierarchy of best-to-worst
compatibility for server certificates with only one FQDN (ex:
www.digicert.com) to match:

1) For best compatibility, issue the certificate with CN=www.digicert.com,
do not include SAN extension at all.

Everything currently supports non-wildcard CN matching.  Some platforms do
not support wildcards (Windows Mobile 5)

2) Only slightly less compatible: issue with CN=www.digicert.com, and
non-critical SAN=(dnsName=www.digicert.com)

There was some talk about always including the SAN extension a few months
ago on the CA/Browser forum.  To try to be a good CA citizen, I went ahead
and made a change so that our certificates would do this (add a 1-element
SAN even if there is only one server ID to be covered by the certificate)

I had to roll back, because within two days (it might have been the very
next day) we got a call from a customer whose server was not accepting the
certificate because the SAN extension was present.  I remember it was some
kind of issue with a blackberry server.  I asked for details about their
platform and version, but I don't believe I got them and I forgot to go back
and ask again.  For now, we're back to using method #1.

That said, there's a good chance I could switch back to this and never hear
of the problem again.  At least half of all our certificates include the SAN
extension and we've almost never had issues with products choking on the
mere presence of the extension (that really is very rare)

3) Still less compatible: issue with CN=www.digicert.com, and CRITICAL
SAN=(dnsName=www.digicert.com)

When the SAN extension is marked critical, some Java based clients or
servers will choke.  Perhaps it's all Java versions older than 2007, but
sadly that describes a fair amount of enterprise customers who run various
legacy applications on very old JVM versions.

4) Least compatible: issue with CN=DigiCert, Inc or no CN at all, and
non-critical SAN=(dnsName=www.digicert.com)

I agree with Nelson's recent post, however, that I would prefer it if the CN
were restricted to just one spot.  There are too many browsers already
behaving differently when there are more than one CN in a subject.  Dan
Kaminsky found Firefox, IE, and openssl behave differently when they see
more than one CN in a subject.  Almost all certificates I'm aware of have
only one CN in them -- and making it even more rare would be a step forward
in my opinion.

My opinion on steps for improvement from where we are now:

1) Clarify CN usage by strongly recommending only 1 CN in a subject.

2) Encourage ubiquitous usage of the SAN extension, so that almost all CA
issued certificates include the SAN extension, only deviating from that for
reasons of compatibility with legacy servers or clients which choke on the
SAN.

3) Make strong recommendations to stop using CN-IDs in subject

4) Stop using server-IDs in common names experimentally

On the topic of name constraints: What if there are ways to push Name
Constraints forward without necessarily having to wait for all legacy
clients to die and all the niche clients to become compatible?  Here's one
idea (admittedly not past v0.1 in my head)

1) Have the major browser vendors add a small mechanism to detect
certificates with Name Constraint violations, and give them a central,
automated way to "report" a certificate found with violated name constraints
which might pose a risk for all the non-compliant browsers and clients.
With something like that in place, the major browsers will be able to handle
name constraints correctly, and the constraints policing feature would help
to erase the incentive that the operator of a constrained CA certificate
would have for violating the constraints to trick legacy devices.

2) NetCraft could possibly help with Name Constraints monitoring, at least
for the public internet.

3) Eventually at some date in the distant future, all the legacy devices
will be dead, and all clients will be compatible, and the programs in #1 and
#2 could be dismantled.

Paul Tiemann
(CTO, DigiCert)

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 03 Oct 2010 22:25:33 -0400

> that we have this info publicly available in the archives ]
[...]
> are still enough devices and clients in circulation that only do Common Name
[...]

Essentially the same message is already in the archive:

http://www.ietf.org/mail-archive/web/certid/current/msg00256.html

But thanks for sending it again: I realized I wanted to reply to the
part about name constraints.

-- 
Matt

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Oct 2010 10:34:50 -0600

On 10/3/10 6:45 PM, =JeffH wrote:
> [ forwarding with permission of the author (I didn't write the below) in
> order that we have this info publicly available in the archives ]
> 

<snip/>

Jeff, what is your take? Here's what I see...

> 1) Clarify CN usage by strongly recommending only 1 CN in a subject.

I think we already do that, because in our working copy Section 3,
bullet 6 states:

       The certificate MAY contain more than one DNS-ID, but SHOULD NOT
       contain more than one CN-ID.

> reasons of compatibility with legacy servers or clients which choke on the

Again I think we already do that, because in our working copy Section 3,
bullets 1 through 3 state:

   1.  The certificate SHOULD include a "DNS-ID" (i.e., a subjectAltName
       entry of type dNSName) if possible as a baseline for
       interoperability.

   2.  If the service using the certificate deploys a technology in
       which a server is discovered by means of DNS SRV records
       [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate
       SHOULD include an "SRV-ID" (i.e., a subjectAltName entry of type
       otherName whose name form is SRVName as specified in [SRVNAME]);
       furthermore, multiple instances of the "SRV-ID" identifier type
       are allowed.

   3.  If the service using the certificate deploys a technology in
       which a server is typically associated with a URI (e.g., this is
       true of [SIP]), then the certificate SHOULD include a URI-ID
       (i.e., a subjectAltName entry of type uniformResourceIdentifier);
       the scheme SHALL be that of the protocol associated with the
       service type and the authority component SHALL be the fully-
       qualified DNS domain name of the service; furthermore, multiple
       instances of the "URI-ID" identifier type are allowed.

> 3) Make strong recommendations to stop using CN-IDs in subject

Done via bullet 5 in Section 3 of our working copy:

   5.  Even though many deployed clients still check for the CN-ID
       within the certificate subject name, the certificate SHOULD NOT
       represent the server's fully-qualified DNS domain name in a
       CN-ID.

> 4) Stop using server-IDs in common names experimentally

That's an implementation and deployment issue, not a spec issue,
although we would hope that folks do some experiments and report on the
results.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/