>Does anyone else see the problem or the lack of one?
Yes, there are problems with the MIME-PEM specification.
Paul, my question was specific to the thread Jeff and I were discussing,
not a general one. If there are problems, please be specific about
exactly what is an issue and why.
>I think Jeff and I could both really use some alternative insight.
This is not a problem of mechanisms, but of requirements. It is
true that many interesting mechanisms can be defined to
distribute public keys. Not all of these mechanisms are
necessary. As a working group we need to focus on what
requirements MIME-PEM should address.
How does key distribution factor into the discussion at hand? To date
this issue has not been discussed.
Changes have been made in MIME-PEM that add requirements to
existing implementations of RFC1421 PEM beyond the basic MIME
encapsulation formats. Rather than spending too much time
rationalizing how a data base can be changed, as a group we need
to focus on the mechanisms that these
Your sentence ended abruptly. Where is the rest?
PEM/MIME does require some changes to existing implementations. Which
changes do you have a problem with? Note that the changes from RFC 1421
are detailed in a separate section of the draft specification. Please
be specific when indicating the changes you don't like.
As a start, on documenting the requirements:
Why does MIME-PEM need 5 identifiers and 3 name forms?
What problems (requirements) are these mechanisms attempting to solve?
See previous message to Jueneman. I've enclosed it below just in case
you overlooked it.
Jim
--- Begin Message ---
However, in light of the excellent work done by Warwick and his
compatriots, and echoing John Linn's suggestion, instead of
continuing to roiund and round on this, maybe we could first ask
Jim Galvin for a reprise as to why the current mechanism was
adopted by TIS in the first place, and what problems it was
supposed to solve that weren't addressed by the PEM RFC. I think
I know in general, but I would like to hear a detailed analysis
to refresh all of our memories.
Quoting from the introduction of the PEM Security Services and MIME
specification:
In order to make use of the PEM services, a user is required to have at
least one public/private key pair. Prior to this specification, the
public key was required to be embodied in a certificate, an object that
binds a public key with a distinguished name, a name form that
identified the owner of the public key. The embodiment was issued by a
certification authority, a role that was expected to be trustworthy
insofar as it verified the identity of the owner prior to issuing the
certificate. However, the deployment of certificates and the creation
of the hierarchy of certification authorities has been problematic.
Instead, this specification bases the PEM services on a public/private
key pair. Each key pair is required to belong to a user (where user is
not limited to being a human, e.g., it could be a process or a role)
which has a name. There are 3 name forms specified by this document.
For backward compatibility (and forward compatibility if the X.500
Directory becomes a ubiquitous service) one of the name forms is a
distinguished name. In addition, email addresses and arbitrary strings
are allowed.
Since a user may have more than one key pair, a name form is
insufficient for uniquely identifying a key pair. A unique key selector
must be assigned to each key pair. The combination of a name form and a
key selector uniquely identifies a key pair and each key pair is
uniquely identified by a name form and key selector combination.
Throughout this document, this combination is called an identifier.
There are 5 identifiers specified by this document.
Quoting from Section 2 of the PEM Security Services and MIME
specification:
Currently, [3] requires the use of certificates to create and receive
PEM messages. Within certificates, [4] requires the use of
distinguished names as specified by the X.500 Series of Recommendations.
However, the Internet community has a great deal more experience with
the use of electronic mail addresses as a name form and there is a
desire to be able to use arbitrary strings to identify the owners of
public keys. Hence, there is a need to support name forms which do not
conform to the expected usage of distinguished names.
When receiving PEM messages it is necessary to be able to uniquely
identify the key pair used to create the message. A certificate is one
mechanism that accomplishes this, since it is uniquely identified by the
combination of its issuer's distinguished name and its serial number.
In any case, an identifier is required that consists of both a name form
and key selector.
In addition, users may distribute their public keys via mechanisms
outside the scope of the PEM specification, for example, in a file via
FTP. Users receiving such keys will probably assign name forms to them
to be displayed when receiving messages created with them. As a result,
it is desirable to be able to explicitly specify the public key used
rather than an identifier of the public key.
Then I would suggest that we all look at the v3 version of the
X.509 certificate and see whether it solves the problem that Jim
was trying to address. I suspect and hope that it will.
If this is the case, I would hope that we could begin a healing
process that would eventually result in a harmonization of PEM
without MIME, PEM with MIME, AOCE, andsome of the various other
encryption/signature implementations (maybe even PGP?) that are
currently on the table, each with their various strengths and
faults.
While the new X.509 certificate may in fact solve the same problem, I
would be very much against delaying these documents or the technology
since both are forward compatible with this work when it is generally
accepted and available.
Keep in mind, the PEM/MIME proposal includes complete support for
certificates (as does the available implementation). A user can begin
now with email addresses (a concept understood and appreciated much more
readily by many more people than certificates) and easily migrate to
certificates when the need arise. Note, the available implementation
already includes the ability for a user to assign themselves a
public/private key pair and then to "insert" the public key in a
certificate later. Or, of course, a user could choose to start with a
certificate and migrate "back" to a public/private key pair.
Jim
--- End Message ---