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

[Andrew Gallagher <[e-mail]>]

Hi, Johannes.

Thanks for the thorough examination! I’ll try to address each of your points below (please remind me if I have missed something).

> I think you are missing a combined third case where a chain of forward replacements (like A -> B -> C -> ...) ends in one certificate that has an inverse replacement subpacket (this achieves key equivalency at most between the last two certificates). If this is not intended, then it should be written in the document, or did I miss it?

Correct, the last two certificates that have the equivalence binding are equivalent to each other, and the other certificates in the chain have no equivalence relationship. I think this interpretation follows naturally though, and doesn’t need to be explicitly clarified - but if anyone has a suggestion for wording, please feel free to propose it. :-)

> Suggestion: Clarify what transitivity means since it can easily lead to wrong assumptions.

Yes, this could be better clarified. I have opened a ticket: https://gitlab.com/andrewgdotcom/openpgp-replacementkey/-/issues/29

> t0: Key A is created.
> t1: Key B is created as a replacement for A and key A is updated to include a forward replacement, and key B is created with an inverse replacement for A.
> t2: Key C is created and replaces both A and B (inverse replacement). Keys A and B are updated with a new forward replacement to C.
> 
> Case 2: An implementation has B and C at time t2 but A is at version t1.
> Now B and C are equal, but A is not equal to anything. If we assume that forward replacements are also transitive, then we have: A is replaced by C due to transitivity of forward replacements and thus A equals C. Due to transitivity of key equivalence A also equals B.

This effectively sidesteps the requirement for an equivalence binding, which is that both key owners must consent. If B has been updated so that there is no equivalence relationship between it and A, then we cannot assume that B still consents to the relationship. But this is perhaps too simplistic.

This is one specific example of a broader concern: are equivalence relationships “sticky”? i.e. if A and B had an equivalence relationship in the past, and a correspondent used their pre-existing trust in A to derive a trust value for B, what happens if the equivalence relationship is broken in the future? This can happen for many reasons - updating the replacement key subpacket in B is only one way, the key owner could also hard-revoke A or make a new self-sig on it without the subpacket. Should correspondents who relied on equivalence at a point in the past retain a memory of that equivalence calculation even after facts change? The “A is subsequently hard revoked” scenario is particularly tricky.

I have opened a ticket: https://gitlab.com/andrewgdotcom/openpgp-replacementkey/-/issues/31

> Suggestion: As you suggest put a limit on how many replacements are followed or put in a proper loop detection. Possibly there are more solutions.
...
> 1) What about chains of forward replacements? It should be clarified that we iterate until the end of the chain (where we find an inverse replacement subpacket or no replacement subpacket at all). Going from the end of the chain, the subkeys can be chosen as described. Note that you can have key equivalency between the replacement certificate and a certificate in the fallback list that belongs to another chain than the one you followed to the replacement certificate.

I would RECOMMEND a short limit per invocation, preferably 1. If it takes N encrypted messages to iterate to the end of a chain of length N, then that’s a reasonable price to pay for stability IMO. In such a case, we don’t need to consider transitivity explicitly,

Ticket here: https://gitlab.com/andrewgdotcom/openpgp-replacementkey/-/issues/28

> 2) It is mentioned that other means than key equivalency can be used to validate the replacement certificate. However, when going through the list of original/fallback certificates that the replacement certificate lists, only key equivalency is considered. Wouldn't it make sense to validate them by some other means as well (if possible)? If successful, we can use the fallback even without an equivalency binding. If that is not intended, the draft should state why.

This was not explicitly considered during the design process. Fallback is effectively a bonus feature of key equivalency that we get for free due to the inverse subpacket construction. The original design only considered forward relationships and not inverse, so non-equivalent fallback relationships did not arise, and nobody thought to specify them since.

When would a key owner wish to declare such a standalone fallback? Do we need to support this use case, or would it just be for theoretical symmetry?

> 3) What if the replacement certificate points to a fallback certificate that in turn claims it is replaced by yet another certificate (instead of the currently processed replacement certificate)? This can happen in legitimate cases, for example when the version of the newly fetched fallback certificate is newer than the replacement certificate that we found and thus points to an even newer replacement certificate. Note again, that not all fallback certificates must belong to the chain you followed, so you might fetch this one at a different time than the ones you already have.

I think this is a convincing argument against following unpaired fallback references. ;-)

> 4) This might be obvious, but subkeys of soft-revoked certificates should not be used. Might not hurt to explicitly state how implementations should handle this.

Personally I think this is obvious, but I wouldn’t object to adding a clarification. Any suggestions for wording?

> B might want to state "I am a replacement for A". But in doing so, B forms an equivalence binding with A and legitimates the use of A's subkeys. Do we need a possibility to state "I replace this key but I don't want anyone to use it as fallback"?

Yes, this is an interesting use case that we didn’t think of. As you say, we know that in practice we cannot assume that offline/escrowed revocation certs always exist, so any method of conveying the same information by other means deserves serious consideration.

If we specified such a flag, it would need to be located inside each target record, not in the class octet, so that setting it on one original would not prevent fallback to any others. Would it prevent both encryption and signature verification? Could it be abused?

I have opened a ticket: https://gitlab.com/andrewgdotcom/openpgp-replacementkey/-/issues/30

A