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 <walter.n...@superlogica.com> 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. > > 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, >> On Mon, Jul 16, 2018 at 3:30 PM Walter Neto <walter.n...@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 <mel...@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.n...@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 > > > > -- > -- > Walter Neto > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
