signature, H = message hash, C = certificate hash, D = message
encryption)

PEM-suite: (KS = RSA, H = MD5,MD2, C = MD2, D = DES)

We also know that other suites of algorithms are being explored. One
is driven by export considerations. The Software Publishers
Association and the U.S. government have worked out arrangements for
quick export licensing of software that uses RC4 (or RC2) with keys
limited to 40 bits and RSA used for key management with RSA keys
limited to 512 bits. This is extremely controversial because the RC4
key is so short, but there's also a lot of pressure to use it because
it will permit export of implementations of PEM that use this suite.
LEt's call this suite

Export-suite: (K = RSA/512, S = RSA, H = MD5,MD2, C = MD2, D = RC4/40)

Another suite is the one emerging from NIST. Only the Digital
Signature Algorithm (DSA) and the Secure Hash Algorithm (SHA) have
emerged so far. Let's call this the NIST-suite.

NIST-suite: (K = ???, S = DSA, HC = SHA, D = DES)

Despite the incomplete nature of this suite and the incompatibility
with the RSA-based PEM-suite, at least some parts of the U.S.
government will insist on using this suite instead of the PEM-suite.

These suite seem fairly certain to me. Additionally, one can consider
the U.S. government's Pre-MSP (PMSP) to be a version of PEM except for
the algorithms. So far as I can tell, the suite is similar to the
NIST suite except for using its own Key Exchange Algorithm and Message
Excryption Algorithm.

PMSP-suite: (K = KEA, S = DSA, HC = SHA, D = MEA)


Now, do we want these suites to be documented in the RFC series? It
seems to me we need to balance the need to have them documented with
the need to protect the standardization process. We do not want to
add our imprimatur to an inadequately vetted set of algorithms nor do
we want to encourage fragementation and incompatility.

One approach is to issue RFC1115bis with its documentation of the
PEM-suite, and have it set forth the skelton for documenting other
suites. The other suites can then be documented via Experimental or
Prototype RFCs whenever someone wants to document them, and if they're
properly vetted, they can advance through the standards process.

If this approach is acceptable to the PEM WG, I think it will also be
acceptable to the IESG and IAB. Adjustment in RFC1115bis is needed to
convey the notion of suites and anticipate the documentation of
additional suites, but I don't anticipate the need for anything else.



Comments?


Steve

From pem-dev-relay@TIS.COM Thu Nov 12 15:50:08 1992
Received: from TIS.COM by scss3.cl.msu.edu (4.1/4.7) id AA06568; Thu, 12 Nov 92 15:50:04 EST
Received: by TIS.COM (4.1/SUN-5.64)
id AA28410; Thu, 12 Nov 92 14:46:39 EST
Received: from inet-gw-2.pa.dec.com by TIS.COM (4.1/SUN-5.64)
id AA28402; Thu, 12 Nov 92 14:46:28 EST
Received: by inet-gw-2.pa.dec.com; id AA20931; Thu, 12 Nov 92 11:46:26 -0800
Received: by us1rmc.bb.dec.com; id AA17289; Thu, 12 Nov 92 14:43:52 -0500
Message-Id: <9211121943.AA17289@us1rmc.bb.dec.com>
Received: from albeit.enet; by us1rmc.enet; Thu, 12 Nov 92 14:43:54 EST
Date: Thu, 12 Nov 92 14:43:54 EST
From: John Linn 12-Nov-1992 1445 <linn@albeit.enet.dec.com>
To: us1rmc::"crocker@tis.com"@erlang.enet.dec.com
Cc: pem-dev@TIS.COM, iesg@cnri.reston.va.us, linn@albeit.enet.dec.com
Apparently-To: pem-dev@tis.com, iesg@cnri.reston.va.us
Subject: RE: Multiple suites of PEM algorithms
Sender: pem-dev-relay@TIS.COM
Status: O

draft-ietf-pem-algorithms-01 (the current 1115bis) states the following about
extensibility to other algorithms than those presently used in PEM:

Some parts of this material are cited by other documents and it is
anticipated that some of the material herein may be changed, added,
or replaced without affecting the citing documents. Therefore,
algorithm-specific material has been placed into this separate
document. Use of other algorithms and/or modes will require case-
by-case study to determine applicability and constraints. Additional
algorithms and modes approved for use in PEM in this context will be
specified in successors to this document.

