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