Rob Shirey writes:
The comparison you offer is not especially interesting in the context
of >>the pem-dev mailing list.
The PEM objective has been a standard for secure mail with
Internet-wide >>interoperability. We now have such a standard, ... >>
At this time, RFC 1423 specifies the use of >>RSA for symmetric key
distribution and signature, and MD2 and MD5 for >>hashing. ElGamal (in
any form), DSS, and SHS are not listed in the RFC. >>Nor are RC2 and
RC4.
I appreciate the history lesson, but please explain to me, if you can,
how PMSP/DMS is more "interesting" or "relevant" (see below) than an
similar ElGamal/DSA/DES product. Frankly, I find *all* these things
both interesting and relevant.
PMSP uses the NIST "suite" of algorithms (at least the DSA/SHA). It's a
good bet MSP will use the same algorithms for sender and message
authenti- cation. No RSA, no DES, no MD2/MD5. Yet we find PMSP/DMS
being discussed on PEM-DEV. Guess it just depends on who posts, huh?
Or maybe it's okay to discuss these things as long as the algorithms
involved aren't mentioned. Please clear this up for me, Rob.
The question of whether DSS should or will appear as a PEM algorithm
has >>been discussed in the PSRG and the PEM WG since as early as NIST
first
Steve Kent apparently feels such discussions are outside the scope of
the WG, not to mention this mailing list. I quote:
---------------------------------------------
Mike,
While I appreciate the comparative timing data you provided
from your company's product, this is a mailing list for discussion of
PEM, not generic file/email security technology. If you company
produces a PEM-compliant product, discussion of its performance would
be relevant to the mailing list and I would encourage such discussion.
However, since the product you described is not intended to be a
PEM-compliant implementation, its discussion in this list is
inappropriate. The discussion is even less relevant case since the
algorithms utilized in your product are not covered by the published
PEM algorithm suite in RFC 1423. I would similarly discourage the RSA
folks from comparing BSAFE performance, using RC-2, on this list, so
please don't interpret this note as being directed against ISC.
Rather, it is a request I would make to anyone pursuing discussion of
technology not consistent with the charter of the PEM WG.
Thanks,
Steve Kent
Chair, PEM WG
---------------------------------------------
I take it ElGamal and the DSA/SHA are outside the scope of the charter.
In that case, it beats me why you guys bothered to discuss them at all.
[Personally, I for one would welcome the posting of BSAFE benchmarks
here, including those for RC2/RC4. I'm sure I'm not alone in this--I
think Rob's original query even asked for them. Anyone from RSADSI
listening?]
However, the U.S. Government, particularly the Department of Defense,
is >>proceeding along a path that will make it difficult for vendors to
sell a >>secure e-mail package that is both PEM-compliant and meets
Government >>standards.
The conclusion seems obvious, doesn't it?
As I said in 1991, you guys need to get on the PEM bandwagon for
long-term >>marketability.
If we had gotten on the PEM "bandwagon" in '91, we'd probably be out of
business by now. I haven't seem Simpact around lately with their
mailer. To quote an IRS employee who shall remain anonymous, "You're
not going to sell any of that around here." So let me offer some advice
of my own:
PEM needs to get on the DSA/SHA bandwagon for long-term *survivability*
as well as short-term *utility*. You do want PEM to be deployed on at
least as large a scale as PGP, don't you?
As long as there is no NIST standardization on the symmetric
cryptosystem used in PMSP, FIPS 41-1 & 86 specify what the federal
government must use--so we're stuck with DES. FIPS XX and YY specify
DSA/SHA. ElGamal, being the basis of the DSA, is a good near-to-middle
term solution to the key management problem. The Universities can use
whatever the hell they like; DLA trading partners and electronic tax
filers will have to use the DSS, no? This means the
registration/certification of ElGamal public keys. TIS, at least, is
working in the right direction. As is NASA/Ames, AT&T, and others.
If someone [Steve Crocker?] would care to point me in the right
direction, I'd be happy to work on an RFC, or whatever is needed to
propose an alternate suite of algorithms for use with PEM. Provided we
can get Steve Kent's permission, that is. :-)
mjm
----------
Michael J. Markowitz, VP R&D
markowitz(_at_)dockmaster(_dot_)ncsc(_dot_)mil
Information Security Corp. 708 405-0500, fax: 708 405-0506
1141 Lake Cook Rd., Suite D MCI: 363-1959
Deerfield, IL 60302 CIS: 76206,2617