[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: editorial on Photuris
] > My principle: if you're making a secure connection to a DNS-named
] > entity, then the certificate MUST bind its DNS name to its key.
] > (Something that can be trivially and algorithmically mapped to a DNS
] > name would be OK -- but I've never seen anyone present an X.509
] > example, real or hypothetical, where that's true. One post to this
] > list (or pkix -- I forget) showed the DN in a Verisign certificate of a
] > real SSL-using web site, and the relation between its DN and it DNS
] > name was not even as close as Charles' example above. The DN named the
] > parent corporation of the entity that ran the web site...)
]
] You are quite correct that establishing trust is the single most important
] issue for any public key infrastructure. However, deriving trust from the
] name, whether using DNs or domain names is foolish at best. I can spoof
] DNS servers, can't you?
Spoofing the server buys you denial of service, no more. The server you
are directed at either won't know the private key of the certificate
for the real server, or won't have a certificate that links to someone
you do trust.
] At this time the only secure method (of which I
] am aware) that has been suggested for establishing trust for public key
] operations is to cryptographically link an unknown Name/Key binding to some
] established Name/Key binding that you implicitly trust.
100% agree. Don't see why it contradicts my example, though. It does
point out that I omitted a few details-- the process of checking the
certificate of the server one is talking to does indeed have to include
checking the signature on that certificate, which is done recursively
until one gets to a signature that can be checked via an apriori known
key of a trusted CA. But it also has to include checking that the name
of the principal you think you are talking to is the same as the name
in what you call "Name/Key binding" that is presented as proof of the
principal's identity.
]
] X.509 specified a very general approach to solving this problem, an approach
] that was too general to be of any use. Finding an approach that works well
] in various operational environments is difficult, and has been the subject
] of much debate. This is the most significant difference between PGP and PEM.
] It, not the horrid encoding format, is the fundamental problem slowing
] X.509 deployment. It is the problem that any replacement for X.509
] would have to solve. And it is the problem that the pkix working group
] is wrestling with.
Maybe this is the long term problemt they're tackling, but right now
they seem particularly to be arguing about how the wedge the internet
identity and CA locating information into the "extensions" field of v3
X.509 certificates. X.509 certs work perfectly fine when your directory
is X.500 and your mail is X.400, but (IMHO) leave around some pretty
useless artifacts when your directory is DNS and your mail is SMTP.