> 6.2 > "identity-pki-level: how deep are the IDevID certificates that are > issued?" > Would just clarify formulation a bit: how many levels of CAs exist > above the certificates issued. (The 'depth' concept seems ambiguous and > may cause confusion.) I've added a reference back to section 5.1. > identity-anchor-storage: 'Recover' the private key is a bit ambiguous - > different quorums may be needed for a) making it available to sign a > new CA vs. b) making it possible to actually copy the root key around > to new devices/places. I would maybe use the term 'to access' here to > avoid that debate altogether, since signature access is enough to > compromise. I've split this up. Since your review, I have added a section _Preservation of CA and Trust Anchor private keys_ which I'll now reference. I've now changed this to read: identity-anchor-storage: : how is the root CA key stored? An open description that might include whether an HSM is used, or not, or even the model of it. identity-shared-split-extra: : referring to {{splittingnumbers}}, where a private key is split up into n-components, of which k are required to recover the key, this number is n-k. This is the number of spare shares. Publishing this provides a measure of how much redundancy is present while not actually revealing either k or n. identity-shared-split-continents: : the number of continents on which the private key can be recovered without travel by any of the secret share holders I've thought a lot about whether one should reveal k, or n, and decided that it is safe to reveal n-k. This does not reveal n or k, or the relationship between them, but it does tell an external entity what about redundancy there is. } In this document, each of the people who hold a piece of the secret are } referred to as Key Executives. I would sure like comments on n-k, and on this term Key Executives. I re-read shamir79 (having found a new copy, since the URL I had went stale), and I did not find a clear term for the holder of the D_i. In rewriting things, I have created some next text in this patch: https://github.com/mcr/idevid-security-considerations/pull/4/commits/503cec4... about secret sharing. More review would be very welcome. > Potentially some indicators to add could include how wide the issuing > CA access is stretched, if that can be captured in a simple question. What do you mean "captured in a simple question"? > The easiest way to deploy a subCA is to give everyone a copy of the > private key, and then you can't place a whole lot of trust on the CA > itself. Handing off subCAs vs. having a centralized entity controlling > all issuing CAs does make a difference in possibility for > administrative oversight. Yes. Multiple subCAs in different places is, I think, a third way. } This might be a very good way to manage a code signing or update signing key. } Split it among development groups in three time zones (eight hours apart), } such that any of those development groups can issue an emergency security } patch. } (Another way would be to have three End-Entity certificates that can sign } code, and have each time zone sign their own code. That implies that there } is at least a level two PKI around the code signing process, and that any } bootloaders that need to verify the code being starting it are able to do PKI } operations) > 6.3 more in another email. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-