After returning from attendance at the S/MIME Developers Workshop
yesterday (I feel somehow like I've been spun up in a tornado, and
dumped back in exactly the same place) ...
Issues of concern:
1. Will the current PKCS standards, along with the current dusse drafts
be submitted as Informational RFCs as is, or not; and if so, is this
submission, in light of desire to proceed along the true RFC standards
track at a later time, problematic or not?
From an ediint perspective, I have a vested interest in seeing the
current work gaining some sort of RFC status in the immediate future, as
the ediint drafts reference the dusse drafts. If an Informational RFC
is a short term answer, and progression down the standards track, with a
revised, and more functional version of S/MIME / PKCS in the future, so
be it. Dave Crocker gave the impression that submitting the same
material for both Informational RFC status, and standards track, would
be asking for trouble. I didn't know if this was in the context of
submitting the SAME material (current dusse drafts, and PKCS#7 v1.5) for
Informational RFC, and down the standards RFC track, or also included
the case of having an essentially rewritten form (i.e. S/MIME V3, PKCS#7
v2) go down the standards track. If the former, great, but if the
latter, I'd say, drop the Informational RFC quest, and push the
standards track.
2. Could the current drafts even pass as Informational RFCs right now.
Opinion on this seems to be pretty well split. I echo Keith Dennis'
concern voiced in his earlier message, that RSA's hold on rsaEncryption
is a big problem, regardless of whether or not precedence has been set
on this before, in the IETF decision making process. I hope, being one
of the skeptics, that I'm wrong...
3. Moving forward...
Cutting to the chase ... S/MIME and MSP merge, and a completely revamped
PKCS#7. Great. How long are we talking about to get these completed,
and through the IETF process (or does the IETF process get dropped?).
We've got S/MIME product in the market place right now. And our
customers want standards compliant, interoperable products (the word
"standards" used loosely - truly for "most" clients, standards compliant
really does mean interoperable!!!), that, with all the current press,
provide for DSS and DH, as well as RSA. In asking the question, can
S/MIME and PKCS#7 v1.5 support DSS and/or DH, I've gotten no details,
but answers ranging the gambit from:
a. can't be done
b. can be done as a hack
c. can be done, in a standards* compliant manner
d. we've done it
(Could someone please technically prove any of the above?)
Bottom line - we need to provide DSS and DH soon. We need to know what
our options are, and timelines. Will we have the ability to implement
them though our current product (current versions of S/MIME, PKCS)? If
not, has anyone ever considered making algorithm independence a sole
modification to the existing smime draft to get it on standards track,
quickly? Or is supporting PGP as well, our answer...
--
Karen Rosenthal Email: karenr(_at_)premenos(_dot_)com
Premenos Tel#: 1-510-688-2928
1000 Burnett Ave Fax#: 1-510-602-2133
Concord, CA 94520 Visit: http://www.premenos.com