Karen,
Karen Rosenthal wrote:
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) ...
Welcome home Dorthy! >;)
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?
My guess is problematic at this point.
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 usually discount most of what Dave Crocker say anyway. His
reputation has definatly proceded him in several other venues.
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.
I believe tht pushing for the standards track is the better
alternitive.
2. Could the current drafts even pass as Informational RFCs right now.
Possibly some could with some cleaning up. But what's the point
really?
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...
I to am one of the skeptics. Seems that this process is following
the same type of policy wonking that the TLS process has run into
lately.
Dam shame too!
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?).
At this point, who knows?
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
Our answer is D.
(Could someone please technically prove any of the above?)
What would you require? I can provide some basic documentation
for our "Interface Facility" or MLPI if you care to except this?
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...
All the above is your answer IMHO. others will say, "Can't be done".
But we are not others. >;)
--
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
Regards,
--
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. IEG. INC.
Phone :913-294-2375 (v-office)
E-Mail jwkckid1(_at_)ix(_dot_)netcom(_dot_)com