Jeff,
In this message I'm replying to two of your messages, both under the
subject of key selectors.
Suppose you have one key certified by different issuers A and B
(or one key used for different roles, as in Bob's case).
It is the intent of RFC1422 to disallow this. In other words, you would
not be able to accomplish this with "classic" PEM. I base this on the
following words which appear in RFC 1422:
3.4.2.2 Ensuring the Uniqueness of Distinguished Names
...
As noted earlier, a CA may be certified under more than one PCA,
e.g., because the CA wants to issue certificates under two different
policies. If a CA is certified by multiple different PCAs, the CA
must employ a different public key pair for each PCA. In such
circumstances the certificate issued to the CA by each PCA will
contain a different subjectPublicKey and thus will represent a
different entry in this database. The same situation may arise if
multiple, equivalent residential CAs are certified by different PCAs.
In point of fact, use of the same key for different purposes is strongly
discouraged. In fact, not doing so is a serious security vulnerability,
notwithstanding the fact that it eliminates accountability.
The question is, what does it mean to be compliant with
MIME/PEM? Do you get to pick and choose like this, and if so,
what will it mean if a vendor touts MIME/PEM compatibility if
they only implement what they feel like? They won't
interoperate with someone else who has picked and chosen a
different part.
You don't get to pick and choose anything. As in typical with IETF
standards, unless otherwise explicitly stated you implement everything
in the specification. If you already have a PEM implementation, the
changes to your PEM implementation to be in compliance with PEM/MIME are
quite minimal. On the downside, you need a MIME implementation to pick
up the pieces. If you don't have one of those and don't have access to
one (there are several free versions on the Internet) then you may have
some development to do.
I think that the draft is responsible for stating what is needed
for compliance and what is not. Some people, and unfortunately
this includes the authors, think this is a "local issue" and
that the draft does not have to address compatibility.
Compatibility is diffent than compliance. It is unfair to hold these
documents to a higher standard than any other IETF standard with respect
to this issue.
As far as compatibility is concerned, we explicitly state in the
document exactly where we are different than 1421. What point do you
believe we have not covered?
You mention that all you have to do is "store one additional bit
of information in your X.500 directory". To someone who wants
to use an existing database to simply work with MIME-formatted
messages, it is not a small deal to rework the database just to
do this, if that is required to be MIME/PEM compliant.
There is no additional bit to store, per se. If you are storing issuer
name and serial number than you can store name form and key selector.
If you can lookup by issuer name and serial number than you can lookup
by name form and key selector.
If you have chosen to tightly-couple your implementation to knowledge of
the structure of the values you are looking up with, then it is possible
you may have some database work to do. That would be an unfortunate
result of the choice of database mechanism you made in the first place.
This is a big objection of mine to the current draft. I think
the ambiguity on this point - of what information the database
is required to carry for compliance - must be cleared up. It is
inexcusable to leave an implementor out in the cold in this
issue.
The issue of what goes in a database or not is completely, 100%, without
a doubt, let there be no mistake, outside the scope of this
specification. Period.
The data a user (whether an originator or recipient) must have access to
is completely within the scope of the specification. I believe this is
adequately addressed. However, I'd be very happy to include whatever
text you write that you believe should be included to clarify this
issue.
Jim