Re: [MLS] Agile Credentials and Signature Keys

["Hale, Britta (CIV)" <[e-mail]>]

Allowing (1) certainly makes sense in the interest of allowing for hybrid PQ certs, should they become desired. There are also some backwards compatibility use cases where hybrid certs for 2 standard algorithms may be advantageous. Limiting a credential to only containing one public key also does not gain any particular advantage, so this changes seems solid on all sides. The corresponding signature scheme should certainly be defined within the credential to prevent potential creativity in misuse (good catch on noticing that it is currently not).

Given that signature keys are actually per group and not necessarily identity keys at all (i.e. across all groups Alice is in), I also support (2). “Identity keys” is a misnomer when comparing their use in the current specification and it would be good to fix that. Since MLS is designed without the use of group signature keys (i.e. a “group signing” algorithm for hiding the signer within the group) or other such types/uses of signature keys, we do not need to worry about collision in terminology when renaming “identity keys” to “signature keys”.


-- Britta



From: MLS <[e-mail]> on behalf of Konrad Kohbrok <[e-mail]>
Date: Wednesday, September 16, 2020 at 10:01 AM
To: "[e-mail]" <[e-mail]>
Subject: [MLS] Agile Credentials and Signature Keys

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!