Nelson B. Bolyard wrote:
> Ben, this thread began with someone wanting to be able to view PKCS7
> encrypted messages with the browser, not the S/MIME email viewer.
> I think they were asking for the ability to view such pages via http.
Yes, that was I, and Yes, you right, I wish those pages to be delivered
to browser via http or https.
>
> There are many issues with that idea that were not addressed in that
> suggestion. I'm not sure the person who made the request had considered
> all the implications of the idea.
Well, nobody can tell he/she considered _ALL_ the implications. Even after
product is made and tested. But I spent quite some time figuring the best technological
way for my problem. And I have answers for questions you are giving here.
>
> For starters, the encryption keys for PKCS#7 messages only available to
> specific people whose certificates must be given at the time the encrypted
> message is created. Only those people will be able to decrypt the messages.
> So, some of the issues are:
>
> a) if you attempt to view a page containing a PKCS#7 encrypted message,
> and you're not one of the people for whom the message was encrypted
> (that is, you don't posess the private key corresponding to any of the
> public key certs used to prepare the message), then what do you see?
It's not a fundamental problem. In the correctly written website there should be
no such situations. But if such happens, then there are number of
choices (listed in order of my preferences):
1) Open a download window as in cases when we got http response with unknown
Content-Type (optionally with comment, stating that browser was unable to
decrypt result).
2) Mozilla/PSM builtin text stating what had happen;
3) Empty window, but lock-icon changed to something to indicate what happened
4) your option.
The only other UI changes it needs is:
1) change of lock-icon when such file is shown;
2) when user clicks on lock-icon he should see an extra text with information
how strong this file was encrypted and optionally who else could decrypt
the same file.
>
> b) how do you prepare such a page? Does composer get beefed up to include
> all the stuff necessary for selection of the recipient's certs?
For my purposes I don't need composer (but I don't know what other needs).
PROGRAM MINIMUM is to be able to create these pages by scripts on server side.
Real example. Person A is responsible for updating some information. He submits
that file to script. Script finds that people B,C,D and E should have access to
that file. It takes public keys for them, crypts using them and stores until this
info will be needed by these persons. You crack server or go around permitions
system, you get file but you don't get information. The only way to get it - write
your cert to the list of recipients on server, corrupt file, complain to
responsible person and hope he/she will re-submit file.
PROGRAM MAXIMUM is to do encryption on client side. This should be simmilar to
form signing documented at:
http://developer.iplanet.com/tech/security//formsign/formsign.html
To sign a form javascript's crypto.signText() function is used. For encryption
it would be natural to have crypto.encryptText(), where one of parameters would
be list of certs of entities who should be able to read that text.
What is a "list of certs" and where to get it from? In the signing example
a hidden field in the form is used to store signature of form submitted. We
could store "list of certs" here. In what form? It is difficult question 'cos
I find no
pkcs-N created to store just list of certs (I can be wrong here). But it seams that
pkcs#7 envelopedData type message with empty data has sufficient information
to create another pkcs#7 message with the same recipients and user supplied
contents. I sugest to store "example" pkcs#7 message "base-64-encoded" into
hidden field, and onSubmit pass it to crypto.encryptText() function.
Better alternatives more than wellcome.
I see following applications for this:
1) document is created using javascript, encrypted and submitted;
2) file, selected by user is taken from disk [security gurus where are you?],
encrypted and sumbitted.
Now about UI. PKCS#7 has two types for encrypted data with certs -
envelopedData {pkcs-7 3}
and signedAndEnvelopedData {pkcs-7 4}. In first case no signing is done. Therefore
user could not be held responsible for encrypted data. So maybe in this case UI is
optional and could wait s/mime integration into mail client. Of course, two
separate functions crypto.encryptText() and crypto.signAndEncryptText() will
be needed.
> Ben Bucksch wrote:
>
>> Nelson B. Bolyard wrote:
>>
>>
>>> Remember that for encrypted messages, you need the cert of each person who
>>> is an intended recipient.
>>
>> But the collection happens without UI (OK, there might be a pref). If
>> there is some kind of import allowed, that's PSM's job. Same for
>> management (deletion, display) of them.
>
>
> I don't understand that last paragraph above at all. Not at all.
> Collection? Import? of what?
[Sorry I moved part of message. In this place answer could be more clear]
What Ben tries to say is [free interpretation].
"Look, he have a form. He have a list of recipient's
certs in the hidden field. He wants to crypt some other field and then
submit form. For this he calls crypto.encryptText(). This function is
part of PSM. PSM gets all the needed info from call's parameters. So it
can do all the magic without prompting user for anything. Of course
there could be an option that forces PSM to open a window where user will
be able to add (import a cert from list of certs user knows)/remove some
cert to be used in encryption. But all manipulation with cert list is
duty of PSM."
Does this make sense?
>
> These are (some of) the UI issues of which Bob Relyea wrote. I don't
> thing the original request considered any of those issues.
Ok, I found an answer to (a) today. But for (b) I spent over a week
trying to get it done with communicator 4.7. Unfortunately failed due to lack
of functionality in it. But I
have clear understanding how the working system should function.
>
> Many of these issues are easily resolved in the context of email.
> At composition time, the recipient's certs are selected via their email
> addresses. And since the pages are sent to the recipients, non-recipients
> do not, in general, need to deal with pages they cannot decrypt.
>
> So, the point of my initial one-line reply was that the mechanism to
> view encrypted PKCS#7 "pages" is (er, should be) S/MIME, not the browser.
Browser and mail client have their own uses. Have you ever had to
write script which will _automagically_ process booking [to some event]
information filled in mail client and sent via e-mail? With 100%
reliability? I would not take
such job no matter how much I would be paid. But this job is not so
difficult when you use browser and forms. On the other hand, have you
ever find a web-mail system which is more convienient than mail client?
I did not. So let's use mail client when we need to write free-form
letters but let's use browser when we need to use/create rigid business
application.
>
> If someone comes forth with a complete, well thought out, proposal for
> viewing encrypted PKCS#7 web pages, including how such pages would be
> created, and what happens when the page cannot be decrypted, not solving
> the important issues with hand waving (e.g. "PSM should just do it"),
> then it should be considered.
I tried to do so. I'm not sure could this result be considered
"complete". But If it is not, then I would like to hear what parts
need further explanaition and I'll try my best.
>
> --
> Nelson Bolyard http://nelson.bolyard.com/
> Speaking only for myself.
Rgds,
Aidas
