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

Walter Neto <walter.neto@superlogica.com> Mon, 16 July 2018 18:31 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 B687C130F00 for <tls@ietfa.amsl.com>; Mon, 16 Jul 2018 11:31:40 -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 i7os9v03aYLm for <tls@ietfa.amsl.com>; Mon, 16 Jul 2018 11:31:34 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 CE1E613111D for <tls@ietf.org>; Mon, 16 Jul 2018 11:31:33 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id a5-v6so19205119qtp.2 for <tls@ietf.org>; Mon, 16 Jul 2018 11:31:33 -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 :cc; bh=ko5ZxDU+UYLokM0EwEqXqoW+tVsH0w7ZnHlGSBlwTUU=; b=VruizZqRv5NPMVNGayAIp2LLFkEUaIoy52u11dOJbeRF240Saky8cXXDirv/0JPBSU 5G0EaVtjXbDf1MiqSTDA5Tv29wWthsqVvC+K/nlLaP8IE265iljvODNEYZvn93FOEE1D FslhEmZ2cBk5kvQcdiTcNE19x3J8uJyc0S6lE=
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:cc; bh=ko5ZxDU+UYLokM0EwEqXqoW+tVsH0w7ZnHlGSBlwTUU=; b=gJrkP1uWjFfUWDGv0mrYRFzunqWKdff9HL6/UZBkctvCd9DMpsumqpOQHklBVqw6y4 XBQiCANJ2KUUIMdKatPR4E9a6F5hrjuXD+l+fVd78vgZ5qYXX5jyw0jRdruvhViVWE+J cf4XClzmgu2+/hZ1TyMDwLXOJj08hIsqNUr/4fasASS2pZYHLbgkMxkJUgvZ22MdHZmH Ifed5Hr6lz+YmA9AQSsIDcsZSng2iwny6pkoKwdem60H/cpXnzvj4Rf5Jcs/Wx0omtYf /BCutxCh572GTlf1x5H3zkfZWHYEEvSUEle9UHBAoIsbnBcL0EXGbAMISw6kv5TbUOsN +9uQ==
X-Gm-Message-State: AOUpUlFjrmDLZE3mZlnb2FiD+DosdZ22bXgToXhTCUW/0El2tcABuF5K ACCSVTCdmw6zol6KQMYLm7fwt8HVSCm39/U+NocZ5iSaUmU=
X-Google-Smtp-Source: AAOMgpdTgkvn7xRv0h0gZT/IsgE14q27pZ+a6iNDTRQPVVJ5MHB+3z/gx3s13xlU6wgm0mdVp+UAjXaXl9+z3gCqVmE=
X-Received: by 2002:ac8:91d:: with SMTP id t29-v6mr16183589qth.188.1531765892790; Mon, 16 Jul 2018 11:31:32 -0700 (PDT)
MIME-Version: 1.0
References: <CAM3y_Mu8dax-59dm5GpLkfRZqZZMNF=NT0nqm_e2Acxg15vV2A@mail.gmail.com> <CAPt1N1nZQ5ZWA_mvwA_jpXaYyhO06c+bE4T5vk3pHbkpRXc=Sw@mail.gmail.com>
In-Reply-To: <CAPt1N1nZQ5ZWA_mvwA_jpXaYyhO06c+bE4T5vk3pHbkpRXc=Sw@mail.gmail.com>
From: Walter Neto <walter.neto@superlogica.com>
Date: Mon, 16 Jul 2018 15:30:56 -0300
Message-ID: <CAM3y_MvUb4TUtq9YE1og3k02D9Qsqx3sg41CwJXCBsWGX2PwFg@mail.gmail.com>
To: mellon@fugue.com
Cc: tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0-kZVh16gYf3wlYr56ov4Tr2EMk>
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: Mon, 16 Jul 2018 18:31:41 -0000

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