Subject: RE: 3280bis: CRL validation - where DN comparison is important

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 23 Jun 2005 10:22:19 +0100

James,

We may use many mechanisms in addition to name matching when trusting a
subject DN for mapping to a user account.

A very common method is to configure which CAs (out of all trusted CAs)
that is trusted to provide user authentication for an application or a
system.

This is done e.g. for authenticating users in windows domain accounts
(as you quote) where every CA that is trusted to support user
authentication must be listed in the NTAuth store of the directory of
the account domain.

Another option is to limit to certificate issued under certain policies.

How applications choose to trust CAs to provide adequate user
information is however a thing between the CA and its users. It is
outside the scope of this standard to mandate the composition of subject
names.

We need to focus on the fact that path validation does not result in
silent false validation of a certificate.

Stefan Santesson 
Program Manager, Standards Liaison 
Windows Security 

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Manger, James H
Sent: den 23 juni 2005 05:26
To: pkix
Subject: RE: 3280bis: CRL validation - where DN comparison is important

Stefan Santesson said:

"A consequence of this [same DN for different entities], and probably
the only consequence of this, is that security should not ONLY rely on
name comparison of loosely related entities.  The only place this is
allowed, to my knowledge, is for indirect CRLs where we today might
accept any CRL with a matching CRL issuer name as long as it can be
supported by a trusted path."

Indirect CRLs are certainly not the only place this matters.  It matters
almost everywhere, which is why the context in which a DN is unambiguous
is so contentious.  Perhaps indirect CRLs are the only place it matters
within path processing, but the DN is then going to be used by the
relying party for other purposes, such as checking an access control
list.

For example, using Apache Tomcat with TLS mutual authentication and its
default user database requires subject DNs to be listed in
conf/tomcat-users.xml.

  <user username="CN=Jim, DNQ=Acme Customer, C=AU" password="null"
roles="manager"/>

This is unsafe if DNs are not unambiguous amongst all the CAs under all
the roots trusted by Tomcat.

Another (not unrelated) example is Java.  It uses the Principal class to
represent an entity in all sorts of security-related situations.  The
only standard way to get a Principal from a certificate path is to get
it from an individual certificate (via
X509Certificate.getSubjectX500Principal()) as an X500Principal that only
uses a single DN for equality matching.  This is unsafe if DNs are not
unambiguous amongst all the CAs under all the roots trusted by the Java
Virtual Machine.

Microsoft Internet Information Server allows you define rules about
subject and issuer DN attributes when mapping certificate-based access
to a Windows accounts.  Though the rules can cover the issuer DN they
cannot cover anything further along the certificate path.  This is
unsafe if issuer DNs are not unambiguous amongst all the CAs under all
the roots trusted by IIS.

By all means define how processing can work under weaker assumptions
than DNs being unambiguous under all trusted roots.  Recognise, however,
that that weakening is likely to have a huge impact of heaps of
software.  Systems must not be limited to those weaker assumptions to be
compliant, particularly given that diligently choosing which roots to
trust and the use of name constraints could be sufficient for many
situations.

James

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 23 Jun 2005 14:13:43 +0200

Stefan Santesson wrote:

> A very common method is to configure which CAs (out of all trusted 
> CAs) that is trusted to provide user authentication for an application 
> or a system.
>
And how do you configure that CA ?
You're just transferring the problem to the CA, either you have DN based 
identification for the CA, or identification based on a specific 
certificate, and you need to reconfigure when you re-key the CA.

> Another option is to limit to certificate issued under certain policies.
That point is quite orthogonal to our problem here.
If you suspect that some CA/hierarchy  is more likely to raise the 
problem of a non unique DN, you can try to restrain it from asserting 
the higher trusted policies, but this will not change the problem for 
any policy you trust it for.

> outside the scope of this standard to mandate the composition of 
> subject names.
>
Clearly, designing a name collision resistant system with no 
recommendation to user about how to stay name collision resistant when 
they use it is not very useful.