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

From: Kaspar Brand <[email-masked]>
Date: Sun, 04 Jul 2010 11:59:47 +0200

On 30.06.2010 19:51, Peter Saint-Andre wrote:
> On 6/30/10 11:46 AM, Martin Rex wrote:
>> I'm actually confused by refering to one end with "most significant" and
>> the other with "most specific".  Couldn't we just drop the "most significant"
>> entirely and use "least specific" / "most specific" for the two ends?
> 
> Given that we never use the term "most significant" in this I-D, I'd say
> we can remove any mention of it.

I would definitely recommend that.

It's still present in two places in -07, though:

> 2.2.  Subject Naming in PKIX Certificates
>
>    [...]                                            In the DER encoding
>    of a DN, the RDNs are always in order from most significant to least
>    significant (i.e., the first RDN is most significant and the last RDN
>    is least significant); however, in the string representation of a DN
>    as used in various protocols and data formats, the RDNs might be
>    ordered from most significant to least significant (e.g., this is
>    true of LDAP) or from least significant to most significant.

>    3.1.3.  Server Identity Check
> 
>    [...]                                     For example, some X.500
>    implementations order the RDNs in a DN using a left-to-right (most
>    significant to least significant) convention instead of LDAP's right-
>    to-left convention.

After another look at X.501 and some of the LDAP RFCs (2247 in
particular), I'm getting to the conclusion that the "most specific vs.
most significant" distinction is actually a construct which mainly
originates from / applies to the DNS world - and through various RFCs
(among them 2818) somehow made its way into the PKIX world... but it
doesn't seem that for a "classic" X.500 DN there is really a notion of
"most/least specific". [1]

Section 2.2 in -07 also has

>    Because a DN is an ordered sequence, order is preserved in the string
>    representation of a DN.  However, because an RDN is an unordered
>    group of attribute-type-and-value pairs, the string representation of
>    an RDN can differ from the canonical DER encoding; in the canonical
>    encoding, the RDN that is deepest in the tree (and that therefore
>    distinguishes the relative name) is called the "most specific" RDN.

I don't quite understand what you mean by "in the canonical    encoding,
the RDN that is deepest in the tree" - I think the second sentence is
about the (canonical) encoding of an RDN, and an RDN itself can't have a
"most specific" RDN, obviously...

In any case, using both "specific" and "significant" (and mixing in
"most" and "least") in the text is definitely confusing, as pointed out
by Martin. Let's stick to one, at most.

Kaspar

[1] Re-reading section 3.1 in RFC 2818 can actually confirm this
hypothesis, under the following interpretation: "the (most specific)
Common Name field in the Subject field of the certificate MUST be used"
can be understood to mean the domain name which has the highest number
of DNS labels: if the subject has CN=foo.example.net and CN=example.net,
then the first one must be used for the identity check (it's more
specific than CN=example.net), irrespective of its position in the DER
encoded subject, actually.

---

From: Ludwig Nussel <[email-masked]>
Date: Tue, 6 Jul 2010 14:35:29 +0200

> encoded subject, actually.

That interpretation at least doesn't require knowledge about
certificate encoding subtleties. It's ambiguous though. You could
have several CN with an equal number of dots after all. Just think
of this one:
http://www.mail-archive.com/[email-masked]/msg61198.html

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 06 Jul 2010 18:42:13 +0200

> http://www.mail-archive.com/[email-masked]/msg61198.html
X.500 defines a tree structure, the nodes are relative names put
into a hierarchie represented by a DN. a prefix of the elements in
the sequence defines thus a "subtree", and the relative name of a leaf
is the rightmost element, In a tree the most specific element a leaf
and moving backwards defined less specific.

There is no need at all to talk about binary encoding, or DER or
whatever. A DN is a sequence of relative names forming a tree
structure when interpreted in the X.500 context. This is thus
one clear interpretation of 'most specific'  (for a RDN).

But: Since RDN can have multiple occurences of AVAs with the
same type, (and one my even construct interpretations as above)
it is not clear whether anything else than putting exactly one AVA
with type Common Name into the very last component and not
having any AVA with type Common name may lead to unexpected
results, making 2818 unclear.

At least I think one can agree that Common name in the last RDN
as the only AVA is "safe". What can one do else:

- some other RDNs without after it? probably ok, but not sure.
- other RDNs with Common Name before? oh oh, like th \0 attack
- multiple AVAs in the same RDN. maybe.
...

