> John is talking about an entirely different set of capabilities - none
> of which are required or necessary for your use case.
Tim,
You clearly do not understand my "get random" proposal. (Either that or you are deliberately lying to the group.) For your benefit, and anyone else who is unclear about the Q'Labs' "get random" proposal here's the executive summary:
1. Supports fixed and variable length, including "infinite" length, generation of random bits from server to client
2. Supports DRBG and NRBG constructs
3. Allows clients to share random securely using the same features in KMIP that currently allow clients to securely share keys and certificates; i.e. a managed object
4. Allows Templates to be used to specify the attributes of random
5. Supports lifecycle management of random
6. Supports state management of random, including the ability to mark random as having been compromised
7. Supports usage limits on random; e.g. how often a DRBG requires re-seeding, or how many clients may share a single random object
8. Supports delivery of random using the Put operation
9. Supports signalling of attribute changes to a random object using the Notify operation
Tim, if you have any further questions about what the Q'Labs' proposal is about, I would - as always - be happy to elaborate. However, I would appreciate that you not mislead the group again. It is very poor form.
Regards,
John
