Re: [certid] Need to define "most specific RDN"

[Paul Tiemann <[e-mail]>]

On Wed, Jul 14, 2010 at 11:07 PM, Kaspar Brand <[e-mail]> 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 about CAs:  They'll 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)