Peter:
I can imagine many applications where the originator performs
encryption, and no recipient even process the result. One example is
an archive, where recovery from the archive is a rare event.
I can also imagine many applications where there is a single
originator and a single recipient are involved. The use of CMS in
SIP in the simple cases is an example.
I can think of many applications, not just email, where there is a
single originator and many recipients. RFC 4108 (the protection of
firmware images) is one non-email example.
As you point out, there can also be an asymmetry in the resources
available to the originator and the recipient. This asymmetry can
occur in each of the scenarios listed above.
CMS needs to support all of these situations. The question is which
case the syntax is optimized to handle. All of them are
accommodated. I believe that we have always in the past arranged the
field placement to permit the recipient to handle the stream efficiently.
Russ
At 11:17 PM 5/6/2007, Peter Gutmann wrote:
Russ Housley <housley(_at_)vigilsec(_dot_)com> writes:
>When faced with streaming trade-offs in the past, we have usually considered
>the recipient as the one that needs to be able handle the stream
efficiently.
>This is because there are many situations where there is one originator and
>many recipients.
This is a very email-centric view. I know of a number of applications
involving secure transmission of content from sensing devices (medical imaging
for example, which generates huge uncompressed images) and security monitoring
where the sender has minimal resources and the receiver has all the storage
and processing power.
Peter.