Re: [openpgp] Call for adoption of draft-gallagher-openpgp-replacementkey

[Andrew Gallagher <[e-mail]>]

On 19 Apr 2024, at 08:30, Simon Josefsson <simon=[e-mail]> wrote:
> 
> Signed PGP part
> Daniel Kahn Gillmor <[e-mail]> writes:
> 
>> My understanding is that the editors proposed some changes to address
>> Simon's concerns about scope and use patterns, but haven't released a
>> new draft with those changes.  Those proposed changes are here:
>> 
>>  https://gitlab.com/andrewgdotcom/draft-gallagher-openpgp-replacementkey/-/merge_requests/2/diffs
> 
> Those changes seems nice, but my basic question still doesn't seem to
> have a clear answer (at least that I've been able to understand): what
> is the problem this draft is intended to solve?

I’ve attempted to flesh out the introduction even more in the most recent commit, although I’m struggling to identify where the lack of clarity arises. This is probably just me being unable to see the forest for the trees, having been inside the draft for too long.

> Two rough outlines of problem statements:
> 
>   1) replace human written key transition documents
> 
>   2) enable automatic non-interactive upgrades to PQ keys
> 
> Are both these problems in scope?  Are other problems in scope?  Is
> there some problem that we know is not in scope?

Yes and No-ish, to the first two questions. I would widen option 2 to include non-PQ replacement keys, but the principle is the same. I have specifically bulletpointed these in the latest introduction.

Not sure how to answer the third question, but if there is any potential confusion then suggestions for explicit exclusion would be welcome.

> There is a bunch of different modifications I can think of for this
> draft but have hesitated to suggest.

Please suggest them anyway! The process of asking may help us find the root cause of the confusion.

> Without understanding the problem
> we are trying to solve, it is hard to evaluate if a suggested
> modification is a good idea or not.  The two goals 1) and 2) may lead to
> conflicting requirements on the protocol.  This make me unable to feel
> that I can contribute anything other than raising this question.

I don’t believe that use cases 1 and 2 are in conflict, I think they are clearly distinguished by whether the old key remains valid or is expired/revoked. A receiving implementation that first validates both keys and then orders them according to the replacement key indirection will behave sensibly in either case.

A