You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A trusting directive hard-codes a specific public key, which seems like it would make it hard to rotate those keys without brute-force trying every current version. Is there some mechanism for handling this?
The text was updated successfully, but these errors were encountered:
The typical KMS-style key rotation approach is to issue a new key, use that for new credentials, but keeping the old key valid for some time window which doesn’t immediately invalidate them.
Ideally you could make that expiration window longer than the credential validity period.
Third-party blocks carry the public key that can be used to verify them, so the external signatures are only verified once, with the public key carried in the block. The trusting annotation then allow to select the third-party blocks based on their public key.
You can have several public keys in a trusting annotation, so you can have the old and new public keys in the annotation, and the third party block will be considered if either one matches.
So the rotation process would be:
generate a new key pair
expose its public keys so that it can be added to trusting annotations
start emitting third-party blocks signed with the private key
Since for third party-blocks, the block emitter and the users of trusting annotations are not the same entity, the validity period of public keys has to be longer than the validity of the token containing the trusting annotation, which can be ensured through TTL checks.
A
trusting
directive hard-codes a specific public key, which seems like it would make it hard to rotate those keys without brute-force trying every current version. Is there some mechanism for handling this?The text was updated successfully, but these errors were encountered: