Understanding Derived Credentials
Derived Credentials are a relatively new concept, and I’ve found their name tends to cause some confusion as to what they actually are and do.
In a nutshell? A derived credential is a credential created through a process of proving ownership of some existing trusted credential. The main use case of this is with a user owning a PIV card and a Mobile Device (like an iPhone), and they use their PIV card to generate a set of derived credentials on the Mobile Device.
What a derived credential is not:
- It’s not a certificate that is somehow generated off your existing certificate. There is no relationship between the public/private key pair in the derived credential from that in the owner’s original public/private key pair. They are entirely seperate certificates.
- It’s not a certificate limited in any way, unless you set that in the policy for the signed certificate. If you don’t set it up properly, your derived credentials could be enforcing the same key usages and policies as the ones in your PIV card, which is of course a terrible idea.
The main considerations for implementing derived credentials are:
- Where are the derived credentials going to be stored? Are they going on to iOS devices? What about Android? Are the keys held in a TPM-like part of the device to prevent extraction/misuse?
- Does the derived credential have the same policies associated with it as the root credential? You might have a cross-certification agreement with another organisation, and that agreement stipulates that only particular certificate policies are trusted and that those certificates must be held in hardware-based storage. Will the derived credentials still meet these requirements like these?
Ultimately derived credentials are more of an implementation of business process than a new PKI concept. It’ll be interesting to see how, or if at all, businesses and software choose to implement it.