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.
>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.
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.
... 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.
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.
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.
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.
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.
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 problmes that were slowing down the adoption of PEM, and
that also would ahve 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.
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.
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.
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?
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.
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. 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, but otherwise all technical changes were a direct
result of embracing the MIME technology or adding features our
experience suggested were useful.
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.)
If you got this far, thanks for your patience.
Jim