Re: [Ace] Text for KID in POP
Jim Schaad <ietf@augustcellars.com> Thu, 19 July 2018 00:07 UTC
Return-Path: <ietf@augustcellars.com>
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 773111311F5 for <ace@ietfa.amsl.com>; Wed, 18 Jul 2018 17:07:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 b8wYe7SOIOYC for <ace@ietfa.amsl.com>; Wed, 18 Jul 2018 17:07:10 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746461310D1 for <ace@ietf.org>; Wed, 18 Jul 2018 17:07:10 -0700 (PDT)
Received: from Jude (107.18.132.214) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 18 Jul 2018 17:03:35 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: ace@ietf.org
References: <03d401d41ee4$6db06300$49112900$@augustcellars.com>
In-Reply-To: <03d401d41ee4$6db06300$49112900$@augustcellars.com>
Date: Wed, 18 Jul 2018 20:07:01 -0400
Message-ID: <03fa01d41ef4$6c8cb040$45a610c0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQF7wd9kqDkalgiQlyGo6BYQltNQLKVGZOpQ
X-Originating-IP: [107.18.132.214]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/garcXUmWNHmEgZNS7FKT-AYBgMI>
Subject: Re: [Ace] Text for KID in POP
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.27
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: Thu, 19 Jul 2018 00:07:13 -0000
Should be circumscribed not circumcised although the first does echo my personal feelings. Jim > -----Original Message----- > From: Ace <ace-bounces@ietf.org> On Behalf Of Jim Schaad > Sent: Wednesday, July 18, 2018 6:13 PM > To: ace@ietf.org > Subject: [Ace] Text for KID in POP > > Add the following text to section 3.4. > > WARNING: The use of a Key ID in a POP CWT needs to be carefully circumcised. > Where the Key ID is not a cryptographic value derived from the key or where > all of the parties involved are not validating the cryptographic derivation, it is > possible to get into situations where the same Key ID is being used for multiple > keys. The implication of this, is that an RS may have multiple keys registered > with it that have the same Key ID and thus it does not know which key the new > CWT is to be associated with > > In the world of constrained IoT devices, there is frequently a restriction on the > size that a key id can be either because of table constraints or a desire to keep > message sizes small. These restrictions are going to protocol dependent. For > example, DTLS can use a key id of any size. > However, if the key is being used with COSE encrypted message then the length > of the key needs to be minimized and may have a limit as small as one byte. > The value of a key id is not always the same for both parties. When sending a > COSE encrypted message with a shared key, the key id may be different on > both sides of the conversation with the appropriate one being included in the > message based on the recipient of the message. > > For symmetric keys, the key ID is normally going to be generated by the CWT > issuer. This means that enforcing a rule that key ID values only match if CWTs > have the same issuer works for matching key ids between CWTs. In this case > the issuer can ensure that there are no collisions between currently active > symmetric keys for all CWTs that it has issued. This allows for an RS to use the > pair of issuer and key id for matching with existing keys. > > For asymmetric keys, the key ID value is normally going to be generated by the > client and thus the possibility of collisions is going to greatly increase. It would > be normal for all clients to start by assigning a key id of 0 given that key ids are > frequently only needed to be unique and meaningful to the client. This > problem can be addressed in a couple of different ways depending on how the > key id value is going to be used. > > * The issuer can assign a new unique key id the first time it sees the key, > depending on the protocol being used the new value may then need to be > transported to the presenter by the protocol used to issue CWTs. In this case > the rule of requiring that the issuer, key id pair be used for matching works. > > * The issuer can use a different confirmation method if a collision is > unavoidable. > > * Clients may decide not to use a CWT based on a created key identifier if it > does not fit the clients requirements. > > * If an issuer is going to issue confirmations of Key ID and is not going to > guarantee that serial number uniqueness is going to be preserved, the relying > party needs to have that information configured into it so that appropriate > action is going to be taken. > > > Jim > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace
- [Ace] Text for KID in POP Jim Schaad
- Re: [Ace] Text for KID in POP Jim Schaad