![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
EKR wrote: > Jeffrey Altman <jaltman at secure-endpoints.com> wrote: > Sure, but as we're seeing in a number of applications, this doesn't > preclude the use of self-signed certs. > No it doesn't. However, as I've seen in a number of commercial and open source products, the authors don't want to go to the trouble of writing code to generate certificates as part of the install so they install the same self-signed certificate and private key on every system in the world. Most users are to naive to know how to replace the certificate, probably don't know that they should, and assume that because there is a certificate there that they are secure. One of these commercial products and its self-signed certificate was in use for many years by a major Medicare system. Self-signed certificates have their place but they should not be used as a bootstrap method for other authentication technologies. Too many people make the wrong assumptions just based upon their presence. Please do not insist that they be used as part of a TLS-GSS solution. Jeffrey Altman
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS at lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls