Subject: Re: DPD & DPV requirements

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 22 Jan 2001 16:20:59 -0700

Quite so.  The problem with the existing cross-certificate structure, and with
 top-down name constraints, is that they are imposed on subordinate 
entities, rather willy-nilly, by the CAs, without providing a mechanism
for the relying parties to specify the extent to which they wish to trust the 
CAs themselves, other than by switching roots.  In particular, there is no
ability to control "delegation" (trust, really) in the upwards direction.

And I remain convinced that name subordination is a badly broken 
mechanism.  It really doesn't work in a multi-lingual environment,
and except perhaps in certain closed user group organizational constructs 
it simply doesn't work at all.  

What am I supposed to do with respect to a residentialPerson --
reject anyone whose certificate  indicates that they reside in the State of 
California?  (Not such a bad idea, actually, considering how they have 
managed to screw up their power infrastructure and are now relying
on their neighboring states to help them out.)

The Novell Security Attributes construct was invented to solve precisely
the kinds of problems you have pointed out.

Bob

>>> Russ Housley <[email-masked]> 01/22/01 03:08PM >>>
Peter:

Your question regarding cross-certificates makes an assumption about trust 
models that is not universal.  Also, the mechanism that I proposed allows 
the relying party, not a CA, is impose name constraints (in the same way 
that the relying party can impose policy constraints).

Russ

At 06:30 PM 1/22/2001 +0100, Peter Sylvester wrote:
> >
> > I would like to second Russ Housley's comments above for associating name
> > constraints with trust anchors. Without naming constraints we would get
> > security threats that would imply global trust, which is not a real life
> > situation. If other words, I want to be able to detect when company X
> > certifies a name from a user (or entity) from company Y, and when this is
> > not allowed.
> >
> > Denis
> >
> >
>
>Can you give an example what do you want to do that you cannot
>do with an appropriate cross certificate.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Jan 2001 12:44:48 -0500

bob,

>ability to control "delegation" (trust, really) in the upwards direction.

As I said in my response to your recent message, the word "trust" is 
vastly misused in these discussion, and your comments above are a 
prime example.

>it simply doesn't work at all.

Sorry you still don't like the notion of name subordination, but it 
is a fact of life in many, if not most, contexts. Why don't you 
change your e-mail address one that terminates with bbn.com and try 
to get the e-mail routed to you at Novell.  I'll do what I can at 
this end to make sure it never happens!

>on their neighboring states to help them out.)

The lack of context for the comments makes it hard to respond to, but 
my guess is that you were trying to say that absent someone from the 
state of CA taking responsibility for issuing certs in that state, 
you prefer to rely on TTPs to assert identifies of this sort.

>the kinds of problems you have pointed out.

One more reference to your favorite corporate product and I'll ask 
Paul to filter your messages from this list, if only to save virtual 
trees :-)

Steve