[openpgp] Re: New Version Notification for draft-dkg-openpgp -stateless-cli-15.txt

Hey Andrew, list,

On 1/12/26 6:28 PM, Andrew Gallagher wrote:
> There are use cases where extending subkey expiration is necessary, 
> e.g. if the secret key is distributed across multiple devices, or if 
> it is in a hardware token with limited storage for subkeys (e.g. 
> openpgp card) and rolling the secret would be difficult. Such guidance 
> can therefore never be universal, so applications can never remove the 
> ability to extend such keys. And so long as that code path exists, it 
> could potentially be triggered.
>
> But if you have a separate mechanism for ephemeral keys, and if the 
> expiry date was part of the key material packet (not the binding 
> signature), and contributed to the fingerprint, it would be very 
> difficult to make any such code path function at all. This would offer 
> an actual guarantee that the expiry date of this kind of key cannot be 
> accidentally extended, and is therefore solid enough to build a 
> "secure disappearing messages" UX on top of. Without solid guarantees 
> I think the attractiveness of the mechanism will be limited.
>
> We can't prevent people from trying to work around security 
> guarantees, but we can make it difficult.
>

I like the idea of "stronger typing" for new semantical objects (like 
ephemeral keys).
Putting the expiration time in the key packet sounds very attractive to 
me, if we want to forbid extension of validity.

Then we could even forbid unlimited validity for that packet type, by 
saying that "0" is an illegal validity duration.
(Or shoot for the stars, and not specify validity as a duration at all, 
and just use a timestamp, like a normal person).

> If we are using a new wire format, we don't have to distribute it in a 
> certificate, or at least not a traditionally-formatted one. I'm just 
> thinking off the top of my head here, but we could (throws dart at a 
> board) define a new UAT subpacket and put both the ephemeral key and 
> its binding signature in the UAT, so that legacy code will think the 
> UAT is unbound and silently ignore it. I'm sure we can think of plenty 
> of other ways of doing it that are invisible to legacy code...

I've found myself agreeing with many points in your mail, but am a bit 
horrified by the notion of putting anything that is not an 
"identity"-like object into a User Attribute Packet.

If we want to move towards "strong typing" on the packet type level, I'd 
hope that it would be a viable path to use an actual named *type*.
My impulse would be to specify a new packet type id (in the non-critical 
range).

:) Heiko

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