What's a conformant recipient to do, however, if a message is generated for
it using a encryption key which not only doesn't match its encryption key
preference but whose referenced certificate doesn't permit key management
usage? I'm not sure how comprehensively an S/MIME recipient is expected to
process and validate *its own* certificates, when encountered as references
identifying the key(s) used to encrypt messages sent to it. In a spirit of
conditionally liberal acceptance despite erroneously non-conservative
generation, I'd propose that local policy and configuration should control
whether a recipient system is allowed to decrypt such a message, and whether
the associated user is to be warned or consulted for confirmation before
proceeding. Does anyone's interpretation disagree, and would this case be
worth noting in MSG and/or CERT?
I think this is a Bad Thing, for three reasons: Firstly, if a key is marked
as (for example) authentication only, then a number of profiles say that you
can't use it for other purposes (of course you're free to choose a profile
which says the field is advisory only, even if marked critical). Secondly,
confidentiality keys may be issued under a completely different policy to
authentication keys, so you could quite easily be violating the cert policy by
doing this. Finally, it looks like governments are going to (at least try to)
regulate confidentiality keys under very different terms from authentication
keys. By making every key a potential confidentiality key, you really mess up
the legal framework surrounding the keys.
Peter.