Subject: key preferences, usages, and S/MIME recipients

From: "Linn, John" <[email-masked]>
Date: Mon, 21 Dec 1998 13:51:08 -0500

In reading sections 2.5.3 and 2.5.3.1 of msg-05, I'm wondering about the
possibilities where an S/MIME recipient may receive a message encrypted with
a key which doesn't match its encryption key preference, and about what that
recipient can and should do under such circumstances.  

In the last sentence of 2.5.3, I'm presuming that the statement, "... the
receiving agent may use any certificate in replying to the sender that is
valid" implies that the certificate's key usage extension (if present)
should be checked to verify that it allows key management operations.  It's
clear that a recipient must be able to accommodate suitable certificates
diverging from its intended preference. 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?

Regards, ...

--jl

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 27 Dec 1998 15:54:06 (NZDT)

>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.