Anyway, since there is no good reason not to put a subjectAltName,
I do not think that one shouls say anything more than
"If you use a Common Name other than in the most simple case one
  may run a risk not to be interpreted correctly."

replace:

    The subject field of a PKIX certificate is defined as an X.501 type
    Name and known as a Distinguished Name (DN) -- see [X.501] and
    [PKIX].....  and so on

by

    In essence, Subject (and Issuer) are essentially are defined in PKIX and
    X.50x/ISOnnnn  as ASN.1 type DistinguishedName which is (in ASN.1 terms)
    a a row of elements (SEQUENCE OF in ASN.1 terms)
    of type RelativeDistinguishedName (RDN).

    In the directory context and in the PKIX context
    this defines a hierarchical tree structure
    from left to right and least to most specific, i.e. a prefix defines
    a subtree and the relative name of a leaf is the rightmost one
    in the sequence.
    An RDN is a collection (SET OF in ASN.1 terms) of elements of
    the ASN.1 type  AttributeValueAssertion (AVA).  ... leaving as
    exercise a definition of AVA.

    Thus, regarding this, the usage of "most specific RDN of type Common
    Name" in HTTPS is not precise enough.
    Furthermore,  string representations (as well as graphical ones)
    may confuse
    users because of two possible interpretations of an implied order of 
RDNs.
    e.g. LDAP define the order ....
    and, historically, Openssl uses the other direction.

By the way: Certificates are not binary objects. At best:

Certificates are structures defined as ASN.1 types, and (almost always) 
transmitted in
an encoding called DER... which may be encapsulated in base64, i.e.
becoming textual ... etc. Anyway, does this matter here?

Compare: The last paragraph of 2.2 doesn't use DER.

SubjectAltname is not a 'field', it is an occurence of type
Extension identified (... let's say ... ) as SunjectAltName.

Certificate subjects may have alternate names represented as Extension
identified as SubjectAltName.

Thus: 2.2 can be greatly simplified IMO.

ave fun.

---

From: Kaspar Brand <[email-masked]>
Date: Wed, 07 Jul 2010 08:41:55 +0200

> one clear interpretation of 'most specific'  (for a RDN).

I don't think that this is the issue here - it's the wording in RFC 2818
which is the source of all this... well, I'd say, mess:

   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.)

Reading "(most specific) Common Name field" as "Common Name in the most
specific RDN" is one interpretation, but I'm not sure if it's the only
one. And given the attention this issue received on the list so far, it
also seems somewhat ironic that this "requirement" is only appearing in
parentheses in an RFC which happens to be informational only, BTW...

>   may run a risk not to be interpreted correctly."

A BCP document should say more that just state how implementations
currently behave, I think [1].

Leaving that "most specific", peculiar requirement from RFC 2818 aside,
I don't believe that there are really strong arguments against treating
multiple CNs in the subject different from a subjectAltName extension
with multiple dNSName entries - why not consider "a match in any one of
the set[s]" acceptable...? [2]

Clarifying/fixing that blurry "(most specific)" statement from RFC 2818
would be highly desirable for the new BCP, IMO. If by this we can get
away with a term whose meaning isn't intuitively clear (compare this
e.g. to "left-most DNS label"), then I would definitely consider that a
plus.

Kaspar

[1] From RFC 2026: a BCP document
   [...] is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function."

[2] I'm aware of Nelson's message at
http://www.ietf.org/mail-archive/web/certid/current/msg00115.html, but
am wondering to how many CAs the statement about unvetted CNs really
applies. In my sample from 2009, the multi-CN certs (211 out of ~90,000)
are basically limited to one of the so-called "commercial CAs", and I'm
pretty sure that this CA does (/claims to) vet all CNs... what they
actually do is mirror the entries from the subjectAltName extension in
the subject DN. (It happens to be the same CA as the one appearing in
the message referenced by Ludwig, for the sake of completeness.)

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Jul 2010 11:22:54 -0600

> parentheses in an RFC which happens to be informational only, BTW...

Is there a good security reason for this "requirement"? I don't see one.

> currently behave, I think [1].

For sure.

> the set[s]" acceptable...? [2]

That seems eminently sensible to me. (Whether any given CA would issue
such a certificate is a matter of CA policy...)

> e.g. to "left-most DNS label"), then I would definitely consider that a

