Subject: [TLS] Doubts about a solution or new service/protocol

From: Walter Neto <[email-masked]>
Date: Mon, 16 Jul 2018 13:08:19 -0300

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Jul 2018 12:50:27 -0400

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 <[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Walter Neto <[email-masked]>
Date: Mon, 16 Jul 2018 15:30:56 -0300

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 <[email-masked]> 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 <[email-masked]> wrote:
>>
>> Hi IETF tls list,
>>

---

From: Walter Neto <[email-masked]>
Date: Fri, 20 Jul 2018 12:41:23 -0300

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.

My proposal:

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

Does this proposal make sense?

Regards,

-- 
--
Walter Neto

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 20 Jul 2018 15:53:49 +0000

IMHO no it doesn't. TLS is just a way to provide secure pipes between the communicating entities. Making long-term signatures that persist after the connection is dropped had never been on the site of TLS.

Regards,
Uri

Sent from my iPhone

> On Jul 20, 2018, at 11:42, Walter Neto <[email-masked]> wrote:
>

---

From: Hubert Kario <[email-masked]>
Date: Fri, 20 Jul 2018 19:30:19 +0200

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:
> B - The Brazilian Internal Revenue Service, who requires "A" to emit
> invoices using "B" webservices;
> "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
 
> > 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).> 
> > > encapsulation?  What you are describing sounds more like pgp than tls.> 
> 
> > >> 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
> > >> 

-- 
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