axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "José Ferreiro" <jose.ferre...@gmail.com>
Subject Re: *SPAM* Re: *SPAM* Re: *SPAM* Re: *SPAM* RE: *SPAM* RE: Problem verifying the signature with wss4j... Good News!!
Date Thu, 04 Sep 2008 20:39:37 GMT
Hola Tomás,

<parameter name="signatureKeyIdentifier" value="DirectReference"> is there
to avoid all those problems see http://ws.apache.org/wss4j/cert.html
I mean you do not need to store all the client certificates (public keys) in
the server keystore.

In my opinion the server side should have a certificate signed by a CA
(public and private key) and also the certificate from the CA(that will
become a trusted certificate in the CA after you insert a certificate signed
by the CA) (public key)

This means when your client sends a sign SOAP to the server side, then the
server side
will check the certificate (public key) sent within the SOAP client.
Has the client's certificate been issued by CA's certificate stored in the
server keystore?
If the client's certificate has been issued by the same CA's certificate as
for the server (signed in other worlds by the CA's private key) then the
SOAP message will be
further processed, otherwise an exception will be thrown as it seems to be
your case.

I do not remember exactly but for the interop examples shipped with axis 1.x
I think you may use the keystore interop2.jks for the client and the server.
May you try?

Un saludo

Jose







On Thu, Sep 4, 2008 at 5:24 PM, Tomás Tormo <ttormo@indenova.com> wrote:

>  Hola Jose
>
>     You mean that signing certificate I'm using for the webservice is not
> issued by a trusted CA for the server side, don't you?
>
> I don't think sample.jks will work cause I got it from an IBM tutorial,
> where they show how to make them with OpenSSL hehehe
>
> I'm waiting for an answer from the server administrator in order to know
> wich certificates are trusted by them. Then, I'll take the CA public
> certificate of the server and insert it in interop2.jks. What do you think?
>
> Muchas gracias.
>
> José Ferreiro escribió:
>
> HOLA Tomás,
>
>
> You may already inspect both keystores (your sample.jks and the
> interop2.jks). You will be able to see the trusted entries.
>
> Command is: keytool -list -v -keystore path2/interop2.jks
>
> I do not think that importing bob certificate will change the problem.
>
> The problem you have in my opinion is that you are using different
> certificates issued by different CA.
> Every keystore has trusted certificates that are introduced into it.
>
> In my opinion the thing you may do is to insert the sample.jks CA public
> certificate into interop2.jks keystore.
> You should try!
>
> UN SALUDO
> José
>
>
> On Thu, Sep 4, 2008 at 9:00 AM, Tomás Tormo <ttormo@indenova.com> wrote:
>
>>  I'm really thankful to all for your help. Then, if I understood it well,
>> the problem is that, due to I'm using a sample keystore, the certificate
>> used by the webservice in order to sign the message is not in the sample
>> keystore, then, that certificate is not trusted. I was thinking about making
>> a backup of the original java keystore, and import the bob certificate in
>> it. Then, maybe, issuer's certificate of the webservice certificate is
>> installed into the keystore and it would work... what do you think?¿
>>
>> José Ferreiro escribió:
>>
>> Hola Tomás,
>>
>> I agree with Martin,
>> You should set up your dev box.
>> You may even used the interop2.jks keystores (client and server with bob
>> and alice) without creating any self-signed certificate or trusted
>> certificates. You only need to adapt the crypto.properties and
>> client_deploy.wsdd
>>
>> On this way, you may try your client with the signature.
>>
>>
>> From
>> http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html
>> your axis error fault might be seen
>> and the comments in the code from wss4j developers around line 266 and 288
>> say the following:
>>
>>  "Now we can check the certificate used to sign the message. In the
>>  following implementation the certificate is only trusted if
>>  either it itself or the certificate of the issuer is installed in
>>  the keystore."
>>
>> This may lead us to the conclusion that the SOAP message you are
>> receiving (WSDoAllReceiver) is not signed with a certificate that is
>> installed in your "client" keystore.
>>
>> As your certificates are from interop2.jks
>>
>>
>> Also, this seems not to be correct:
>>
>> <parameter name="user" value="sample"/>
>>  sample should be bob or alice
>>
>>             */**
>> 266 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#266>
*            * Now we can check the certificate used to sign the message. In the*
>> 267 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#267>
*            * following implementation the certificate is only trusted if*268 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#268>
*            * either it itself or the certificate of the issuer is installed in*
>> 269 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#269>
*            * the keystore.*270 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#270>
*            **
>> 271 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#271>
*            * Note: the method verifyTrust(X509Certificate) allows custom*272 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#272>
*            * implementations with other validation algorithms for subclasses.*
>> 273 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#273>
*            */*274 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#274>
>> 275 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#275>
            *// Extract the signature action result from the action vector*276 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#276>
            WSSecurityEngineResult <http://ws.apache.org/wss4j/xref/org/apache/ws/security/WSSecurityEngineResult.html>
actionResult = WSSecurityUtil <http://ws.apache.org/wss4j/xref/org/apache/ws/security/util/WSSecurityUtil.html>
>> 277 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#277>
                    .fetchActionResult(wsResult, WSConstants.SIGN);278 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#278>
>> 279 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#279>
            *if* (actionResult != *null*) {280 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#280>
                X509Certificate returnCert = actionResult.getCertificate();
>> 281 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#281>
282 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#282>
                *if* (returnCert != *null*) {
>> 283 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#283>
                    *if* (!ver*if*yTrust(returnCert, reqData)) {284 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#284>
                        *throw* *new* AxisFault(
>> 285 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#285>
                                "WSDoAllReceiver: The certificate used for the signature is
not trusted");
>> 286 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#286>
                    }287 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#287>
                }
>> 288 <http://ws.apache.org/wss4j/xref/org/apache/ws/axis/security/WSDoAllReceiver.html#288>
            }
>>
>>
>>
>>
>> Un saludo
>>
>> José
>>
>>
>> On Wed, Sep 3, 2008 at 9:31 PM, Martin Gainty <mgainty@hotmail.com>wrote:
>>
>>> you can avoid all that and create the cert yourself for testing purposes
>>> on your dev box
>>> http://code.google.com/support/bin/answer.py?answer=71864&topic=11369
>>>
>>> Martin
>>> ______________________________________________
>>> Disclaimer and confidentiality note
>>> Everything in this e-mail and any attachments relates to the official
>>> business of Sender. This transmission is of a confidential nature and Sender
>>> does not endorse distribution to any party other than intended recipient.
>>> Sender does not necessarily endorse content contained within this
>>> transmission.
>>>
>>>
>>> ------------------------------
>>> Date: Wed, 3 Sep 2008 20:11:56 +0200
>>> From: ttormo@indenova.com
>>> To: axis-user@ws.apache.org
>>>  Subject: Re: *SPAM* Re: *SPAM* RE: *SPAM* RE: Problem verifying the
>>> signature with wss4j... Good News!!
>>>
>>> Because I had no time enough to make the entire development with the
>>> right certificate, I'm still waiting for it and this should be finnished on
>>> friday... That's why I wanted to have some code(altough I was not gonna
>>> work), and then had something prepared for the right certificate. Then, in
>>> this case and if everything is all right, it "should" work (at least
>>> partially) with the correct certificate... Could this be a client error? (It
>>> looks as sever error...as I told you, i'm new in axis...)
>>>
>>>
>>> This is the complete exception:
>>>
>>>
>>> AxisFault
>>>  faultCode: {http://schemas.xmlsoap.org/soap/envelope/
>>> }Server.generalException
>>>  faultSubcode:
>>>  faultString: WSDoAllReceiver: The certificate used for the signature is
>>> not trusted
>>>  faultActor:
>>>  faultNode:
>>>  faultDetail:
>>>         {http://xml.apache.org/axis/}hostname:cifweb02.asoatario.com
>>>
>>> WSDoAllReceiver: The certificate used for the signature is not trusted
>>>         at
>>> org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222)
>>>         at
>>> org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:129)
>>>         at
>>> org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087)
>>>         at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
>>> Source)
>>>         at
>>> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown
>>> Source)
>>>         at
>>> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
>>> Source)
>>>         at
>>> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
>>> Source)
>>>         at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
>>> Source)
>>>         at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
>>> Source)
>>>         at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>>>         at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
>>> Source)
>>>         at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
>>>         at
>>> org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
>>>         at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
>>>         at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)
>>>         at
>>> org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
>>>         at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
>>>         at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
>>>         at org.apache.axis.client.Call.invoke(Call.java:2767)
>>>         at org.apache.axis.client.Call.invoke(Call.java:2443)
>>>         at org.apache.axis.client.Call.invoke(Call.java:2366)
>>>         at org.apache.axis.client.Call.invoke(Call.java:1812)
>>>
>>>
>>> Thank you very much / Muchas gracias por tu ayuda
>>>
>>>
>>> José Ferreiro escribió:
>>>
>>> Correct Frank,
>>>
>>> Why don't you get the right certificate you need that is issued and
>>> signed by the correct third party?
>>>
>>> Un saludo.
>>> José
>>>
>>> On Wed, Sep 3, 2008 at 7:09 PM, Tomás Tormo <ttormo@indenova.com> wrote:
>>>
>>> Good news!!! After changing the keystore for "interop2.jks", and using
>>> "alice" as alias the exception changed :). Now it looks like this:
>>>
>>>     WSDoAllReceiver: The certificate used for the signature is not
>>> trusted
>>>
>>> I'm trying the webservice client against a public webservice, that's why
>>> I think this exception is pretty normal, cause this certificate is
>>> self-signed, and the public webservice maybe needs a trusted certificate. Am
>>> I right?
>>>
>>> Thank you very much
>>>
>>> Tomás Tormo escribió:
>>>
>>> Sorry, my mistake, the client_deploy.wsdd file I'm using is the following
>>> one:
>>>
>>> <deployment xmlns="http://xml.apache.org/axis/wsdd/"<http://xml.apache.org/axis/wsdd/>xmlns:java=
>>> "http://xml.apache.org/axis/wsdd/providers/java"<http://xml.apache.org/axis/wsdd/providers/java>
>>> >
>>>  <transport name="http"
>>> pivot="java:org.apache.axis.transport.http.HTTPSender"/>
>>>   <globalConfiguration >
>>>   <requestFlow>
>>>    <handler name="DoSecuritySender"
>>> type="java:org.apache.ws.axis.security.WSDoAllSender" >
>>>     <parameter name="passwordCallbackClass"
>>> value="pruebawebserviceregistraduria.PWCallback"/>
>>>     <parameter name="user" value="sample"/>
>>>     <parameter name="action" value="Signature"/>
>>>     <parameter name="signaturePropFile" value="crypto.properties" />
>>>     <parameter name="signatureKeyIdentifier" value="DirectReference" />
>>>    </handler>
>>>   </requestFlow>
>>>   <responseFlow>
>>>    <handler name="DoSecurityReceiver"
>>> type="java:org.apache.ws.axis.security.WSDoAllReceiver">
>>>     <parameter name="passwordCallbackClass"
>>> value="pruebawebserviceregistraduria.PWCallback"/>
>>>     <parameter name="action" value="Signature"/>
>>>     <parameter name="signaturePropFile" value="crypto.properties" />
>>>    </handler>
>>>   </responseFlow>
>>> </globalConfiguration >
>>> </deployment>
>>>
>>> Thank you
>>>
>>> Tomás Tormo escribió:
>>>
>>> Ok, sorry i didn't see the link...
>>>
>>>     Anyway i would like to ask you why you don't use "DirectReference" as
>>> "signatureKeyIdentifier" instead of  "X509KeyIdentifier".Is the server able
>>> to verify the sign just with that?
>>>
>>> The client_deploy.wsdd file I was using was the following one (now it's a
>>> mix of several xD):
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <deployment xmlns="http://xml.apache.org/axis/wsdd/"<http://xml.apache.org/axis/wsdd/>xmlns:java=
>>> "http://xml.apache.org/axis/wsdd/providers/java"<http://xml.apache.org/axis/wsdd/providers/java>
>>> >
>>>  <transport name="java"
>>> pivot="java:org.apache.axis.transport.java.JavaSender"/>
>>>  <transport name="http"
>>> pivot="java:org.apache.axis.transport.http.HTTPSender"/>
>>>  <transport name="local"
>>> pivot="java:org.apache.axis.transport.local.LocalSender"/>
>>>   <globalConfiguration >
>>>    <parameter name="disablePrettyXML" value="true"/>
>>>    <parameter name="enableNamespacePrefixOptimization" value="true"/>
>>>   <requestFlow>
>>>    <handler type="java:org.apache.ws.axis.security.WSDoAllSender" >
>>>     <parameter name="action" value="Signature"/>
>>>     <parameter name="passwordCallbackClass" value="PWCallback"/>
>>>     <parameter name="user" value="sample"/>
>>>     <parameter name="signaturePropFile" value="crypto.properties" />
>>>     <parameter name="signatureKeyIdentifier" value="DirectReference" />
>>>     <parameter name="encryptionSymAlgorithm" value=
>>> "http://www.w3.org/2001/04/xmlenc#aes128-cbc"<http://www.w3.org/2001/04/xmlenc#aes128-cbc>/>
>>>     <parameter name="encryptionKeyTransportAlgorithm" value=
>>> "http://www.w3.org/2001/04/xmlenc#rsa-1_5"<http://www.w3.org/2001/04/xmlenc#rsa-1_5>/>
>>>    </handler>
>>>   </requestFlow>
>>>   <responseFlow>
>>>    <handler type="java:org.apache.ws.axis.security.WSDoAllReceiver">
>>>     <parameter name="passwordCallbackClass" value="PWCallback"/>
>>>     <parameter name="action" value="Signature"/>
>>>     <parameter name="signaturePropFile" value="crypto.properties" />
>>>    </handler>
>>>   </responseFlow>
>>> </globalConfiguration >
>>>
>>>
>>>
>>>
>>>
>>> Martin Gainty escribió:
>>>
>>> Tomas<BR>
>>>
>>> the provided example works with WSS4J ..specifically<BR>
>>>
>>> *WSS4J configuration*<BR>
>>> Below is the important parts from the deployment .wsdd-file for the web
>>> service. The test.PWCallback <BR>
>>> class is a simple class returning the password of the private key in the
>>> keystore. I used the same <BR>
>>> crypto.properties as the one supplied as wsstest.properties in the
>>> interop-folder. As you can see I have <BR>
>>> specified which algorithms to use for the session key and ecrypted
>>> session key (RSA15 and AES128).
>>> <BR>
>>> Did you try?<BR>
>>> Saludos<BR>
>>> Martin <BR>
>>> ______________________________________________
>>> Disclaimer and confidentiality note
>>> Everything in this e-mail and any attachments relates to the official
>>> business of Sender. This transmission is of a confidential nature and Sender
>>> does not endorse distribution to any party other than intended recipient.
>>> Sender does not necessarily endorse content contained within this
>>> transmission.
>>>
>>>
>>> ------------------------------
>>> Date: Wed, 3 Sep 2008 16:10:30 +0200
>>> From: ttormo@indenova.com
>>> To: axis-user@ws.apache.org
>>> Subject: Re: *SPAM* RE: Problem verifying the signature with wss4j
>>>
>>> Thank you very much for your answer, but i forgot to specify that i'm
>>> writing a client in java using wss4j and not WSE, and i don't have access to
>>> the server (anyway, i'm new in this field,  so maybe i haven't understood it
>>> well...)
>>>
>>> Do you know how to do the same for wss4j in the client?
>>>
>>> Thank you.
>>>
>>> Martin Gainty escribió:
>>>
>>> <policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy"<http://schemas.microsoft.com/wse/2005/06/policy>
>>> ><BR>
>>> <policy name="x509"><BR>
>>> assume the specified policy includes the directive
>>> messageProtectionOrder="SignBeforeEncrypt"
>>> <BR>
>>>
>>> http://erlend.oftedal.no/blog/?blogid=12
>>> <BR>
>>> Saludos<BR>
>>> Martin <BR>
>>> ______________________________________________
>>> Disclaimer and confidentiality note
>>> Everything in this e-mail and any attachments relates to the official
>>> business of Sender. This transmission is of a confidential nature and Sender
>>> does not endorse distribution to any party other than intended recipient.
>>> Sender does not necessarily endorse content contained within this
>>> transmission.
>>>
>>>
>>> > Date: Wed, 3 Sep 2008 14:30:40 +0200
>>> > From: ttormo@indenova.com
>>> > To: axis-user@ws.apache.org
>>> > Subject: Problem verifying the signature with wss4j
>>> >
>>> > Greetings
>>> >
>>> > I'm trying to write an webservice client wich uses signed SOAP
>>> > messages in order to communicate. For this, i'm using wss4j 1.5.3 with
>>> > axis 1.4. I've succesfully wrote the client code wich signs the message
>>>
>>> > and sends it to the server, but i'm getting the following error:
>>> >
>>> > WSDoAllReceiver: security processing failed; nested exception is:
>>> > org.apache.ws.security.WSSecurityException: The signature
>>> > verification failed (The provided certificate is invalid)
>>> >
>>> > As far as i know (by reading posts in the internet) this is caused
>>> > because the XML is modified after it is signed. I've tried to set the
>>> > disablePrettyXML to true and the enableNamespacePrefixOptimization to
>>> > false, but it didn't work...
>>> >
>>> > I've read in other posts that this could be caused by the default blank
>>>
>>> > namespaces added by Axis (when I checked the XML thanks to TCPMonitor,
>>> > i could see that the attributes of the sent objects had no namespace,
>>> > but the object itself had).
>>> >
>>> > Does anybody have any solution for this problem? Could be possible to
>>> > disable the default namespace in axis?
>>> >
>>> > Thank you very much
>>> >
>>> > --
>>> > Un saludo,
>>> >
>>> > Tomás Tormo Franco
>>> >
>>> > Indenova, S.L.
>>> > Tels.: +34 963 81 99 47 ext.519
>>> > http://www.indenova.com
>>> > mailto:ttormo@indenova.com <ttormo@indenova.com>
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> > For additional commands, e-mail: axis-user-help@ws.apache.org
>>> >
>>>
>>> ------------------------------
>>> Get more out of the Web. Learn 10 hidden secrets of Windows Live. Learn
>>> Now<http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns%21550F681DAD532637%215295.entry?ocid=TXT_TAGLM_WL_getmore_092008>
>>>
>>>
>>> --
>>> Un saludo,
>>>
>>> Tomás Tormo Franco
>>>
>>> Indenova, S.L.
>>> Tels.: +34 963 81 99 47  ext.519http://www.indenova.commailto:ttormo@indenova.com
<ttormo@indenova.com>
>>>
>>>
>>> ------------------------------
>>> See how Windows Mobile brings your life together—at home, work, or on the
>>> go. See Now<http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/>
>>>
>>>
>>> --
>>> Un saludo,
>>>
>>> Tomás Tormo Franco
>>>
>>> Indenova, S.L.
>>> Tels.: +34 963 81 99 47  ext.519http://www.indenova.commailto:ttormo@indenova.com
<ttormo@indenova.com>
>>>
>>>
>>> --
>>> Un saludo,
>>>
>>> Tomás Tormo Franco
>>>
>>> Indenova, S.L.
>>> Tels.: +34 963 81 99 47  ext.519http://www.indenova.commailto:ttormo@indenova.com
<ttormo@indenova.com>
>>>
>>>
>>> --
>>> Un saludo,
>>>
>>> Tomás Tormo Franco
>>>
>>> Indenova, S.L.
>>> Tels.: +34 963 81 99 47  ext.519http://www.indenova.commailto:ttormo@indenova.com
<ttormo@indenova.com>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Un saludo,
>>>
>>> Tomás Tormo Franco
>>>
>>> Indenova, S.L.
>>> Tels.: +34 963 81 99 47  ext.519http://www.indenova.commailto:ttormo@indenova.com
<ttormo@indenova.com>
>>>
>>>
>>> ------------------------------
>>> See how Windows Mobile brings your life together—at home, work, or on the
>>> go. See Now<http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/>
>>>
>>
>>
>>
>> --
>> Jose Ferreiro
>> EPFL Communication Systems engineer
>> ing.sys.com.dipl.EPFL
>>
>>
>>
>> --
>> Un saludo,
>>
>> Tomás Tormo Franco
>>
>> Indenova, S.L.
>> Tels.: +34 963 81 99 47  ext.519http://www.indenova.commailto:ttormo@indenova.com
<ttormo@indenova.com>
>>
>>
>
>
> --
> Jose Ferreiro
> EPFL Communication Systems engineer
> ing.sys.com.dipl.EPFL
>
>
>
> --
> Un saludo,
>
> Tomás Tormo Franco
>
> Indenova, S.L.
> Tels.: +34 963 81 99 47  ext.519http://www.indenova.commailto:ttormo@indenova.com <ttormo@indenova.com>
>
>


-- 
Jose Ferreiro
EPFL Communication Systems engineer
ing.sys.com.dipl.EPFL
Mime
View raw message