Hello Phillip, I believe that the level of security you described has already been implemented in RFC7250 (Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)) and there is a mention also in the latest TLS 1.3 draft (Section A.4.1 Unauthenticated Operation - https://tools.ietf.org/html/draft-ietf-tls-tls13-12#appendix-A.4.1). The browsers do not support it yet, but this may change.
Fotis On 04/22/2016 10:15 PM, Phillip Hallam-Baker wrote: > In a side conversation at IETF ‘95, it was pointed out to me that ‘short > lived certificates’ are not actually equivalent to having a revocation > mechanism: if a malefactor can simply apply for another cert. Short lived > certificates do eliminate the administrative snafus that lead to most > revocations, lost private keys, mis-spelt company names. But they do not by > themselves address the case where a certificate holder is doing something > malicious - like hosting a Warez site, malware distribution point, phishing > capture site, etc. > > It is also clear that we have something of a disagreement over philosophy > here. Some people maintain that the lowest tier of certificate should be > mitigation of MITM attacks only and others point out that as far as users are > concerned, that padlock icon means ‘you are safe’. > > Looking at the market, I think we have reached an inflection point similar to > the point that was reached in the late 90s when SSL was no longer just for > doing online commerce. DV certainly had a use case not met by OV. But they > were not the same thing. Server technology and market demands now make ‘TLS > everywhere’ the near term objective. But there are many servers out there for > which the DV criteria are not going to be a good match. > > > Which is why I think we need a new tier of certs that is below DV for DV > without the certificate management and revocation mechanisms that DV > requires. Such ‘Unmanaged DV’ (UDV) certificates would be sufficient to turn > on TLS encryption but not sufficient to tell the user that this has happened. > They would still have to meet the Domain Validation requirements and the > algorithm requirements. > > I have proposed similar treatment for self-signed certs for decades now - > upgrade without padlock. The reaction of a client to a security upgrade on an > insecure connection should always be ‘yum yum, give it to me’. Turning on AES > will never make the user less secure unless the user is told about it. > > Establishing this tier would also provide an alternative to watering down the > DV management requirements to meet the needs of the infrastructures that are > going to be essential if ‘TLS everywhere’ is going to be a possibility. > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public > _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
