Bob,
Following is a single reply to excerpts of several of your messages, all
under the subject key selectors. It's very unlike me to post such long
messages but I hope that folks will bear with me.
Jim,
I truely appreciate the effort involved in collating the comments extracted
from a
number of my messages and replying to them. You seem to have gathered the most
important points. You certainly don't need to apologize to _me_ for the length,
although there is some risk that someone might think I had written it and forged
your name. :-)
It is not my intent to keep going round and round on these issues if everyone's
mind is already made up. But because I really am trying to find a reasonable
compromise so that we can move forward with a concensus, let me play back your
comments and amplify my thoughts one more time. Maybe I'll convince myself that
you
are right, or maybe I'll persuade you to see things my way. At any rate it seems
worth one more try before we take out the old duelling pistols and meet at
sunrise
(figuratively speaking, of course -- the Boston area has seen enough shooting
recently, not to mention Washington. But I promise not to crash an airplane into
your front yard.)
>1. Suggestion to require key selector to be the public key
Jim, I think I was one of the first to raise a question about
what the intent was behind the key selector field. If you are
going to summarize positions, you ought to at least include all
of those who have provided comments.
What I was doing in the summary was to state known positions of known
persons. It is not clear to me what your position is. You've done an
excellent job of digging in to the issues but I have not assessed your
position.
Maybe I was too subtle. I am opposed to the alternative structure(s) you have
suggested, in particular the use of "bare" keys, and would hope to convince you
and
the larger community that we don't need these complications. I know we have gone
over this in the past, but let me try one more time.
At this point in time, I would seriously dispute the
"requirement" to hide public keys to prevent traffic analysis.
Likewise, I believe that hiding the public keys to prevent or
forestall cryptanalysis is very likely to produce a false sense
of security.
I hope at this point you've caught up on my other messages and now
realize that the PEM/MIME specification does not represent either of the
assertions you make. The purpose of the key selector is to distinguish
among the multiple keys of an owner, as identified by the owner's name.
At the time I made the comment, Jeff had requested an explanation for these
capabilities and some other comments had come in sideways. I was responding
more to
those comments than to you, and trying to guess what your purpose was.
... we have a perfectly good way of identifying the key -- by
identifying the certificate that contains it, i.e., by
specifying the issuer and serial number.
This assumes that all persons are using certificates as defined by
X.509. The PEM/MIME specifications completely supports this mode of
operation. However, it also allows for the existence of bare public
keys (viz the PGP model). In this model I assign myself a name (hey,
I've already got one and it's called an email address) and then I assign
a key selector to each of the keys I own. The name and key selector
server precisely the same function as the issuer name/serial number from
a certificate: they identify the key pair that is being used.
In other words, all we've done is not require the existence of
certificates, which our assessment of the global internet is a feature.
This is obviously our most significant area of disagreement. So that there
cannot
possibly be any misunderstanding, I would very much like to kill the notion of
distributing bare keys, scorch the ground from which the notion sprang, and then
pour salt on top of it to make sure it doesn't spring back up again. I believe
that
if PEM/MIME starts down that track it will be very difficult to ever get back to
the point of having a more structured, less anarchistic approach.
I don't dispute the fact that PEM has failed to take off, especially during the
key
period when you were coming to some of your design conclusions.
I will also confess that as a result of some of my long-winded discussion of the
requirements for business and electronic commerce, I may be _personally_
responsible for some of the misunderstanding and/or misperception that I think
has
come to exist in the minds of some of the users and perhaps some of the
implementors.
However, having had the problems clearly pointed out to me (by people such as
yourself), I have significantly moderated my position and want to be much more
inclusive of multiple approaches to the problem of bootstrapping such a large
system into existance. I would particularly like to give credit to Rhys
Weatherley
for numerous discussions along these lines.
I certainly wish that I had come to this realization earlier. I also wish that I
had had a better understanding of how X.500 was actually being deployed and what
directory service providers had in mind, rather than being quite so influenced
by
the X.500 standard and X.521 in particular.
I may part company with Steve Kent on some of these issues, and perhaps with
Peter
Williams as well, although we haven't had a follow-up disucssion on these points
recently. Nonetheless, I feel that our/my too-rigid insistance on a geopolitical
naming scheme within the Distinguished Name field of an X.509 certificate was
misguided. In addition the shortcomings of the X.509 certificate in not easily
allowing for extensions beyond the DN were also a very limiting factor.
Having said my mea culpas and Hail Mary's, however, I don't want you to say
"See,
that's what I've been saying all along." Unfortunately, from my perception at
least, just about the time I/we started adopting a more flexible approach to
certificates, you had made up your mind and had stopped listening. I'm now
trying
to recognize the problems you pointed out and bring us back together again,
without
upsetting the entire apple cart.
If I don't already have the certificate in hand from the
originator and only have the key digest, I haven't any idea
where to look until a worldwide directory of keys indexed by
such digests comes into existance.
I couldn't agree more. This is an excellent reason for not using just a
digest of a public key.
Let's table this. I'm hoping that we won't have to do this at all.
I guess that my overriding concern is that the hidden agenda
behind the use of a key selector as opposed to the certificate
issuer name and serial number is the desire to abandon the use
of certificates entirely and simply embrace the PGP direct trust
model directly.
I should say we've dispensed with this overriding concern. There's
obviously no hidden agenda and the purpose of a key selector (serial
number) has been precisely stated both here and in the specification.
I should not have talked about a hidden agenda, as though there was some sort
of a
conspiracy. And I may have oversimplified by merely talking about the key
selector,
instead of the name form, key selector, ID, etc. But my single greatest concern
is
still the fact that you are introducing the use of keys in a direct fashion, as
opposed to being incorporated in some kind of a certificate, even a self-signed
certificate.
What I really don't understand is how the use of an e-mail
address as a key selector is helpful at all, since I may have
many different keys/certificates that I use for dfferent roles
at the same e-mail address.
The email address is a name form, not a key selector. In combination
with a key selector it is an identifier. How might it be used? Well,
imagine if my public key was stored in a secure DNS server. The email
address provides me with all the information I need to track down the
user's public keys, just like a distinguished name. In fact, I would
assert it provides even more information than an issuer name and serial
number combination, since it points me right at the user information.
This is another major difference, or at least a fundamentally different point of
view. You keep talking as though a distinguished name was _necessarily_
different
from an e-mail address, and I keep saying that an e-mail address might very
well be
a perfectly satisfactory DN, even in an X.500 directory, but especially in an
X.509
certificate. It just depends of what you want to use the certificate for. (I do
admit, however, that this is a significant change from the position I would have
taken two years ago, when I was concerned about sending the sheriff out into
cyberspace to serve a warrant. Sometimes old dogs _can_ learn new tricks.)
Likewise, I don't understand the intent behind specifying some
completely arbitrary private name string as a key selector.
It is not a key selector, it is a name form. In combination with a key
selector it provides an identifier. It useful for closed communities
that have established via a mechanism outside the scope of these
specifications an interpretation of the arbitrary string.
Again, sorry for the misuse of the term. My concern is that the communities
won't
stay closed, and that we will end up with N-squared different forms of names to
be
supported.
If we had simply replaced RFC 1421 with an enhancment to add
security to MIME body parts, I think that the result would have
been met with acclaim. Alternately, we could have fixed some of
the problems that were slowing down the adoption of PEM, and
that also would have been well received.
It was never a design goal to replace RFC 1421. Although that may very
well be the result of progressing both PEM/MIME and RFC 1421, the result
could equally validly be that PEM/MIME loses and RFC 1421 wins. I've
got my crystal ball but you'll have to pay to get my opinion.
Ideally, a non-MIME aware PEM UA would see a stream that would default to the
RFC
1421 format. If that cannot be the case and we have to make a choice between the
two different kinds of functionalities, I would give serious consideration to
adopting the more flexible one (MIME), although it may have the effect of
slowing
down the introduction of the service somewhat.
It was our intention to do exactly as you state in your last sentence.
Rhys and I (and others) had this discussion more than a year
ago, and essentially worked out a roadmap to overcoming the
perceived problems in getting a CA infrastructure in place:
Guess what? We tried your roadmap and it didn't help enough. To wit:
1. Add explicit support in the RFC for self-signed certificates
in order to jump-start the process and address those users who
were more interested in issues of trust and trustworthiness, as
opposed to a formal hierarchical identification policy.
Well, the RFC didn't address this issue but our software always
supported it. In fact, we started the notion of self-signed
certificates by observing that implementations were simplified if the
root certificate was self-signed.
Yes, I appreciate that fact. I'm not sure who first suggested it, but I had
implemented something very similar almost 5 years earlier as a way of dealing
the
the equivalent of direct trust at multiple levels. And Steve Kent agreed that
the
use of wild cards to select in or select out various users, CAs, or PCAs was
reasonable and proper. However, I would observe that in the absence of an
explicit
lead from the RFCs, the TIS-PEM documentation in this area was rather opaque,
and
the user community may not have picked up on it sufficiently.
Those folks who tried the software appreciated the ability to have
self-signed certificates. However, the "certificate" carried so much
"baggage" we just couldn't get enough folks interested in PEM or our
software.
As you say, there was, and apparently still is, a lot of baggage that is
associated with a certificate, whether rightly or wrongly. I'm trying to reverse
that, as I don't think that it is justified. V3 of X.509 should make that much
clearer, as well.
2. Support a simple e-mail based certificate-issuing responder
service that would have used the fact of e-mail connectivity as
a basis for a PCA policy model for identification.
In fact, at one time RSADSI setup their Persona PCA exactly this way.
The fee structure was "free certificate" but $25 to get it revoked. How
many people do you know with a certificate?
I'm not quite sure what that proves, other than the fact that Persona
certificates
were perceived to be the equivalent of a clown suit, to quote John Gilmore. I'm
not
sure whether you should conclude from that there is very little demand for
anonymous communication, or that whatever demand there might be was just as well
satisfied by pgp (which was at that time generally free/stolen). In any case,
I'm
probably as knowledgable as anyone else about what RSA was doing at the time,
and
this didn't exactly make a huge blip on my radar screen.
I haven't asked George Parsons recently, but my understanding was that the free
certificate included within AOCE was attracting a fair amount of takers, even
though it wasn't widely advertised.
3. As part of this compromise between the medium-high
integrity/well-structured systems that are required by most
large corporations (witness Paul Lambert's excellent comments
recently) and the low integrity, low cost, anarchists VolksMail
PGP approach, we would adopt the use of the rfc822 e-mail name
as a distinguished name, as an alternative or in addition to the
organizational person or residential person DN model.
TIS tried this also. We created an OID for an email address and
enhanced our software to support it. However, we met with a *LOT* of
resistance from vocal members of the X.500 arena. You see, you run into
interesting problems like getting all X.500 applications to know about
your OID. They need to know the syntax of it in order to know how to
encode/decode and to compare it. These issues effect an implementations
ability to verify a signature, since the representation of a email
address in a certificate may be suitable for display (i.e., capitalize
letters in the host name) but is wholly unsuitable for signature
creation and verification (i.e., you must down case the host name).
With the syntax you don't know these things.
That's interesting, but I think you have run several different problems into a
single thread. Let me try to separate them.
1. I'm glad to hear that there ARE vocal members of the X.500 community. I
keeping
hoping that I'll meet some some day. :-) However, I think you are mixing apples
and
oranges here. The issue should not be whether an X.500 DSA or DUA understands
the
OID and syntax, since we are not requiring that X.500 be available to support
the
system. The only issue is whether your _own_ certificate generator can include
such
an attribute and generate a certificate in the first place, and whether your own
certificate issuer can sign such a certificate. We certainly convinced ourselves
that TIPEM should be used to generate such a certificate, and the RSA
Certificate
Issuing System could be used to sign it, without too much work. In any case,
OIDs
for RFC822 names were available from the Paradise project and the NADF, so this
wasn't necessarily a new work item.
2. RFC822 is supposed to be insensitive to case, although there may be some
implementations that are still sensitive. But so what? INcLUde wHATevER case the
user types in in the certificate. You are not asking the recipient to retype
anything, only to cryptographically validate the signature applied to the
certificate. Who cares whether the case if "right" or not? If you dump it into
a To
address and it doesn't work, that's the user's problem, it seems to me. Either I
don't understand, or this is a red herring.
Unfortunately, instead of adopting that rather simple solution
and preserving all of the work that had been done to date, some
of the folks at TIS decided to combine all of the benefits of
southern efficiency and northern charm (can your beer do this?)
into one indigestible system with flaws that are now perceived
as rather serious, at least to a significant portion of the user
community.
As you can see, we tried all your suggestions.
I don't mean to suggest that you may not have made a good faith effort along
those
lines, at least within your development group.. Unfortunately, at least as far
as I
can recall, those efforts were practically invisible. I don't recall any
significant discussion of them on pem, and I don't recall anyone else mentioning
them. It doesn't seem fair to cover up your light with an opaque basket and then
complain that the light isn't bright enough to see by.
In addition, of course, TIS-PEM was not and is not the only game in town. I
certainly had discussions with Sead Muftic along these lines (I remember
because I
was upset that he was doing exactly what I am now suggesting, and for the above
reasons). But if some of these other implementations didn't see the light quite
as
clearly, then perhaps we didn't give it a fair enough trial.
Also we are not aware of
any flaws in our design. We very carefully and consciously adopted the
principles of the 1421 PEM. We did allow the complete separation of
signature and encryption services, i.e., we didn't require you to sign
in order to encrypt,
I don't have any huge problem with that, although I wonder about the utility of
being able to fill up the airways with encrypted messages that no one is
williing
to take ther responsibility for.
but otherwise all technical changes were a direct
result of embracing the MIME technology
I won't argue those particularly, either. I haven't seen anything I am terrible
upset by.
or adding features our
experience suggested were useful.
Ah. there's the rub. You are asking, nay almost demanding, that the WG adopt
your
solution to a problem based on your particular experience, while seemingly
rejecting experience from other quarters that would contraindicate some of those
conclusions, especially in light of the harm that some of us feel might result.
As Steve Crocker said, you aren't through when you have thrown everything into
the
pot you can think of, but rather when you have taken out everything that isn't
necessary.
Since I and several others have pointed out ways of accomplishing precisely the
same goals that you have set for yourself without requiring these new, and in my
mind potentially dangerous extensions, I conclude that we aren't through yet.
The security policies that were embedded in classic PEM were
carefully thought out, argued, and debated at length by a number
of people with extensive experience in this area. The new specs
(and here I am talking almost exclusively about the
key/certificate management aspects) abandoned those principles
and adopted new ones.
No, Bob, what we did was not require the adoption of any particular one.
We did not abandon anything. What we did was allow for those users who
wanted certificates and all the "baggage" that goes with it to proceed.
(To date, our experience suggests this user community is quite small.)
We then allowed those users who want to have "bare" public keys to also
make use of the PEM technology. (Compared to the certificate PEM
community, this community of people is huge, viz PGP.)
I could have understood your position much better if you had come right out and
said that you wanted PEM/MIME to be interoperable with PGP. but counting the
number
of PGP users with whom you are not compatible doesn't seem like a sufficient
justification.
I'll grant the possibility that I am wrong, and that the PGP community has
become
so polarized with respect to their existing usage that they would absolutely
refuse
to adopt anything new (and assuming that the PGP communityis even relevant). But
you'll then have to grant me the possibility that the PEM community as a whole
hasn't given adequate consideration or encouragement to such an expanded
approach
as to consititue a valid experiment, your attempts of a year or so ago not
withstanding.
If you got this far, thanks for your patience.
Jim
Thank you for YOUR patience. And I would like to underscore the fact that
although
we may disagree, and perhaps ultimately will have to agree to disagree, I have
nothing against you personally or against any other of the TIS folks or PEM/MIME
contributors for your position, which I'm confident was taken in good faith.
And as
I said, I'll even take a fair amount of the heat for perhaps having CAUSED some
of
the disenchantment that some may have felt with conventional certificates,
although
I think that a good part of that was caused by X.400 OR names, and not
necessarily
by me.
I hope that this reprise of my position has been helpful. If you are still
unclear
as to where I stand, just ask me. My fingers havn't fallen off quite yet,
although
carpel tunnel syndrome is becoming a distinct possibility. :-)
And BTW, I don't think that anything I have said would impact on moving forward
on
the multipart stuff. Separating the MIME stuff from the certificate management
issues is a GOOD THING. Even separating the purely PEM stuff from the
certificate
management stuff has merit. If absolutely all other form of compromise were to
escape us, I would at least like to see a statement in the proposed standard to
the
effect that the usage of bare keys is strongly deprecated, and provided solely
for
the purpose of accommodating users who may not be as familiar with certificates
or
need to jump start the infrastructure.
Regards,
Bob