There seems to be attempting to table any discussion of X.509v3 based on this
being a new work item for the group:
Well, since we've been discussing X.509v3 for weeks, I'd say that tabling it
per se is a bit futile. What we should table are attempts to stall PEM-MIME
*while* we discuss X.509v3. I have no problems with discussing X.509v3.
I'd love to, after we clear the table of old business.
Old business before new business. PEM-MIME is old business. X.509v3 is
new business. Very important new business, but of no direct impact on
PEM-MIME (in any way that is not equally true for RFC1421 and RFC1422).
The PEM charter places a strong emphis on the use of X.509. The X.509v3 work
is in the scope of this working group.
The PEM charter, as I understand it, defines no scope for this working group.
It is simply a description of RFCs 1421-1423. Perhaps there is some other
charter of which I am unaware, however. I'd love to read it.
I also see no mandate to move away from X.509 certificates in the charter of
the group.
I see no mandates whatsoever in the charter. This is one of my principal
difficulties with the group in its current form, in fact. However, for the
past two years the de facto agenda of the group has been to hash out a
representation for PEM that can coexist with MIME. It is because I have a
direct interest in this being done that I am participating here at all.
If such activity is not within the scope of this group, or is to be delayed
indefinitely while the group deliberates upon drafts (or worse yet, vague
statements about drafts) from other standards bodies, then my continued
participation is of no benefit to me or anyone else.
Whether this is a bug or a feature depends on who you ask, I suppose.
Right now, most of my colleagues in the software industry have written off
PEM, but are willing to look at PEM-MIME if it solves a problem (securing
MIME messages and body parts) that nothing else does. We have a duty to
our customers to provide solutions. Many of us would like this particular
solution to be the product of this working group. However, if there ends
up being no such product, we will have no other choice but to roll our own.
It will no doubt look a lot like a MIME profile of the relevant PKCS
standards, since they're already deployed and in use, and we generally
trust RSA to know their area of business.
I've been half tempted recently to set up a big conference call for email
vendors, hash out the MIME-related syntax and encoding details, and submit
an informational RFC for the benefit of anyone else who wants to play.
Yes, it would run roughshod over the IETF process, but THAT PROCESS IS
CURRENTLY NOT SOLVING MY PROBLEM.
Time is money. Balance the cost of future revision against the cost
of delay. If PEM-MIME turns out to need revision, so be it. Standards
are revised and obsoleted all the time. We try something, we deploy it
in the field, and we learn from our mistakes. Trying to guarantee that
it will all work perfectly in advance is isomorphic to the halting problem.
It simply can't be done.
The question, in my mind, is not whether PEM-MIME is perfect--clearly, it's
not. The question is whether PEM-MIME is good enough.
Amanda Walker
Senior Software Architect
InterCon Systems Corporation