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

[Anil Saldhana <Anil.Saldhana@redhat.com>]

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.
>>>
>>> Regards,
>>> Anil
>>>
>>> Arshad Noor wrote:
>>>> Thank you, Allen.  I will send out sections of the
>>>> document as it gets ready rather than wait till the
>>>> end.
>>>>
>>>> Hope your recovery goes well.
>>>>
>>>> Arshad
>>>>
>>>> Allen wrote:
>>>>> Hi Arshad,
>>>>>
>>>>> I'll be happy to be editor for this. I'm currently recovering from a 
>>>>> minor surgery so I have the time.
>>>>>
>>>>> Allen
>>>>>
>>>>> Arshad Noor wrote:
>>>>>> Thank you, Mike.  Any volunteers for Editor?  I'm not sure the
>>>>>> author can serve as Editor too.
>>>>>>
>>>>>> Arshad
>>>>>>
>>>>>> Mike Nelson wrote:
>>>>>>> Arshad,
>>>>>>>
>>>>>>> I'll be glad to contribute to the review of formal specification 
>>>>>>> document
>>>>>>> for SKSML. The checklist seems fairly straightforward.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 3/22/08 3:06 PM, "Arshad Noor" <arshad.noor@strongauth.com> wrote:
>>>>>>>> 2) I received some information from Mary McRae that the TC needs
>>>>>>>>     to write a formal Specification document for SKSML - the XSD
>>>>>>>>     isn't sufficient :-(.
>>>>>>>>
>>>>>>>>     I am happy to start the writing work on this, but I will need
>>>>>>>>     some support for a formal Editor and some Reviewers.  May I
>>>>>>>>     request some volunteers from interested TC members?  There is
>>>>>>>>     a checklist of what needs to be done at this URL:
>>>>>>>>     http://docs.oasis-open.org/templates/QAChecklist.html
>>>>>>>>
>>>>>>>>     My goal is to try to get a Spec created in time for a May or
>>>>>>>>     June TC vote.
>>>>>>>>
> 

-- 
Anil Saldhana
Leader,
JBoss Security & Identity Management
JBoss, A division of Red Hat Inc.
http://labs.jboss.com/portal/jbosssecurity/