Meeting: Mon 22nd July 2024, 0930 - 1130 (local) / 1630 - 1830 (UTC)
Notetakers: Jonathan Hammell
Slides:
https://datatracker.ietf.org/meeting/120/materials/slides-120-openpgp-openpgp-chair-slides-00
Crypto-refresh is in Auth48. Will be RFC 9580 once published.
Presenter: Patrick Brunschwig
DKG: Is there another Summit coming up?
Patrick: Planning for April 2025. Anyone is welcome. An invitation will
be sent to the WG mailing list.
Slides:
https://datatracker.ietf.org/meeting/120/materials/slides-120-openpgp-pqc-draft-update-00
Presenter: Aron Wussler
Mike Ounsworth: The issue with the provisional KEM combiner will come up
in LAMPS also. Do we want to wait for the CFRG?
Aron: I would like to move faster if the CFRG outcome will be years. It
would be nice to have a KEM combiner shared across other systems, but it
is a small part of implementations.
Mike: I tend to agree, but we should make this decision intentionally.
Aron: We have a security analysis in the draft.
Quynh Dang: There is a possibility that CFRG endorsement could be
combined with NIST compliance. I recommend being patient.
Aron: As a summary, the CFRG has intention to "standardize" a KEM
combiner. Not all protocols require the same safety properties. Would
like to see what happens in the CFRG session.
Stephen: CFRG is a research group and does not standardize mechanisms.
The CFRG has a KEM Combiner Design Team. At what point do we want to fix
the KEM combiner for OpenPGP? The time to make that decision is not
right now.
DKG: We have not designed OpenPGP to require use of a generic KEM
combiner. We can have multiple code-points.
Mike: I like this and support this direction. If the research later
implies addition binding would be helpful, we can add it later.
No concerns raised with plan on binding to v6 in the next draft (~2
months from now).
Mike (in chat, read aloud): Is the OpenPGP WG ready to assign a
milestore for publishing the PQC RFC?
Aron: Having a strict deadline following publication of NIST standards
is not feasible. It would be nice to have stability by end of year
because some contributers have funding that expires.
Stephen: Goal of stability by end of year is acknowledged, but I think
it may be optimistic.
Presenter: Quynh Dang
DKG: There is a traditional OpenPGP signature process, is that what you
are using?
Quynh: Yes.
DKG: Are you binding the signature scheme to the digest?
Falko: We'll have to check that.
Quynh: There are two different signatures due to the pre-hash step.
Falko: In OpenPGP we are always checking the signature algorithm ID. You
input H(m) to your signature function. It is minor in order to be
compliant with the way OpenPGP functions.
Daniel Huigens: In PureEdDSA the hash is not the same as the hash of the
message. For the crypto-refresh, it is important to specify the correct
one. I don't think we can re-interpret that as using HashEdDSA on the
message.
Stephen: Please take this to the mailing list because it requires more
investigation on the APIs.
Stephen: At one point do you want to ask for WG adoption.
Falko: Ready to call for adoption now. Work can continue to address the
minor issues under discussion.
Stephen: If the WG decides to adopt this, then the WG will decide the
direction of the remaining issues. Let's give people a little more time
to read it. Then, in a while, the chairs will issue an call for
adoption.
Daniel: Who really needs this? The non-quantum algorithms are just a
fallback. Since a NIST-approved PQC alg combined with any non-quantum
algorithm will still be FIPS compliant.
Quynh: Good question. There are a lot of places where implementations
have NIST curves and not X25519/X448. Beyond the web, there is a lot of
P-256 use. No reason to not allow both.
Daniel: X25519 is quite widely deployed in OpenPGP implementations.
Quynh: Interest in deploying good crypto solutions. More good solutions
the better.
Daniel: There is a down-side to more options for implementations,
testing, etc.
Falko: I believe that Brainpool curves are the only ones approved for
use by BSI in Germany. Therefore, this is required for some.
Stephen: This comes up often. If the WG decides not to adopt,
code-points can still be assigned.
Quynh: There is benefit for implementers to support one of these cipher
suites.
DKG: If you say MAY, then there is less pressure for implementers.
Stephen: Discussion of WG adoption will occur in the not-to-distant
future.
Presenter: Daniel Huigens
DKG: Is anyone trying to implement this?
Falko: It is interesting to have this feature because symmetric
encryption is quantum-resistant. Does this allow the scenario for
symmetric encryption from Alice to Bob?
Daniel: This was not intended for communication. But it is common to use
asymmetric crypto for encrypting to yourself.
Falko: Would it be useful to include this use case so that you do not
need to rely upon public key crypto?
Daniel: I think that is reasonable. Currently the draft doesn't say much
about intended use cases.
Falko: If it is a communication algorithm, I may be interested in
implementing it.
Andrew Gallagher: If we don't envision using this for Alice to Bob
usage. Is there a use case that helps reducing key distribution issues
with key servers.
Daniel: I agree this isn't relevant with key servers.
DKG: There may need to be interoperability between implementations. How
do you envision testing this?
Daniel: There is some testing. But if you wish to test full round trip,
you'll need to send the password.
DKG: If you have ideas on how to solve that, merge requests are welcome.
Slides:
https://datatracker.ietf.org/meeting/120/materials/slides-120-openpgp-replacement-keys-00
Presenter: Andrew Gallagher
Justus Winter: There is complexity with allowing use of SHA-1
replacements.
Andrew: The question is whether we need the generic mechanism. SHA-1 is
a potential concern, but there may be future concerns with other hash
functions. The design may be slightly over-engineered to give
flexibility. Agree that there is redundancy in the proposed solution and
that does come at a price.
DKG: This is now WG adopted and the WG can request changes to the
design.
DKG: Can you explain why there is a version number in the subpacket?
Andrew: Historically, there has been a few instances of subpackets with
version numbers in them. Not sure if it is required. Will defer to the
WG. If the WG wants to use separate code-points, no concerns with that.
Stephen: Since this was mentioned as a migration tool, what is the best
way for progressing with this work? Do we need an interim meeting to
discussion this?
Aron: I am biased, but I like the idea of having a discussion on the
version. Having an interim between IETFs would be good.
Andrew: I would be happy to have that discussion. The high level context
would benefit from more discussion
DKG (Chair): Will schedule an interim in next couple months and send
notice to the mailing list.
Presenter: Daniel Huigens
DKG: Binding to hash algorithm length makes sense for sending, but not
sure how to handle it on receiving end if it doesn't match.
Daniel: Current draft does not say much about it. Copied from v6
salting. Propose doing the same thing as there.
DKG: If we do the same thing, then implementations that do not
understand this will accept and those that do not will reject. This
seems strange.
Daniel: Agreed. Perhaps we should do something about that.
Stephen: Let's continue discussion on the list to see what people think
about future adoption.
Chairs: Interim meeting will be scheduled before IETF 121 in Dublin.