Guidelines for Cryptographic Key Management
RFC 4107
Yes
No Objection
Recuse
Note: This ballot was opened for revision 03 and is now closed.
(Sam Hartman; former steering group member) Yes
(Alex Zinin; former steering group member) No Objection
(Allison Mankin; former steering group member) No Objection
Not a Discuss, but for a discussion at some point: Is it possible to add to the reasons for not using automated key management that an automated key management protocol is not available with suitable applicability for the application environment? (IKEv2 and IPSec are not ideal for every application environment, but what other warm recommendation do we have for automated key management for applications?)
(Bill Fenner; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Harald Alvestrand; former steering group member) No Objection
Reviewed by Scott Brim, Gen-ART Some comments that may need addressing; full review in comment log.
(Margaret Cullen; former steering group member) No Objection
(Scott Hollenbeck; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
(Thomas Narten; former steering group member) No Objection
> 2.2. Manual Key Management > > Manual key management is a reasonable approach in any of these > situations: should we s/is a/may be a/? My concern is that the first example "limited bandwidth" is something I hear a lot about, and I don't want folk to be able to say "see, this document says we're a special case"
(Russ Housley; former steering group member) Recuse