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

[Martin Rex <[e-mail]>]

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

This is what has been in common use over the past 15 years,
what makes the most sense and what is the most interoperable.

A "Best Common Practice" (BCP) document ought to be about what is in
use and known to work well, not about some folks disliking what is
there and trying to exert undue pressure and chastise an installed
base that is working perfectly fine.

I do not have a problem with browsers or other application clients
that ignore CN-IDs whenever there is a SAN extension DNSName present
in a servers cert.  But I have a problem with words in a BCP that
are in clear violation of rfc-2119 section 6 last sencence
with the potential to cause interop problems and entirely without
a cause.


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

What is the purpose of marking SAN critical other than having a
number of peers choke on it and reject it?  It's hardly make a
cert more understandable.  An implementation of PKI has no control
over what exactly an application does with a SAN.


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

If the J2EE versions out there would be 100% backwards compatible, then
this problem would be insignificant.  Unfortunately, due to a lack of
planning, there seems to be a release-specific lock-in.

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

No CN would be a pretty bad idea.
If I look at the administrative interfaces, the "handle" to a
digital identity is normally it's CN= content, i.e. when administering
IIS server certs on W2K3.

And if you google around, the amount of documentation that instructs
you to have the fqdn hostname in the CN= part of the cert just everywhere,
the only document that doesn't is the current I-D.


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

I do _not_ like the idea to make multiple CN= matching part of the
standard.  The clients that match on more than one CN= are quite few
(mine does), it never was part of any standard or suggestion and
the behaviour of clients in presence of multiple CN-IDs is difficult
to predict.

Documenting what is there would be reasonable though, i.e.
Most clients will match CN-ID when no SANs are present, but only
the most specific.  Having multiple CN-IDs in a subject name was
never recommended, and only a few clients implement it that way.
Since there are some commercial CAs do a poor job of vetting
subject name components for the CSRs they receive, matching multiple
CN-IDs could make a client that trusts one of those negligent CAs
vulnerable to server identity spoofing.

Having the fqdn server name as a CN-ID in the server certificate
is a well-established tradition, documented in that fashion everywhere,
and many adminstrative user interfaces use the CN part of the subject
distinguished name of a certificate as the prominent identifier
and distinguisher.


> 
> My opinion on steps for improvement from where we are now:
> 
> 1) Clarify CN usage by strongly recommending only 1 CN in a subject.

OK.  Makes sense.


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

OK.  Makes sense.


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

Really bad idea, completely unnecesary and clear violation of
rfc-2116 section 6.

Im pretty sure that every one which strongly cares about this can
make his client ignore CN-IDs when at least one DNSName SAN is
present, so 2) is perfectly sufficient.


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


All the big players have implemented IPv6 and tested interop.

Why don't we shutdown the entire IPv4 internet to force the
users to use IPv6? 


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

Huh?

For the preconfigured trusted CAs shipping with browsers, name constraints
are entirely irrelevent, just as irrelevant to most of the users out there.

Name constraints might be interesting to individual large and hierarchical
organizations that run a CA hierarchy and delegate authority constrained
to name spaces or domains.  On the other hand, I remeber a really
large multi-national (US-originating) company that doesn't run
company-internal CAs because of liability issues.
Which puzzles me, because I believe their legal department is more
sophisticated and experienced than ours, and we've been operating
CAs for company-internal purposes for more than a decade...

But what has name constraints to do with CN-ID?

An organization that can operate a CA hierachy and configure name
constraints, should be perfectly able to equip all of their server
certs with SANs, in which case the software of all of the
"MUST ignore CN-ID if DNSName SAN is present" will reliably
ignore the CN-ID, so that it means no harm.


-Martin

PS: Are you aware that processing name constraints for DNSName SANs
    is still optional in rfc-5280 ("RECOMMENDED"), whereas processing
    name constraints for DirectoryName was already a requirement ("MUST")
    in rfc-2459?