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