I believe that this statement is wholly sufficient to foreshadow and allow
future extension to accomodate alternative suites as they emerge. A prime
original purpose for splitting 1115 off from 1113 was to modularize algorithm
descriptions to be separate from the base message processing procedures,
thereby allowing the possibility of extending the algorithm choices in future
without reissuing the 1113 descendant.

>In preparing to advance the PEM specs to Proposed Standard status, the
>question arises how to address and document multiple suites of
>algorithms. Although the RSA/DES suite is the main focus, alternate
>suites are being pushed forward in various quarters. I don't think
>there's any question that the RSA/DES suite should be the basis for
>the PEM standard.

I agree that the RSA/DES suite should remain the basis for the PEM standard, at
least for the present time.

>At the same time, other suites will be used and
>it's necessary to document these alternates.

Now I'm confused. Given that the RSA/DES suite is, as agreed, the basis of the
PEM standard, why is it the responsibility of the PEM standard's specification
to document conflicting alternatives?

>Additionally, one can consider
>the U.S. government's Pre-MSP (PMSP) to be a version of PEM except for
>the algorithms. So far as I can tell, the suite is similar to the
>NIST suite except for using its own Key Exchange Algorithm and Message
>Excryption Algorithm.
>
>PMSP-suite: (K = KEA, S = DSA, HC = SHA, D = MEA)

I'm not familiar with PMSP; do proponents exist for use of this suite in
conjunction with PEM, and are documents available which would allow
determination of whether or not its KEA and MEA are compatible with PEM
processing requirements?

>Now, do we want these suites to be documented in the RFC series? It
>seems to me we need to balance the need to have them documented with
>the need to protect the standardization process. We do not want to
>add our imprimatur to an inadequately vetted set of algorithms nor do
>we want to encourage fragementation and incompatility.

Based on the experience gained with PEM prototyping, I believe that PEM RFCs
should document only those algorithm choices which are sufficiently mature and
vetted in not one, but two senses: (1) in terms of accepted cryptographic
quality of the algorithms themselves, and (2) in terms of available detailed
specification (e.g., with regard to padding, bit layout, usage mode, etc.) so
as to avoid ambiguity, interoperability problems, and potential security
vulnerabilities introduced above the bare algorithm level. At this point, I
believe that these criteria have been satisfied for the RSA/DES suite but not
for any of the other prospective suites cited in Steve's message.

>One approach is to issue RFC1115bis with its documentation of the
>PEM-suite, and have it set forth the skelton for documenting other
>suites. The other suites can then be documented via Experimental or
>Prototype RFCs whenever someone wants to document them, and if they're
>properly vetted, they can advance through the standards process.
>
>If this approach is acceptable to the PEM WG, I think it will also be
>acceptable to the IESG and IAB. Adjustment in RFC1115bis is needed to
>convey the notion of suites and anticipate the documentation of
>additional suites, but I don't anticipate the need for anything else.

I'm not convinced that 1115 needs to define the concept of suites in order to
make future extensions possible; it was, after all, always intended to act as
the repository within which additional alternatives would be documented. Any
future 1115 successor would, as the present 1115 does, define the sets of
algorithms which are to be used in conjunction with one another. For now, I
believe that draft-ietf-pem-algorithms-01 as it stands is ready for advancement
along with the other PEM specifications, as discussed at the last PEM WG
meeting at the Cambridge IETF.

--jl

From crocker@TIS.COM Thu Nov 12 15:58:43 1992
To: Markowitz@DOCKMASTER.NCSC.MIL
From: shirey@mitre.org (Robert W. Shirey)
X-Sender: shirey@smiley.mitre.org
Subject: RE: RIPEM (updated)
Cc: pem-dev@TIS.COM
Sender: pem-dev-relay@TIS.COM
Status: OR

In a previous message, I said: "Just as soon as I know for sure that
information on this subject [DMS PreMSP] is publicly releasable, I will
forward it or references to this list." Here are pointers to the
currently available public info.

