Russ and S/MIME WG,
I have a few minor comments on ira and sender-auth.
1. AuthenticatedData has built-in resistance to "surreptitious
forwarding" when used properly. Proper key management includes
static-static DH key agreement, 1-Pass ECMQV or previously distributed
symmetric keys. In such cases, the AuthenticatedData will have a
"rid" field identifying the recipient's public key or "keyIdentifier"
field identifying the recipient's previously distributed symmetric
key. This field is enough to ensure that only the recipient
identified can authenticate the message. If Bob forwards Alice's
AuthenticatedData to Carol, Carol will be notified that the
"Authentication Failed". This is a stronger notice than "Valid
signature, but you are not an intended recipient". So, I think it would
be redundant to include all the TO: and CC: names as
intended-recipient authenticated attributes. (But i-r signed
attributes are fine.)
2. In the case of BCC, can't "surreptitious forwarding" still be
prevented by sending an individual CMS entity to each BCC
recipients, distinct from the one common CMS entity sent to
all the TO and CC recipients, as would be done normally?
Say Carol is on a BCC list. Then she receives an individaul
copy of the message, with an individaul CMS object. The CMS
can be a SignedData and include Carol as an intended-recipient
signed attribute or an AuthenticatedData. Carol will be assured
that there is no surreptitious forwarding because she is an i-r or
it is a valid auth-data, won't she?
3. Surreptitious forwarding is quite different from non-repudiation.
If true repudiation is wanted, then SignedData should be avoided.
Even if Alice uses Bob's public key to encrypt the contents before
signing it, Alice can't deny her signature on the ciphertext and Bob
can reveal the plaintext. With many algorithms, it is possible to
verify that ciphertext is public-key encryption of the plaintext using
Bob's public key. Bob does not have to reveal his private key, just
the plaintext and perhaps a one-time salt-value. To completely avoid
non-repudiation, AuthenticatedData should be used instead.
4. Can the intended-recipients feature be abused? What if Alice
signs "I'll pay you $100." with intended recipients of both Bob and
Carol? Can Alice abuse this to create confusion and deny obligations?
6. Does the intended-recipients feature create too much extra
bandwidth by including the names of the intended recipients? If so,
can there be an option where the intended-recipients are omitted
from the CMS entity itself but automatically grabbed from the
TO and CC headers in order computed the signed attributes?
Thanks,
Dan