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

From: Stephen Kent <[email-masked]>
Date: Fri, 24 Jun 2005 16:26:31 -0400

At 10:22 AM +0100 6/23/05, Stefan Santesson wrote:
>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

Stefan,

I understand some of your comments above, but I do not agree with 
many of them, at least in a more general context.

X.509 includes the name constraints extension and that extension is 
explicitly designed to allow a CA to issue a cross cert that 
restricts the portion of an address space for which the 
cross-certified CA is recognized as an appropriate cert issuer. Thus 
subject names are very much within the scope of X.509 cert processing 
rules that help us to decide whether to accept a given subject name 
as legitimate relative to a cert path.

In contrast, the notion of configuring a set of CAs in a directory 
that users are supposed to accept as "trusted" for certain functions 
is not part of ITU-T or IETF PKI standards.  In fact it runs counter 
to the basic PKI model that says one ought not have to rely on the 
integrity of a directory for PKI-based security. If we wanted to rely 
on directories as securely configured databases, we would not have to 
have CRLs, or not have to sign them. We could just look at a 
directory and see if an entry was marked as revoked, or not, or 
download a CRL via a secure communication path (e.g., via SSL) and 
rely on  the integrity of the directory rather than the signature of 
the CRL issuer.  Or, in a less dramatic example, we would not require 
a next issue data in  a CRL, because we could rely on the directory 
to always have the most recent CRL.

In contrast, making cert acceptance conditional on cert policy data 
IS a valid, standardized way for an application to decide if a 
candidate cert is suitable for use in a given application context.

Steve

---

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 27 Jun 2005 16:16:52 +0100

Steve,

I think we have a misunderstanding.

What I was talking about was just an example of selecting appropriate
trust points for a certain purpose (user account verification). This is
not a certificate validation mechanism.

These certificates still need to be validated according regular PKI
standards. For that process, everything you say is true.

ITU-T and PKIX documents do not regulate the fundamental trust
decisions, e.g. how trust anchors are selected. 

Neither how a RP selects which CAs it choose to trust for a certain
purpose.

These are processes that may leverage several informational elements in
certificates, but they may also be handled completely OOB.

Stefan Santesson 

________________________________

From: Stephen Kent [mailto:[email-masked]] 
Sent: den 24 juni 2005 22:27
To: Stefan Santesson
Cc: pkix
Subject: RE: 3280bis: CRL validation - where DN comparison is important

	James,

	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

	Windows Security

Stefan,

I understand some of your comments above, but I do not agree with many
of them, at least in a more general context.

X.509 includes the name constraints extension and that extension is
explicitly designed to allow a CA to issue a cross cert that restricts
the portion of an address space for which the cross-certified CA is
recognized as an appropriate cert issuer. Thus subject names are very
much within the scope of X.509 cert processing rules that help us to
decide whether to accept a given subject name as legitimate relative to
a cert path.

In contrast, the notion of configuring a set of CAs in a directory that
users are supposed to accept as "trusted" for certain functions is not
part of ITU-T or IETF PKI standards.  In fact it runs counter to the
basic PKI model that says one ought not have to rely on the integrity of
a directory for PKI-based security. If we wanted to rely on directories
as securely configured databases, we would not have to have CRLs, or not
have to sign them. We could just look at a directory and see if an entry
was marked as revoked, or not, or download a CRL via a secure
communication path (e.g., via SSL) and rely on  the integrity of the
directory rather than the signature of the CRL issuer.  Or, in a less
dramatic example, we would not require a next issue data in  a CRL,
because we could rely on the directory to always have the most recent
CRL.

In contrast, making cert acceptance conditional on cert policy data IS a
valid, standardized way for an application to decide if a candidate cert
is suitable for use in a given application context.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 27 Jun 2005 12:00:41 -0400

At 4:16 PM +0100 6/27/05, Stefan Santesson wrote:
>What I was talking about was just an example of selecting 
>appropriate trust points for a certain purpose (user account 
>verification). This is not a certificate validation mechanism.

OK, sorry for the confusion.

>Neither how a RP selects which CAs it choose to trust for a certain purpose.

agreed.

>  These are processes that may leverage several informational 
>elements in certificates, but they may also be handled completely 
>OOB.

Agreed.

Steve