Re: [Ace] [T2TRG] Minimizing overhead of certificates in constrained IoT
Carsten Bormann <cabo@tzi.org> Sat, 03 November 2018 06:56 UTC
Return-Path: <cabo@tzi.org>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDAF12958B; Fri, 2 Nov 2018 23:56:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Ow8oMP65mqMW; Fri, 2 Nov 2018 23:56:14 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 E2EB3127332; Fri, 2 Nov 2018 23:56:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wA36u5pV014479; Sat, 3 Nov 2018 07:56:10 +0100 (CET)
Received: from [IPv6:2001:67c:1230:105:15de:f7b0:1a03:10c6] (unknown [IPv6:2001:67c:1230:105:15de:f7b0:1a03:10c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42n8q743gTz1Bqf; Sat, 3 Nov 2018 07:56:03 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <3F7E42DF-7CA9-4765-AB67-A53B4E7D1AC1@ericsson.com>
Date: Sat, 03 Nov 2018 13:55:58 +0700
Cc: "t2trg@irtf.org" <t2trg@irtf.org>, "ace@ietf.org" <ace@ietf.org>
X-Mao-Original-Outgoing-Id: 562920956.278599-6ab7790c9349491a7bf7601c2e6db6e6
Content-Transfer-Encoding: quoted-printable
Message-Id: <1FA4F305-B83D-4E42-8F7A-93B2937C8DA4@tzi.org>
References: <3F7E42DF-7CA9-4765-AB67-A53B4E7D1AC1@ericsson.com>
To: John Mattsson <john.mattsson@ericsson.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/HTsBhLiYeZLalWPP-gB2ldRVumI>
Subject: Re: [Ace] [T2TRG] Minimizing overhead of certificates in constrained IoT
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Nov 2018 06:56:16 -0000
Much of this discussion is less of a technical nature but about framing things right. If all signed assertions are called certificates, it may be hard to get rid of X.509, because that is what people think of when they say “certificate". What signed assertions do we need for constrained IoT, and which of these really “need” to be certificates? (A chain of signed assertions might ultimately terminate in an X.509 certificate, because that’s the way we store public keys with long-term validity in many places, but how important is it to have the full X.509 certificate represented in a constrained device?) Grüße, Carsten
- [Ace] Minimizing overhead of certificates in cons… John Mattsson
- Re: [Ace] Minimizing overhead of certificates in … Hannes Tschofenig
- Re: [Ace] [T2TRG] Minimizing overhead of certific… Carsten Bormann
- Re: [Ace] Minimizing overhead of certificates in … Benjamin Kaduk
- Re: [Ace] Minimizing overhead of certificates in … Joel Höglund