> > 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 potus@xxxxxxxxxxx > 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
Attachment:
Phillip Hallam-Baker (E-mail).vcf
Description: Binary data