OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ekmi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ekmi] My slip-up and an update


There is an element that tells you exactly that, Anil; the
GlobalKeyID.  If this element has zeros for the ServerID
and KeyID (10514-0-0), that tells you the same thing as
create="true".

There can be no key in the SKMS with a GKID that contains
0-0 for ServerID-KeyID, so this becomes a natural indicator.
For all other requests (for existing keys), these values will
be non-zero.

The advantage in having the GKID be the indicator for a new
or existing key, is that the server does not have to parse
for any other element or attribute.

Arshad

Anil Saldhana wrote:
> I really really want to see an xml element or an attribute that tells me 
> when I read the payload, that it is for a new sym key request.
> 
> So, you can certainly have something like:
> 
> <SymkeyRequest create="true"
> 
> Now if the sym key does not exist, one will be created. If it already 
> exists, the create attribute is ignored and a the key is returned.
> 
> Arshad Noor wrote:
>> We could do this.  Under this scheme, there would be three
>> kinds of SKSML messages (actually 5, but I'm ignoring the
>> KeyCachePolicy messages for the discussion):
>>
>> 1) NewSymkeyRequest (for new symmetric keys)
>> 2) SymkeyRequest (for existing symmetric keys)
>> 3) SymkeyResponse
>>
>> Under the older scheme, there would be 2 kinds of messages:
>>
>> 1) SymkeyRequest (for new and existing symmetric keys)
>> 2) SymkeyResponse
>>
>> Personally speaking - and being a bit of a minimalist - I'd prefer to 
>> stay with the 2-message protocol.  Less work on the
>> spec but no change on the implementation - the server code
>> would still have to branch its code based on the request no
>> matter which way the message came.
>>
>> What do you think?
>>
>> Arshad
>>
>> ----- Original Message -----
>> From: "Anil Saldhana" <Anil.Saldhana@redhat.com>
>> To: "Arshad Noor" <arshad.noor@strongauth.com>
>> Cc: "ekmi" <ekmi@lists.oasis-open.org>
>> Sent: Tuesday, April 15, 2008 4:27:27 PM (GMT-0800) America/Los_Angeles
>> Subject: Re: [ekmi] My slip-up and an update
>>
>> Very interesting that it took me close to a month to answer this. :(
>>
>> I was referring to the usage of GKID to indicate that the request is 
>> for a new symmetric key.  Why not have an explicit element such as
>>
>> ekmi:NewSymKeyRequest
>>
>>
>>
>> Arshad Noor wrote:
>>> I will expand the abbreviations to reflect the full and
>>> meaningful names, Anil.  However, I don't recall the "new
>>> XML element to obtain the symmetric key".  Can you refresh
>>> my memory on that?  Thanks.
>>>
>>> Arshad
>>>
>>> Anil Saldhana wrote:
>>>> Arshad,
>>>>   additionally as discussed at IDTrust08, I hope we can get the 
>>>> expansion of the abbreviated xml element names and a new xml element 
>>>> (to obtain sym key) into the drafts.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]