On September 14, 2000 at 07:31, Aumont wrote:
Digital signature and encryption.
For digital signature : When digital signature is verified, it's
not so simple with Mhnarc to include some html (a bolt icon) :
how to give a diference betwin the mhonarc look of a signed message and
the look of a mutipart message forged in order to look like a
signed message mhonarc image ? As you can see in this message,
a signed message contain a application/x-pkcs7-signature attachement.
My mhonarc extract it in a file sufixed ".bin" so
nothing can be done with it when the browser get this file.
It can be if you create a application/x-pkcs7-signature filter.
The filter can return a more appropriate link.
Encryption : Sympa store encrypted message in a encrypted form.
The list archive will contain some uncrypted message and some crypted
ones. Crypted message Content-type is application/x-pkcs7-mime
they are also stored by mhonarc on ".bin" files.
How to change this ? How to force link to x-pkcs7-mime message to
be different from link to others messages ? The URL of this kind
The indexes can still link to a regular HTML page (which shows the
basic message headers) but the message body portion would contain
appropriate (https) links the the encrypted data. I.e. The encrypted
data will be like attachments, but the links to the attachments must be
special to support the encrypted aspect of the data.
of messages must be https in order to be able to perform strong client
authentication based on client X509 certificat. My idea is to replace
encrypted message page by a page with some information about encryption and a
httpS link to a real image of the message decrypted.
If you create a application/x-pkcs7-mime filter, you can have it
return a https link to the data (saved wherever you want).
Do you have the RFC numbers for S/MIME? An issue I am unsure about
that could complicate x-pkcs7 filters is if there are relationships
between the different parts of the multipart/signed message. I.e.
To properly process one part, a filter must access another part?
If so, a filter approach like the HTML filters uses for MHTML messages
would need to be done. If no relationship is required for filtering,
then stand-alone mime filters can be created for the data.
What needs to be determined is if modifications to the base MIME
parsing code needs to be done to support S/MIME or if it is sufficient
as-is.
If you can provide a (technical) scenario of what you desire to have
done with S/MIME messages, I can help better on what is additions to
mhonarc are needed to make it happen. In the scenario, I'm looking for
specifics like how the pkcs7 should stored (and if any filtering is
needed during storage or it can be stored as-is) and what HTML should
show on the message page to allow the reader to view the data.
Something like the following will help: Given raw message X, here is
what the converted message (the HTML) should look like (by having
actual sample HTML).
--ewh
