To Michael Roe:
You might have seen it, but some PGP (Pretty Good Privacy, the RSA+IDEA
scheme) users have figured out they are going to soon have a key management
crisis because of the number of keys involved. (Don't know if they have
figured out they have assurance problems because of their lack of
certificates.) Over the weekend, there were messages on this to sci.crypt,
alt.security, alt.pgp, and other lists
The kickoff of the string was from you neck of the woods in the UK: Paul C
Leyland, pcl(_at_)ox(_dot_)ac(_dot_)uk(_dot_) I replied (third attachement
here) and implied you
existed. I got two individual UK replies, and leave it to you to contact
them, please.
Regards, -Rob-
Robert W. Shirey, The MITRE Corporation, Mail Stop Z202
7525 Colshire Dr., McLean, Virginia 22102-3481 USA
shirey(_at_)mitre(_dot_)org * tel 703-883-7210 * fax 703-883-1397
------------------------------------
Date: Mon, 7 Jun 93 16:33:52 BST
From: tjfs(_at_)tadtec(_dot_)co(_dot_)uk (Tim Steele)
To: Rob Shirey <shirey(_at_)mitre(_dot_)org>
Subject: Re: The impending PGP key distribution logjam
Content-Length: 199
X-Mdf: Mail for shirey sent to shirey(_at_)smiley(_dot_)mitre(_dot_)org
Who's the contact at Cambridge University trying to set up key
distribution? I'd like to contact him/her.
Tim
--
Tim Steele, Network Manager, tjfs(_at_)tadtec(_dot_)co(_dot_)uk(_dot_) PGP key
available via finger.
------------------------------------
From: pcl(_at_)neon(_dot_)athena(_dot_)ox(_dot_)ac(_dot_)uk
Date: Mon, 7 Jun 93 17:17:00 +0100
To: Rob Shirey <shirey(_at_)mitre(_dot_)org>
Subject: Re: The impending PGP key distribution logjam
X-Mdf: Mail for shirey sent to shirey(_at_)smiley(_dot_)mitre(_dot_)org
Dear Mr. Leyland,
I encourage you to hasten to read RFC 1422, which
is the third generation RFC in a continuing effort to
establish a public key
distribution hierarchy for the Internet. This probablly
will lead you to
also read RFC 1424, and they 1421 and 1423.
...
Thanks for pointing this out and especially so for doing so in a public
forum where others will see it.
Now, will this be pgp compatible, I wonder. I certainly hope so.
Paul
------------------------------------------
In <PCL(_dot_)93Jun4150854(_at_)rhodium(_dot_)ox(_dot_)ac(_dot_)uk> Paul C
Leyland, pcl(_at_)ox(_dot_)ac(_dot_)uk writes:
about the need for RFCs to define key distribution for PGP.
Dear Mr. Leyland,
I encourage you to hasten to read RFC 1422, which
is the third generation RFC in a continuing effort to establish a public key
distribution hierarchy for the Internet. This probablly will lead you to
also read RFC 1424, and they 1421 and 1423.
Members of the Privacy-Enhanced Mail Working Group of the Internet Engineering
Task Force will be in Cambridge, UK, the week of July 5, and of course will be
at the IETF meeting in Amsterdam the week of July 12. (In fact, a member of WG
in on the staff of Cambridge University and has been active in setting up
a key distribution system in the UK for Internet mail.) Perhaps we could
meet informally sometime in one of those weeks.
Attached are details on the RFCs, as well as the Executive Summary for 1422.
Regards, -Rob-
Robert W. Shirey, The MITRE Corporation, Mail Stop Z202
7525 Colshire Dr., McLean, Virginia 22102-3481 USA
shirey(_at_)mitre(_dot_)org * tel 703-883-7210 * fax 703-883-1397
------------------------------------------------------
1424 Kaliski, B. Privacy Enhancement for Internet Electronic Mail: Part IV:
Key Certification and Related Services. 1993 February; 9 p. (Format:
TXT=17538 bytes)
1423 Balenson, D. Privacy Enhancement for Internet Electronic Mail: Part
III: Algorithms, Modes, and Identifiers. 1993 February; 14 p. (Format:
TXT=33278 bytes) (Obsoletes RFC 1115)
1422 Kent, S. Privacy Enhancement for Internet Electronic Mail: Part II:
Certificate-Based Key Management. 1993 February; 32 p. (Format:
TXT=86086 bytes) (Obsoletes RFC 1114)
1421 Linn, J. Privacy Enhancement for Internet Electronic Mail: Part I:
Message Encryption and Authentication Procedures 1993 February; 42 p.
(Format: TXT=103895 bytes) (Obsoletes RFC 1113)
------------------------------------------------------
1. Executive Summary
This is one of a series of documents defining privacy enhancement
mechanisms for electronic mail transferred using Internet mail
protocols. RFC 1421 [6] prescribes protocol extensions and
processing procedures for RFC-822 mail messages, given that suitable
cryptographic keys are held by originators and recipients as a
necessary precondition. RFC 1423 [7] specifies algorithms, modes and
associated identifiers for use in processing privacy-enhanced
messages, as called for in RFC 1421 and this document. This document
defines a supporting key management architecture and infrastructure,
based on public-key certificate techniques, to provide keying
information to message originators and recipients. RFC 1424 [8]
provides additional specifications for services in conjunction with
the key management infrastructure described herein.
The key management architecture described in this document is
compatible with the authentication framework described in CCITT 1988
X.509 [2]. This document goes beyond X.509 by establishing
Kent [Page 1]
RFC 1422 Certificate-Based Key Management February 1993
procedures and conventions for a key management infrastructure for
use with Privacy Enhanced Mail (PEM) and with other protocols, from
both the TCP/IP and OSI suites, in the future. There are several
motivations for establishing these procedures and conventions (as
opposed to relying only on the very general framework outlined in
X.509):
-It is important that a certificate management infrastructure
for use in the Internet community accommodate a range of
clearly-articulated certification policies for both users
and organizations in a well-architected fashion.
Mechanisms must be provided to enable each user to be
aware of the policies governing any certificate which the
user may encounter. This requires the introduction
and standardization of procedures and conventions that are
outside the scope of X.509.
-The procedures for authenticating originators and recipient in
the course of message submission and delivery should be
simple, automated and uniform despite the existence of
differing certificate management policies. For example,
users should not have to engage in careful examination of a
complex set of certification relationships in order to
evaluate the credibility of a claimed identity.
-The authentication framework defined by X.509 is designed to
operate in the X.500 directory server environment. However
X.500 directory servers are not expected to be ubiquitous
in the Internet in the near future, so some conventions
are adopted to facilitate operation of the key management
infrastructure in the near term.
-Public key cryptosystems are central to the authentication
technology of X.509 and those which enjoy the most
widespread use are patented in the U.S. Although this
certification management scheme is compatible with
the use of different digital signature algorithms, it is
anticipated that the RSA cryptosystem will be used as
the primary signature algorithm in establishing the
Internet certification hierarchy. Special license
arrangements have been made to facilitate the
use of this algorithm in the U.S. portion of Internet
environment.
The infrastructure specified in this document establishes a single
root for all certification within the Internet, the Internet Policy
Registration Authority (IPRA).
**CHANGED TO Internet Certificate Issuers Registry (ICRA)**
The IPRA establishes global policies,
described in this document, which apply to all certification effected
Kent [Page 2]
RFC 1422 Certificate-Based Key Management February 1993
under this hierarchy. Beneath IPRA root are Policy Certification
Authorities (PCAs), each of which establishes and publishes (in the
form of an informational RFC) its policies for registration of users
or organizations. Each PCA is certified by the IPRA. (It is
desirable that there be a relatively small number of PCAs, each with
a substantively different policy, to facilitate user familiarity with
the set of PCA policies. However there is no explicit requirement
that the set of PCAs be limited in this fashion.) Below PCAs,
Certification Authorities (CAs) will be established to certify users
and subordinate organizational entities (e.g., departments, offices,
subsidiaries, etc.). Initially, we expect the majority of users will
be registered via organizational affiliation, consistent with current
practices for how most user mailboxes are provided. In this sense
the registration is analogous to the issuance of a university or
company ID card.
Some CAs are expected to provide certification for residential users
in support of users who wish to register independent of any
organizational affiliation. Over time, we anticipate that civil
government entities which already provide analogous identification
services in other contexts, e.g., driver's licenses, may provide
this service. For users who wish anonymity while taking advantage of
PEM privacy facilities, one or more PCAs will be established with
policies that allow for registration of users, under subordinate CAs,
who do not wish to disclose their identities.