-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE
kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh
HbGVud29vZA==,03
MIC-Info: RSA-MD5,RSA,sBcN63uLahKvO4B2QJHyevT5iYwh180o3YdCEsuBBqC
7DuftOWRQc5142uceOoknH2Bur/fEpmauDFCu2vOdv+lAOx31ET991WEoOYTrxox
ADld2tFGlhjokT1y8/xaj
Steve Kent set forth ten goals for the Internet Certification System
with rationale for these goals. These goals and rationale are well
stated, coherent, appealing, and consistent with views he's expressed
consistently for the last several years. These goals have been the
accepted thinking within the PEM design community, so they're fairly
familiar to most of us.
It's particuarly useful to have this expression of the goals so we can
dissect them cleanly. We now have the benefit of a few years of
experience, and we can evaluate the goals in the light of that
experience.
I believe the Internet Certification System fails a simple test: It's
not being used. The Internet is a fast-paced system. It is entirely
possible for new services to be introduced and gain tens or hundreds
of thousands of users within a few months. This has not happened with
PEM, and it's fair to ask why. Naturally there will be multiple
opinions. This note includes some of my opinions, keyed to Steve's
ten goals. My main thesis is the goals articulated by Steve K are too
ambitious. The Internet has demonstrated repeatedly that simple ideas
work best, that new services should be built on top of existing
structures, and that large edifices which look complete often fail to
attract any following. I
1. Support key management for confidentiality (encryption)
I'm not sure this point is stated clearly enough. On the one hand,
the choice might be whether to support or not encryption. On the
other hand, the choice might be whether to use the same key for both
encryption and signature.
I believe the keys for signature and encryption should be handled
separately. The fact that the RSA algorithm works for both purposes
is a distracting accident. As an optimization, it might be useful to
facilitate the use of the same key for both purposes, but it's a
mistake to design the system in a way the makes it impossible to
separate them.
2. Support key management for data orign authentication,
integrity, and non-repudiation (digital signature)
The non-repudiation aspect of this goal doesn't come for free, and I
believe the attempt to support this part of the goal has cost us
greatly.
Let's consider possible uses of sender authentication and integrity
without non-repudiation. This would mean that I could send a message
and sign it. You could check that it came from me and detect whether
it had been tampered with. I would be protected against someone
forging my name. This is a big step forward. The head of an
organization would be able to send out a message in his name, but no
one else would be able to do so. Individuals would be able to send
message or take actions that require their authority, and no one would
be able to substitute himself instead.
What more could we want? Well, the notion of non-repudiation is that
once I've signed a message and sent it out, I can't later retract it
by saying my key was compromised or that it was some other Steve
Crocker. In order to reach this level of assurance, the basic
mechanism of digital signatues has to be augmented with additional
mechanisms and with ties into the civil and legal structures of society.
The most important manifestation of this goal is that "distinguished
names" are used in the current design, but email addresses are used in
the mail system. In my view, the attempt to live across two disjoint
name spaces is the single biggest impediment to the success of PEM,
and it's been driven not by the basic goal of protecting the sender
against someone forging mail from him, but by the more ambitious goal
of establishing legally relevant identities for senders and of
attempting to establish a basis for legal recourse in case the sender
renegs on whatever he sends.
Non-repudiation and the related goal of establishing a legally
relevant identity are reasonable to pursue, but I believe they're both
unnecessary and costly now.
Moreover, it's not at all clear to me that even if the mechanisms in
the current design were widely deployed that they would be sufficient
for the kind of electronic commerce envisioned. All sorts of
ancillary structures will be required. My name and the fact that I
work for TIS carries a lot of weight, but it may not be quite enough
to provide the basis of large commitments without some other
information or assurances.
Very important simplifications are possible if we drop the goal of
non-repudiation. And I believe very little is lost, either now or in
the future.
3. Scale to accommodate hundreds of millions of end users, and
millions of organizations
The implication of this goal is that it's important to introduce a new
name space because the current name space, i.e. email addresses,
obviously doesn't scale.
This is either not really a problem or much bigger than the use of
distinguished names can solve.
The present Internet is using domain names and email addresses on a
regular basis. By any measure, it's a first class success. I believe
it's also been a major mistake not to have made use of the existing
name space. It would have been possible to deploy and use PEM very
broadly by this time if we had tied it to email addresses.
But it's argued that domain names and email addresses don't scale well
and that the Internet will have to go through a major change. Perhaps
so, but whatever change is required, it will be backward compatible
with the present system.
The attempt to introduce a new name space and thereby solve the naming
problem of the Internet is far too ambitious. In my view, all of our
experience on the Internet suggests it's far better to bite off
smaller goals and move forward quickly. If something fails because
it's too successful and becomes overloaded, there will be time and
energy to evolve. However, if something fails because it's too
cumbersome and is not used, then it simply fails.
I believe a PEM system which is rooted in email addresses instead of
distinguished names will handily serve the existing two (three?
five?) million Internet users. If it doesn't serve fifty or five
hundred million users, someone will fix the problem.
4. Provide descriptive naming or a wide range of entities as part
of the authentication facility.
The fundamental purpose of a public-key certificate is to
bind a name to a public key.
This is a statement I agree with.
The form of names expressed in certificates goes a long way toward
determining the ultimate utility of a certificate system.
Well, yes, but this doesn't necessarily lead to the notion of
distinguished names. If I want to send you mail, I want the name in
the certificate to match your email address. That would dramatically
increase its utility.
Most people, upon reflection, agree that names in certificates
should be globally unique and that the names should be capable of
identifying a wide range of entities.
Ok. Email names have this property.
Moreover, to suport the rapidly-growing Internet community, the
globally unique, flexible names in certificates should be capable of
being assigned in a distributed manner.
Ok. Email names have this property.
The rest of this section appears to be an argument in favor of X.509
distinguished names. Out of context, this is a plausible argument,
but the obervable fact is that we need a scheme that fits into our
existing enviornment, not one that attempts to establish a whole new
enviornment.
5. Accommodate anonymous, but authenticated, email exchange,
signed object posting, etc.
Some people have complained that PEM does not allow encrypted
messages that are not also authenticated. The availability of
free persona certificates addressed that concern <link to RFC 1422
and to RSADSI Persona PCA text>.
This is confusing. Essentially all schemes make it possible to have
signed anonymous mail so one can establish continuity in an exchange
of messages without necessarily revealing anything about one's
identity. Moving toward email names does not change that. If I want
to receive mail from you, I have to provide an email address for you
to send to. That may be an anonymous mailbox in a remailer host.
The issue of sending encrypted mail which is not authenticated is
somewhat distinct, although some people tie the two together as a
means of achieving anonymous mail. There are other reasons for
separating encryption and signatures, however. Simple parsimony of
mechanism is sufficient for me, but the export laws and the potential
of using a common key for encryption among two or more parties instead
of tieing encryption to digital signatures are two other reasons.
6. Accommodate different levels of user and organization
authentication, and related security procedures
This is an attempt to introduce a set of goals and constraints
that are not intimately tied to the main goals of privacy,
prevention of forgery and prevention of tampering. We already have a
variety of means for determining how much to trust someone; it's
inappropriate to burden the design of the PEM certificate structure
with this goal.
7. Operate across national boundaries
This brings a social problem into the PEM arena that is much larger
than just PEM. When the domain name system and email addresses change
to accommodate a richer character set, it will be time to worry about
the character set used in certificates.
8. Provide a certification structure that is easy for end users
to understand
Here I think we're in agreement, although the details may vary. A
hierarchy that's matched to the domain name system achieves this goal.
However, there is also clear desire to have a system that can be
brought into service privately without copmplete coordination with the
existing establishment.
9. Support distributed name assignment
DNS works here, as noted.
10. Minimize management overhead
The supporting text of this item is an argument against cross
certification. We're in agreement; manual cross certification only
works in the small. However, there are many forms of hierarchy that
can be automated. Some of these look like cross certification and
some look like a a web of trust. The IPRA based hierarchy is useful,
but it's not clear everyone will subscribe to it. What happens then?
Bottom line:
o Separate encryption keys from signature keys
o Use the DNS and email names for identification
o Drop the notion of non-repudiation and other attempts to tie into
the civil and legal structure.
o Move forward quickly and gain experience.
-----END PRIVACY-ENHANCED MESSAGE-----