A Certificate Authority signs other certificates. A signing certificate can sign documents. There is a big difference. With this week’s discussion of the Flame malware and the mechanism used to sign it, I think it is important to point out why we are not using an X509 as the signed token in Keystone.
When a CA signs a certificate, it indicates what that certificate may be used for in the future. A CA itself has a certificate that states it is allowed to sign new certificates. When I request a certificate for my personal use, one thing I want to be able to use this to do is to sign email to prove that I actually wrote it. This is a different attribute.
To put it simply, it is much safer to distribute a certificate that can sign email than to distribute a certificate that can be used to sign other certificates. The first does not allow delegation of signing authority.
I am currently working on Openstack Keystone’s signed token Blueprint. Under this design the tokens are signed documents. People were originally calling the certificates, and I want to make sure that people understand that they are not certificates. The cryptographic signing of the data in the token provides a guarantee that the data is correct according to the signer. In this case, the signer is Keystone. Why not make them certificates?
Then Keystone would become a CA. If Keystone got compromised, we’d have to deal with all of the issues of revoking the certificates signed by Keystone, as well as the Keystone certificate itself. Keystone should not have to worry about this. People deploying Keystone should not have to worry about this.
Yes, it is possible to limit what a CA cert can sign. but that rule has to be enforced outside of Keystone, by the CA that signs Keystones certificate. This is a case of not asking for more authority than required to perform a task. It is the cryptographic equivalent of not running your web server as root.
A simple rule of thumb is that automating the process of signing certificates is risky business, do it at your peril.
A quick note, the format for signed email is “Cryptographic Message Format” or CMS. The utilities to do signing in both OpenSSL and NSS have CMS in their names.
If you need to be able to verify the data in a document, consider using CMS and signing certificates.
Discussion of Flame and the certificate management that lead to it getting signed and distributed is here: http://rmhrisk.wpengine.com/?p=52
Well said Adam! I think its also worth pointing out that signed tokens are meant to be be short-lived where as certificate life spans are much longer. Signed tokens expired in hours and certificates are generally expired in months or even years. Therefore, from risk management standpoint, short-lived token is no different than a “grace period” if token access changes while the token is still outstanding. Revocation is not required. However for a long-lived certificate, the risk is much higher.