[iot-wg] k-of-n splitting in draft-richardson-t2trg-idevid-considerations (part 2)

    > 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/503cec4700a08175a55ee2a6ccff7406f387e42a

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 at sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </ripe/mail/archives/iot-wg/attachments/20221102/6a29b126/attachment.sig>