Re: [P1619-3] IEEE P1619.3 proposed key state diagram and descriptions
I was indeed assuming keys were always generated in the KM Server. I
would agree, though, that in some situations, it may be the KM Client or
CU that creates a key and hands it back to the KM Server. I think such
a key would land in the protect-and-process state when it was given to
the KM Server. It would be generated prior to that time, but the KM
Server would be unaware of the existence of that key.
Jon
Luther Martin wrote:
> It seems much more difficult to enforce most useful policies if a client
> can generate their own symmetric keys. So requiring that all keys be
> generated by a server seems a reasonable thing to do.
>
>
>> -----Original Message-----
>> From: Garry Mccracken [mailto:Garry.Mccracken@WINMAGIC.COM]
>> Sent: Thursday, October 18, 2007 9:29 AM
>> To: P1619-3@LISTSERV.IEEE.ORG
>> Subject: Re: [P1619-3] IEEE P1619.3 proposed key state diagram and
>> descriptions
>>
>> I like this document. I did notice that this model doesn't seem to
>> allow for the generation of the symmetric key by the Client. It
>>
> assumes
>
>> the Key Manager Server originally generates the key. Can the Client
>> generate the key? The key would be in the Generated state until it
>>
> was
>
>> sent to the KM Server and protected at which time it would transition
>>
> to
>
>> the Ready state.
>>
>>
>>
>> Garry L McCracken, CISSP
>> VP Research & Development
>>
>> WinMagic Inc.
>> 200 Matheson Blvd. West, Suite 201
>> Mississauga, Ontario L5R 3L7
>> Canada
>>
>> Phone: 905.502.7000 x269
>> Fax: 905.502.7001
>> Toll Free: 1.888.879.5879
>> Email: garry.mccracken@winmagic.com
>>
>>
>>
>>
>>
>>
>> - WinMagic underwrites latest Aberdeen research paper dealing with
>> Endpoint Security Strategies entitled "Encryption and Key Management".
>> For your free copy, please go to
>> http://www.aberdeen.com/link/sponsor.asp?spid=30410543&cid=4262
>>
>>
>>
>> * WinMagic awarded under 2 Blanket Purchase Order Agreements to
>>
> supply
>
>> US federal, state and local governments with data at rest solutions:
>> to read more, please see
>> http://www.winmagic.com/corporate_info/20070621.asp
>>
>>
>> -------------------------------------------------------------
>>
>>
>>
>> Legal Disclaimer
>>
>> This E-mail and any attachments hereto are strictly confidential and
>>
> the
>
>> addressee(s) shall not forward, disclose, or copy this E-mail or
>> attachments to any third party without the prior consent of the
>>
> sender.
>
>> If you are not the intended addressee, you must not disclose, forward,
>> copy or take any action in reliance on this E-mail or attachments. If
>> you have received this E-mail in error, please notify WinMagic Inc. at
>> (+1) 905 502 7000 extension 1 or email the sender as soon as possible.
>> Addressee(s) should check all attachments for viruses. WinMagic Inc.
>> makes no representations as regards the absence of viruses in
>> attachments to this E-mail.
>>
>>
>> -----Original Message-----
>> From: Jon Holdman [mailto:Jon.Holdman@SUN.COM]
>> Sent: October 17, 2007 7:32 PM
>> To: P1619-3@LISTSERV.IEEE.ORG
>> Subject: [P1619-3] IEEE P1619.3 proposed key state diagram and
>> descriptions
>>
>> Resending this to the larger P1619.3 group. Previously sent only to
>>
> the
>
>> Architecture subteam.
>> Jon
>>
>> All,
>> Attached is a document with proposed diagrams and text for key
>> lifecycle, states and transitions. Its based on the NIST 800-57
>>
> states,
>
>> with some extensions. There are two aspects not covered here: key
>> recovery and some key compromise transitions. Since the architecture
>> diagram mentions archiving, we'll need to add recovery.
>>
>> I do have the diagrams in visio.
>>
>> Jon Holdman
>> jon.holdman@sun.com
>> Sun Microsystems, Inc.
>>