Would removing all mention of "(most specific)" qualify as clarification?

> the subject DN. 

Yes, I think that's what is happening in the example cited.

Peter

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

---

From: Kaspar Brand <[email-masked]>
Date: Tue, 13 Jul 2010 07:09:50 +0200

> Would removing all mention of "(most specific)" qualify as clarification?

-08 looks good to me, generally speaking, but in addition to the
implementation note at the end of 2.2 I would add some wording to 4.4.4
which states that a) if multiple CN-IDs are found in the subject, all of
them should be checked and b) this deliberately allows broader matching
than the one originally "specified" in [HTTP-TLS] and [GIST].

(Finally, let me add that browsers such as MSIE, Opera or Safari already
implement this kind of multi-CN checking - if there is no subjectAltName
extension, they will go through all CNs and look for a match [1]).

Kaspar

[1] E.g., cf. this discussion from 2004 on apple-cdsa:
http://lists.apple.com/archives/apple-cdsa/2004/Apr/msg00012.html

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 13 Jul 2010 09:32:06 -0700

At 7:09 AM +0200 7/13/10, Kaspar Brand wrote:
>them should be checked

Wait, wait. The spec says in a few places that there must only be a single CN. If you add that (which was taken out of -08), you have to change all of them. I propose that we stay with the current MUST for a single CN.

> and b) this deliberately allows broader matching

Yes, saying that would be good.

>extension, they will go through all CNs and look for a match [1]).

That doesn't make it a best current practice.

--Paul Hoffman, Director
--VPN Consortium

---

From: Kaspar Brand <[email-masked]>
Date: Tue, 13 Jul 2010 20:24:36 +0200

On 13.07.2010 18:32, Paul Hoffman wrote:
>> implementation note at the end of 2.2 I would add some wording to
>> 4.4.4 which states that a) if multiple CN-IDs are found in the
>> subject, all of them should be checked
> 
> Wait, wait. The spec says in a few places that there must only be a
> single CN. If you add that (which was taken out of -08), you have to
> change all of them.

I'm not sure I'm following you. Add what "which was taken out of -08"?
Section 3 currently says:

       If a CN-ID is included, the
       certificate's subject field SHOULD NOT contain more than one
       CN-ID, and MUST NOT contain RDNs which consist of multiple Common
       Name attributes.

and CN-ID is defined as

      *  CN-ID = a Relative Distinguished Name (RDN) in the certificate
         subject that contains one and only one attribute-type-and-value
         pair of type Common Name (CN); see [PKIX] and also
         [LDAP-SCHEMA]

What's underspecified in 4.4.4 is how CN checking should be done if
multiple CN-IDs are present, but that's the only place where it needs to
be covered, I think.

> I propose that we stay with the current MUST for a single CN.

But this wouldn't really address the issue of how to handle a
certificate with multiple CNs in the subject... and they do occur in the
wild, so they shouldn't simply be ignored in this document - let's use
the opportunity to specify this explicitly.

>> (Finally, let me add that browsers such as MSIE, Opera or Safari
>> already implement this kind of multi-CN checking - if there is no
>> subjectAltName extension, they will go through all CNs and look for
>> a match [1]).
> 

Not in the literal sense, because currently there's no real consensus on
the meaning of the "(most specific) Common Name field" statement from
RFC 2818, so implementations differ in their behavior right now. I would
at least consider it "best future practice", however, given that you
would no longer have to argue about most specific vs. least specific etc.

Kaspar

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 14 Jul 2010 08:47:36 -0700

> Would removing all mention of "(most specific)" qualify as clarification?

<dilbert> Gaa! </dilbert>   Let's not open Pandora's box wider!!

One of the big weaknesses of PKI right now is the lack of effective use of
name constraints.  CAs do not constrain the names that their subordinate
CAs may issue.  And one of the big reasons for that is that name constraints
are not defined to apply to DNS names in Subject CNs, so they're ineffective.

Trying to apply DNS name constraints to subject CNs is a can of worms,
because subject CNs may legitimately contain things that are not DNS names
at all.  It's not correct to declare a cert chain invalid because the EE
cert contains CN="Peter Saint-Andre" and also CN="www.stpeter.im" but the
issuer CA is constrained to "*.stpeter.im".  There's no test that 100%
accurately answers the question "Is this string a DNS name or not?", and
so it is not generally possible to answer the question "Should this CN
be subjected to a DNS name constraint or not?".

