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

[Allen <netsecurity@sound-by-design.com>]

Hi Marc,

I guess it is a matter semantics in a way. For me generating a
new key is not the same as requesting a copy of an existing key.

I do agree with you about the combination of thing and action but 
don't see it as all that different from a request with a 
parameter set to say which action is requested.

A request with a parameter is to me a Swiss Army Knife solution 
that works quite well for an occasional use, but a specific 
request is like using the right screwdriver for the particular 
screw you are confronted with. The Swiss Army model will get the 
job done most likely but the risk of buggering the screw head is 
higher compared to using the tool designed for the screw.

Each action goes through a separate process at some point in the 
work flow. Somewhere the question is asked "New or Existing?" and 
then two different paths are taken.

As I see it where that decision point comes in the work flow is 
the real core question that needs to be answered. Does it come at 
  or near the head of the process or does it come further down 
the path?

Syntactically the difference is really whether the command makes 
the difference in the request clear or does some parameter that 
needs to be set make the request clear. If it is the command name 
then one reads it at a higher level, if it is a parameter, then 
it is at a lower level and one must parse the parameters in order 
to understand what is being done.

Doing it with parameters simply makes following the flow harder 
and is somewhat more error prone. Both will work. The command 
name one might be easier to understand by someone who did not 
write the original file and I would generally opt for that as the 
best choice as it reduces the "legacy code" problem for those who 
come after us.

Best,

Allen


Marc Massar wrote:
> I think we would be adding to confusion if we added a
> NewSymKeyRequest tag. If you look at the 2 tags now one is
> labeled "request" and the other "response."  In my opinion
> submitting a request to generate a symmetric key is the same
> as requesting a new key. I like to think of things and actions
> when reading XML. A NewSymKeyRequest tag implies both thing (a
> new key) and action (give me a key). The other tags don't have
> the same implied value in my opinion. If anything I think we
> add a new action in the request that requests a new key and
> requires the data elements needed to generate and label a key
> (which are present in the spec now I believe).
> 
> Sent from my iPhone
> 
> On Apr 17, 2008, at 1:17 AM, Allen
> <netsecurity@sound-by-design.com> wrote:
> 
> Hi Arshad,
> 
> I don't disagree about the "overloaded" aspect of OO
> languages, however if overloading is such a virtue by making
> for more compact code then why are we creating so much buggy
> code?
> 
> The thing I see is that documentation of what is being done is
> often lacking and when one uses the same command in multiple
> ways then it can not be self explanatory. Since programmers
> have shown an historical resistance to documenting their code
> it seems logical to create command words that are self
> documenting rather than count on retrospective documentation.
> 
> I'll give you an example that might clarify the size of the
> issue of code maintenance in a real world scenario.
> 
> About three years ago Yahoo wanted to refresh their authoring
> for the web front end and add some new functionality. It had
> been written in Python and when that version was to be updated
> all the developers who had worked of the original were no
> longer at the company. When they looked at the code (and
> Python is easy to read!) they found they did not have enough
> information in the code to just do a refresh and the Python
> developers who they had look at it said, faster to re-write
> from scratch. Well, they didn't have enough Python developers
> on staff and hiring them and getting them up to speed would
> stretch it out longer than they wanted to so they re-wrote the
> entire authoring system and all the modules in PHP! Big money
> costs.
> 
> As I understand it using XML with properly chosen command
> names is to help with the documentation and maintenance of the
> code over time so that a change only has to be made in one
> place and it is clear what the command - with attached
> parameters - does. Overloading defeats this goal to save what?
> Clarity? Documentation needs? File size? Developer time?
> 
> I don't think there is enough value gained for the small
> decrease in file size of SKSML messages to cut corners by
> overloading.
> 
> Also, pray tell, which dialect of Klingon computerese? Shall I
> get together a list of the 100+ current versions in use and
> then we can see how crazy a language it is? ;->
> 
> Allen
> 
> 
> 
> Arshad Noor wrote: 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
> 
> 
> ---------------------------------------------------------------------
>  To unsubscribe from this mail list, you must leave the OASIS
> TC that generates this mail.  You may a link to this group and
> all your TCs in OASIS at: 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> 
> 
> ____________________________________________________________________________________
>  Be a better friend, newshound, and know-it-all with Yahoo!
> Mobile.  Try it now.
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>