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
Drop requiring alg to be present on the message + enhancements (#39)
`alg` is discouraged owing to the possibility of key downgrade attacks
in [RFC 9421](https://www.rfc-editor.org/rfc/rfc9421.html#name-key-and-algorithm-specifica).
Previous incarnations of this crate assumed that `alg` would either be
present in the message or supplied externally. This change instead
requires the *keyring* to remember which algorithm a key corresponds to
during verification, meaning we no longer trust the message's use of
`alg`.
The change involves a few places:
1. `KeyRing` is now a hashmap from key IDs to algorithms and public
keys, rather than just public keys. In the long term, we should move
these fields to a dedicated `KeyAndMetadata` struct.
2. `Algorithm` has been extended to support all known algorithms per the
IANA list. However, we will continue to only support importing
ed25519 keys in the keyring. If the community needs this, people can
add support. Similarly, we will not attempt to verify or sign a
message for non-ed25519 keys just now.
I've additionally dropped `alg` being required on the HTTP signature
directory.
I've also lumped in a feature request I received internally: the ability
to inspect the message components in the signature base. I did this by
making `ParsedLabel` public, as well as `SignatureBase`. They were not
public previously since I surmised people would find more value in these
details being opaque - but there's no serious reason they need to be
private. It also means we don't need to needlessly clone
`ParameterDetails`.
0 commit comments