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

[Johannes Roth <[e-mail]>]

thanks for clarifying.

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?
I have some feedback to different aspects of the draft, apologies for 
the lengthy mail.


# Transitivity of Key Equivalence

I think for most here it's clear how key equivalence transitivity works. 
However, I fear it's currently described in a very misleading way. The 
draft states "if A is equivalent to B and B is equivalent to C, then A 
is equivalent to C."

What people (at least me) intuitively think is that A is replaced by B 
(forward) and B replaces A (inverse) and (perhaps at a later time) B is 
replaced by C (forward) and C replaces B (inverse). This cannot be due 
to the graph topology restrictions, as you already point out in your 
previous mail.

What the (only) correct interpretation is: A and C are both replaced by 
B and B has an inverse replacement for both. In that case, A equals C 
due to transitivity.

In the current draft, pairwise equivalency between two or more 
certificates is only achieved if a set of certificates point to the same 
replacement certificate and that one points back at all the others. Then 
due to transitivity, each key is equivalent to any of other keys.

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


# Transitivity of Forward Replacements

I think it makes sense to think about the following scenario with three 
different points in time:

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 1: An implementation has all three certificates at time t2.
Everything works out as expected. A and C are equal and B and C are 
equal, this directly follows from the definition. A and B are also equal 
due to transitivity.

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.

In practice one cannot always guarantee that all certificates are 
up-to-date so this might be relevant and make things a bit smoother.
Note that even with transitivity for forward replacements, key 
equivalency will only be achieved if the replacement certificate also 
claims the inverse relationship. Thus, when creating a new certificate D 
that replaces all others, the decision whether or not key equivalency 
with A, B, or C is desired can still be made, but without the need to 
also update A or B. More generally, you only need to update the last 
certificate in the chain when you add a new replacement.

Suggestion: Add transitivity for forward replacements unless there is an 
argument against it.
Alternative Suggestion: Explicitly state that forward replacements are 
not transitive (and why). Also explain that the consequence is that when 
creating a new replacement, all previous certificates need to be updated 
if key equivalence is desired.


# Infinite Loops

If chains of forward replacements are possible, then infinite loops are 
possible: A points to B and B points to A (both forward replacements). 
Since a loop like this makes no sense, it is likely there by accident or 
by malicious intent.

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.


# 6. Selection of Encryption Subkeys

Section 6 describes an algorithm how the encryption subkeys are to be 
chosen. It is missing four things in my opinion:

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.

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.

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.

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.


# Replacing a key that I don't want to be used

Imagine a scenario where key A is replaced by B (forward+inverse 
replacement) and then I lose access to my secret key for A. In the 
best-case scenario, I would be able to revoke A even after I lost my 
keys, but that's not guaranteed.

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"?

B can simply drop the inverse relationship but this makes the transition 
from A to B less smooth.


I hope I did not mix up any As and Bs and Cs and this was comprehensible.

Best,
Johannes

On 12.12.2024 11:40, Andrew Gallagher wrote:
> Hi, Johannes.
> 
> On 12 Dec 2024, at 10:27, Johannes Roth <[e-mail]> wrote:
> 
>> I also have quick question: Are chains for forward replacements 
>> supposed to be allowed, e.g. A claims to be replaced by B and B claims 
>> to be replaced by C? From what I read in the draft it should be 
>> allowed. In that case I'll have some feedback. If no chains are 
>> allowed, I'll have less feedback.
> 
> If a valid equivalence binding exists (i.e. two certs A and B, where A 
> indicates that B is its replacement and B indicates that A is its 
> original/fallback), it is not possible to create a chain. This is 
> because only one live subpacket can be present in each self-signature, 
> and that subpacket is either a forwards or an inverse subpacket. While 
> it is possible for an inverse subpacket to refer to multiple originals, 
> it is not possible to mix forwards and inverse references in the same 
> self-signature.
> 
> If however there are no inverse subpackets, then it is possible to 
> create a chain of references - e.g. cert A may have a forward reference 
> to cert B and cert B may have a forwards reference to cert C (instead of 
> an inverse reference to A). We did not explicitly prohibit this since 
> such a construction is merely advisory, however it may be prudent to 
> implement a limit on how many such references should be followed.
> 
> A
> 
> 
> _______________________________________________
> openpgp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]