SANs solve this whole problem.  They have a component that may ONLY contain
DNS names, and therefore is easily constrained.  DNS name constraints would
be effective if certs ONLY put DNS names into SANs.  But putting DNS names
into SANs effectively bypasses name constraints (at least, in
implementations I tested last year).

IMO, we should be attempting to drive a stake in the heart of DNS names in
subject CNs, and moving all CAs to use SANs exclusively for DNS names.

Let's close Pandora's box, not open it wider.

---

From: Kaspar Brand <[email-masked]>
Date: Thu, 15 Jul 2010 07:07:39 +0200

On 14.07.2010 17:47, Nelson B Bolyard wrote:
> be effective if certs ONLY put DNS names into SANs.

That's an argument for completely banning CN-IDs, in the first place.
But I fail to see how it is relevant for the decision whether to only
check the "(most specific) Common Name field" or all of the CNs.

> But putting DNS names

Should read "... into CNs", I guess? In any case, if you disregard CNs
in the subject for name matching as soon as there is a subjectAltName
extension with at least one dNSName (as
draft-saintandre-tls-server-id-check-08 does), then it's becoming a
non-issue.

> subject CNs, and moving all CAs to use SANs exclusively for DNS names.

-08 already does this in several places:

       The certificate SHOULD NOT represent the server's fully-qualified
       DNS domain name in a CN-ID, even though many deployed clients
       still check for this legacy identifier configuration within
       certificate subjectName. [...]

      Notwithstanding any of the foregoing rules, reference identifiers
      of type CN-ID (if included) MUST always be the lowest-priority
      reference identifiers in the list. [...]

      Security Note: A client MUST NOT seek a match for a reference
      identifier of CN-ID if the presented identifiers include an
      SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName
      entry types supported by the client.

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

Kaspar

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Jul 2010 17:36:43 +0200 (MEST)

> check the "(most specific) Common Name field" or all of the CNs.

In the PKIX specs implementing name constraints for DNames is a MUST,
while implementation of DNSName SANs officially "RECOMMENDED" and
in reality probably a MAY.

> Should read "... into CNs", I guess?

AFAIK, Name constraints conceptually are supposed to work at the certificate
path validation level.  So a name constraint imposed by a rootCA for an
intermediate CA works for exactly that particular type of name.

If applications check for acceptable names in certs by comparing with
different types of names (like DNSName SAN and CN-ID), then a name
constraint on only one of them is obviously ineffective from preventing
the intermediate CA to bypass the name constraint.

> 
>                                       In any case, if you disregard CNs

I don't think this is an appropriate characterization of the issues
at hand.  There are a number of parties involved, each with
very different objectives.

Name constraints is tool for a multi-CA hierarchy that a CA higher up
the hierarchy can use to impose limits to the authority of CAs closer
to or issuing the EE certs.

name constraints are not in the interest of the server, not in the
interest of the client and not necessarily in the interest of the
issuing CA (the presencs of name constraints is evidence that
it is not in the interest of the issuing CA -- but instead in the
interest of the higher up CA).

The inclusion of DNSName SANs or CN-IDs in a Servers EE-Cert might be
in the interest of the Server, might be in the interest of the issuing CA
or might be a mere technical restriction of the CA's software or the
CA's configuration.

A Server that intentionally uses an EE-Cert with DNSName SANs has no
control over the clients that connect to that server.  Whether these
clients understand DNSName SANs or only CN-IDs, or whether these
clients ignore CN-IDs when DNSName SANs are present or always check
both, is also completely outside of the control of the server.

The server and the issuing CA might consent to not put a CN-ID into
the server's EE-Cert, but that is likely result is a number of clients
rejecting the server's cert.

> > subject CNs, and moving all CAs to use SANs exclusively for DNS names.

That decision, and the risk management for the resulting interop problems,
should be left to the combined decision of the Server operator and
issuing CA to no longer include CN-IDs in EE-Certs on a case-by-case
basis.

>       reference identifiers in the list. [...]

It has been recently asked (I think by Paul Hoffman) why there is
an ordering when checking is going to be performed as a linear search,
and similarly I'm wondering what "lowest-priority reference identifiers"
is supposed to mean here.

I assumed the matching was about a Boolean decision, either it matches
the servers identity or it doesn't match.  "lowest-priority" sounds
like a XX% acceptable match instead of a Boolean.  

