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

From: "Manger, James H" <[email-masked]>
Date: Thu, 23 Jun 2005 13:25:42 +1000

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: "Santosh Chokhani" <[email-masked]>
Date: Thu, 23 Jun 2005 06:55:20 -0400

James Manger,
 
Good point,  We have asked SAML 2.0 that when certificate is used for
authentication, keyinfo (e.g., subject public key or its hash) should be
used to make authorization decisions rather than name matching.
 
In their infinite wisdom they have actually deleted the text proposed to
them.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Manger, James H
Sent: Wednesday, June 22, 2005 11:26 PM
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