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

[Arshad Noor <arshad.noor@strongauth.com>]

Allen,

While I don't deny the confusion the English language causes,
the protocol will be implemented by software developers who
are most likely already used to Klingon :-).

Consider object-oriented programming languages - every one of
them has overloaded methods within classes, which are a very
well understood paradigm.  Far from being confusing, they are
in fact, considered a strength because it makes code compact
(so he said as he downloaded the latest version of Linux at
nearly 3+ GB ;-)).  The SKSML messages are no different from
over-loaded method calls inside a class file, IMO.

Arshad


Allen wrote:
> Hi Arshad,
> 
> It is often best to *not* have the same name mean multiple things.
> 
> For example: bear. Which am I talking about, the four footed animal or a 
> burden or even meaning to move in the direction of (to bear right)?
> 
> Then there are words like, there, their, and they're. Written on paper 
> it is easy to see the differences but when speaking a lot of effort and 
> confusion can develop. Homonyms in English and similar confusions make 
> English among the most difficult of languages to achieve fluency in.
> 
> The more explicit the words chosen are and the less overlap the less the 
> chance of silly, but understandable, coding errors.
> 
> Given that it is current estimated that ~400,000 bugs of various sorts 
> and severities are being coded into programs currently but only about 
> 50,000 a year are being found and eliminated, we should do our best to 
> chose keyword sets that reduce the likelihood of inadvertent mistakes.
> 
> Allen Schaaf - CISSP, C|EH, C|HFI, CEI
> Information Security & Risk Analyst - Business Process Analyst
> Training & Instructional Designer - Sr. Documentation Developer
> Certified Network Security Analyst and Intrusion Forensics Investigator 
> - Certified EC-Council Instructor
> 
> Security is lot like democracy - everyone's for it but
> few understand that you have to work at it constantly.
> 
> 
> 
> 
> 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
>>>>