Re: [lamps] Call for adoption for draft-ito-documentsigning-eku
Stefan Santesson <stefan@aaa-sec.com> Thu, 11 November 2021 16:12 UTC
Return-Path: <stefan@aaa-sec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4820C3A0B6F for <spasm@ietfa.amsl.com>; Thu, 11 Nov 2021 08:12:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.229
X-Spam-Level:
X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 te4lt4VG_6Zf for <spasm@ietfa.amsl.com>; Thu, 11 Nov 2021 08:12:33 -0800 (PST)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [93.188.3.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927313A0B19 for <spasm@ietf.org>; Thu, 11 Nov 2021 08:12:32 -0800 (PST)
Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id BA2DB2EB7E78 for <spasm@ietf.org>; Thu, 11 Nov 2021 17:12:25 +0100 (CET)
Received: from s645.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id AB94F2E33218; Thu, 11 Nov 2021 17:12:25 +0100 (CET)
Received: from s898.loopia.se (unknown [172.22.191.5]) by s645.loopia.se (Postfix) with ESMTP id 9376615778CA; Thu, 11 Nov 2021 17:12:25 +0100 (CET)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s630.loopia.se ([172.22.191.5]) by s898.loopia.se (s898.loopia.se [172.22.190.17]) (amavisd-new, port 10024) with LMTP id ZUy8Rpl6YCNi; Thu, 11 Nov 2021 17:12:25 +0100 (CET)
X-Loopia-Auth: user
X-Loopia-User: mailstore2@aaa-sec.com
X-Loopia-Originating-IP: 90.229.17.25
Received: from [10.0.1.119] (unknown [90.229.17.25]) (Authenticated sender: mailstore2@aaa-sec.com) by s630.loopia.se (Postfix) with ESMTPSA id E02E113ACC8E; Thu, 11 Nov 2021 17:12:24 +0100 (CET)
Message-ID: <df508f23-c7b4-a0ca-d552-51c2b1d9663a@aaa-sec.com>
Date: Thu, 11 Nov 2021 17:12:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:95.0) Gecko/20100101 Thunderbird/95.0
Content-Language: en-US
To: "Brown, Wendy (10421)" <wendy.brown=40protiviti.com@dmarc.ietf.org>, LAMPS WG <spasm@ietf.org>
References: <CD589623-52EE-4958-80AB-73F0CFB3A36E@vigilsec.com> <1739DC01-D237-4080-99F2-1B82A4571C49@vigilsec.com> <SA1PR03MB66262B6CA20602F3417C0B7EEE949@SA1PR03MB6626.namprd03.prod.outlook.com>
From: Stefan Santesson <stefan@aaa-sec.com>
Organization: 3xA Security AB
In-Reply-To: <SA1PR03MB66262B6CA20602F3417C0B7EEE949@SA1PR03MB6626.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/6B1ZppC7FdxXv5jQwUj0x5_iQGs>
Subject: Re: [lamps] Call for adoption for draft-ito-documentsigning-eku
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Nov 2021 16:12:39 -0000
Hi, I just went through large part of this mail thread, the draft itself and the presentation at IETF112. I would at least like to raise some concerns about this EKU. My absolute biggest worry is that we will initiate the old non-repudiation debate in key usage where we desperately attempted to distinguish between usage of keys for something similar to "document signing" as apposed to using the key for signing to support authentication or just data integrity. In the wake of that discussion, many people started to debate how the setting of this or that bit would affect the legal effect of such signature. I think that the only thing we could agree on in the end was that it probably was a huge mistake to try to bind a key to a purpose, as opposed to binding the key to a particular protocol. The main difference is that if a certificate is declared as suitable for a protocol, then it is easy to just deny that protocol action if the identifier is not there. That has no implications rather than the end-points fixing their certs to make the protocol work. But if you receive a signed document, the harm is done and you can't go back and ask the signer to sign with another cert. And the commitment is done, and legally binding, whether there is a declaration of this type or not. So my question is basically. What are the signer and the verifier supposed to do based on seeing or not seeing this EKU in a cert. That is not at all clear to me. My biggest fear is that other standards groups in this area, like ETSI ESI will start to update their signature validation procedures to check for the presence of this EKU. I can hear the debate already. To comments on the actual draft. The following text is problematic: "Inclusion of this KeyPurposeId in a certificate indicates that the use of any Subject names in the certificate is restricted to use by a document signing." This is not compatible with the function of the EKU extension. If you for example add a second EKU to the certificate, the certificate is equally valid to be used with the other EKU. An EKU can therefore not limit or restrict the use of the certificate for just this purpose. Also, the definition of document signing is problematic: In modern electronic services you cant isolate the signed document from the process of creating, approving and signing content. This is because what you see is what you sign is just a fairy tale. In practice you see something, but you often sign some machine processable data that binds the transaction/agreement to you, but it is not the visible content. It is not even a document that you can make visible directly. This is the case often when for example signing tax declarations. What you sign can be an XML construct of codes and data that is key to the declaration, but the XML data is only for machine processing. The data itself can be visually presented, but it is a stretch to call that the signed document. The world is simply not that neat and contained that we would like it to be. In the end. This EKU worries me. A lot. /Stefan
- [lamps] Call for adoption for draft-ito-documents… Russ Housley
- Re: [lamps] Call for adoption for draft-ito-docum… Salz, Rich
- Re: [lamps] Call for adoption for draft-ito-docum… Eliot Lear
- Re: [lamps] Call for adoption for draft-ito-docum… Ryan Sleevi
- Re: [lamps] Call for adoption for draft-ito-docum… Tadahiko Ito
- Re: [lamps] Call for adoption for draft-ito-docum… Ryan Sleevi
- Re: [lamps] Call for adoption for draft-ito-docum… Eliot Lear
- Re: [lamps] Call for adoption for draft-ito-docum… Ryan Sleevi
- Re: [lamps] Call for adoption for draft-ito-docum… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] Call for adoption for draft-ito-docum… Tomofumi Okubo
- Re: [lamps] Call for adoption for draft-ito-docum… Ryan Sleevi
- Re: [lamps] Call for adoption for draft-ito-docum… Tomofumi Okubo
- Re: [lamps] Call for adoption for draft-ito-docum… Ryan Sleevi
- Re: [lamps] Call for adoption for draft-ito-docum… Eliot Lear
- Re: [lamps] Call for adoption for draft-ito-docum… Deb Cooley
- Re: [lamps] Call for adoption for draft-ito-docum… Ryan Sleevi
- Re: [lamps] Call for adoption for draft-ito-docum… Eliot Lear
- Re: [lamps] Call for adoption for draft-ito-docum… Ryan Sleevi
- Re: [lamps] Call for adoption for draft-ito-docum… Deb Cooley
- Re: [lamps] Call for adoption for draft-ito-docum… Ryan Sleevi
- Re: [lamps] Call for adoption for draft-ito-docum… Russ Housley
- Re: [lamps] Call for adoption for draft-ito-docum… Eliot Lear
- Re: [lamps] Call for adoption for draft-ito-docum… Santosh Chokhani
- Re: [lamps] Call for adoption for draft-ito-docum… Deb Cooley
- Re: [lamps] Call for adoption for draft-ito-docum… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] Call for adoption for draft-ito-docum… Ryan Sleevi
- Re: [lamps] Call for adoption for draft-ito-docum… Carl Wallace
- Re: [lamps] Call for adoption for draft-ito-docum… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] Call for adoption for draft-ito-docum… Ryan Sleevi
- Re: [lamps] Call for adoption for draft-ito-docum… Ryan Sleevi
- Re: [lamps] Call for adoption for draft-ito-docum… Carl Wallace
- Re: [lamps] Call for adoption for draft-ito-docum… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] Call for adoption for draft-ito-docum… Ryan Sleevi
- Re: [lamps] Call for adoption for draft-ito-docum… Carl Wallace
- Re: [lamps] Call for adoption for draft-ito-docum… Ryan Sleevi
- Re: [lamps] Call for adoption for draft-ito-docum… Carl Wallace
- Re: [lamps] Call for adoption for draft-ito-docum… Salz, Rich
- Re: [lamps] Call for adoption for draft-ito-docum… Ryan Sleevi
- Re: [lamps] Call for adoption for draft-ito-docum… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] Call for adoption for draft-ito-docum… Michael Richardson
- Re: [lamps] [EXTERNAL] Call for adoption for draf… Mike Ounsworth
- Re: [lamps] Call for adoption for draft-ito-docum… Russ Housley
- Re: [lamps] Call for adoption for draft-ito-docum… Daniel Kahn Gillmor
- Re: [lamps] Call for adoption for draft-ito-docum… Michael Richardson
- Re: [lamps] Call for adoption for draft-ito-docum… Russ Housley
- Re: [lamps] Call for adoption for draft-ito-docum… Ryan Sleevi
- Re: [lamps] Call for adoption for draft-ito-docum… Russ Housley
- Re: [lamps] [EXTERNAL] Re: Call for adoption for … Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: Call for adoption for … Russ Housley
- Re: [lamps] [EXTERNAL] Re: Call for adoption for … Mike Ounsworth
- Re: [lamps] Call for adoption for draft-ito-docum… Michael Richardson
- [lamps] Call for adoption for draft-ito-documents… Russ Housley
- Re: [lamps] Call for adoption for draft-ito-docum… Yoshiro YONEYA
- Re: [lamps] Call for adoption for draft-ito-docum… Corey Bonnell
- Re: [lamps] Call for adoption for draft-ito-docum… Brown, Wendy (10421)
- Re: [lamps] Call for adoption for draft-ito-docum… Stefan Santesson
- Re: [lamps] Call for adoption for draft-ito-docum… Tadahiko Ito
- Re: [lamps] Call for adoption for draft-ito-docum… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] Call for adoption for draft-ito-docum… Deb Cooley
- Re: [lamps] Call for adoption for draft-ito-docum… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] Call for adoption for draft-ito-docum… Deb Cooley
- Re: [lamps] Call for adoption for draft-ito-docum… Russ Housley
- Re: [lamps] Call for adoption for draft-ito-docum… Tadahiko Ito
- Re: [lamps] Call for adoption for draft-ito-docum… Russ Housley