A Request For Information (RFI) was issued by the Air Force Standard
Systems Center, Gunter AFB,Al, on December 1992. (See "Commerce Business
Daily" for 17 December 1992.) This RFP concerns X.400 products for use
in the Defense Message System. In brief, DOD needs hundreds of thousands
(of units) of secure UAs over the next several years.

In the RFI, there is publicly released information concerning Preliminary
Message Security Protocol (PMSP, or sometimes, PreMSP), which is to be
used for unclassified by sensitive information. PMSP is something that
exists. Do not expect it to interoperate with PEM.

Saying "Pre" MSP implies there is a "real" MSP to come later. There is.
It comes from NSA's Secure Data Network System Program. SDNS and MSP
information is available from NIST, and decriptions are found in the
proceedings of the National Computer Security Conference and other major
security conferences in the last few years. (Perhaps someone will chime
in again with the NIST references, etc.)

DMS security developments, including PMSP, will be addressed further by
an NSA representative at the AFCEA [Armed Forces Communications and
Electronics Association] DMS Symposium on 8 April.

Regards, -Rob-

Robert W. Shirey, The MITRE Corporation, Mail Stop Z202
7525 Colshire Dr., McLean, Virginia 22102-3481 USA
shirey@mitre.org * tel 703-883-7210 * fax 703-883-1397

---------------------------------------------------------------------------
The following statement on MSP was released previously:

Defense Information Systems Agency
Defense Network Systems Organization

In reply Refer To: DISM 12 November 1991

MEMORANDUM FOR DEFENSE MESSAGE SYSTEM (DMS) MILITARY COMMUNICATIONS
ELECTRONICS BOARD (MCEB) COORDINATOR

SUBJECT: Rationale for the Secure Data Network System (SDNS) Message
Security Protocol (MSP) for the DMS


1. As a result of the Allied Message Handling (AMH) International Subject
Matter Experts (ISME) working group meeting held in March 1991, certain
actions regarding message security were tasked to the U.S. representatives.
These tasks include two information papers which address the U.S. intentions
to use MSP to provide required message security services.

2. The first of these papers, which addresses the rationale and near-term
interoperability issues for the use of MSP, is enclosed. We are forwarding
this paper to you, as the DMS MCEB Coordinator, for dissemination to the AMH
ISME membership.

3. This paper has also been forwarded to the Chairman, Data Communications
Protocol Standards (DCPS) Technical Management Panel (DTMP) for use in
resolving an Interoperability Resolution Process (IRP) issue regarding the DoD
position on the use of MSP. Both the AMH ISME and DTMP processes will be
worked as parallel efforts.

4. My point of contact for this effort is CPT(P) Wayne C. Deloria, DISA/DISMB,
(703)285-5232, DSN 346-5232. He can be reached through electronic mail at
DELORIAW@IMO-UVAX.DCA.MIL. Please do not hesitate to contact him with any
question regarding this matter.


Enclosure a/s THOMAS W. CLARKE, Chief
DMS Coordination Division

cc: DMS Coordinators


22 October 1991

THE DEFENSE MESSAGE SYSTEM (DMS)
MESSAGE SECURITY PROTOCOL AND ALLIED INTEROPERABILITY


1. Introduction

The Defense Message System (DMS) Program has adopted Message Security
Protocol (MSP) as the target security protection mechanism for all DMS
organizational and individual message traffic. MSP was developed under the
auspices of the Secure Data Network System (SDNS) Program concurrent with
international development of the CCITT X.400 1988 Recommendation. SDNS MSP
and 1988 X.400 offer a similar set of security services. However, the two
approaches diverge in certain areas, due to differing priorities and
requirements, and the operational environment of the U.S. Department of
Defense (DoD). The purpose of this paper is to define the principal points of
departure, provide rationale for U.S. use of MSP, and to provide a framework
for agreement on near term messaging interoperability.

2. Rationale for Use of MSP

While the security services provided by MSP are similar to the 1988 X.400
Recommendation, the divergence in their implementation introduces
incompatibilities between the two strategies. Following is U.S. rationale for
use of MSP.

2.1 High Level of Assurance: DMS provides secure automated store-and-
forward message service to meet the operational requirements of the U.S. DoD.
The DMS conveys information ranging from unclassified to the most sensitive
classifications and compartments, requiring very high levels of assurance
throughout the system. While few, if any, individual User Agents (UAs) will
handle this entire range, many will handle more than one, and therefore
require a high degree of trust. MSP provides high assurance in the areas of
implementation strategy, access control, content security, and use of
commercially available products and services.

2.1.1 Implementation Strategy. To achieve a high level of assurance,
MSP was designed to provide separation of message security from message
processing, and to facilitate a certifiable and accreditable implementation.
By implementing the MSP security services in a separate protocol sub-layer, a
multi-level secure (MLS) architecture can follow conventional approaches in
the design of certifiable systems. The MSP approach depends upon creating a
small nucleus of "trusted" software, implemented as an adjunct to the UA, that
interacts with multiple, single-level instantiations of more complex software,
e.g., text editors and communications protocols. Further, placing the
security services at the end system (originator/recipient) is consistent with
the principle of "least privilege", which requires security processes in a
system to grant only the most restrictive set of privileges necessary to
perform authorized tasks.

1


22 October 1991

2.1.2 Access Control. The approach to access control adopted by MSP
places access control decisions in a separate process within the originator
and recipient UAs, providing a higher level of assurance for this service.
This high level of assurance is supported by detailed security design analyses
performed on various MSP prototype implementations.

2.1.2.1 MSP access control decisions are made as part of message
preparation and release, and as part of the processing of a received message.
End system (UA) responsibility for access control is a cornerstone of the MSP
security architecture. The access control decision relies on authorization
information contained in multiple certificates. These certificates provide
extended resolution for access control decisions and are further protected by
cryptography at the UA. Consequently, no access control message security
requirements are levied on the Message Transfer Agents (MTAs).

2.1.2.2 In contrast, 1988 X.400 access control decisions and
enforcement are vested in the Message Transfer System (MTS) and are exercised
independently by the MTAs at each end of the message transfer. This requires
that every subscriber uniformly trust all of the MTAs to enforce access
control for the subscriber community. A message originator has no independent
means of determining the access rights of a possible recipient, nor the means
to determine the level of trust of the MTAs that make access control
decisions. He must rely on the correct operation of the MTAs.

2.1.3 Content Security. MSP provides content security and integrity
services with the implementation of independent cryptographic algorithms and
key management system at the UA. Encapsulation of message content with
appropriate security parameters (e.g., algorithm identification and signature
information) into a MSP content prior to submitting it to the MTS, ensures
writer-to-reader control for all security services. This is true regardless
of the message transfer system employed. Since only the originator and
recipient may access the information, content security is preserved, and the
means for message confidentiality, integrity, authentication, and non-
repudiation with proof of origin is maintained.

2.1.4 Commercial Products/Services. A primary objective of the DMS
Program is to employ commercially available products and services wherever
possible, to minimize or eliminate the need for specialized systems. It is
also assumed that such products and services will undoubtedly be "untrusted"
from the security perspective. The use of MSP allows the DMS to deploy over
any reliable and heterogeneous MTS and still provide the same level of message
security and system assurance. The MSP design and implementation strategy,
coupled with the incorporated access control and content security mechanisms,
is consistent with this objective. While the 1988 X.400 Recommendation offers
similar services, its employment by DMS would require use of "trusted" MTAs, a
prospect that is not only cost prohibitive by lacking in deployment
flexibility.

2


22 October 1991

2.2 Key Management Support. MSP was designed to be independent of
cryptographic algorithms and key management schemes. Although 1988 X.400
maintains independence of the cryptographic algorithms used, it does employ a
specific key management scheme as defined in CCITT Recommendation X.509. The
protocol mechanisms that realized this key management scheme are incompatible
with MSP key management.

2.2.1 A solution consistent with the MSP concept might be implemented
within the X.400 syntax, but would represent a semantic inconsistency. Within
X.400, no syntax exists to exchange multiple certificates and other per-
message security data.

2.2.2 Even if a certifiable architecture using MSP-like key management
schemes could be developed to be consistent with 1988 X.400, it would likely
represent a substantial departure from COTS products.

2.3 Performance. Like MSP, the 1988 X.400 Recommendation defines both
per-message and per-recipient security data items. However, the allocation of
security relevant data, especially the signature and receipt information, is
different in X.400 and in MSP. 1988 X.400 requires one signature per
recipient while MSP requires one per message. The major performance
implications of this difference are the higher number of signature generation
operations required by 1988 X.400, and the higher volume of additional data
carried in each 1988 X.400 message.

3. Allied Interoperability.

3.1 Suggestions from the Allied Message Handling International Subject
Matter Experts Working Group (AMH ISME WG) recommend that the U.S. incorporate
MSP mechanisms with the 1988 X.400 framework. In reviewing this, technical
difficulties surface as previously discussed, and present a resultant product
which is semantically non-conformant with the 1988 X.400 Recommendation. This
suggestion is unacceptable from a security protection standpoint, and is cost
prohibitive.

3.2 The differences in the MSP and 1988 X.400 security protection
strategies as described in the rationale serve to illustrate an allied message
interoperability issue. It is evident that the U.S. will continue to pursue
implementation of MSP while U.S. allies, including NATO, appear poised to
pursue implementations of the 1988 X.400 Recommendation. When the U.S. begins
deployment of X.400/MSP components in the 1996 and beyond time frame, a MSP
gateway will be required to facilitate interoperability between users who have
implemented X.400 with MSP and users who have not. A Gateway will be required
to perform protocol mappings between MSP and X.400-based systems, and to
provide the required cryptographic and key management conversion services for
the systems employed. This Gateway will facilitate U.S. transition to MSP, as
well as provide interoperability with allied users during the international
transition to X.400.

3


22 October 1991

4. Conclusions.

4.1 Based on the rational provided above, the U.S. concludes that use of
MSP is superior to 1988 X.400 security protection in terms of assurance, key
management, performance, deployment flexibility, and cost.

4.2 As indicated above, allied interoperability will require an MSP
Gateway. The AMH ISME WG is an excellent forum to collect requirements for
this Gateway to ensure its timely development and deployment, and
effectiveness in providing near term allied interoperability. Long term
interoperability is being analyzed and will be the subject of a 15 February
1992 U.S. submission to the AMH ISME WG.

4

-----------------------------------------------------------------------
The Privacy and Security Research Group (PSRG) (i.e., that part of the
Internet Research Task Force that invented PEM and tossed it over the
fence into the Internet Engineering Task Force for final standardization
and deployment) received inqiries about the position of the U.S.
Federal Government on the use of Privacy-Enhanced Mail (PEM) (see RFCs
1421, 1422, 1423, and 1424). The PSRG issued a statement which is now
outdated but was along the following lines:

The PSRG does not speak for the U.S. Federal Government or for any other
government. It can, however, arrange some referrals for those seeking
Government information.

Like all bodies operating under the cognizance of the Internet
Activities Board (IAB), the PSRG is an independent committee of
professionals with a technical interest in the health and evolution
of the Internet system (see RFC 1160). When the PSRG was designing
and developing PEM, and when the IAB approved and encouraged PEM
implementation, there was discussion of existing U.S. and other government
policies and policy trends. No agreements were reached with any agency
or official. Some PSRG members are aware of talks that have taken place
within the U.S. Government about PEM, but the PSRG is not aware of any
publicly-announced policies that have been directed specifically at PEM.

For further information, the PSRG suggests that questions be directed
to the following PSRG members, who will either answer the question
or provide a referral to responsible officials:

For questions regarding the U.S. Government generally:

Miles Smid smid@st1.ncsl.nist.gov
National Institute for Standards and Technology
Building 225, Room A216
Gaithersburg, Maryland 20899

For questions regarding the U.S Department of Defense in general, and
the Defense Message System in particular:

Rob Shirey shirey@mitre.org
The MITRE Corporation, Mail Stop Z269
7525 Colshire Drive, McLean, VA 22102-3481

For other questions, send to pem-dev@tis.com and hope for the best!





From pem-dev-relay@TIS.COM Wed Mar 17 20:41:09 1993
Received: from TIS.COM by scss3.cl.msu.edu (4.1/4.7) id AA15091; Wed, 17 Mar 93 20:41:08 EST
Received: by TIS.COM (4.1/SUN-5.64)
id AA16468; Wed, 17 Mar 93 19:37:16 EST
Received: from DOCKMASTER.NCSC.MIL ([26.1.0.172]) by TIS.COM (4.1/SUN-5.64)
id AA16337; Wed, 17 Mar 93 19:35:10 EST
Date: Wed, 17 Mar 93 19:28 EST
From: TCJones@DOCKMASTER.NCSC.MIL
Subject: DMS
To: pem-dev@TIS.COM
Message-Id: <930318002851.390123@DOCKMASTER.NCSC.MIL>
Sender: pem-dev-relay@TIS.COM
Status: O

DMS is described in:

Secure Data Network System (SDNS) Network Transport, and Message
Security Protocols.

Published by NIST as NISTIR 90-4250

Tom Jones - Lemcom

From pem-dev-relay@TIS.COM Thu Mar 18 16:43:44 1993
Received: from TIS.COM by scss3.cl.msu.edu (4.1/4.7) id AA16794; Thu, 18 Mar 93 16:43:42 EST
Received: by TIS.COM (4.1/SUN-5.64)
id AA08270; Thu, 18 Mar 93 15:30:28 EST
Received: from DOCKMASTER.NCSC.MIL ([26.1.0.172]) by TIS.COM (4.1/SUN-5.64)
id AA08081; Thu, 18 Mar 93 15:28:11 EST
Date: Thu, 18 Mar 93 15:18 EST
From: Markowitz@DOCKMASTER.NCSC.MIL
Subject: was RE: RIPEM, now who knows?
To: pem-dev@TIS.COM
Message-Id: <930318201858.302694@DOCKMASTER.NCSC.MIL>
Sender: pem-dev-relay@TIS.COM
Status: OR

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@dockmaster.ncsc.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

From pem-dev-relay@TIS.COM Thu Mar 18 17:43:42 1993
Received: from TIS.COM by scss3.cl.msu.edu (4.1/4.7) id AA16892; Thu, 18 Mar 93 17:43:41 EST
Received: by TIS.COM (4.1/SUN-5.64)
id AA13498; Thu, 18 Mar 93 16:49:19 EST
Received: from CCV1.BBN.COM by TIS.COM (4.1/SUN-5.64)
id AA13492; Thu, 18 Mar 93 16:49:17 EST
Message-Id: <9303182149.AA13492@TIS.COM>
To: Markowitz@dockmaster.ncsc.mil
Cc: pem-dev@TIS.COM
Subject: apprpopriate PEM-DEV topics
Date: Thu, 18 Mar 93 16:47:53 -0500
From: Steve Kent <kent@BBN.COM>
Sender: pem-dev-relay@TIS.COM
Status: O

Mike,


I agree with your observation that Rob's PMSP/DMS status
message is also not directly relevant to this mailing list. Perhaps
Rob felt it appropriate to bring up this topic because an initial
version of PMSP looked an awful lot like PEM. Perhaps I viewed Rob's
message as less inappropriate than yours because he was not engaging in
an advertisement for his corporate product, as your message did. The
private message I sent to you, and which you included in your last
posting, tried to address this issue politely, but perhaps too
indirectly. The example I cited with regard to RSA algorithms was an
attempt to establish the sort of groundrules that you inquire about in
your message, in a non-discriminatory manner.

As you observerd, PMSP makes use of a "suite" of algorithms,
of which DSA/SHA are two FIPS candidates which have been published.
The policy we have adopted for PEM is to publish profiles for suites
of algorihtms, not just individual algotrithms, to avoid combinatorial
explosion of choices, which would lead to diminsihed interoperability.
When the full "NIST suite" becomes available, it would be a candidate
to profile for use with PEM. However, since we are short a couple of
algorithms to complete that suite (the symmetric encryption algorithm
and a public-key key management algorithm requested of NIST by
Congress several years ago), we can't produce the relevant profile yet.

I won't argue market share or size with you. PEM is intended
to addresses a worldwide Internet user population. The US Government
is electing to employ a different email security protocol, i.e., MSP
(PMSP has become just MSP with a different algorithm suite). We could
argue whether this decision will ultimately result in more PEM or MSP
users in the global marketplace, but it would be idle speculation on
everyone's part. Many of us recall the US Government's decision to
adopt OSI as a procurement directive (GOSIP) in the mid-1980s. Folks
who sell TCP/IP both to the government, and to the general user
population, have prospered despite that decision. One can argue that
PEM is doomed if it fails to adopt SHA/DSA, or that it is doomed
anyway because of MSP, but the arguments are far from convincing
at this point. I'm sure the RSA folks would point to the long list of
major hardware and software vendors who license their algorithm and
suggest that the US Government policy of buying COTS products will
lead to widespread use of RSA, irrespective of a the latest
procurement regulations.

You propose that a suitable additional PEM suite would consist
of DSA, SHA, DES, and El Gamal. Since the NIST suite is only
partially populated, as noted above, this suggests that we would
likely have two suites with DSA/SHA, but with different encryption
algorithms. This begins to sound like the sort of diversity that we
were trying to avoid by profiling suites. Note also that the DSA is
currently the subject of two patent infringement claims in the US, as
observerd by NIST at their workshop last month. We worked for some
time to make appropriate arrangements with regard to use of RSA with
PEM (in the US) and would have to engage in potentially more elaborate
arrangements to use DSA since it is the subject of international (not
just US) patent claims. Thus it may be premature to encourage the PEM
community to use of the DSA at this point, in addition to the other
concerns cited above.

Several points in your message seem to focus on US Government
users. The PEM WG has a broader target population and thus may weigh
various factors differently. One could argue, from your message, that
the US Government market will adopt MSP/PMSP and the "NIST suite" and
thus the choice of algorithms for use with PEM is less relevant to
them, as they are using a different secure email protocol. One also
could argue that using a common algorithm suite is good for everyone,
even if different protocols are employed, since it would be easier to
interoperate by sticking with the same algorithms but selecting
different protocols as required. However, that approach would seem to
argue for adopting the whole NIST suite, not half of it plus two other
algorithms, which seems to be the proposal you put forth.

In regard to your final comment, I believe Steve Crocker would
advise you, as will I, that anyone is free to develop and submit a
document as an Internet Draft. The publication of such documents as
experimental RFCs is also relatively straightforward. If you want to
pursue development of an additional PEM algorithm suite as an Internet
Standard, then that work falls under the purview of this WG. If there
is sufficient interest in the work and concensus on the results, then
it will be progressed.


Steve

From pem-dev-relay@TIS.COM Thu Mar 18 18:26:33 1993
Received: from TIS.COM by scss3.cl.msu.edu (4.1/4.7) id AA16918; Thu, 18 Mar 93 18:26:32 EST
Received: by TIS.COM (4.1/SUN-5.64)
id AA15033; Thu, 18 Mar 93 17:03:49 EST
Received: from mwunix.mitre.org by TIS.COM (4.1/SUN-5.64)
id AA15024; Thu, 18 Mar 93 17:03:45 EST
Received: from smiley.mitre.org.sit (smiley.mitre.org) by mwunix.mitre.org (5.65c/SMI-2.2)
id AA19761; Thu, 18 Mar 1993 17:03:00 -0500
Received: from [128.29.140.100] (shirey-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1)
id AA04972; Thu, 18 Mar 93 17:02:28 EST
Message-Id: <9303182202.AA04972@smiley.mitre.org.sit>
Date: Thu, 18 Mar 1993 17:04:13 -0500
To: Markowitz@DOCKMASTER.NCSC.MIL
From: shirey@mitre.org (Robert W. Shirey)
X-Sender: shirey@smiley.mitre.org
Subject: Re: was RE: RIPEM, now who knows?
Cc: pem-dev@TIS.COM, saag@TIS.COM
Sender: pem-dev-relay@TIS.COM
Status: O

At 3:18 PM 3/18/93 -0500, Markowitz@DOCKMASTER.NCSC.MIL wrote:

>... please explain to me, if you can,
>how PMSP/DMS is more "interesting" or "relevant" (see below) than an
>similar ElGamal/DSA/DES product.

PMSP (now being tested in prototype, and planned for use in DMS) is
interesting in the context of the pem-dev list because:

(1) It seems to be a complete electronic mail system/architecture with
very nearly the same functionality as PEM, and is interesting from a
comparative viewpoint.

(2) DMS is not used just by DoD, and not even just by the U.S. Government.
Even if just by DoD, PMSP will be used across the Internet by a major
subcommunity of the Internet, and this naturally raises the question of
interoperability and/or coexistence/cooperation with PEM.

(3) El Gamal is not by itself an e-mail system. Given that a PEM
implementation already needs RSA for protecting DEKs, why also be burdened
with a different, separate signature algorithm? There would have to be
functional advantages to paying for extra software. Are there?

>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.

As PMSP evolves to MSP, it might continue to use the same algorithms that
it does now. It might also evolve to different Type 2 algorithms. In any
case, these algorithms, other than DSA and SHS, might never be published.
The algorithms might even migrate from software into custom hardware that
is designed to prevent reverse engineering. In any event, all this
addresses only unclassified information. For classified information, its a
VERY good bet that MSP does NOT use the same suite. By definition it uses
a Type 1 suite, not a Type 2 suite.

>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.

I am not in charge of this list or of any working group; I was just passing
out relevant information to help people in the industry do their job.
Stupid as it sounds, MITRE's charter is to work in the public interest.
(We have no shareholders; we have no shares! If MITRE decides to go out
business, the assets that remain are basically given to the President of
the United States to dispose of as she sees fit.)

However, since you ask, IMHO it is OK to discuss the algorithms. For
example, at the PSRG Workshop in San Diego in February, there was an active
discussion of RCx and potential uses in Internet protocols. I think that
it might be appropriate for someone to follow on here with a well-written
analysis of the pros and cons of using an exportable suite of algorithms in
place of the one specified in RFC 1423. For example, GOOD because
exportable and therefore rapidly deployable; BAD because 40 bits of key
length implies less strength than 56; etc. However, such an analysis, to
be constructive, needs to propose a complete suite that is exportable.
What do we use to replace RSA for protecting DEKs? That is how we have
viewed the DSS question in the past: When the Government publishes a
complete suite/profile of algorithms for PEM, they should be considered for
inclusion. Mixing and matching would seem to inhibit rather than foster
interoperability that scales to the world.

>Steve Kent apparently feels such discussions are outside the scope of
>the WG, not to mention this mailing list.
>[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?]

I think that there are other, obvious places to post that kind of stuff,
like sci.crypt, for example. I was asking about PEM performance.

>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?

PGP doesn't use DSA/SHA either, no?

My simple understanding of the situation is that use of PGP by, for
example, The MITRE Corporation, not to mention General Motors, or even
official support of large-scale PGP usage by the student body at a large
University, leaves the institution open to very damaging legal action.
(New York Times, 18 March 1995: "U.S. Marshalls in cooperation with
Software Publishers Association and Public Key Partners today raided the
offices of Crosscountry Insurance Corporation in 15 cities, confiscating
numerous computers, including some containing unlicensed copies of software
that uses RSA encryption.") We decided not even to keep a copy on a
restricted server for analysis.

The legal situation causes PGP to have inherent limits to growth. PEM does
not have those limits. Further, when RSA comes built into my Mac OS along
with a built-in license, even the licensing problem will no longer be a
barrier to PEM growth in the U.S. How the export issue will play out, time
will tell. But the algorithms you propose are no more and no less
exportable than the ones already approved for PEM.

>Provided we
>can get Steve Kent's permission, that is. :-)

Don't waste your technical and entrepreneurial talents being snide. Show
up at the IETF, or present your ideas electronically. The IETF is one of
the most open and tolerant forums for technical discussion that can be
found in the world. It has to be to keep with the technology it is
attempting to standardize. Any well-reasoned Internet-Draft on the subject
of alternative algorithms would be a positive contribution that surely
would have no trouble finding space on the pem Working Group agenda or on
its official discussion list, pem-dev.

Regards, -Rob-

Robert W. Shirey, The MITRE Corporation, Mail Stop Z202
7525 Colshire Dr., McLean, Virginia 22102-3481 USA
shirey@mitre.org * tel 703-883-7210 * fax 703-883-1397



From pem-dev-relay@TIS.COM Thu Mar 18 19:08:37 1993
Received: from TIS.COM by scss3.cl.msu.edu (4.1/4.7) id AA16960; Thu, 18 Mar 93 19:08:37 EST
Received: by TIS.COM (4.1/SUN-5.64)
id AA18888; Thu, 18 Mar 93 17:48:52 EST
Received: from blackbird.afit.af.mil by TIS.COM (4.1/SUN-5.64)
id AA18880; Thu, 18 Mar 93 17:48:49 EST
Received: from scgraph.afit.af.mil by blackbird.afit.af.mil with SMTP id AA19454
(5.65c/IDA-1.4.4 for <pem-dev@tis.com>); Thu, 18 Mar 1993 17:48:07 -0500
Received: from lion.zoo_serv (lion.afit.af.mil) by scgraph.afit.af.mil (4.1/SMI-4.1)
id AA09725; Thu, 18 Mar 93 17:48:04 EST
From: gwishon@afit.af.mil
Message-Id: <9303182248.AA09725@scgraph.afit.af.mil>
Subject: Re: was RE: RIPEM, now who knows?
To: Markowitz@DOCKMASTER.NCSC.MIL
Date: Thu, 18 Mar 93 17:46:33 EST
In-Reply-To: <930318201858.302694@DOCKMASTER.NCSC.MIL>; from "Markowitz@DOCKMASTER.NCSC.MIL" at Mar 18, 93 3:18 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: pem-dev-relay@TIS.COM
Status: O

>
> 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.
>

The sad thing here is, of course, there are many of us who must work and
interact with colleagues in _both_ worlds, and who are anxiously awaiting
the eventual reconciliation and convergence of standards, certification
heirarchies, and products.

We'll see that day come soon, won't we....


Gordon



Gordon D. Wishon, Air Force Institute of Technology
2950 P Street, Wright-Patterson AFB, OH 45433-7765 USA
gwishon@afit.af.mil * tel (513) 255-8000 * fax (513) 476-7080



From pem-dev-relay@TIS.COM Thu Mar 18 19:29:13 1993
Received: from TIS.COM by scss3.cl.msu.edu (4.1/4.7) id AA16975; Thu, 18 Mar 93 19:29:12 EST
Received: by TIS.COM (4.1/SUN-5.64)