Formatting comments:
1st paragraph under "Disk Encryption Key Escrow"
"The goal is to allow recovering from a e.g. a lost password for ..." should either remove "a e.g." for replace it with "a lost key, suchas,"
=
2nd paragraph under "Disk Encryption Key Escrow"->"Features", last sentence ===
The parenthetical note "(perhaps letting the user to change the password)", drop the 'to'
General comments
Escrow Packets
We should not preclude the storage and transport forms of the 'Escrow packets' would necessarily be the same. It may be that keys are recovered through some key exchange mechanism. For the initial implementation, it's probably OK to make the key exchange some sort of local transport, but the architecture should not assume it. (at least for the key portion of the Escrow packets.
We should probably spell out all the data we need in an escrow packet (in the design step), and identify those portions which are CSP, or security related data.
Escrow Packet encryptions: This needs careful design and review. Encrypting with passwords can be made to work, but may not be the best method of Key exchange. At rest, it would probably be best if the packets were encrypted with some fix or private key on the server and rekeyed on transport. I'm a little bit afraid of at rest packets encrypted with a PBE.
Rekey
Volume rekey can be an expensive operation. I don't know if LUK or dmcrypt has any low level primitives to help that. If not, we may want to add some. Probably not essential for first release, but a good thing to keep in the back of our minds (particularly how to do it in a way that benefits LUK and dmcrypt when not using the key management system.
Key Splitting
The RHCS DRM has support for this already. I'll present RHCS DRM issues in a separate section.
CMS Escrow Packet encryption
Certainly for the packet meta data, and perhaps a wrapped version of the key, this would be a fine choice. I don't think it's a good idea to encrypt raw key data with CMS directly. We really need to store encrypted keys with some sort of key wrapping standard. It's OK to use the CMS session keys generated as part of CMS as the source key from the wrapping standard.
Using CMS PBE and NSS: If we use CMS as the Escrow Packet (and I'll assume we will in the rest of the comments, since I think the point of my first paragraph can be handled within that framework still). The design will need a PBE based CMS implementation. It should be relatively easy to get that working in NSS. NSS already has CMS code as well as PBE, code, the missing piece if figuring out how to get the PBE password to NSS at the right time. (NSS already does something like this for PKCS #12 support in the old PKCS #7 standard). A well implemented patch for this that allows easy integration with existing apps like Thunderbird would be very welcome by NSS upstream.
On-line Recovery
This could make an excellent feature, but we will need to be very careful in designing the protocol. It should be reviewed internally and externally. We should probably look to having a professional outside security review as well.
TLS Transport of Escrow Packets
I'm presuming that we are talking about transport of *encrypted* escrow packets, and that the packets (or more importantly, the key data) is not 'in the clear' inside the TLS stream (that is the reader of the SSL pipe will not get a key in the clear). We don't want the key management program itself to have to actually touch key data in the clear (first, it's a bear for FIPS, second, it precludes that use of replacing pieces with certain hardware, and finally it's just good security hygiene to keep key data from the higher level policy code. (NOTE: even NSS's CMS and SSL implementations never have access to raw key data, for instance).
That being said, it is possible to use the TLS Transport as a method of key exchange. We did this back in the old Netscape days with something called FORTEZZA pre-encrypted files. FORTEZZA was a hardware token which never gave up it's keys, and each FORTEZZA card has a fixed key which could be used to wrap other keys in the card. This FIXED key was unique to each card and could not be extracted. The idea was to store the files at rest encrypted with a key (FORTEZZA data key) wrapped by the fixed key of the server's FORTEZZA card. When we transferred the files across SSL, we would use the keys generated by the SSL key exchange to rewrap the FORTEZZA data key from the server's FIXED key to the KEK key which was part of the SSL key exchange (which both the client and server knew). On the client size the key was again reencrypted with the fixed key in the Clients FORTEZZA card. The reason the format was called 'pre-encrypted' was because it was initially assumed that the SSL connection was a FORTEZZA with NULL encryption connection. In practice, it turned out that there was little cost in making a fully encrypted connection, but it was noticed that it was useful to have these files live encrypted whenever they came to rest. The Browser know how to decrypt the result, and then would chain the output to the next 'content handler' (the content type would be encoded in the pre-encrypted file itself). The result was that the decrypted content typically only lived in memory, and never in places like the Firefox disk cache).
The format of pre-encrypted files were non-standard, and the support was removed when FORTEZZA support was deprecated (long after FORTEZZA use had effectively died out), but the idea did not have to be tied to FORTEZZA, we could implement something like this for any sort of algorithm and using standard encryption encapsulations (like CMS), just as long as we has a way to store and access persistent keys (either private or symetric) on both the client and server.
This is just an idea, and it would require some work to implement. It may be simpler to implement some other key exchange between the client and server and rekey in the application before we send the data down the SSL pipe (which is what I think the current document presumes).
RHCS DRM
The RHCS Data Recovery Manager does most of what you want, except it works with private keys rather than fixed keys. Those things it does not do are things that would improve DRM itself. The sets of problems between the two requirements are extremely similar, so it seems that we really should have exactly one escrow manager here. DRM is physically a separable piece of the RH Certificate System, and doesn't require the rest of RHCS to do it's job.
If we want to use it, I see the following work that may need to be done: 1) if we go with KMIP, we would want to have DRM talk KMIP as well. DRM currently talks CRMF and CMMF. If KMIP isn't yet ready for prime time, we can fall back on CRMF as a transport. 2) DRM needs a beefed up on-line recovery protocol. Right now that recovery is a PKCS #12 file (basically a PKCS #7 format used to wrap private keys and certs - PKCS #7 is the predecessor to CMS). The RHCS produce would benefit from an on-line reovery scheme like the one envisioned by this document. 3) DRM would need to modified to store fixed keys. This should be relatively simple, the only probable complication is storing the key meta data (key type, key purpose, etc).