However, at least here in the US there are a number of other
applications that are waiting in the wings that might end up dwarfing
MIME, and even e-mail itself as the "killer application," including
the use of the PKI infrastructure for income tax reporting,
insurance/benefits claims processing, etc., with agencies such as the
US Postal Service getting geared up to play a major role. Although I
would like to support interested vendors in this community as much
as possible, I don't want to do it at the expense of screwing up
the broader base without due deliberation.
Actually, it's an eye towards that broader base that is behind much of my
concern with MIME/PEM. All I want is the ability to provide to MIME messages
and individual MIME body parts the same set of services as RFC 1421 provides
to ASCII text. I don't actually care about key management--I'm perfectly
happy to stick with X.509 and allow self-signed certificates (which I will
distinguish in my UI).
However, I don't necessarily want to use it for email. I'm also interested in
the implications for WWW, database applications, and so on. MIME is the first
compound data representation that this industry has created that people don't
have to be forced at gunpoint to implement (look at the market success of ODA,
for comparison). This is a win. My immediate concern is email, but the
ability to provide security services within the MIME transport representation
will have many more uses that just email.
While we are having this discussion, I am also ramping up for SHTTP, directory
services, and so on, all of which are using or leaning towards using MIME as
their compound object format.
Amanda, I absolutely agree with you, and I agree with both you and Ned about the
virtues of being able handle complex objects in a fairly uniform manner using
MIME
(although Ned keeps mentioning little crawly things that concern me somewhat.)
I was lying awake last night and this morning trying to think about how to
phrase
my objections nicely, but you've said it perfectly. If we had simply replaced
RFC
1421 with an enhancment to add security to MIME body parts, I think that the
result
would have been met with acclaim. Alternately, we could have fixed some of the
problmes that were slowing down the adoption of PEM, and that also would ahve
been
well received.
Rhys and I (and others) had this discussion more than a year ago, and
essentially
worked out a roadmap to overcoming the perceived problems in getting a CA
infrastructure in place:
1. Add explicit support in the RFC for self-signed certificates in order to
jump-start the process and address those users who were more interested in
issues
of trust and trustworthiness, as opposed to a formal hierarchical identification
policy.
2. Support a simple e-mail based certificate-issuing responder service that
would
have used the fact of e-mail connectivity as a basis for a PCA policy model for
identification. As I recall, RSA indicated their willingness to support such a
service. This policy would clearly lie somewhere in between the RSA Commercial
Hierarchy and the Persona PCA policy models for identification purposes.
Billing for such services wasn't discussed, but it might be reasonable to charge
$30 to $50 per 10 users per e-mail account or domain name, rather than trying to
bill for $1 to $3 per user certificate. (TARNSTAFL - There ain't really no such
thing as a free lunch.)
3. As part of this compromise between the medium-high integrity/well-structured
systems that are required by most large corporations (witness Paul Lambert's
excellent comments recently) and the low integrity, low cost, anarchists
VolksMail
PGP approach, we would adopt the use of the rfc822 e-mail name as a
distinguished
name, as an alternative or in addition to the organizational person or
residential
person DN model. I even offered to host a free or very low cost X.500 directory
service to facilitate such an effort, and would have been happy to deal with the
problem of aliasing back and forth between the more conventional forms of DNs.
Unfortunately, instead of adopting that rather simple solution and preserving
all
of the work that had been done to date, some of the folks at TIS decided to
combine
all of the benefits of southern efficiency and northern charm (can your beer do
this?) into one indigestible system with flaws that are now perceived as rather
serious, at least to a significant portion of the user community.
It is also unfortunate that it is those large customers who are most likely to
benefit from the use of complex MIME structures for moving forms and electronic
doucments around, rather than the AOL newbies would wouldn't be willing to pay
for
commercial quality services in any case.
Vendors such as you and Ned would therefore seem to be on the horns of a
dilemma --
you have presumably invested substantially in a product that doesn't seem to fit
either marketplace terribly well.
Is it absolutely too late to try to turn back the clock, salvage the excellent
work
done in the MIME area, and graft it back on to an mildly extended RFC 1422
certificate-based processing scheme along the lines I sketched above?
Bob