[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Doubts about a solution or new service/protocol
From:       Hubert Kario <hkario () redhat ! com>
Date:       2018-07-20 17:30:19
Message-ID: 2794700.6u4tZpJgc5 () pintsize ! usersys ! redhat ! com
[Download RAW message or body]


On Friday, 20 July 2018 17:41:23 CEST Walter Neto wrote:
> Hi guys, after I saw I did not express myself clearly I decided to write
> this message trying to do that.
> 
> The actors:
> A - The business company that needs to emitt the invoice;
> B - The Brazilian Internal Revenue Service, who requires "A" to emit
> invoices using "B" webservices;
> C - The software company that emits the invoice for company "A" through "B"
> webservices.
> 
> The current Brazilian common model:
> 
> "A" pass to "C" his certificate who uses it to sign and communicate it
> through "C" webservices.
> 
> For me here we have a serious security problem, once this private keys is
> shared between "B" employees.

yes it is

> My proposal:
> 
> To exist a service that TLS Client implementations consume to make the tasks
> who only the certificate private key detainer can do.

TLS client certificates sign just the handshake, they don't sign the contents 
of the exchanged messages, both the client and the server have keys that can 
be used to create messages looking as if they were created by either side of 
connection, so you can't say if the messages were created by an "evil" server, 
or are genuine

worse still, as the exchanged data is authenticated either with HMAC or some 
form of AEAD tag (so symmetric crypto), when you are able to verify the 
messages as genuine, you also are able to forge them

so no, TLS itself is not the technology that can be used to solve this
 
> Regards,
> 
> On Mon, Jul 16, 2018 at 3:30 PM Walter Neto <walter.neto@superlogica.com> 
wrote:
> > Sorry Ted, I think I was not so clear.
> > 
> > We use https (http over tls) to transmit this invoice files and I think it
> > will be great if we have the option on the tls protocol to ask another
> > service to encrypt things to it, without having the certificate (with
> > private key).> 
> > On Mon, Jul 16, 2018 at 1:50 PM Ted Lemon <mellon@fugue.com> wrote:
> > > Why do you need to extend tls to do this?  Why not just use it for
> > > encapsulation?  What you are describing sounds more like pgp than tls.> 
> 
> > > On Mon, Jul 16, 2018 at 12:15 PM Walter Neto 
<walter.neto@superlogica.com> wrote:
> > >> Hi IETF tls list,
> > >> 
> > >> I have some problem to solve I believe it is good to make my questions
> > >> and
> > >> proposals here.
> > >> 
> > >> I'm from Brazil, here we need to use X.509 certificates to sign
> > >> electronic
> > >> invoices XMLs and to communicate this XMLs through https.
> > >> 
> > >> The problem is that the most of emitters pass their certificates (with
> > >> private and public keys) to the software companies that communicate
> > >> this invoices, what in my point of view it is so insecure, the other
> > >> problem is that generate a certificate to the software company
> > >> authorized to emmit the invoice is so bureaucratic.
> > >> 
> > >> My proposal is to create a service that generates tokens to third
> > >> applications use this service to sign, and encrypt data without the
> > >> certificate, and introduce an option in the tls protocol to pass the
> > >> token and the service address to use it when don't have local cert
> > >> files.
> > >> 
> > >> Does it make sense?
> > >> 
> > >> --
> > >> Walter Neto
> > >> 
> > >> _______________________________________________
> > >> TLS mailing list
> > >> TLS@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/tls


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]