Subject: [Openpgp-dt] 2022-01-19 design team notes

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Jan 2022 15:59:47 +0000

# OpenPGP Design Team Meeting

2022-01-19

Present:
dkg
justus
stephen
gniibe
daniel h
paul

# Agenda

We jumped about a bit and addressed some but not all of these

## v5 sig simplification (!86 and #49)
(dkg: open for a while, written in response to an open bug report, 
re-written 3 weeks ago to address concerns raised in the DT, but little 
subsequent review; blocking other discussion)
not discussed

## padding (!118 and #55)
(dkg: do we want to say padding can go anywhere?  or do we want to say 
specifically where padding should be placed?)
justus: anywhere (for rx) but not a big deal
dkg: add "while this can show up anywhere, implementations SHOULD try 
place 'em in <these> locations, unless there's external information that 
the receiver can effectively discard padding from anywhere" IOW, 
"<these> are the safe places to put pading"
daniel H: do we know if implementations will choke on <not-these>?
justus: maybe
ACTION: dkg to add sentence along those lines, then merge

## keys-sigs versioning, one-pass sig versioning, fingerprint versioning 
(!120 and #68) HARD
(dkg: asymmetries between signing and encryption for version indicators)

## AEAD variations (!121/!122/!127) HARD
(dkg: additional possible option: new version number of SEIPD)
daniel H: I closed !121; key derivation justus proposed seems like an 
alternative to !101 - maybe we revert !101 and then merge !122?
daniel H: !128 reverts !101; maybe merge !128, then !127 and then !122?
dkg: gotta read !128 but seems sensible
justus: likes the idea
paul: ok with it
stephen: confused:-)
gniibe: !127, !128 ok, !122 needs more consideration
dkg asks about AAD and inputs to HKDF as well
ACTION: justus will update !122 including AEAD alg etc. in AAD for key 
derivation, then merge !128, !127 and !122 in that order
dkg: withdraws SEIPD v2 suggestion so we progress
justus: IV ok starting with zero?
paul: IPsec did something similar

## v5 Fingerprint usability (!123, !106 and #44)
(dkg: do we want both !123 and !106?  is this sufficient guidance?)
daniel H: disliked how !106 said collision resistance wasn't important 
as that may not always be correct, but if application knows collision 
resistance isn't important then it may be ok
justus and dkg do not want shorter FPs
dkg: we want to compare primary key to FP without having to worry about 
collisions;
dkg: wondering about subkeys - can a bad actor convince someone to 
accept a colliding subkey into their keyring? (e.g. company/role 
subkey), in that case referring to subkeys by keyid may be risky
justus: similarly, if you accept a primary key from elsewhere, it could 
collide
dkg: binding of subkey to primary is ok as it uses full FP
justus: existing tooling displays subkey FPs, what should they do?
dkg: display full FP (if for debug purposes)
...usability discussion...
We seem to be happy(ish) with !123
dkg proposes masochism: merge !123 and a !106 with this added: 
"implementations that allow users to compare identifiers for v5 primary 
keys should accept and generate 96-bit(?) key ids for usability purposes"
daniel H: do we know (e.g. via ref to publication) that 96 bits of 
pre-image resistance is enough?
justus: seems more than enough
paul: why 96? (because shorter is "more usable")
more discussion needed...

## session key salting/reply to all (!122 and #57)
(dkg: does the DT want this feature? is it in scope? could it cause 
problems?)
This is resolved in discussion above wrt !122

## salting v5 signatures (!91)
(dkg: does the DT want this feature? is it in scope? could it cause 
problems?)
not discussed

As usual we're asking Paul to merge MRs with >1 approval and no thumbs-down
dkg: @gniibe, @justus: please review !86, we're starting to assume it's 
been merged
justus: PBKDF2 uncontroversial? #75
justus: #63, incompatibility with existing smartcards?
justus and gniibe discuss identifying v5 keys on smartcards by (96-bit) 
keyID instead of full 256-bit v5 fingerprint.  gniibe to run this 
suggestion by other smartcard folks.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 25 Jan 2022 20:05:19 -0500

> ACTION: dkg to add sentence along those lines, then merge

I've just now taken the above action, sorry for the delay.

If y'all have a chance to review it and comment on !118 (re-approving if
you do approve) that would be great!

    --dkg