everyone knows the problem:

We have dozens or hundreds of services to login and every service wants
a user-name and a password. Most users reuse their passwords and a lot
of services do not protect the passwords securely (no hashing, salting,
etc.). If a service is hacked or malicious, the perpetrator can be quite
sure to be able to reuse the credentials at other services. Not to
mention passwords like 12345.

In TLS operation, a user can be authenticated with a client-certificate.
The password is neither transmitted over the wire nor to the
service-provider. There is only one single password for the
client-certificate instead of multiple passwords for multiple services.
But if every service issues a certificate for a user the user
application will be bloated with client-certificates. Not to mention the
work-load for the user to create backups and to renew the
client-certificates. A single client-certificate can be issued by a
Certificate Authorities which is usually complicated, expensive and CAs
have been proven to be unreliable.

DANE-SMIMEA allows to validate an email-address/SMIME-certificate tupel
via DNSSEC. That way a service-provider can validate a user is matching
the email-address, be it a CA-issued or self-signed S/MIME-certificate.

This establishes the opportunity to use DANE-SMIMEA as a global
authentication system. The user creates a self-signed S/MIME-certificate
and publishes it via DANE-SMIMEA. At a service he selects
DANE-SMIMEA-Authentication and in his application (e.g. browser) the
user selects the S/MIME-certificate to be used. The service provider
(e.g. a mod_auth_smimea-module in Apache) validates the
email-address/Common Name against the DNSSEC-protected public key in the
SMIMEA-RR and can be sure to be connected with the user having that
exact email-address.

So I suggest to add this case to the application description in section
6 of draft-ietf-dane-smime-12 or a successor/errata. (Sorry, I lost
track of the current state of SMIMEA).



dane mailing list

Reply via email to