I believe the first step in their ever being noteworthy
consensus regarding MIME-PEM's promotion to the standard track
is that the technical discussion and argument of MIME-PEM
returns to where it belongs - in the open.
Speaking personally, it's not obvious to me when the process was not in
the open. While it is true that some discussions occurred within small
groups, this is consistent with IETF practice. The results of all
discussions were presented here, via revised draft documents.
They should demonstrate that there is a significant and active
implementor and user constituency which desires a move away from
822 PEM's design precepts.
As far as precepts go, I believe there are only three changes from those
specified in 1421, which I will state here. If you believe there are
others, please ask about them. Of course, please feel free to ask about
further clarification on the issues included here.
First, I would like to point out that none of the mechanisms proposed in
the drafts exclude any functionality provided in RFC 1421. In fact, it
was a design goal to continue to support the same functionality. All
we've done is allow additional functionality and features.
1. The separation of signature and encryption services.
Quoting from the latest draft document:
The use of a MIME-capable user agent makes complex nesting of enhanced
message body parts much easier. For example, the user can separately
sign and encrypt a message. This motivates a complete separation of the
confidentiality security service from the digital signature security
service. That is, different key pairs could be used for the different
services and could be protected separately.
This is useful for at least two reasons. First, some public key
algorithms do not support both digital signatures and encryption, for
example, the way that the RSA algorithm does; two key pairs would be
required in this case. Second, an employee's company could be given
access to the (private) decryption key but not the (private) signature
key, thereby granting the company the ability to decrypt messages
addressed to the employee in emergencies without also granting the
company the ability to sign messages as the employee.
2. Allowing alternate name forms from the original distinguished names.
Quoting from the latest draft document:
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.
3. Allowing alternative trust models.
The same two paragraphs above apply here. In the RFC 142X series,
the trust was tightly couple with the hierarchy, which had rules for
the choice of names. It is not our intention to suggest this model
is totally unusable, rather it is unsuitable for everyone. The
acceptance and use of PGP unquestionably motivates this.
Jim