Draft: draft-ietf-mls-protocol

Commentary: 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  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 . 
 KeyPackages do n't support multiple signature schemes ? In what scenario is it beneficial ? 
 Ah , right . I think that was the case in the past , but you 're right , they do n't . Of course it 's always possible to just bundle a bunch of certificates , each supporting a different signature scheme and then treat that as your " Multi - Scheme Credential " in the grand scheme of things . However , if you end up rotating them a lot , where you have to sign them and potentially store the whole chain for a longer period of time , being able to support multiple signature schemes in only one credential means less overhead . 
 Credentials are stored in each group 's ratchet tree though , so you 're keeping a bunch of unnecessary key material in the group 's tree which everyone has to store 
 That 's fair . And it 's not something you have to do if you do n't want to . I 'm just proposing for MLS to support that type of Credential in general . 
 To support hybrid PQ / standard schemes at any point in the future , allowing for multiple schemes is reasonable ( in addition to the above arguments for it ) . Most applications probably will not use the feature , especially to start with , but providing support for just the option is not going to cause any of the problems noted . 
 PQ schemes can be used by switching the entire group to a new ciphersuite using those schemes . Requiring everybody in the group to store a bunch of unused key material is n't reasonable 
 The statement was not about PQ , but hybrid PQ / standard schemes . Those require use to two signature schemes , for which both types of keying material are used . 
 Then you need a ciphersuite that specifies a hybrid scheme . 
 It would be ideal to have a ciphersuite specifying a single hybrid scheme , but even that does not imply use of a single credential , unfortunately . In fact , hybrid schemes may rely on two separate credentials , with the ciphersuite specifying the hybrid algorithm for combining them . Since the " main " method of building a solo hybrid credential is under patent , there is also additional motivation for applications to use two . 
 I concur with  here . To be consistent with our earlier decisions to ( a ) keep KeyPackages to one ciphersuite and ( b ) include the signature algorithm in the ciphersuite , we should keep credentials to one signature algorithm as well . Propose closing this PR without merging . 
 Discussed at 2020 - 10 - 06 interim ,  : Re - add SignatureScheme enum , re - using the TLS signature schemes Clarify that the main job of a Credential is to provide a public key for verifying messages How it provides the credential might be different per credential type e.g. , in BasicCredential , it 's provided directly , X509Credential , have to parse the leaf certificate 
 LGTM with a couple nits .
Paragraph (version B):
Additionally, Credentials SHOULD specify the signature scheme
corresponding to each contained public key.
Paragraph (version A):
The second form considers authentication with respect to the sender,
meaning the group members can verify that a message originated from a
particular member of the group.  This property is provided by digital
signatures on the messages under identity keys.
Paragraph (version B):
Message encryption keys are derived via a hash ratchet, which
provides a form of forward secrecy: learning a message key does not
reveal previous message or root keys.  Post-compromise security is
provided by Commit operations, in which a new root key is generated
from the latest ratcheting tree.  If the adversary cannot derive the
updated root key after a Commit operation, it cannot compute any
derived secrets.