Hi Marcel, Mimi, Tadeus, I want to consider adding or doing the following bits to the keyrings facility, aiming for the next merge window: (*) Bring in the patches that I posted to change how the trust model on a keyring works. The model will then be that keys aren't automatically marked trusted, but linking a key into a keyring that is marked trusted-only will validate the key against the contents of the keyring before permitting its addition. Note that we can then vary the policy on a per-keyring basis. (*) Add Mimi's patches to allow keys/keyrings to be marked undeletable. This is for the purpose of creating blacklists and to prevent people from removing entries in the blacklist. Note that only the kernel can create a blacklist - we don't want userspace generating them as a way to take up kernel space. I think the right way to do this is to not allow marked keys to be unlinked from marked keyrings, but to allow marked keys to be unlinked from ordinary keyrings. The reason the 'keep' mark is required on individual keys is to prevent the keys from being directly revoked, expired or invalidated by keyctl without reference to the keyring. Marked keys that are set expirable when they're created will still expire and be subsequently removed and if a marked key or marked keyring loses all its references it still gets gc'd. (*) Provide KEYCTL_{SIGN,VERIFY,ENCRYPT,DECRYPT} operations for use with asymmetric keys, allowing offload to hardware or use of the crypto routines for a software fallback. One question is as to how to set parameters. The key will be specified by a key ID and this will set the crypto algorithm (eg. RSA, DSA, ECDSA, etc.) and the key size (eg. RSA-4096), but other parameters will need to be supplied such as: - Hash type. I'm expecting the hash value to be passed through this interface not the data-to-be-hashed, but the type may need to be known for other purposes. - Password to decrypt the private key. I'm not sure whether this should be presented at the point of key usage or the point of key instantiation. The former means that you don't have an unsecured key sitting around in the kernel. Another question is what form the data should be presented. In many ways, I would favour raw data with internal metadata attached as appropriate by userspace (eg. the hash algorithm OID included in a signature as per RFC4880 sec 5.2.2). I would certainly rather avoid any ASN.1 or PGP encodings in this interface. One problem we have is that we only have four arguments to play with, one of which has to represent the key ID, but we need two buffers, two buffer lengths and some options per operation. However, we could include the buffer lengths inside the options maybe: keyctl_sign(int key, const char *options, const void *data, void *buffer); Another option is to allow a key to be queried for the buffer sizes and always require that amount of data - maybe something like: struct keyctl_asymmetric_info { unsigned encrypted_data_size; unsigned decrypted_data_size; unsigned signature_size; unsigned signed_data_size; } info; keyctl_query_asymmetric(key, &info); Possibly these values will all be the same, so we might only need get one value back. I'm assuming here that userspace would do the dressing up of the data for signing with whatever metadata and padding is required. (*) In reference to the above, potentially provide a KEYCTL_KEY_UNLOCK that takes a key and password and gives you another key that has the private key unlocked that you can use temporarily and then discard. I'm not sure how best to manage *hardware* private keys though - and I suspect that will be hardware dependent. (*) A TPM asymmetric key subtype that allows access to asymmetric keys stored in a TPM. (*) Provide KEYCTL_SEAL_KEY for sealing an asymmetric key to hardware. (*) Add a symmetric key type that acts as a container for a symmteric key, using either hardware or software, to be accessible through AF_ALG. (*) Provide a way to generate a new symmetric key, encrypting it with an asymmetric key inside the kernel. Again, how to parameterise is probably a tricky question. (*) Sort out the KEYCTL_UPDATE mess with trusted and encrypted keys. David -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html