>       entry types supported by the client.

This MUST NOT is an unnecessary a violation of rfc-2119 section 6,
and completely ignorant of the situation that software updates must
not break the installed base.

It is trivial for the server&CA to make this happen by having the
CA issue a Cert without CN-ID.  

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 15 Jul 2010 18:04:47 -0700

On 2010/07/14 22:07 PDT, Kaspar Brand wrote:
>> Trying to apply DNS name constraints to subject CNs is a can of
>> worms, because subject CNs may legitimately contain things that are
>> not DNS names at all.  It's not correct to declare a cert chain
>> invalid because the EE cert contains CN="Peter Saint-Andre" and
>> also CN="www.stpeter.im" but the issuer CA is constrained to
>> "*.stpeter.im".  There's no test that 100% accurately answers the
>> question "Is this string a DNS name or not?", and so it is not
>> generally possible to answer the question "Should this CN be
>> subjected to a DNS name constraint or not?".
>> 
>> SANs solve this whole problem.  They have a component that may ONLY
>> contain DNS names, and therefore is easily constrained.  DNS name
>> constraints would be effective if certs ONLY put DNS names into
>> SANs.
> 
> That's an argument for completely banning CN-IDs, in the first
> place. But I fail to see how it is relevant for the decision whether
> to only check the "(most specific) Common Name field" or all of the
> CNs.

See my argument below.

>> But putting DNS names into SANs effectively bypasses name
>> constraints (at least, in implementations I tested last year).
> 

Yes, sorry.

> In any case, if you disregard CNs in the subject for name matching as
> soon as there is a subjectAltName extension with at least one dNSName
> (as draft-saintandre-tls-server-id-check-08 does), then it's becoming
> a non-issue.

Yes, but as I read it, people here are proposing to open the spec to say
that multiple CN-IDs are just as acceptable as multiple DNS names in a
SAN.  Frankly, IMO, that will kill SANs and name constraints too.

SANs are having enough trouble getting off the ground.  FAR too many
people still think that CN-IDs are *THE* standard, and are utterly
unaware of SANs.  If we raise multiple CN-IDs to a status they did not
enjoy with RFC 2818, then there will remain no motivation to use SANs at
all, and constraints will die.

Today, the ONE motivation to use SANs is to get multiple DNS names into
a cert.  And that brings with it the hope of constraints.  Take away
that sole motivation, and constraints die.

Sorry, I'm repeating myself.  This constraints issue is very important.

