Developers of Sympa

[Aumont <address@concealed>]

Hi

Christian Mock wrote:

> the patch does the following:
> 
> - a new authentication method (for scenari) "smime_enc", which means that 
> the
> incoming mail is encrypted and signed with S/MIME
This this not compatible with Sympa scenario concept : encryption has nothing
to
do with authentication method. This is a property of the message but not a way
to authenticate the sender.  In addition, creating a new authentication method
implies to modify all existing scenario rules : current rules using
authentication
method smime will not be applyed if the message is crypted.

The correct way to do this is to test the message Content-Type in the related
scenario :

match([header->Content-Type],/x-pkcs7-mime/)      smime    -> XXX

Currently the [header->Content-Type] variable is available only in send.*
scenario
(no need to modify the existing sources).Do you need this feature for commands
as well ?
We will do it asap.
                            
> - smime_encrypt and some other stuff was broken ...

> - smtp::mailto had a problem with signed/encrypted mails, ...

That's true, thoses bugs comes with some modification we have made because in
some
cases Sympa did alter the S/Mime signature. We are looking for the best way to
fix it
(using your patchs proposal).

> - one austrian certification authority, a-sign.datakom.at, encodes the email
> in the subject's CN instead of a separate /email= attribute, so tools.pl and
> wwsympa.pl (for SSL client cert authentication) had to be changed

The solution used by a-sign.datakom.at seems really not conform with X509
standard.
It may be dangerous because some can use this feature with an existing
certificat
authority to by-pass certificat properties. 
Imagine thawte accept to deliver me a certificate for
C=fr; o=cru; address@concealed; address@concealed

I could use it to spoof  your authentication !

Could you give us somme mor details why this austrian certification authority
made DN ?

> - what I've also done, but not included in the patch-set, is to change the
> "mailto" URLs in the subscription auth messages so the auth command is sent 
> in
> the body instead of the subject line -- this is needed with S/MIME auth as 
> the
> subject is not signed and therefore commands in the subject are not accepted
> (I'm not sure if the "body=" attribute in mailto: URLs is really a standard;
> it works with netscape, which is enough for me ATM.
Is there a way to specify in the mailto:// url  that the message must be
signed ?
Do you need this modification in the standard distrib or could you just modify
your
locally defined templates | translation ?

> I also noticed that there are some traces in the code related to PGP -- is
> anybody actively working on providing the same functionality with PGP as 
> with
> S/MIME in sympa?
Some french users ask me about PGP, GPG etc. I did explain them how they
can do it and what to do to submit a contrib. I am not sure they will do it.
I think it is not difficult to do for someone that known about PGP. 
If someone write 4 subroutine pgp_encrypt pgp_sign, pgp_verify and
pgp_decrypt,
similar with smime_xxx equivalent subroutines I will help for the integration
into
Sympa.

Thanks for your help
Serge
-- 
-----------------------------------------------------------
Serge Aumont        Comité Réseaux des Universités
                     Campus Beaulieu 
                     35042 Rennes Cedex   +33 2 998 471 47