invoicing with PKI

[Peter Gutmann]

>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 majordomo at metzdowd.com