[openpgp] Re: Outstanding questions re Key Replacement draft

Daniel Huigens <[email protected]>
Newsgroups gmane.ietf.openpgp
Message-ID <7S4J__B0xL5WhPj_0kwmJLlRS_EBhRDDfOa6tzGQyxl04zp3hNGSRc46wwtYX6RyWFprn9E0CzjrAchON8VaEJN2c5ldUfki-TRmHcVrlf8=@protonmail.com>
Hi all,

As I said in the meeting, saying that you don't want the fallback key
to be used for encryption sounds similar to revoking the fallback key
(or perhaps its encryption subkey). Therefore, that use case/problem
sounds out of scope and more in scope for draft-dkg-openpgp-revocation.

In other words my preference is option 0.

Best,
Daniel


On Wednesday, February 12th, 2025 at 13:43, Andrew Gallagher wrote:

> Hi, all.
> 
> The interim meeting did not reach a consensus on the issue of optional fallback encryption. To summarise, the basic options presented were:
> 
> 0. Fallback is always possible (no change to current draft)
> 1. Fallback to each particular original is possible IFF a flag is set in the target record (granular control, wire format change)
> 2. Fallback to all originals is possible if a flag is set in the class octet (all or nothing, no wire format change)
> 
> [!17] implements option 1 above, but is not yet merged.
> 
> A straw poll indicated that the attendees were evenly split between “no change”, “change” and “undecided”. We did not further explore which particular changes would be acceptable to the “change” contingent, and decided to come back to the list for further discussion.
> 
> If you voted for “change” in the meeting, it would be greatly appreciated if you could reply to this email stating which particular change you are in favour of, and why. If you voted for “no change” in the meeting, it would be similarly appreciated if you could note your objections.
> 
> In the meantime, I have opened a merge request to clarify the treatment of target records with unexpected lengths [!21]. This should ensure that any later change to the target record wire format will be backwards-compatible, without specifying or anticipating any particular change. IMO it is a sensible idea to specify a robust interpretation of unexpected record lengths whether these occur intentionally or not. If there are no objections to this clarification, I will merge it this week.
> 
> Thanks again,
> Andrew.
> 
> [!17] https://gitlab.com/andrewgdotcom/openpgp-replacementkey/-/merge_requests/17
> [!21] https://gitlab.com/andrewgdotcom/openpgp-replacementkey/-/merge_requests/21
> 
> _______________________________________________
> openpgp mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.