I agree that we can move forward by ducking some of these hard issues
at the moment. I have a difference of opinion as to the
suggested mechanism for accomplishing that, and would prefer the use
of user-signed certificates, rather than abandon the use of
certificate entirely, as I said in my lengthy message to Jim Galvin.
By my reading at least, there's nothing preventing the use of self-signed
certificates; it just isn't mandated. My own feeling is that both PCA-signed
and self-signed certificates will be prevalently used in building policy
frameworks on top of the basic MIME/PEM mechanism (witness the current
discussion about "who's a trusted introducer" among PGP users), but that
providing the capability to use bare keys and such is also useful. In
particular, providing a well-defined representation for signatures and
encryption without certificates allows free experimentation with alternate
applications and policy frameworks, without introducing incompatible basic
representations.
If you as a vendor are seriously prepared to move forward with
an integrated PEM/MIME capability, then I would withdraw my objection
to trying to do too much at one time. Up till now, I have had
enough problems trying to get a vendor to offer one of these
capabilities (MIME, PEM, X.500 directory integration), and I thought
that it would be too much to ask for everything all at once.
When can I buy one?
Well, I'll put it this way. We're already selling MIME mail software. You
can FTP a 30-day demo from ftp.intercon.com. We have all the code for
signatures and encryption. I've started the wheels turning to get the
necessary commercial licenses from RSA. I can parse & use the keys and X.509
certificates contained in Apple PowerTalk signers and other PKCS-compatible
certificates. All I need is a stable spec for how to construct and parse the
appropriate MIME multiparts. As soon as that happens, PEM rolls into the
feature pipeline for TCP/Connect II.
I can't give dates in advance, of course, but to say that we're "seriously
prepared" to offer MIME/PEM is an understatement. "Chomping at the bit" would
be more accurate :). We will offer MIME/PEM, one way or another. If nothing
ends up in the standards pipeline, I'll be talking to TIS, Innosoft, Qualcomm,
and so on to try to ensure that we interoperate even in the absence of a
proposed standard, but I'd very much rather work with the output of this
working group than form an industry cartel. If the latter becomes necessary,
then I think this WG will have failed.
As I said several messages ago, I think the window is closing quickly.
Amanda Walker
InterCon Systems Corporation
PGP Key fingerprint: 594F63C03B52DC4E37E9160DE733CD87
PEM MD5OfPublicKey: 8E4A21B7025943DE2EDC7CC038B3D6B1