-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIBwDCCAWoCEQC43J7oZ50NWTRSVBShvvaXMA0GCSqGSIb3DQEBAgUAMFkxCzAJ
BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl
Y3VyZVdhcmUgUENBMRcwFQYDVQQLEw5FbmdpbmVlcmluZyBDQTAeFw05NDA0MDUx
NzA2NDJaFw05NTA0MDUxNzA2NDJaMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9T
ZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNlY3VyZVdhcmUgUENBMRcwFQYDVQQL
Ew5FbmdpbmVlcmluZyBDQTEVMBMGA1UEAxMMQ2hhcmxlcyBXYXR0MFkwCgYEVQgB
AQICAgQDSwAwSAJBDNmUqe2+nqg6iuUWzxaXegxki426RzmVNO6VHHYCV4nbo/WL
X9a7Jn/2nWqZUK/l+RXqCHU/21Ur9jFIt4GNHhcCAwEAATANBgkqhkiG9w0BAQIF
AANBAEY6kP5jHqK9B9PhZCCJ9mckYuKMufWr7l61LulXGwUTqFzjFC0MOYwXo5s+
8lqrLQ7YpTzyE74pKR1cl5TAUU4=
MIC-Info: RSA-MD5,RSA,
AZEgWJDlxqnAm6O9sossdEqsoHIrBDmZt6+G9Mf5Las/7X6wsBMWmM6dRHnPvLSz
Qk6NhmiggAaL16y9eiu7We0=
X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED
X-Information-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED
From: Rex Buddenberg <budden(_at_)nps(_dot_)navy(_dot_)mil>
But the list of contenders was shortened
as questions grew about the complex architecture.
Has anyone gone through the exercise of taking the government's functional
requirements and mapping them into Internet/SMTP/etc. technology, too see
how well it could be supported, how much it would cost, how quickly it
could be deployed, etc.???
Dave
First, before we can get to your direct question, Dave, we
have some underbrush to (at least) recognize and identify.
How well do the stated functional requirements reflect what
the government really needs?
I've had detailed discussions with three of the four consortia fielding
proposals, and I think a more interesting question is the market that
these groups believe they are addressing with a fielded DMS product suite.
Sure, a guaranteed 2 - 3 million seats with supporting infrastructure is
a significant chunk of change, but all groups that I talked to were more
interested in the prospect of selling their DMS solution to large corporate
customers.
My own understanding is that the security functionality
could be implemented equally on X.400 or SMTP. The spec
recognizes FIPS 146 in that it requires X.400. However,
(from memory) an RFC 1006 solution over TCP/IP is OK.
Now if we could just get SMTP and X.400 to converge and
co-opt each other ...
This is not quite true. I will paraphrase a few of the requirements,
hopefully not butchering them too much. Part of the problem prospective
bidders had was determining what precisely the requirements were,
particularly in regard to security.
1) All DMS software components must use strong mutual authentication
for all cooperating transactions, including UA-MTA, MTA-MTA,
UA-DSA, MTA-DSA, etc... This must be done using the NSA-approved
cryptographic algorithms supplied on the Tessera Card.
2) Support must be provided for signed receipts, i.e. non-repudiation
with proof of receipt.
3) The infrastructure must support multiple levels of message
priority with guaranteed delivery times, starting I believe at
three minutes.
4) Centralized auditing facilities should provide real-time message
tracing as well as performance and security monitoring.
5) All DMS components must be managed from a centralized management
workstation.
6) All of the above must be supplied as COTS products.
Needless to say, when the RFP first came out, no suite of products met all
of the requirements. The X.400 protocol suite provides specifications for
meeting these requirements, although no vendors had everything available
in COTS products. SMTP/PEM does not provide specifications for any of these,
although they can certainly be added as higher level functions on top of the
existing infrastructure -- but this would be a significantly larger stretch
on #6.
In addition to the above, the functional requirements mandate that virtually
all of the P2 and P22 EOS's (elements of service) be supplied, as well as most
of the P722 EOS's (a couple hundred more specified I believe by a NATO WG for
interoperable messaging in defense situations). Most of the required EOSs
are UA issues, but a fair number require services that are only provided
by a complete X.400 MTA implementation.
Probably the biggest functional difference between the
envisioned DMS applications and conventional e-mail is
that DMS is intended for organizational as well as personal
messaging. Consider the scale-up problems of, say, CentCom
during Desert Shield where command(_at_)centcom(_dot_)mil might be getting
several tens of thousands of messages a day. Few user agents
are equipped to internally route, account for, and tickle for
replies for this kind of volume. (The MH guys are happy
to handle 300 messages a day).
(This problem may be solved gratis for the military; I
understand that president(_at_)whitehouse(_dot_)gov is having a similar
problem;-).
# From: Ned Freed <NED(_at_)sigurd(_dot_)innosoft(_dot_)com>
# This really has nothing to do with PEM, but I could not resist...
#
# Really? I'm actually somewhat amazed to hear this. We routinely deal with
sites
# handling message loads this large or larger on a single system. If several <=
# 2(0000) we rarely have any trouble dealing with the load. Maybe our software
is
# extra-special-good, but I've always assumed that our competition can handle
# comparable loads with similar facility.
#
I'm sure Ned's code is amazingly efficient, but Rex was talking about a UA
handling that volume of traffic, not an MTA.
The organizational messaging facilities are one of the major features that
make DMS attractive to the bidders as they look forward to commercial
customers. In an evironment controlled through the use of public key
cryptography and cryptographically protected authorizations, an
organizational role consists of several individuals qualified to create
messages on behalf of the organization. These messages are produced by
them as individuals, and are forwarded to a special UA where the messages
are reviewed by a(n) individual(s) authorized to sign documents on behalf
of the organization. After review, the messages are resigned with the
organizational private key, the message content is scanned and a
distribution list is determined. The message is then encrypted for each
recipient.
Recipients are most likely other organizations, which are represented by
a "Profiling User Agent". This entity decrypts the message, scans it for
key words, phrases, etc..., builds a distribution list for recipients
within the recipient organization, and returns a signed receipt to the
originator. The message is then reencrypted for each of the final
recipients. Imagine decrypting/profiling/encrypting 50,000 messages a
day, particularly with the performance (slow.....) exhibitted by the Tessera
Card.
Transmission of organizational messages occurs via the infrastructure of
DMS MTA's, all providing authenticated exchanges, auditing, centralized
management and guaranteed delivery time.
These organizational facilities work in parallel with standard interpersonal
messaging. They do not need to be supplied by existing COTS products.
This is a very ambitious program. But it isn't much of a stretch to
envision it as the backbone for robust electronic commerce, or organizational
messaging within the commercial world.
Charles Watt
SecureWare, Inc.
-----END PRIVACY-ENHANCED MESSAGE-----