Time: Thursday Nov 7th 2024, 0930-1130 UTC, Liffey MR 2
Chairs: Daniel Kahn Gilmor and Stephen Farrell
Notetaker: Jonathan Hammell
Slides:
https://datatracker.ietf.org/doc/slides-121-openpgp-chair-slides/
Should it move to https://tests.openpgp.org?
DKG: Post your opinions on that to the mailing list.
Slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-openpgp-pqc-draft-update-00
Stephen Farrell: Does anyone have an opinion on the key derivation and
combiner
Quynh Dang: When derive keys from ML-KEM, then KMAC is good. But when
you include non-NIST approved secrets in a different area than the key
(e.g. additional data), then it would not be compliant. If you
concatenate the non-NIST approved secrets as the key input, then it
would be okay.
Stephen: I heard a similar discussion in LAMPS. When is NIST going to
approve X25519?
Quynh: NIST wants to focus on update to PQC and is not planning to do
more testing with X25519.
Stephen: Lack of blessing of X25519 is causing difficulties with PQ
migration for hybrid constructions.
Quynh: Will pass along that feedback.
Aron: If SP 800-56C is used instead, the key is put into the additional
data. Is that okay.
Quynh: If the ECDH key share is moved, then it would not violate the
compliance. SHA-256 would be fine, too.
Aron: Let's discuss on the mailing list to get confirmation on NIST
compliance.
Sophie Schmieg: Can we just use the LAMPS combiner given the
complexities of figuring out the NIST compliance?
Aron: Agree in principle on aligning on a single combiner, but when it
was brought to the CFRG for WG alignment, it made the process more
complex.
Sophie: It seems very challenging to get a NIST-approved combiner, we
may have to resort to approving a pure ML-KEM or X-Wing to get PQ
deployed quickly. It is the not ideal, but the simpliest way.
Aron: If it is just move the key share in the combiner, then we may be
able to reach compliance.
Stephen: If someone wants to propose removing the EC component of
hybrid, we'll have to have that as a dedicated discussion on the mailing
list.
John Gray: As one of the authors of the LAMPS composite drafts, we have
proposed doing all the hybrid work in the cryptographic library layer.
In OpenPGP, you are carrying the keys separately, so it isn't as quite
as seemless as composite.
Paul Wouters: Once this draft goes to IESG, the ADs will prefer that the
cryptographic approach is aligned with other WGs.
Aron: We are roughly aligned with LAMPS and both want to ensure
compliance.
Quynh: If X-Wing moves the constant from the front to the back, then
that construction would be compliant with SP 800-56C. NIST specifies
KDFs, but later on IETF and other SDOs have specified different KDFs.
NIST attempted to support those KDFs to the benefit of the community.
Alicja Kario: Agree with Sophie that we need both hybrid and pure PQ.
The other concern is the NIST validation queue. If we utilize NIST
elliptic curves with PQ, then that can be validated earlier than the PQ.
Aron: No NIST elliptic curves are specified in this draft. Those have
been split out to a separate draft.
Alicja: Also support a single approach to the combiner.
Mike Ounsworth: In the RATS WG, I have a draft that has long test
vectors. Once you have an RFC, you cannot add new links. The tools team
recommended pointing to a GitHub location where you can update test
vectors.
Aron: Some test vectors will still be included in the draft.
DKG: I agree with both inclusion and external referenced test vectors,
but recommend including a test vector for each algorithm. The RFCs don't
have a page limitation.
Aron: The SLH-DSA test vectors would result in the artifacts being 90%
of the draft.
DKG: That would be okay.
Stephen: The combiner discussion will need to be resolved. For ML-DSA
and SLH-DSA, there is not specification holding up the allocation of
code-points?
Aron: That is right.
John: Should we not align with the composite signatures in LAMPS?
Aron: OpenPGP does not have the non-separability issues from LAMPS.
John: As a software developer, it would result in two hybrid signature
implementations.
Aron: The signature algorithms are validated separately via the
cryptographic libraries, then the result is an AND.
Scott Fluhrer: LAMPS signs the hash of the message.
Falko Strenzke: There is no issue in OpenPGP requiring the LAMPS
complexity. Composite signatures requires too much from the
cryptographic library. It also requires introduction of OIDs into
OpenPGP.
John: You can still use the OpenPGP code-points. If composite signatures
are implemented in the library, the OpenPGP code-points can allow you to
call that.
Falko: It is only three lines of code in OpenPGP. Why should we try to
align on this? There are more severe issues in the AEAD approach of CMS,
and no one has attempted to align the AEAD approach between CMS and
OpenPGP.
Quynh: If this document, is there any use of pre-hash signatures?
Aron: No. Libraries will not support pre-hash. Discussion occurred on
the mailing list. OpenPGP already performs a hash prior to the signature
validation that includes other info. Therefore, there are no
cross-protocol attacks.
Deirdre Connolly: Composite KEMs approach is fine, but may be a bit of
overkill. KMAC inputs should be figured out in a FIPS compliant way.
X-Wing uses SHA-3 and allows combining inputs to be FIPS compliant. For
Composite signatures and alignment with LAMPS, it is apparent that
Composite signatures are more complex. Support separating Composite
signatures into a separate draft, and supporting pure ML-DSA.
Aron: This discussion occurred at IETF 119 and it was decided not to
split the draft between PQ KEMs and PQ signatures, and to do hybrid for
both. Nothing prevents the WG from doing pure PQ signatures in a
separate document.
Stephen: What is the IANA requirements for the code-points?
Aron: It is expert review.
Stephen: The chairs can ask for a provisional assignment. Don't need to
wait until the document is in the RFC Editor queue.
Quynh: Is it okay to use the NIST OIDs for the OpenPGP code-points?
Stephen: No OIDs are used in OpenPGP.
DKG: OpenPGP uses single octet identifiers.
Slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-openpgp-key-replacement-01
Daniel Huigens: The main use case for this draft is moving from v4 to
v6, so it is not critical to include the imprint. But is isn't
significant to include it, so no opinion as to whether it is included or
not.
DKG: Do you have an opinion on the preferred key server (PKS)?
Daniel: It is a bit late to include it when switching from an old key.
The recipient can find a new key wherever they found the old key. If you
are switching key servers, you'd have to update the old key on the old
key server. It is possible, but not sure it is needed.
Andrew: Should we overcomplicated this by including the PKS?
Poll: Are you okay with dropping all reference to the PKS from this
draft?
Result: 7 yes, 0 no, 6 no opinion
Poll: Are you okay with including PKS information in the record format?
Result: 3 yes, 3 no, 12 no opinion
Andrew: Seems that no one has objection to dropping PKS. It will
simplify the draft and implementations.
Quynh: From the poll, maybe it would be good to give people time to
think about these issues, then have a poll later. The no opinions seems
to indicate people may have not read the draft.
DKG: This is just giving feedback to the editor. The recommendation has
been to simplify. If you have concerns, speak up on the list.
Andrew: Regarding the fingerprint/imprint, there are four options for
going forward.
Poll: Do you object to Option 1: Keep fingerprint and imprint, no
deduplication?
Result: 0 yes, 7 no, 7 no opinion
Aron: Voted no opinion. In favour of having a fingerprint. Options are
all fine. But if had to choose, I'd prefer option 0.
DKG: We'll have to take this to the mailing list. If you have a
preference over Option 1, please post to the mailing list.
Andrew: When previously asking what people's preferred option is, we got
a plethera of responses. So this poll was useful to determining a
balanced approach that is acceptable to most people.
Justus Winter: Object to the name of the draft. It should be replacement
certificate, as that is visible to most people.
DKG: I agree that we should be thinking about the full workflow, which
includes the peer requesting new certificate. The replacement of the key
seems to be a small part of the workflow. So in favour of Justus's
proposal.
Andrew: There is guidance on how to consume the subpacket is in the
draft. If that could be improved, please make a recommendation on the
mailing list.
Slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-openpgp-persistent-symmetric-keys-00
DKG: How does this work given SOP contraints?
Daniel: Technically speaking, this is a hack; but will get to that in
the slides.
Daniel: Any opinion on the separability of the IV and ciphertext for
AEAD?
Andrew Gallagher: Do we need to worry about reserving such a large
portion of the registry for persisten symmetric key algorithms?
Daniel: Could reserve fewer symmetric key algorithms. Having 127 seems
like a lot. But I don't think it is a huge concern.
Andrew: Maybe we could reserve code-points above 127 and do a UTF-8
transformation with the subpacket length encoding. UTF-8 encoding is
self-synchronizing allowing inclusion in a trailer.
Daniel: Another option for IV separability is to define AEAD mode as
part of the algorithm ID. Didn't do that since we already have a
registry for AEAD algorithms.
Daniel: In the extract certs operation, for persistent symmetric keys
you should drop them because you cannot generate a certificate from
these private keys. For that operation, you do not need to necessarily
understand the algorithm.
DKG: If an implementation does not know about persistent symmetric keys,
and tries to handle this as a public key encoding, they may get out
something from extract certs. Will they be at risk?
Daniel: No, the implementation should do the correct thing if it knows
what part is the asymmetric algorithm. If it does it incorrectly and
sends the result to a peer, it will be meaningless.
Justus: There is a risk if you have a v4 secret key. If you don't
understand the public key algorithm, you do not know where the public
key ends and the secret key starts. A naive implementation may
accidentally include secret key bits. We should restrict to v6 keys
because there is an explicit octet count for the public key portion.
Andrew: Is that not the same risk you run for any v4 secret key?
Justus: Yes. But we are not introducing other new algorithms to v4.
Daniel: We could restrict to v6. But we still need to support SEIPDv1
and PSK3.
Falko Strenzke: Understand the impact of PQC for email, but for other
purposes the overhead may not be relevant.
Daniel: Yes, it depends on the use case.
Andrew: I don't think this applies to key replacement. There is no
reason to put it in the certificate. It is entirely a local decision.
Justus: Deterministically generate fingerprint(?) from the secret is
desireable to some.
Daniel: I thought it wasn't necessary for AEAD, because the fingerprint
includes other info.
Justus: This would be a pain to implement. We may encounter a locked
public key. This would be a problem for our API.
Daniel: For encrypt/verify our implementation was already able to pass a
secret key. We would throw an error if the key is locked. You have to
explicitly unlock it.
Falko: Deterministic generation may be useful for communication between
two parties. Knowing a private key is bound to a public key would be
useful.
Slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-openpgp-stateless-openpgp-00
Not presented due to lack of session time.
DKG: If you are an implementer or consumer, please read the draft.
DKG: Will schedule an interim meeting to cover the remaining material.