[Top] [All Lists]

Re: sender-auth and ira

2001-10-25 09:10:58

here a bit:


- 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


The two I-Ds are:

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


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

<Prev in Thread] Current Thread [Next in Thread>