Carl,
I have not given the question much thought in the PEM
environment. Generally I would expect the performance difference to
be rather minor since the user employs his secret key only once per
message, to sign a tranmitted message or to decrypt his token in an
incoming, encrypted message. So I'm not sure its worth the complexity
to make special provisions for this case.
However, it certainly is syntactically possible to have
multiple certificates with the same DN but different keys. If a user
belonged to an organization that was certified by multiple PCAs, then
there could be multiple certification paths, leading to the different
PCAs, as noted in 1422. The user might be represented by different
certificates issued (transitively) under these different PCAs and that
would all be unambiguous from a certificate validation standpoint. I
guess one could imagine a situation where a primary difference between
the two PCAs was the key length requirements for users (reflecting a
more general difference in security stringency). Offhand, I think you
could accommodate this requirement in PEM without any modification, if
I understand correctly what you are trying to do.
My main concern is that we not confuse matters between RIPEM
and PEM. If PEM needed to chage to accommodate the facility you
describe (or any other facility) there would first have to be
concensus within the PEM WG that it was a real requirement. Then, we
would worry about how to achieve it and, coincidentally, one could
discuss whether PEM and RIPEM might require different approaches to
deal with a requirement. RIPEM does not have an IETF WG per se, or
standards track RFCs documenting the protocol, so RIPEM developers are
free to pursue changes in a less structured fashion.
Steve