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

Walter Neto <walter.neto@superlogica.com> Mon, 16 July 2018 16:09 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 61371130E3B for <tls@ietfa.amsl.com>; Mon, 16 Jul 2018 09:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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] 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 M1ma28aKBtBa for <tls@ietfa.amsl.com>; Mon, 16 Jul 2018 09:08:58 -0700 (PDT)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 24C0E13109B for <tls@ietf.org>; Mon, 16 Jul 2018 09:08:57 -0700 (PDT)
Received: by mail-qt0-x22a.google.com with SMTP id f18-v6so33316804qtp.10 for <tls@ietf.org>; Mon, 16 Jul 2018 09:08:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=superlogica.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=/Qw2AYa6Fymfq7kBHEq9M1y22pp/UeBUMbUvq1t6M7M=; b=N/hzsv4j2r8U1Lux9fn1jL8OVcaoVmE1z2x2JFWUZRHa36+N3Br5cm4vpaylXrHaro x2Zp2lwqcwv0blWzckKEr41BFXUj00sfZs0LmTXXxbhGSna3GFjp9TkI6lXiDDjwIG/c vK1Py/Sq6MhrX+Gki9sxQU6pmZru7PpGG3l2Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/Qw2AYa6Fymfq7kBHEq9M1y22pp/UeBUMbUvq1t6M7M=; b=ABAsgGYIGx13JNUXE8IVajX1M7kJCjIjCW/MekKr4qXyDnF2oq3woS5cMOzefzsGBL slItwlRQV9mGQ4oS9okylaZYcHVsLc0/uVQqeBhzZALX9AAooVvE0VpPI++s2h51+Spc QQDgJlgEU0d0035Y32RXwNRxkTyHiZ6yMqzdPgiNvQjbw9TVW3nWk1HG+FtHx1ZNt9Z3 qlup3O0KyNSz9lL2A7QfjhhclomwHmu+1vP9IuZ2SoypWhFENrGMVvvTe9DSQy2XJYyS Jc/GlL54djRyBTBl3jGG/k4bG9LksKiGw1/vl8o0fKdGlDNNZnbHMlg4E/fAX51J6/fA TuNQ==
X-Gm-Message-State: AOUpUlGd1ZE3uoGbc765l0N5DM0riR80obZ13WvyA/Y1QP6AdIg1ZC3d 4dpklWSronsurIrZw9myDfEozAn85azMlETBBJYxF7h6SAI=
X-Google-Smtp-Source: AAOMgpdFLgW6/FXmEfglvf4xoq5lZqI7PFBcOoQIcUp3lh8CPxWCbU8+QD45OOnNWaxyUmnNdeSXBDLiu0lYgl8Pp6U=
X-Received: by 2002:aed:2561:: with SMTP id w30-v6mr14920035qtc.240.1531757335910; Mon, 16 Jul 2018 09:08:55 -0700 (PDT)
MIME-Version: 1.0
From: Walter Neto <walter.neto@superlogica.com>
Date: Mon, 16 Jul 2018 13:08:19 -0300
Message-ID: <CAM3y_Mu8dax-59dm5GpLkfRZqZZMNF=NT0nqm_e2Acxg15vV2A@mail.gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/npGk9y7XMkOJVRk_bY9GXHSKq9U>
Subject: [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 16:14:29 -0000

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