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

From: "Manger, James H" <[email-masked]>
Date: Fri, 24 Jun 2005 11:24:16 +1000

Santosh,

Isn’t the whole point of a (X.509) PKI that relying parties don’t have to manage lots of public keys.  A PKI allows them to manage names instead.  Names are assumed to be meaningful to relying parties, while public keys are just numbers (meaningless in themselves).  Only having to manage meaningful things is the value that PKI offers.

Matching public keys, instead of names, is a valid way to build an authorization system – but such a system does not need X.509 certificates, it does not participate in a PKI!  [It is closer to SPKI/SDSI, see RFC 2693.]

[Without knowing any of the context or specifics…] SAML 2.0 was probably right to reject the use of public keys for authorization when certificates are used.  Perhaps, they should additionally allow public key cryptography to be used without X.509 certificates and, in those cases, use the public key for authorization.

  _____  

From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Thursday, 23 June 2005 8:55 PM
To: Manger, James H; 'pkix'
Subject: RE: 3280bis: CRL validation - where DN comparison is important

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 24 Jun 2005 07:49:12 -0400

James,
 
The basic point is that the if the relying party (a authorization server)
uses trust anchors or even a single trust anchor, it should use the DN
matching, but in case the names are not unique, it should be able to use the
public key related information presented in the SSL/TLS protocol to match
the public key also (in addition to the DN) to ensure that the correct
client authorizations are used.
 
Only DN matching will be sufficient if the authentication server knows that
the names are unique.  We know from this debate that may not be always.
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Manger, James H
Sent: Thursday, June 23, 2005 9:24 PM
To: pkix
Subject: RE: 3280bis: CRL validation - where DN comparison is important

Santosh,

Isn't the whole point of a (X.509) PKI that relying parties don't have to
manage lots of public keys.  A PKI allows them to manage names instead.
Names are assumed to be meaningful to relying parties, while public keys are
just numbers (meaningless in themselves).  Only having to manage meaningful
things is the value that PKI offers.

Matching public keys, instead of names, is a valid way to build an
authorization system - but such a system does not need X.509 certificates,
it does not participate in a PKI!  [It is closer to SPKI/SDSI, see RFC
2693.]

[Without knowing any of the context or specifics.] SAML 2.0 was probably
right to reject the use of public keys for authorization when certificates
are used.  Perhaps, they should additionally allow public key cryptography
to be used without X.509 certificates and, in those cases, use the public
key for authorization.

  _____  

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