The problem is simple.
No, it is not simple. If it were we wouldn't be having this
conversation.
Now explain to me what my application is supposed to do
when someone encrypts a message with my public key with a
key selector I've never seen before. This is just one
example of an out-of sync comdition.
It does not pass the test. The owner chooses the key selector, not the
originator. Thus, it is not possible for you to get a message encrypted
with your public key with a key selector you've never seen.
When I send you an encrypted message, I have to have your public key, a
priori. Where and how I got this public key will dictate the identifier
used. If I got it from you, presumably you told me what your preferred
identifier (name form/key selector) is. If I got it from some other
source, presumably they told me what your preferred identifier is. If
none of that is true, then I used the PK identifier and there is no
issue.
If your public key comes to me in a certificate, I can not use the
DN identifier since I don't know the key selector. However, I can use
either the IS identifier or the PK identifier.
For n different identifiers there are about n squared of
these conditions to deal with. None of this is addressed
in the current spec and to do so may take more pages then
the existing text !!
Sorry, I still don't see any conditions that need to be addressed.
Jim