Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp685684pxf; Thu, 1 Apr 2021 10:53:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0umRwlZwAZESvTNynNc/5nYoAt+wzANpQHtK05d/YU0PGt2B+Zk9kTK97c63gGv4AEr/Y X-Received: by 2002:a05:6402:1115:: with SMTP id u21mr11165022edv.383.1617299616319; Thu, 01 Apr 2021 10:53:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617299616; cv=none; d=google.com; s=arc-20160816; b=t29u816/0jk0E67r8XiazXybBFeWdOd2g6uzlBc5XiaBIZjHxPoBP3Qw0j5tNwFwWV 0ZkIlNZcAuvSihe33a/B7P0y9aefRoKra46FffJNmh/UMS3UbvzoXb5vZTEz+dxidUDD Zw8KMZHVtfZw7yORMr252327+b+PXdLNj8AfyWTJ+Ges6dVbBKbxhIwIKwn5jmDWnZoN 3QxbDKJgbmR+QhL0vpYId9fRZhYDOQwUDU/Vedk5VK7IZ+AZhueJgQNz+KM6Pj70tMjb SnpX55uRHNxF/Mkk8btqdWpONcS8AyAmmWsoOKnvhwFpC76QeLbvVf7NtZHyXIRGJ1QY fX4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=4LRc5zlX4dmIqJZC4tRXENYZk181mewXwD7X4GEXkKA=; b=wZXSPFc3BZ/8/GxYHaKpID1U8ooN/MGzkSrtJAWoPvvAVAjBaBKx9R8cDuxBYxnF48 g+p1bD7mQSPk3oBC94DalBnGbhmcM+EsYBOjRgJ8HE6gGy+QEgDXWV1F/5Ju+Mcj4Jha pf7AfKHTqEWzVCDYr54TLrJ6t/n/YrChbbbIhXcBvt7jkLVJaTf8+jIFF9s1m8Zh1hHS iPDzni0K6D1T+tUJfYLeM5uY9VlxnTjLwUH6tw09i9MTwNNuX9TL4R7PEkczfYSIkfpc 9H0wcHW9xHEiz4h8WJgz9SYskIa/oLaSlpu/yuuev4I/7aSOfrLxLOPPqc+tM17oMOf3 GTog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Vm+Tjv8E; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hp34si4815954ejc.328.2021.04.01.10.53.12; Thu, 01 Apr 2021 10:53:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Vm+Tjv8E; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235327AbhDARw7 (ORCPT + 99 others); Thu, 1 Apr 2021 13:52:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237112AbhDARu3 (ORCPT ); Thu, 1 Apr 2021 13:50:29 -0400 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C688C005714 for ; Thu, 1 Apr 2021 07:13:02 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id d12so3036287lfv.11 for ; Thu, 01 Apr 2021 07:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4LRc5zlX4dmIqJZC4tRXENYZk181mewXwD7X4GEXkKA=; b=Vm+Tjv8EGF4ON3BmePiF+an1PklXoMoLGfZKYRESqwWronVx6WRRZIS+F6TP+Lbfr9 c2fhhAhZk/8su55Y2QryQk7HxxWzqTdDivxWH4tQoshMJgWi+bZJvhsQdFOJrHT3LogF ReLuPuqCYkvLIBoIvAIP0KsgTTMVWftEFB2m1jz11/crEDOHsPcdzNSm0vmeT8TittD3 wxip5yY2IJe+jJ1e9DNffMb2CBHe+fM+0pjqre0pvnviuVjWpxDowfLaDS073O8T2T1r S/Tk43FTwPTMksk0XsjA7dB2lZp93arrwSecLvBVeuX60gZ9hxIPny6zhtsP+UkF+xgk B/DA== 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:content-transfer-encoding; bh=4LRc5zlX4dmIqJZC4tRXENYZk181mewXwD7X4GEXkKA=; b=DMVNdHkuwq6Rc4gZBaQ5rRHKQvqX/4bxbq8gx65OAPZRDqmIXrGa5krnOAeuG/sITy 7wEGuFRab/C5U9yYqkgYOt/DMZO9U/zI0uhlvIOzDofMmzjL8qM6O1S3aPmPaOkYjDBz jWzsIjbmXQ5VyPwjLJ2DKKUsxdS3dVOLAzC5vb52zb+xYgSmoen9Ue+/LRhJ5qbVEwCa iYcVslMCtZUfc48G0Y0lDMrtlfaxVEybSnIKfk2dUxL4qWwr2t64FkVscXm7SlX7wzI/ mvlSwqNly4YxlWIQyMJEwac4DY/nFttwoolAWyNuj+Js4nwFl/XVoSGMYWVyWUFNdCQg isyw== X-Gm-Message-State: AOAM5317dwvJzHGcIdM5jB+how2aBQlfVo2WpO1FZmqqM6MgGRZuHbWQ /V6BtxNB55HSHGRTYS2aBTZTW8rJfSvPd4aLvE8PSQ== X-Received: by 2002:ac2:5970:: with SMTP id h16mr5350347lfp.108.1617286380737; Thu, 01 Apr 2021 07:13:00 -0700 (PDT) MIME-Version: 1.0 References: <1666035815.140054.1617283065549.JavaMail.zimbra@nod.at> <1846277009.140163.1617285566823.JavaMail.zimbra@nod.at> In-Reply-To: <1846277009.140163.1617285566823.JavaMail.zimbra@nod.at> From: Sumit Garg Date: Thu, 1 Apr 2021 19:42:49 +0530 Message-ID: Subject: Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys To: Richard Weinberger Cc: Ahmad Fatoum , Jarkko Sakkinen , horia geanta , Mimi Zohar , aymen sghaier , Herbert Xu , davem , James Bottomley , kernel , David Howells , James Morris , "Serge E. Hallyn" , Steffen Trumtrar , Udit Agarwal , Jan Luebbe , david , Franck Lenormand , linux-integrity , "open list, ASYMMETRIC KEYS" , Linux Crypto Mailing List , linux-kernel , LSM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Thu, 1 Apr 2021 at 19:29, Richard Weinberger wrote: > > Sumit, > > ----- Urspr=C3=BCngliche Mail ----- > > Von: "Sumit Garg" > > In this case why would one prefer to use CAAM when you have standards > > compliant TPM-Chip which additionally offers sealing to specific PCR > > (integrity measurement) values. > > I don't think we can dictate what good/sane solutions are and which are n= ot. > Both CAAM and TPM have pros and cons, I don't see why supporting both is = a bad idea. I didn't mean to say that supporting both is a bad idea but rather I was looking for use-cases where one time selection of the best trust source (whether it be a TPM or TEE or CAAM etc.) for a platform wouldn't suffice for user needs. > > >> > IMHO allowing only one backend at the same time is a little over sim= plified. > >> > >> It is, but I'd rather leave this until it's actually needed. > >> What can be done now is adopting a format for the exported keys that w= ould > >> make this extension seamless in future. > >> > > > > +1 > > As long we don't make multiple backends at runtime impossible I'm > fine and will happily add support for it when needed. :-) > You are most welcome to add such support. I will be happy to review it. -Sumit > Thanks, > //richard