Subject: Re: sender-auth and ira

From: Peter Sylvester <[email-masked]>
Date: Thu, 25 Oct 2001 18:10:54 +0200 (MET DST)

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.

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 25 Oct 2001 18:32:30 -0400

Peter:

I will respond to your comment in the ira document.  I will let Don Davis 
respond to the other comments.

>usage in an S/MIME context should be made.

I am pleased to move it to the end of the section.

>one bcc: header for each of the recipients.. similar for S/MIME

The whole point of BCC recipients is to keep their identities from other 
recipients.  If you are going to list them, then they are readily 
exposed.  I do not think that we should introduce this leak.

The update to MSG should address BCC in the broader context.

>copies with bccs, signed individually, etc. why should one exclude

Yes, there is a cost.  Again, BCC should be further addressed in the update 
to MSG.

Russ