[MLS] Agile Credentials and Signature Keys

Konrad Kohbrok <konrad.kohbrok@datashrine.de> Wed, 16 September 2020 17:01 UTC

Return-Path: <konrad.kohbrok@datashrine.de>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93113A0CA1 for <mls@ietfa.amsl.com>; Wed, 16 Sep 2020 10:01:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 wQ1MMhdnT4u5 for <mls@ietfa.amsl.com>; Wed, 16 Sep 2020 10:01:08 -0700 (PDT)
Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5263A0BC7 for <mls@ietf.org>; Wed, 16 Sep 2020 10:01:07 -0700 (PDT)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4Bs5w11Nn8zKmgK for <mls@ietf.org>; Wed, 16 Sep 2020 19:01:05 +0200 (CEST)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter03.heinlein-hosting.de (spamfilter03.heinlein-hosting.de [80.241.56.117]) (amavisd-new, port 10030) with ESMTP id oYUDaRwBTO0o for <mls@ietf.org>; Wed, 16 Sep 2020 19:01:01 +0200 (CEST)
Date: Wed, 16 Sep 2020 19:01:01 +0200 (CEST)
From: Konrad Kohbrok <konrad.kohbrok@datashrine.de>
To: "mls@ietf.org" <mls@ietf.org>
Message-ID: <1808963197.6646.1600275661235@office.mailbox.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_6645_1437582045.1600275661231"
X-Priority: 3
Importance: Normal
X-MBO-SPAM-Probability:
X-Rspamd-Score: -1.30 / 15.00 / 15.00
X-Rspamd-Queue-Id: 310791704
X-Rspamd-UID: 2fd0ac
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/_zCQCGNZf_1Po3Oj11gN74Ko6Uc>
Subject: [MLS] Agile Credentials and Signature Keys
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2020 17:01:10 -0000

Hi everyone,

*puts Wire hat on* [0]

I made a pass over the Credentials and KeyPackages Sections and I would like to propose a few changes.

1. Make Agile Credentials possible

The credentials we have defined at the moment only contain a single public key and no information regarding what signature scheme that keypair works with (even though the Spec actually says it should include the signature scheme as well).

It would be nice, however, to support potential CredentialTypes that, similar to KeyPackages, include multiple supported signature schemes, each accompanied by a corresponding public key.

The Key that should be used in any given group is then determined by the CipherSuite of the group (which includes a Signature Scheme). When choosing a KeyPackage of a new member, it has to be one that contains a Credential which supports that Signature Scheme.

Note, that I'm not suggesting that this be the case in all Credentials, or even that we change the BasicCredential.

I understand that it's possible to have multiple credentials per identity, but in some authentication settings it can be beneficial to have a 1-to-1 mapping between Credential and identity.

2. Rename Identity Keys to Signature Keys

The public key in a credential is introduced without a special name and the field in the Basic Credential is currently called public_key, which is not very expressive. A few paragraphs below, it is referenced as "Identity Key" or simply "Identity", which is a bit misleading, as Credentials are supposed to contain an additional "identity" which is not the key.

I propose we clear up the terminology a bit here and refer to the public key contained in a Credential as "Signature Key".

3. Remove the requirement for a Signature/Identity Key to be "long-term" and explicitly forbid changing identity.

Rotating keys is important and in some cases, Signature Keys are not going to be very "long-term". Instead they're going to be rotated periodically.

I thus propose we simply remove the assumption that Signature Keys are of a "long-term" nature (or otherwise "long-lived").

I filed three PRs outlining the changes detailed above. Please let me know what your thoughts are and/or if I missed anything.

Cheers,
Konrad

[0] Not to be confused with Tinfoil hat!