> > Also, as an aside, if we are enumerating the various SP800-90(A) DRBG
> types, I assert we should leave off the Dual_EC DRBGs, if that hasn't
> already been considered. ;->
>
> I think they should remain with enumeration values specified ... We
> haven't made any specific recommendations in terms algorithms to not
> use within KMIP to date and remember we do list DES and things like RC2
> within the algorithm list - see 9.1.3.2.13 within the KMIP 1.2
> committee specification draft.
Well... maybe we ought to remove (or at least deprecate) those, too. Why include anything that is known insecure? Shouldn't we, as a group, feel qualified to make a value judgment here? Or at least follow NIST guidance?
Are there customer use cases out there involving (ahem) questionable crypto? I'd understand if we had a long 20-year history and lots of legacy apps... but I don't think we have that.
Maybe I just get a Voldemort-like reaction to Dual_EC DRBG - "The algorithm that shall not be named". :-)
My $0.02.
-Mike
