I cannot post to the Design Team list, so I post it on this mailing list:
Regarding the discussion around multiple encryption-capable subkeys, I
would like to make the following remarks on behalf of the project
PQC@Thunderbird. At IETF 113 we presented our ongoing project for the
standardisation of PQC in OpenPGP. Well aware that this is not in the
scope of the crypto refresh, we still want to make a comment on the
signalling mechanism for a preferred usage of multiple encryption
subkeys, as it is currently being discussed by the Design Team. The
reason is that a related issue will in our view most likely also arise
in the context of multi-algorithm encryption. What we refer to as
multi-algorithm encryption is often also referred to as hybrid
encryption and means the combined encryption with two public key
encryption schemes in such a way, that the combined scheme is only
broken when both constituent schemes are broken. "Both constituent
schemes" will typically be a classical scheme and a PQC scheme. For such
a combination of two public-key encryption operations, an algorithm for
the derivation of the session key from the input-keys encrypted in each
PKESK is also needed. Proposals for this exist and typically involve the
use of a KDF.
So far to introduce the background. Now we come to the point were the
signalling of the intended subkey usage matters in this approach: If a
user wants to restrict others to only sending him encrypted messages
using multi-algorithm encryption with two specific encryption subkeys
from his keyring in combination – i.e. not allowing them to use either
of the two keys in the default "single-algorithm" manner, the question
arises
* how to signal to the sender that a certain encryption subkey must only
be used in a multi-algorithm combination with another (specific) subkey
from the same keyring (e.g. to indicate: "use this PQC key only in
multi-algorithm encryption together with ECDH")?
In our understanding this problem could be solved by a signalling
mechanism analogous to the one discussed now regarding parallel
encryption. The mechanism would have to be enhanced by a flag signalling
the intended use of a key in the multi-algorithm context only.
We just want to provide this piece of information for the case it
matters for the ongoing discussion in Design Team.
Best regards,
Falko
--
MTG AG
Dr. Falko Strenzke
Executive System Architect
Phone: +49 6151 8000-24
E-Mail: falko(_dot_)strenzke(_at_)mtg(_dot_)de
Web: www.mtg.de
MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde
This email may contain confidential and/or privileged information. If
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email. Unauthorised
copying or distribution of this email is not permitted.
Data protection information: www.mtg.de/en/privacy-policy
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp