here a bit:
summary:
- having a such an attribute for CMS does not seem a useless idea.
- I am not sure about the profiles about how to use this attribute in an S/MIME
context.
details:
The two I-Ds are:
draft-ietf-smime-sender-auth-00.txt
"4.2 Symmetric-Key Semantics"
This is only applied to a mode between TWO participants, and not
to a mode of one sender and several recipients. If a shared key
is used among several then no recipients is sure who has actually
created the message. (If a symmetric key is used for each pair, then
multiple messages are necessary, see also the comment about bcc later).
Or, it isn't clear to me that:
" Users tacitly expect public-key file-encryption to offer the same security
semantics that a symmetric key offers. "
in a context of 1-to-n communication.
---
* If the recipient's name doesn't appear in the signed attribute
listing the intended recipients, then the recipient's software
must inform the recipient that there is a security problem:
the author apparently didn't intend the document for this
recipient's eyes.
I would agree to say : 'the signer did not explicitely indicate
that this is intended for the recipient's eyes (and the recipient
may have to deduce this information otherwise).
draft-ietf-smime-ira-00.txt
Section 3.0 sentence 2 and 3 should be moved to the end of the section
where one talks about usage in the context of S/MIME.
Or, a better separation of the definition of this attribut and its
usage in an S/MIME context should be made.
I am not sure whether I support not including BCCs. This should go
into a security consideration section. The problem is similar of
what happens in standard bcc: processing. It is up to the sending
system to create separate messages which may for example include
one bcc: header for each of the recipients.. similar for S/MIME
envelopes for BCCs, ...
Anyway, a possible and cost intensive solution is to have separate
copies with bccs, signed individually, etc. why should one exclude
this.