On Wed, 26 Sep 2001 15:21:09 -0700, Michael Sierchio wrote:
>David Schwartz wrote:
>> Sufficient for what? I may not want to send my credit card
>>information to anyone who has a Verisign certificate, but I might be
>>willing to send it to someone who has a Verisign certificate for
>>'www.amazon.com' or has that listed as one of the alternate names.
>There's confusion in the PKI realm about what constitutes trust and
>authority.
>My assumption is that the certificate issuer does due diligence --
>presumably, that's YOU if you are developing an application using client
>auth.
No, the application developer may not be the certificate issuer. The
application developer (or whoever configured the application to accept
certificates signed by a particular authority) must trust the certificate
issuer to at least some extent. That extent could vary from total trust to do
anything down to trust only for proof of identity.
>> Comparing the name to name you get when you resolve the IP you
>>connected to doesn't seem useful to me. But comparing the name (or
>>alternate name) to the name you expected to connect to makes very good
>>sense.
>You're talking about connecting to a server via HTTP, which has little if
>anything to do with SSL and mutual authentication. I maintain that it is
>far easier to poison a DNS cache than to recover someone else's private key
>(if reasonably secured).
Huh? A secure HTTP connection does use SSL and can use mutual
authentication.
>Client certs should bind public keys to identity -- however that is defined
>by the application.
And the application can reasonably do that by checking the name in the
certificate and comparing it to the name of the thing the application wanted
to send data to. (Assuming the certificate issues is trusted at least to
provide accurate identities.)
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
