Hi,
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). Regards, Renne _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
