The kid (key id) is the field intended to signify what key should be used for the JWS verification (and thus for the vault).
It should also tell us, where to get the key from (see #7). I.e. it combines a method to obtain a key and a unique identifier of the key. The method can be represented in an URI's scheme and the ID in its authority and path parts.
The URI Scheme
Each scheme must be explicitly supported by the key loader. If an URI is passed to a key loader with an unsupported scheme, loading is expected to fail.
E.g. reading a key from a masterkey.cryptomator file may use the scheme masterkeyfile:.
The Authority and Path
Once the scheme is known and supported by a key loader, we need to uniquely identify what key to load. This should be done by the Authority and Path.
E.g. getting entry "42" from keychain "27" from a password manager would result in authority //27 and path /42
Query and Fragment
There might be additional parameters required to retrieve a key, such as KDF-configuration. For each scheme, the key load may define how to use query parameters of fragments to do so.
E.g. if PBKDF2 is used with 100,000 iterations, this information may be represented as ?iterations=100000
Security Considerations
Tampering with the kid field (which due to its nature needs to be read from the JWS header before checking its integrity) enables an attacker to choose what method and which key should be retrieved.
For example an attacker who assumes the user is authorized to access a variety of keys can trick the user to load key k2 instead of k1. Obviously JWS verification would then fail, so further processing would be impossible, but the raw key is temporarily loaded into memory. If the attacker has root access to a machine, this bears a risk.
overheadhunter
commented
3 years ago
The
kid(key id) is the field intended to signify what key should be used for the JWS verification (and thus for the vault).It should also tell us, where to get the key from (see #7). I.e. it combines a method to obtain a key and a unique identifier of the key. The method can be represented in an URI's
schemeand the ID in itsauthorityandpathparts.The URI Scheme
Each scheme must be explicitly supported by the key loader. If an URI is passed to a key loader with an unsupported scheme, loading is expected to fail.
E.g. reading a key from a
masterkey.cryptomatorfile may use the schememasterkeyfile:.The Authority and Path
Once the scheme is known and supported by a key loader, we need to uniquely identify what key to load. This should be done by the Authority and Path.
E.g. getting entry "42" from keychain "27" from a password manager would result in authority
//27and path/42Query and Fragment
There might be additional parameters required to retrieve a key, such as KDF-configuration. For each scheme, the key load may define how to use query parameters of fragments to do so.
E.g. if PBKDF2 is used with 100,000 iterations, this information may be represented as
?iterations=100000Security Considerations
Tampering with the kid field (which due to its nature needs to be read from the JWS header before checking its integrity) enables an attacker to choose what method and which key should be retrieved.
For example an attacker who assumes the user is authorized to access a variety of keys can trick the user to load key k2 instead of k1. Obviously JWS verification would then fail, so further processing would be impossible, but the raw key is temporarily loaded into memory. If the attacker has root access to a machine, this bears a risk.