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

Walter Neto <walter.neto@superlogica.com> Fri, 20 July 2018 15:42 UTC

Return-Path: <walter.neto@superlogica.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B144130EB0 for <tls@ietfa.amsl.com>; Fri, 20 Jul 2018 08:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=superlogica.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hhfm-4teFYEh for <tls@ietfa.amsl.com>; Fri, 20 Jul 2018 08:42:00 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3404130E02 for <tls@ietf.org>; Fri, 20 Jul 2018 08:42:00 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id b66-v6so6454103qkj.1 for <tls@ietf.org>; Fri, 20 Jul 2018 08:42:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=superlogica.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=gCS48hsjVBJfQdlLnyMkzZlyFOS9isCnB+fQvdqo+jo=; b=iR0/Tt9jfZgW/l7riVMBUJX0zlNVY6sdGRdmSpqHkt95K//pQamHSKd1Pp5Ce4sMq4 jSNKxLeBvCgBHB1WZEzQP7DV1cBduVI9lTUHlmIOWMNnuDR9KYR3EqEJqgd48OFjAqiZ oMJsAuqIB5LEkxS/hSrbuMvm4JuTbcvGqlOGE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=gCS48hsjVBJfQdlLnyMkzZlyFOS9isCnB+fQvdqo+jo=; b=Im/PNUjkVsPUBppXkg9ni5VGEAK0GOfEjvQAlN848ZdemOMA+FYteYb3pbkC6Xvz48 5IqPGyWq+1pwVHTBPsouTMcNmogJhxKSZSb3mAvdoYiyFDGpThbIq1IWY4sKsSXgDGE5 BRGI4ywn9deS0f6RI5xV7JqvmwpUqlKq+W5Kl2kI69ynRpkNg1zpvE9u0o3U+XQaB93g me0MEKwhQkT4NNqe0M42G9ibb0jCGjKpfud1FAvNj6CebXyaMA9rc7vAhEVVhG7svEmz DRdetDQUhPmaRnaLU0f2lKOvKrFgBB5/BLDky0LMT6p4sYldcN5+YKd418EP5UJj0xjo X0Cg==
X-Gm-Message-State: AOUpUlFpne2Nc25UYgk8ddRjU3aUs7mB4I+OiG3m64zzBz6uK4lNrwGL WW/x6vBhPjT9iv9Gk/yO6McdQn0UkxqDwmqji+kfht0l7Vk=
X-Google-Smtp-Source: AAOMgpc/UQjdg7K35xjBK4JoPyqCWzRVxazIHEw6wEW+Uc9PAnUAacKVy2nPuyMymkFyT14dd5KFlKmnH7EZ7YUv560=
X-Received: by 2002:a37:8103:: with SMTP id c3-v6mr2284727qkd.246.1532101319378; Fri, 20 Jul 2018 08:41:59 -0700 (PDT)
MIME-Version: 1.0
References: <CAM3y_Mu8dax-59dm5GpLkfRZqZZMNF=NT0nqm_e2Acxg15vV2A@mail.gmail.com> <CAPt1N1nZQ5ZWA_mvwA_jpXaYyhO06c+bE4T5vk3pHbkpRXc=Sw@mail.gmail.com> <CAM3y_MvUb4TUtq9YE1og3k02D9Qsqx3sg41CwJXCBsWGX2PwFg@mail.gmail.com>
In-Reply-To: <CAM3y_MvUb4TUtq9YE1og3k02D9Qsqx3sg41CwJXCBsWGX2PwFg@mail.gmail.com>
From: Walter Neto <walter.neto@superlogica.com>
Date: Fri, 20 Jul 2018 12:41:23 -0300
Message-ID: <CAM3y_Msv8WNyt9L-ah6=7YJk1VshQsOsOHayEEU_rCFc87_1ug@mail.gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dARv0l7_HRzz-EDSAIVK3viuMyk>
Subject: Re: [TLS] Doubts about a solution or new service/protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jul 2018 15:42:04 -0000

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



-- 
--
Walter Neto