Open PGP WG IETF 122

Chairs:

Scribe(s):
Phillip Hallam-Baker
Benson Muite (secondary)

Agenda:

[Slide presentation]

Daniel Huigens: We don't allow import of v6 yet because there is
insufficient support among other clients.

Andrew Gallagher: Results for Hockeypuck are not surprising as the code
assumes any non v3 key is v4. Surprised lookup works, looking to fix.
Working on Go implementation. Looking for contributors with rust
knowledge for second implementation.

[Slide presentation]
pg. 4
Scott Fluhrer: Incorrect transformations
SF: CNSA require MLKEM 1024 and nothing else
FS: Changes in response to feedback
SF: CNSA 2.0 check this
FS: Will check
pg. 5 Hedged variants for SLH-DSA

Scott Fluhrer: Don't need to make a distinction on hedged variant
because they are completely interoperable. Verifier can't tell the
difference.

pg. 8
PHB: Export from HSM not used in practice, need not specify
FS: Other people said similar on list. Some HSMs do export, may need to
generate a key?

Quynh Dang: These all look good to me. If you care about CNSA 2.0, best
talk to them.

Scott Fluhrer: If you case about CNSA 2.0 compliance, they have
documented in an Internet Draft. [SF in chat: seems they did not write
a draft but they are very insistent on ML-DSA-87/ML-KEM-1024 only.]

JW: Ok for WGLC.

[Slide presentation]

DG: Not convinced this is worth doing. Most implementations don't use
the communication/storage split. Has to do with the duration,
communications only needs to last until other party receives, storage
has to last. Might want to reconsider

PHB: How are these keys being used? Do not like encrypting more than one
chunk of data under a specific key with fragile constructions. Good to
use a different key each time you encrypt, would prefer key sources.

DH: Yes there is a KDF. Session keys. Keep two steps session key for
data, session key encrypted using a key derived from persistent
symmetric key.

AG: If distinguishing between 2 keys, when would one invalidate a
signature.

DH: Main goal is not to invalidate signature, but to indicate which key
to use. Eg. when sending use asymmentric key.

AG: If you are not going to invalidate a signature, do not need to
publish. Could just be a parameter.

DH: Yes, could be a parameter. There is a benefit to not putting key
data on a symmetric siging key.

AG: Skeptical,

JW: Do explicitly support distinction between signing and storage use
cases. Key flags are a good way to signal intent as a key owner.

Stephen Farrell: Speed up out of time.

[Slide presentation]

Stephen Farrell: Is it ok to have PQ first in WGLC?
AG: Yes, that is ok.

[Slide presentation]

JW: Unclear about what a detached revocation is.

AG: Old v4 not like the v6

JW: Please don't do that.

AG: Legacy clients do not support v4 signatures without a userid.

JW: Take offline.

DG: If this is HKP2, legacy doesn't matter.

AG: We may have to live with it due to behavior of existing clients.

[Slide presentation]

DG: Did no see a formal call for adoption.

AG: Deferred to list.

AG: Andrew Gallagher
DH: Daniel Huigens
FS: Falko Strenzke
JW: Justus Winter