[openpgp] Re: I-D Action: draft-ietf-openpgp-replacementke y-05.txt

Hi, Falko.

On 18 Aug 2025, at 08:14, Falko Strenzke <[email protected]> wrote:
> 
> - The beginning of Section 4.2 seems to imply that since there may be only one RKS in one signature, there can only be a single RKSP in the whole certificate. That doesn't seem to work out since according to RFC 9580, v6 keys can have any number of Direct Key Signatures. Later, under Section 5.1, something is said about RKSPs "new" Direct Key Signatures overriding the "older" ones, here I think the clarity could be enhanced as to whether this covers multiple Direct Key Signatures to be present simultaneously or not. Also already Section 4.2 should clarify this aspect.

Yes, RFC9580 is silent about the cumulation rules for signatures. But it’s actually more confusing than that again, because the subpacket can also appear in a revocation signature. We should make clear that a subpacket in a revocation takes precedence over any found in a direct sig.

How about this wording?

"""
A certificate MAY have multiple signatures that contain Replacement Key subpackets, however at most one Replacement Key subpacket in a certificate is current (and therefore meaningful) at any given time.
If the primary key is revoked with a Reason for Revocation of "Key is Superseded", the current Replacement Key subpacket (if any) is found in the most recent valid primary Key Revocation signature.
If it is not revoked, the current Replacement Key subpacket (if any) is found in the most recent valid Direct Key signature.
If the most recent valid primary Key Revocation or Direct Key signature does not contain a Replacement Key subpacket, or the primary key is revoked for any other reason, then there is no current Replacement Key subpacket.
"""

> - In the figures in Sections 4.2 and A.3 it says "Reverse RKSP", but I think according to the new terminology it should say "Backwards RKSP”.

Good catch, thanks!

> - Editorial only: Section 5.1.2: "If so, they may (in some circumstances) send messages encrypted to one of the certificates but addressed to an identity that it does not claim." I suggest for better readability: => " [...] to an identity that this particular certificate does not claim.”

Thanks, I’ll reword this slightly: “to an identity which that particular certificate does not claim”, which I think works even better.

Thanks once again, particularly for the fast turnaround! ;-)

A

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEKR55odxVrielLu+DXB7EBNWQZikFAmijBcQACgkQXB7EBNWQ
Zik9+Q/9GyMv2ZV0DTNtq+R/poXC4sg2AJ8CHbANfeC5ujZWzg2Avd4+MNPHnAT0
92G9NvawFux0cWDsmcf6Amqv7t5zrgFTYsYMTWBwzn2w/QhQ5WmEOpP4Q0fosJVe
Q0joCDnKAYKVOQgd9TJY5wrBqoMYRnQpXiM0s0vfRPazCVP6UD2BzuPwcHykaYd5
Psi5y0gJjV+2wMSpgoSEt0Cnmvv9lHqMOqw5CMisUZ8zYAQBXdzJJ1XeeXpan6cT
BO8WMQgpQNAOnAgRjzICWbhhKnusXRhTZjKT00gq8BFKKuHTsDzzYgeo9IWENQaD
mgrgrkzv6kKqlnyObEIxqGU9upDuiAF3UtgquxrTBxkwkxl3pURwa7lSEkZK+VIw
HWhZBAv+x48xYx7ppP8EjFCjLHFZ1AsMJd50gUTpwqXc3e+f3eM+0afKIh7a47n6
zokOaY2VPt222jr5Q0QEgLVMvX5kAhaiOU/4fklwyfMs2ZWZ4CBvf+fBRvfI4YZQ
IIMXFx2wrYJ+Gr+zDQLrLaNfeDMIrfH09TPMAC3bu7NM+scpA3ZkgAMpRJvqSvBZ
YhNZOkWz3UkUcCUe4+U77lR9zNmxo9bRcAcPN4ItX9wyxhV4QwmWR/1hRA2hiZhO
PWRKT5C7e9GFhYG0sy3AeCP4GLSgVn/7TeRZyAEABQpjydIpE6c=
=Ijx7
-----END PGP SIGNATURE-----