> (which don't recognize the subjectAltName extension).

Can you name any browser or other important network client made in the
last 8 years (since RFC 3280 was published) that does SSL3 and/or TLS
but doesn't recognize DNS names in SANs?

Best Regards,
/Nelson

---

From: Kaspar Brand <[email-masked]>
Date: Fri, 16 Jul 2010 07:29:37 +0200

On 16.07.2010 03:04, Nelson B Bolyard wrote:
> SAN.

Acceptable in the sense that a certificate with multiple CNs and no
subjectAltName extension is treated the same as a certificate with
multiple dNSName entries in the subjectAltName extension, yes. When it
comes to name constraints, this BCP document now says what cert parts an
implementation should take into account as potential identifiers,
effectively closing a gap which is left between RFC 5280 and RFC 2818.

> all, and constraints will die.

I'm not sure if beating people to use SANs by putting fierce
requirements into a BCP document ("MUST NOT put server names into CN
attributes") is the right way to evangelize them.

> Sorry, I'm repeating myself.  This constraints issue is very important.

I have a somewhat different view, but it's also getting a bit off-topic
for this thread, I think. Just one point to be aware of: name
constraints will only take off if *all* relevant TLS toolkits implement
them - otherwise trying to constrain intermediate CAs (through an
extension which some will just ignore) is pretty pointless.

> but doesn't recognize DNS names in SANs?

"important" is a debatable term, but I'm pretty sure that as soon as you
leave the browser camp, you'll encounter quite a few... I didn't have to
search for a long time, actually: take wget as an example.

Kaspar

---

From: Ludwig Nussel <[email-masked]>
Date: Fri, 16 Jul 2010 10:24:52 +0200

> search for a long time, actually: take wget as an example.

Well, I got the impression that clients using openssl are generally
in a bad shape. The complicated low level API, sparse docu and
insecure defaults create many pitfalls for the newcomer.
I hope that with the new RFC a common library that does the server
id checks could be developed though.

cu
Ludwig

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 16 Jul 2010 09:46:55 -0700

> id checks could be developed though.

Some of us might claim that one already exists.
-- 
/Nelson Bolyard

---

From: Paul Tiemann <[email-masked]>
Date: Fri, 16 Jul 2010 12:02:10 -0600

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

---

From: Martin Rex <[email-masked]>
Date: Sat, 17 Jul 2010 02:54:02 +0200 (MEST)

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

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

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

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

> only one CN in them -- and making it even more rare would be a step forward

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.

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

OK.  Makes sense.

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

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? 

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

---

From: Nelson B Bolyard <[email-masked]>
Date: Sat, 17 Jul 2010 15:45:31 -0700

On 2010-07-16 17:54 PDT, Martin Rex wrote:
> But I have a problem with words in a BCP that

Fair enough, but I challenge your implicit assertions that there is any
"clear violation" or that they are "without cause".

> over what exactly an application does with a SAN.

It is obviously to ensure that any relying party relies on the content
of the SAN.  An issuer DOES have control.  It ensures that the relying
party will NOT rely on the cert if it does not grok the SAN.

> Really bad idea, completely unnecesary and clear violation of

Baloney.  May I suggest you re-read that section of the RFC you most
frequently cite?  "Making strong recommendations" is not the same as
"Imperative" or "MUST" and you know it.

But further, section 6 allows imperatives for "behavior which has
potential for causing harm".  Allow subordinate CAs to issue certs that
bypass the name constraints placed on them is most definitely "behavior
which has potential for causing harm".

> present, so 2) is perfectly sufficient.

Only after CAs stop issuing certs without SANs.  I read Paul's message as
saying that Digicert is issuing certs without SANs.  (Paul, please correct
me if that is mistaken.)

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

A great idea.  Especially if the only affected products are really old cell
phones that cannot handle modern web sites anyway.  Continue to have special
wifi.domain.TLD web sites for them, and let the rest of the Internet move
ahead.

> Why don't we shutdown the entire IPv4 internet to force the

Martin, you oppose experimentation?
Do you want to live in the past forever?

>> clients to die and all the niche clients to become compatible?  

Firefox already applies DNS name constraints to DNS names in SANs, and
has for years.  In a forthcoming version of Firefox, DNS name constraints
WILL be applied to last Subject CN under the following circumstances:

- The cert chain being verified is being verified for the purpose of being
an SSL/TLS server certificate
- the server cert has no SAN extension, or no DNS names in its SAN extension

(in other words, under the same circumstances in which we would use the
last Subject CN as a CN-ID for cert name matching purposes).

The value of these name constraints is that they will enable CAs to issue
subordinate CA certs to corporations without any fear that those
corporations will issue false certs for their competitors.

They also allow relying parties to constrain names in entire PKI trees
subordinate to certain national CAs, thereby greatly reducing vulnerability
to the compelled issuance of certificates for domains outside that CA's
national country code domain(s).  Without doubt, the threat of compelled
issuance has been the single biggest threat to public confidence in PKI
to have come along in years, and name constraints are one of the few ways
we have of combating that threat.  So, don't dismiss it lightly.

---

From: Kaspar Brand <[email-masked]>
Date: Mon, 19 Jul 2010 07:33:45 +0200

On 17.07.2010 02:54, Martin Rex wrote:
> (mine does), it never was part of any standard or suggestion

Nor would I consider the wording "the (most specific) Common Name field
in the Subject field of the certificate" from RFC 2818 to be
authoritative or "part of a standard". Some implementers apparently
attached much importance to "(most specific)" in their reading of this
text, but I still wonder what the real intention was when that term was
added to / coined in RFC 2818. [1]

Just to be clear: I'm not advocating that CAs put multiple CNs into the
subject DN: I'm completely fine with having a strong recommendation in
section 3 ("Representation of Server Identity") for a single CN in the
subject only.

In section 4 ("Verification of Server Identity"), however, I think we
should expressly put an end to the debate of what "(most specific)" in
RFC 2818 really means, otherwise the confusion is perpetuated. Of the
two solutions - either explain at great length how it is to be
understood DER-encoding-wise, or just go loop over all CNs -, the latter
definitely seems preferrable to me.

Kaspar

[1] Looking through
http://www.imc.org/ietf-apps-tls/mail-archive/maillist.html didn't give
a clue, unfortunately.

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Jul 2010 18:12:14 +0200 (MEST)

> party will NOT rely on the cert if it does not grok the SAN.

The criticality is on the entire SAN extension, not on a particular name,
and the critically is usually visible only to the PKI part of the software
stack.  Apps don't care, and should not have to--in particular,
when they're seperate from the PKI stuff by several layers of abstractions.

If there is an existing SPKM-like GSS-API mechanism that uses
Subject DNames at the GSS-API level, what should it do when
encountering a cert with a subjectAltName marked critical?

The two possibilities are either choke on it or ignore it.
The PKI software underlying this GSS-API might recognize
subjectAltNames, just that the GSS-API mechanism wrapper above
might not be looking at/form them at all.

There is at least one partner who has built a gssapi-mechanism
with OpenSSL, wrapping SSL-records into GSS-API tokens.

One thing that I find particularly irritating in -08 is that
it completely ignores a much more secure authentication
scheme for servers, by clients knowing the entire subject DName
of a certificate rather than matching only a single
name component.

   4.2. Constructing an Ordered List of Reference Identifiers

   o  The list MUST include a DNS-ID.  A reference identifier of type
      DNS-ID can be directly constructed from a fully-qualified DNS
      domain name that is (a) contained in or securely derived from the
      inputs (i.e., the source domain), or (b) explicitly associated
      with the source domain by means of user configuration (i.e., a
      target domain).

  [...]

      Security Note: A client MUST NOT construct a reference identifier
      corresponding to Relative Distinguished Names (RDNs) other than
      the Common Name and MUST NOT check for such RDNs in the presented
      identifiers.

Comparing the full DName is always more secure than comparing
only CN-ID, so this Security Note is factually flawed.

In that respect, rfc-2818 is much more reasonable:

   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted. (For instance, a
   client may be connecting to a machine whose address and hostname are
   dynamic but the client knows the certificate that the server will
   present.) In such cases, it is important to narrow the scope of
   acceptable certificates as much as possible in order to prevent man
   in the middle attacks.

> "Imperative" or "MUST" and you know it.

Personally, I count an underexplained SHOULD NOT as an imperative,
about as much as you appear to be assuming the presence of
DNSName SAN name constraints to be an imperative.

There is absolutely no problem whatsoever with how reasonable CAs use
and issue Server-Certs with CN-ID, and similarly, there is absolutely
no problem whatsoever with clients matching CN-IDs.

The general approach of rfc-2818 is *MUCH* more reasonable.  Instead
of lamenting on CN-ID, it simply declares them as deprecated and
suggests how to do server endpoint identification in the future.
In particular it does NOT mess around with existing practice
(in documentation, in implementations and in CA practices).

Describing how CAs should issue Certs with DName-SANs for a certain
purpose is OK.  Describing potential security issues and implementation
inconsistencies with CN-ID is also OK.  But trying to change rules
for Subject DName to something that differs considerably from
existing documentation, existing implementations and existing practise
is inappropriate.  After all, CN-ID has been deprecated for many years.

> which has potential for causing harm".

Implementing name constraints for DNSName SANs is optional.  

And an subordinate CA that wants to issue Certs using CN-IDs for
bypassing DNSName SAN Name constraints is certainly not going to
be stopped by a "MUST NOT issue" guidance in a BCP document.
A subordinate CA is more likely to be held responsible for
issuing certs not incompliance with the policies of it's parent CA
than by ignoring a SHOULD NOT in some RFC document.

The only behaviour clearly causing harm are some commercial CAs
which disclaim libabilities for blindly copying unvetted DName
components from the CSR they receive into the Certs they issue.

> saying that Digicert is issuing certs without SANs.  (Paul, please correct

Why?  You mean that there are CAs that issue Server certs _without_ SANs
and CN-IDs that you have to be afraid of?  Why would you be less afraid
if they issued certs with DNSName SANs, and why do you trust such CAs
in the first place?

> wifi.domain.TLD web sites for them, and let the rest of the Internet move

Most software on top of OpenSSL checks CN-IDs only.

> Do you want to live in the past forever?

What you are suggesting is involuntary euthanasia.

I violently oppose the creation of interop problems in order to
discriminate against an installed base, especially when there is
no problem with the existing scheme to have old and new coexist
peacefully together.

> corporations will issue false certs for their competitors.

So you are abusing Firefox to protect an inter-CA business model?

For the end user this is completely irrelevant.

> national country code domain(s).

HUH?  Name constraints work only within one single hierarchy.  As soon
as you have two independent trusted Roots, name constraints no longer
work.  Browsers come preloaded/pretrusted with ~40 independent Roots.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Jul 2010 18:57:50 +0200 (MEST)

Kaspar Brand wrote:
> RFC 2818 really means, otherwise the confusion is perpetuated.

I would prefer to stick with the _exact_ description of rfc-2818.
After all, this method has been deprecated back then and is intended
to remain deprecated.

> Of the two solutions - either explain at great length how it is to be

RFC2818 is likely a specification looking backwards, trying to describe
the current practice and the behaviour of existing implementations.

A lot of TLS clients and most web browsers had been checking only
one single CN-ID when RFC-2818 was written (and still do), and
the "most specific" is likely the attempt to indicate which
CN-ID they are checking.

To me it sounds like the first match on a string search based on the
reversed ordering in "String Representation of Distinguished Names"
(rfc2253 as far as rfc2818 is concerned, which has since been
 obsoleted by rfc-4514).

But frankly, I do no see much value in trying to describe all possible
interpretation of a fairly vague wording, that itself was an attempt
to characterize, NOT specify, what kind of behaviour there is in the
installed base.  Leaving the vague description of rfc-2818 as is,
and pointing out more prominently that it is really deprecated
should be perfectly sufficient.

-Martin

---

From: Shumon Huque <[email-masked]>
Date: Tue, 20 Jul 2010 00:13:07 -0400

> should be perfectly sufficient.

I'm in full agreement.

-- 
Shumon Huque
University of Pennsylvania.

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Jul 2010 01:12:44 +0200 (MEST)

> implementations I tested last year).

Look at the server certificate here(*):

   https://edgecastcdn.net/

and SANs in it.  The Server cert is from a 3-level CA hierarchy
(Entrust on top, two intermediate CAs from DigiCert).

How exactly are name constraints going to make issuing such certs
easier or safer, and can you actually come up with a meaningful
name constraints for such a cert?

-Martin

(*) Server cert example found here:
    http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
    recently mentioned on this list.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 21 Jul 2010 22:57:37 -0400

> name constraints for such a cert?

This certificate has a whole bunch of SAN-dNSNames that are all
over the DNS name space. So, no, there is no useful name constraint
extension that the issuing cert(s) can have for this.

Name constraints would be more useful if the Internet PKI was
hierarchically constructed _with_ hierarchical authority of
the name space. That would have been great, but it isn't the case
(any CA that gets into the club can issue certs for any name).

Maybe Nelson is thinking about an alternative Internet PKI or
some private/enterprise PKI, where they could be useful.

At this point, the best hope for a namespace-constrained Internet
PKI might be with DNSSEC. I think there's a BOF on this topic at 
IETF next week.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 22 Jul 2010 11:14:46 +0200

I am not sure that the discussion about constraints is
the most pressing thing we need to talk about. ;-)

