Re: [Ace] Keeping the same key identifier for groups

Ludwig Seitz <> Tue, 20 August 2019 09:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41E7B120072 for <>; Tue, 20 Aug 2019 02:09:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NMc-l4L1zjnX for <>; Tue, 20 Aug 2019 02:09:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D77A2120041 for <>; Tue, 20 Aug 2019 02:09:21 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=WBJJDKZ+9IhGT1vRjmi4i3YNwz2PGRgE9iT3gOE3XK29oRcTg828AakD6/CvqlKjh6JDLNC74T1rzSHU616Jo/nq7EwRmJmhMOSIpcThPCDqO6OqsVi6EHuwLFDcpgNRkGSXZrk/nknd12a1JcbdIejKF5aevRwnbQYmWy616+dsWV17j34SFeXduHdtpSPsN1+wDAuU0xP1G04Mgv3UsjgmYMMoCCT3J+jwE+3Hb/Rh9BkNe7ZTB+Erdp7GiBCqaBLCSxOIUn2X3ZBx2qrRf5SxAC/DAo4zkQotoZbF3VH+PIffPDNNskJTp6to03AbNG3Sxg5gXku7396b/bKpeg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D/Xx5yD7axveKXeMB2xVydlvWjX+IqQRidzZe9QG1IY=; b=Q9ZteDkGZOneycM+Mii+5c6AwhtYSL1ESuUuU7V38n6HlZb0JvdSNoIARn/TlWRlMO0RpCx2Xx6e39hlEmIw31Sct2KzXX+hWHNqkhmTphCpr+enNM9D1saZNNDWT7Osg4etgJI9e+NVODL+Fe1QP9OT2v5QVvj0+zDS5V1XsdqxaBZII8WrcE94UTyKx6yG5j7hGOO9+wtz7RynVkw4ffxg3kEDdmlgrNOvHaQ6NuyL5+pDcobkf2xXkQQi7gnDe/s8KiUESlJrhr/udHzzry0wJE+ExpiZtVbO2YCejXPT1qkfpnefpjIwHZHuHypJLFNxcr+koJE70MO/8Gq72A==
ARC-Authentication-Results: i=1; 1; spf=pass (sender ip is; dmarc=pass (p=none sp=none pct=100) action=none; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D/Xx5yD7axveKXeMB2xVydlvWjX+IqQRidzZe9QG1IY=; b=JXqhKQRDWWZFoXhvrOy05LEyS8EQp6keTmBPy7WZjgnoAcD4fZTVaCH7D4jeWbE5frC0kuwVkTbutwg/kKKiMSBj6363Vxv4wUD7a1tf/N6g8NOrcRCgjgM7H6Z/bAoblTXpg1urwkTR/5S7TZrVJ3cS0rml7wG6+tltX45Kb4A=
Received: from HE1P18901CA0023.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:8b::33) by AM0P189MB0754.EURP189.PROD.OUTLOOK.COM (2603:10a6:208:1a2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Tue, 20 Aug 2019 09:09:19 +0000
Received: from (2a01:111:f400:7e06::203) by (2603:10a6:3:8b::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2178.16 via Frontend Transport; Tue, 20 Aug 2019 09:09:18 +0000
Authentication-Results: spf=pass (sender IP is;; dkim=none (message not signed) header.d=none;; dmarc=pass action=none;
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2178.16 via Frontend Transport; Tue, 20 Aug 2019 09:09:17 +0000
Received: from [] ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 20 Aug 2019 11:09:16 +0200
To: <>
References: <01fc01d556ce$69f73cc0$3de5b640$>
From: Ludwig Seitz <>
Message-ID: <>
Date: Tue, 20 Aug 2019 11:09:16 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <01fc01d556ce$69f73cc0$3de5b640$>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010703070505030004090004"
X-Originating-IP: []
X-ClientProxiedBy: ( To (
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(346002)(136003)(396003)(2980300002)(189003)(199004)(70586007)(16526019)(26005)(186003)(53936002)(386003)(53546011)(126002)(476003)(6246003)(486006)(33964004)(305945005)(76176011)(336012)(446003)(7736002)(11346002)(2616005)(478600001)(6916009)(5660300002)(2351001)(235185007)(65826007)(31686004)(5024004)(36756003)(14444005)(106002)(229853002)(568964002)(16586007)(316002)(2906002)(65956001)(65806001)(81166006)(22756006)(81156014)(40036005)(16576012)(6116002)(8936002)(70206006)(8676002)(356004)(22746008)(58126008)(71190400001)(31696002)(64126003)(44832011)(86362001)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0P189MB0754;; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: d4ed5141-cd6b-48b7-61e4-08d7254e145d
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(4709080)(1401327)(2017052603328)(7193020); SRVR:AM0P189MB0754;
X-MS-TrafficTypeDiagnostic: AM0P189MB0754:
X-Microsoft-Antispam-PRVS: <AM0P189MB0754BDFFCBDCA209BE35E9B882AB0@AM0P189MB0754.EURP189.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 013568035E
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: SCnHY2qgnNql+mUURpfiLCtFEJ+f6+VmFnHS+Qbsw0QRRkIRswu/YNOm4ObUwOj50F6ZuDCnJyP7gowxIGtZVaCpNYf8PBjP6pHDjeS2EB+iUuYiRvGenMCsSCefqpA2Yv8Lc+Rsd3iEIiN69FBB6jaZOi1a5MXseIm7x7CUYKA9HDAurqx0Z6LdBkUnNq2QqXBXWdm6zoNljpskCSOGnhwM7QoJZdqfg5bGo047YDawSJGQxmbZOKiskF3Is+t9/Zf+gAx1E74bakJGYILRfEizcE02ET4MN/GtfdblvadOCesN1tF/LPVE3KpYiVqytO2PoMOXMnna2UWV1hq/+D0IyWmDzEuCuulXHi17p0XEyAsBXO1NoCYTyWUmt49neSd4oXCi6iFtpgguVT+1ZhagCrXr+fsHmjh52rjSz5o=
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Aug 2019 09:09:17.4524 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d4ed5141-cd6b-48b7-61e4-08d7254e145d
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[]; Helo=[]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P189MB0754
Archived-At: <>
Subject: Re: [Ace] Keeping the same key identifier for groups
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Aug 2019 09:09:25 -0000

On 19/08/2019 22:40, Jim Schaad wrote:
> As Ludwig pointed out during the F2F, it makes far more sense to try and
> keep an entity using the same key identifier for as long as possible.  This
> is in part to make sure that signing keys do not need to be retrieved if
> they can be easily cached.  In looking at this deeper during my
> implementation I ended up with the following question:
> The way that I have set things up in my implementation it is simple to
> ensure that the same kid value is going to be used with the same CWT,
> however it might make more sense to use the signing key as the continuity
> identifier instead.  The issue that arises in this case is that there might
> be two different active CWT objects that are associated with the same
> signing key.  That is there are two CWTs but the same signing key was used
> while doing a join operation.   I already do some matching between different
> CWTs by assuming that if the bearer key in the CWT is the same then they are
> sufficiently equivalent to threat them as the same.  This lead to some
> interesting discussions in Montreal about if this meant just the "secret" or
> if it meant all of the elements provided by the AS which are used in the key
> derivation process.  (I have gone back and forth on this and currently am
> sitting on the "just the secret" side of the fence.)
> Does anyone have any opinions?
Could you please expand the explanation of your use case a bit?

Are you thinking of a scenario where someone would be using the 
counter-signature key from group-OSCORE as a proof-of-possession (pop) 
key in serveral CWTs?

What would these CWT authorize?

Why would an entity hold several CWTs for the same audience?

My stance on multiple CWTs linked to the same pop-key and for the same 
audience is that the latter one should supersede the previous ones.
Example: If you have a CWT authorizing A for audience Z and you now also 
need authorization B for audience Z, you should request a CWT for A+B 
for audience Z, that replaces your previous one.


Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51