falko-strenzke
commented
1 year ago Meeting 2023-01-19:
- Aron: was difficult to implement. At which level should this be done: application level or library level? Check for different keys how / where? use primary identity as identification ?
- Andreas: should at least inform the user
- Aron: then not "MUST". In go we cannot model warnings, only errors
- Andreas: when allowing users to use some primary identity ...
- Aron: concept of linked keys with same primary identity, an impl. should only encrypt to one of these. Could be seen as task for application or for library.
- Aron: keep statement but give guidance for how to do it. Define standard behaviour
- Andreas: Aron, would you come up with a proposal?
- Aron: yes, but not clear so far. Key pointing to another key as newer then no false positive.
- Stavros: is parallel public key encryption done often?
- Aron: can be done by the library if it receives the key information
- Stavros: migration sec says prefer PQC
- Aron: but not MUST, but if using PQC encryption "use only PQC"
- Stavros: talking about the same certificate:
- Aron: not necessarily. Cannot safely decide whether 2 certs belong to the same user. thus false positives can happen. Should not stop encryption.
- Stavros: 2 statements about this: this one and 7.1 migration considerations. There: SHOULD prefer PQC certificate.
- Aron: reference to this statement in migrations considerations.
- Falko: make this statmt a SHOULD?
- Aron: keep it, but give guidance
- Stavros: can always make PQC cert
- Falko: but what if no end date in old
- Aron: will make proposal
wussler
The text contains the following statement:
This should be expanded to ensure what to check when encrypting to the same recipient. Should it be the primary identity?