On Thu, 2019-11-21 at 08:17 -0800, Lakshmi Ramasubramanian wrote: > Hi Mimi, > > >>> everything needed for verifying a signature is included in > >>> the key measurement. > > Regarding the requirement you had stated above, I would like some > clarification. > > When I started this change to measure keys through IMA, the use case > we had in mind was enabling an attestation service, for instance, to > verify if the client has only known good (trusted) keys - for > example, in keyrings such as ".builtin_trusted_keys", ".ima", etc. > > On the client IMA verifies the signature of system binaries using > keys in the IMA keyring. And, if the config namely > CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is > enabled, only keys signed by a built-in trusted key can be added to > the IMA keyring. > > An attestation service can keep a list of public keys of "known good > (trusted)" keys for various keyrings, and verify against the > measurement data provided by the client. > > To achieve the above we decided to include only the public key in > the key measurement buffer. > > I would like to know what benefit we'd get by including "everything > needed for verifying a signature in the key measurement"? X.509 > itself doesn't buy this isomorphism property, which is why the > subject key id > > From testing point of view, if we have the certificate (like the > .DER file), we can validate the key measurement data in the IMA log. > > Do you see a need to include more data or the entire cert for the > product code? You're making the assumption that the public key and the certificate are isomorphic. That's only true if you trust the issuer (which you obviously do, since it's you [microsoft]) but nothing in X.509 prevents the issuer from issuing multiple certificates with the same public key and different properties. Even in your use case, I would think attesting to whether the certificate had expired or not would be useful. James
