>Peter Gutmann wrote: >>It's no less secure than what's being done now, and >>since you can make it completely invisible to the user at least it'll get >>used. If all new MTA releases automatically generated a self-signed cert and >>enabled STARTTLS, we'd see opportunistic email encryption adopted at a rate >>that tracks MTA software upgrades. > >I've thought about this a lot, and I've come to the conclusion that trying to >bootstrap using ADH is not worth the effort. I think the best thing is if >the web servers were to automatically generate self-signed certs on install, >and present them by default.
Right, that's what I meant - RSA is being used as anon-DH anyway, so we may as well stop pretending and just make it fully automated and transparent to the user. If people do want to go to the effort of checking that everything is OK, do it by checking the cert fingerprint in the same way that PGP and SSH have been doing for years. >>The main point he made was that designers are resorting to "fixing" mostly >>irrelevant theoretical problems in protocols because they've run out of other >>things to do, while ignoring addressing how to make the stuff they're building >>usable, or do what customers want. My favourite example of this (coming from >>the PKI world, not in the talk) is an RFC on adding animations and theme music >>to certificates, because that's obviously what's holding PKI deployment back. > >:-) Was this an April 1st RFC? Or a stealth DRM effort? It's a real RFC (currently still a draft), "Logotypes in X.509 certificates". I originally suggested this as a joke a couple of years ago ("Can you imagine KPMGCoopersPriceLybrandWaterhouseAnderson distributing a single cert without the Official Corporate Logo(tm) with Official Corporate Animation(tm) and Official Corporate Song(tm) playing in the background?"). Given PKIX's propensity for standardising anything that comes along ("PKIX was formed to do one thing and has become a standing committee that will do anything, provided it is in ASN.1 syntax" - Phil Hallam-Baker), it was only a matter of time before a draft appeared. I made the following suggestion for a further addition to the RFC, but it hasn't been adopted (yet): -- Snip -- 4.3. Scent logotypes Alongside audio and video logotypes, it may be desirable for certificates to carry scent logotypes in order to uniquely brand certificate holders in a manner meaningful to relying parties. For example, McDonalds may choose to imbue their certificates with the aroma of fried beef patties and grilled cheese, the National Park Service may choose the essence of pure Colorado mountain air with just a hint of pine, the NRA would use a heady mixture of cordite and gun oil, and PKIX could use cold coffee and stale cigarette smoke. The new logotype would be implemented in the form of scratch-n-sniff certificates, and will assist relying parties in making informed decisions as to whether a particular certificate is trustworthy and relevant for its intended usage. Service providers and product vendors invest a lot of money and resources into creating a strong relation between positive user experiences and easily recognizable scents such as grilled beef, fresh air, and cordite, allowing easy and familiar branding of certificates. The scent logotype extension MUST have the following syntax: LogotypeScent ::= SEQUENCE { scentSubtype IA5String, -- MIME scent subtype scent OCTET STRING, refreshInfo ScentRefreshInfo OPTIONAL } A MIME type is used to specify the format of the file containing the scent logotype data. The scent element contains the scratch-n-sniff scent logotype associated with the certificate. Since scents fade over time, it may be necessary to periodically refresh the scent to preserve the user experience: ScentRefreshInfo ::= SEQUENCE { refreshTime INTEGER DEFAULT 30, refreshCount [0] INTEGER DEFAULT 1, refreshUrl IA5String, refreshUrlHash OCTET STRING OPTIONAL } The refresh time specifies the time in seconds after which the scent must be refreshed, the refresh count specifies the number of times the scent should be refreshed after initial deployment, and the URL and optional hash of the data stored at the URL location contains the scent payload and integrity protection mechanism. 7.1. Security considerations Implementors should be aware that there exists the potential for confusion among relying parties when evaluating similar scent logotypes. For example, relying parties may not be able to meaningfully differentiate between the logos for McDonalds and Burger King, or Hersheys and Nestle, or Sealord and Penthouse. Resolution of this issue lies outside the scope of this memo. Intensive usage of scent logotypes may trigger smoke alarms and, by extension, sprinkler systems. Users should be aware of this and carry an umbrella. Certificate users involved in skunkworks projects are discouraged from adding scent logotypes to their certificates. -- Snip -- (OK, that's getting way off topic, but I hope it was at least amusing). Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]