Subject: RE: charter revisions

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 5 Sep 2001 13:59:28 -0700

> > I don't see this as a problem for several reasons:
> > 
> > 1) Logotypes have utility even if they cannot be used with
> > cross-certification.
> 
> Their utility would be substantially reduced.

I disagree.

The arguments against logotypes in cross certificates simply
restate the long standing problems with the concept of cross 
certification. If you care about the problems being raised with
and have not already found a solution then you cannot use 
cross certification.

> Name constraints allow you to limit the "bad things" that happen. You
> can trust MIT to certify MIT affiliates without worrying about whether
> they might issue a certificate claiming to be for George W. Bush.

No you can't.

You can prevent someone from issuing a certificate that claims to
be for C=US; O=Government; OU=EOP; CN=George W Bush.

What you can't do is to stop someone from issuing a subjectAltName
for [email-masked].

> Most bridge CAs employ name constraints in this fashion. I recognize
> that the bridge CA model (and perhaps cross-certification in general)
> does not fit well with some business models, but it is quite 
> popular in
> many communities. Name constraints and other technology that supports
> cross-certification and the bridge CA model are an important 
> part of RFC
> 2459 and successors.

I still do not buy the argument that the trust rests upon the name
constraints. A machine can make sensible decisions on the basis of
a DN, but then again a machine is going to ignore the logotypes in
any case.

The logotypes argument is about the human interface, not the 
machine interface. DNs are a lousy human interface as the virtual
extinction of X.400 mail proves.

		Phill

---

From: Steve Hanna <[email-masked]>
Date: Wed, 05 Sep 2001 17:38:25 -0400

> What you can't do is to stop someone from issuing a subjectAltName

Use a name constraint with permitted subtrees of:
 rfc822Name:mit.edu

-Steve