Anyway, as Martin already summarized, the usage
of common name to identify a server is deprecated
since the last millenium.

It is nncoding of a *complete* identifier as a subcomponent
of another one, something that can happen for
non technical purposes, e.g. user friendliness etc.

Building software based on such ad hoc approaches
requires pattern matching logic, etc, not very difficult
to implement but not necessarily easy to use.

In fact, I think that the whole of defining a thingy CN-ID
complicates the whole text, it should just be a small
note indicating that is is a particular encoding of exactly
one DNS-ID.

It seems to me that the changes in the last version already
go into this direction. Nevertheless, the last paragraph of
2.2 (starting with "We recognize") introduces (AFAIR) a
string representation of a DN which doesn't serve any
real purpose and which has a strange "hierarchy". Note,
that one explains that a DN in X.500 is a hierarchy.
The implementation note refers to what? I see some confusion
regarding the example.

Just because we have mentioned all kinds of adjectives during
the discussion, I do not see the value mentioning them. The
only one that matters is the the "(most specific)" mentioned
in RFC 2818 IMO. There are some people knowning X.500
quite well: If one respects the non-normative schema rules,
can one have more than one Common Name AVA in a DN?

It has also been said that using the reerm "representation" is
unfortunate. In corresponding texts (X.500 etc), the word
'indication'  is used. I suggest to change this all over in the
document.

/P