From nobody Wed Aug 2 10:41:26 2023 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117B9C151984 for ; Wed, 2 Aug 2023 10:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sebbe.eu Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJ7S2mvo_7qF for ; Wed, 2 Aug 2023 10:41:19 -0700 (PDT) Received: from dns2.sebbe.eu (dns2.sebbe.eu [IPv6:2001:470:dff1:1:10::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E05DC16B5BF for ; Wed, 2 Aug 2023 10:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sebbe.eu; s=root; h=Date:To:From:cc; bh=yqYW6bouyc5bvF20mQwTdewP9Rd84SDWq0YOUtTGaX4=; b=n4Bcq4x/g38OEkwTYJF5f3hOCLHGolgllT6UlxKScUTzp3ji+DgyM0BeH9CjyhKstnWRg9EPT+ azRB4WK5abTsSVGHKtL9rnNmGfMrYZ34M31fdgUVJ3R23d7rp8Z/9u5onFRauGUaUgUFNwZxTatMZ GIl4S4yjCXGJSdZYigmE=; Received: from localhost ([127.0.0.1] helo=sebastian-desktop) by sebbe.eu with esmtp (Exim 4_94_RC0-31-83e8da8c0-XX) (envelope-from ) id 1qRFqJ-000D1M-Kb for acme@ietf.org; Wed, 02 Aug 2023 19:41:03 +0200 Received: from [192.168.1.188] (helo=DESKTOPA5BEHQI) by sebbe.eu with esmtpa (Exim 4_94_RC0-31-83e8da8c0-XX) (envelope-from ) id 1qRFqJ-000D1J-By for acme@ietf.org; Wed, 02 Aug 2023 19:41:03 +0200 From: "Sebastian Nielsen" To: "'Mailing List'" References: <169099211414.11957.13218136675686326535@ietfa.amsl.com> <006b01d9c565$35b148c0$a113da40$@sebbe.eu> In-Reply-To: Message-ID: <00c201d9c568$82baa140$882fe3c0$@sebbe.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C3_01D9C579.46440D80" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFyCAfi5epXzZ2YAJPgq2oxnWYfWgE2sAicAkiqeYUA4s06TwIEVjRZsHOK4XA= Content-Language: sv X-Encryption-Target: external Date: Wed, 02 Aug 2023 19:41:03 +0200 Archived-At: Subject: Re: [Acme] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draft-sweet?= =?utf-8?q?-iot-acme-04=2Etxt?= X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2023 17:41:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C3_01D9C579.46440D80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >>Then why use ACME to begin with? What I understand it was to make it easier for =E2=80=9Cnewbies=E2=80=9D = to set up a device. So the device can automatically do = =E2=80=9Cinclusion=E2=80=9D of itself once it connects to a network.=20 =20 I see no security problems with allowing longer certificates, since the = certificates are only locally used, and hard-restricted to the = particular network that uses the certificate. For certificates on the internet, its important with short lifetimes, = revocation and such, since there unauthorized people can get on board. = For local networks this isn=E2=80=99t a risk. A non-revoked certificate is only a risk if = a malicious actor gets its hand on a device after It changed owner, what = my suggestion of mandatory reset if it is not connected, or connected = to a network the device doesn=E2=80=99t recongnize based on certificate = AND a new user is paired through a method that doesn=E2=80=99t = require cooperation by a already paired user/device. =20 These 2 circumstances together is clear evidence that the device itself = is not being owned by the same user anymore, thus it should erase any = keys and certificates for security, both so the new user cannot act = maliciously against the old user, AND so the old user cannot act = maliciously against the new user. =20 Best regards, Sebastian Nielsen =20 =20 ------=_NextPart_000_00C3_01D9C579.46440D80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

>>Then why use ACME to begin = with?

What I = understand it was to make it easier for =E2=80=9Cnewbies=E2=80=9D to set = up a device. So the device can automatically do = =E2=80=9Cinclusion=E2=80=9D of itself once it connects to a network. =

 

I see = no security problems with allowing longer certificates, since the = certificates are only locally used, and hard-restricted to the = particular network that uses the certificate.

For certificates on = the internet, its important with short lifetimes, revocation and such, = since there unauthorized people can get on board. For local networks = this isn=E2=80=99t a risk.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A non-revoked certificate is only a = risk if a malicious actor gets its hand on a device after It changed = owner, what my suggestion of mandatory =C2=A0=C2=A0 reset if it is not = connected, or connected to a network the device doesn=E2=80=99t = recongnize based on certificate AND a new user is paired through a = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 method that = doesn=E2=80=99t require cooperation by a already paired = user/device.

 

These = 2 circumstances together is clear evidence that the device itself is not = being owned by the same user anymore, thus it should erase any keys and = certificates for security, both so the new user cannot act maliciously = against the old user, AND so the old user cannot act maliciously against = the new user.

 

Best regards, Sebastian Nielsen

 

 

<= /body> ------=_NextPart_000_00C3_01D9C579.46440D80--