[openpgp] Re: I-D Action: draft-ietf-openpgp-replacementkey-02.txt

[Johannes Roth <[e-mail]>]

thanks for addressing my points and for creating the issues. We can 
discuss the details there and I want to keep it more high level with 
this email. After reading Daniel's and your reply, my suggestions for 
the chain issue are:

1) Discourage generating chains and discourage following chains (SHOULD 
NOT). This makes reasoning about replacements simpler. That would mean, 
we will always have a simple graph with an N-to-1 structure where N 
certificates have a forward link to 1 certificate and this one points 
back to the N other certificates (or a subset). This does not follow in 
that simplicity and clarity from reading the draft but is anyway the 
"natural structure" that seems to be intended if I understood it 
correctly. Further, the process of updating the forward and inverse 
replacement packets when introducing a new replacement key should be 
outlined: you update all certificates to obtain a new N-to-1 structure 
and re-publish all certificates with the new signatures.

2) The draft should clarify that if you find a chain, the most likely 
causes are a) a malicious entity wants to trick you into a loop or b) 
you have an outdated certificate pointing to a newer certificate (that 
in the mean time got replaced as well).

3) The draft should give guidance what to do when you encounter a chain 
(e.g. due to an outdated certificate with an old replacement key 
subpacket). A simple approach that helps avoiding encountering chains at 
all would be: Update the current certificate first (if possible) to 
obtain the newest replacement key subpacket which should then directly 
point you to the correct replacement certificate. If not the 
implementation SHOULD stop following the chain to find a replacement 
certificate. It MAY follow the chain, e.g., if the current certificate 
is revoked and there is no valid alternative to use. It MUST ensure a 
proper loop prevention in that case.

Making these points explicit in the draft would help with clarity. The 
goal of the draft is simple: Specify a replacement key. But we now have 
the (useful) concepts of forward/backward links, key equivalency, and 
fallback certificates. Mixed in with this are some intricacies regarding 
revocation and trust. Further there is the problem that you may have 
some new and some old versions of certificates (destroying the graph 
structure s.t. either no replacement or not the newest replacement is 
found).
Therefore, everything should be nailed down as much as possible and all 
edge cases should be covered by the draft and whereever there are 
multiple sensible options (e.g. yes/no to stickiness, yes/no to 
following a forward replacement link, ...), there should be some guidance.

I will try to give some input in the Gitlab issues and hope it helps.

- Johannes