Mr. Muftic,
Maybe I don't understand, but how are you proposing to provide
confidentiality and privacy in your scheme by using a single SYMM-KEY?
Also in any scheme where the originator of the message must use
alternative keys to encrypt a message:
How should the originator know that the boss is allowing the secretary
to read his/her mail?
If a separate key is used for each mail, who stores these keys for
later reference? Who generates these random keys if the Recipient of
a mail is on vacation?
Let's consider me as the Boss (B), an originator of a message to me
(O), and my secretary (S). An independent second originator (O')
wants to send B another confidential message.
Scenario:
B is away on vacation and O wants to send B a private letter. So does
O'.
1) Are you saying that both O and O' will use the *same* SYMM-KEY to
send B a confidential letter? If so, what protects O from O' reading
mail which O sent to B?
2) How does O or any other originator know that B has delegated his or
her secretary S to read B's mail? No one sending me a confidential
letter will assume that I have delegated it away.
3) And how does the originator receive these keys? Since B is on
vacation, it seems that an on-line RESPONDER may do the job. HOWEVER,
the responder must generate a random symmetric key per request. How
does the secretary then find out what that key was? How does B find
it.
It seems to me that the Boss-Secretary relationship is an example of
an application that may benefit from using PEM but should not require
PEM to change inorder to support it.
_______________________________________________________________________
Alireza Bahreman E-Mail:
bahreman(_at_)bellcore(_dot_)com
Bellcore, Room RRC-1K221 Phone : +1 908 699 7398
444 Hoes Lane, Piscataway, NJ 08854 Fax : +1 908 336 2943
You write:
...
4. Alternative solution:
Seems to me that current PEM RFCs have already the
possibility to solve Jueneman's request in quite an elegant
way: The idea is to use SYMMETRIC KEY MANAGEMENT to
distribute keys for ENCRYPTED letters (those that might be
also read by a secretary) and to use CERTIFICATES to send
EXTREMELY private letters (to be read only by the boss). In
this way:
a. we separate enc/dec from signing,
b. we have two types of private letters ("group" and
"personal"), and
c. we don't re-engineer PEM.
5. Improvements
The proposed solution may be even further improved: the boss
defines the (symmetric) master key to be used for receiving
ENCRYPTED letters, but using the THRESHOLD scheme. If the
scheme is 1-out-of-2 (the boss and secretary), then the
secretary may read ALL letters, without boss'es further
approval. However, the boss may define k-out-of-n scheme
and in that case he may give himself the right to approve
reading of encrypted letters.
6. PEM Key Management
The boss defines the (symmetric) master key (SYMM-KEY) for
the enc/dec function, keeps it locally in his DB. The type
of the threshold scheme is the local matter. For
distribution to potential senders, the boss encrypts the
SYMM-KEY with senders' certificates, and then:
(a) forwards immediately to each potential sender
(new PEM letter type: SYMM-KEY DISTRIBUTION) or
(b) stores it in a local DB for replies to the (new type
of the) PEM letter: SYMM-KEY REQUEST, which is
replied with the same type of the PEM letter as with
immediate distribution.
----------------------------------------------------------------
Sead Muftic Tel: +46-8-16 16 92
COST Computer Security Technologies Fax: +46-8-739-1839
Stockholm, Sweden E-mail:
sead(_at_)dsv(_dot_)su(_dot_)se
!