[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ekmi] Request ID or entire request in sksml response
Oh, don't undersell your own capabilities, Tomas. I'm sure if there was a question on ASN encoding of digital certificates, I would be completely lost compared to yourself. :-) I will confess that I had to go to the XSD forums to get an answer to a construct that I just couldn't understand either from the XSD specification or a book I'd purchased and read at least 3 times; I got the answer in 10 minutes. God, I love the open-source movement! Arshad Tomas Gustavsson wrote: > > Crystal clear. It really shows is that I'm not an expert in webservices. > > Regards, > Tomas > > > Arshad Noor wrote: >> That is true, Tomas; however, the occurrence is within a <choice> >> element, which implies that you can place only a <GlobalKeyID> or >> a <SymkeyRequestID> in the <SymkeyRequest> and whichever one you >> choose, there must be at least one occurrence of the sub-element. >> >> Does that claify it? I will make it clear in the specification >> and update the notes inside the XSD to indicate this. >> >> Arshad >> >> Tomas Gustavsson wrote: >>> >>> Hi Arshad, >>> >>> Just to make the (false) impression that I read and fully analyzed >>> everything carefully :-) >>> >>> >>>> SymkeyRequest.xsd >>>> ----------------- >>>> >>>> 01) Added the choice of sending either a GlobalKeyID or a >>>> SymkeyRequestID in the SymkeyRequest to accommodate >>>> asynchronous request/responses to/from SKS servers. >>> >>> It says "either or" above. In the symkeyRequest.xsd it says >>> minOccurs="1" on both the GlobalKeyID and the SymkeyRequestID. >>> >>> Cheers, >>> Tomas >>> >>> >>>> >>>> SymkeyResponse.xsd >>>> ------------------ >>>> >>>> 01) Added the SymkeyWorkInProgressType as an additional choice to >>>> the SymkeyResponse element, to accommodate asynchronous >>>> request/responses to/from SKS servers. >>>> >>>> The zip file is available at: >>>> >>>> http://www.oasis-open.org/apps/org/workgroup/ekmi/download.php/29681/SKSML-DRAFT7.zip >>>> >>>> >>>> I don't want to modify the Specification Document until I have >>>> some consensus on the XSD itself. Once we're agreed on the >>>> changes in the XSD, then I'll modify the Spec document to >>>> reflect the changes. >>>> >>>> Can we use Tuesday October 21st (the day of our TC meeting) >>>> as a deadline for reviewing the changes (they're not very big >>>> changes). We can then discuss them on the monthly call and >>>> decide our course of action. >>>> >>>> Thanks. >>>> >>>> Arshad Noor >>>> StrongAuth, Inc. >>>> >>>> Arshad Noor wrote: >>>>> Sorry for the delayed response; just got back last night from >>>>> Madrid where I presented SKSML at the ISSE 2008 conference. >>>>> As always, the work this TC is doing generates great interest. >>>>> Given that entire countries already have PKIs established in >>>>> the EU, EKMI is starting to generate much interest over there. >>>>> >>>>> WRT to the elements, Anil, I feel if we are going to support >>>>> asynch message/responses, then we should do it right, right >>>>> from the beginning. The elements I'm thinking of are fairly >>>>> simple and will not add too much to the protocol. But, the >>>>> advantage is that it allows the SKCL to take on more and the >>>>> client application has to do less. I will have the XSD done >>>>> in a few days and send it to the TC for review. >>>>> >>>>> Arshad >>>>> >>>>> Anil Saldhana wrote: >>>>>> Hi Arshad, >>>>>> asynchronous/deferred processing probably is 10-20% of usage. So >>>>>> is it worth adding explicit elements into the schema? :) >>>>>> >>>>>> My proposal of status and status code should take care of it. If >>>>>> the status is pending, then the relationship between the client >>>>>> and the server is outside the scope of the spec, as to how the end >>>>>> response is delivered to the client. It can be callbacks, polling >>>>>> etc (which is implementation detail). Once the response is ready >>>>>> and delivered to the client, the status can be success. The >>>>>> requestID that is part of the response will tell the client that >>>>>> this is the result of a deferred processing. >>>>>> >>>>>> Asynchronous/deferred processing will involve smarter clients. So >>>>>> we can assume that the client has more processing capabilities in >>>>>> comparison to regular clients. >>>>>> >>>>>> Regards, >>>>>> Anil >>>>>> >>>>>> Arshad Noor wrote: >>>>>>> I am working on modifying the XSD to include a >>>>>>> <SymkeyWorkInProgress> >>>>>>> element as a third response-type. When I get back from my >>>>>>> presentation >>>>>>> at ISSE/SECURE 2008, I'll send out an update on this. In the >>>>>>> meantime, >>>>>>> if there are other suggestions, they are welcome. >>>>>>> >>>>>>> Arshad >>>>>>> >>>>>>> Tomas Gustavsson wrote: >>>>>>>> >>>>>>>> I'll second that. >>>>>>>> >>>>>>>> /Tomas >>>>>>>> >>>>>>>> Anil Saldhana wrote: >>>>>>>>> In my opinion, the 1.0 spec should provide 3 items - status , >>>>>>>>> status code (optional) and status message (optional). The >>>>>>>>> status can be success, error or pending. When the status is >>>>>>>>> error, the code and message are relevant. Apart from the >>>>>>>>> status of pending (or any suitable word), the spec needs to do >>>>>>>>> little for deferred processing. >>>>>>>>> >>>>>>>>> Arshad Noor wrote: >>>>>>>>>> I concur. Any other opinions? >>>>>>>>>> >>>>>>>>>> Arshad >>>>>>>>>> >>>>>>>>>> Tomas Gustavsson wrote: >>>>>>>>>>> >>>>>>>>>>> I vote for 1) or 3). Either one would work. Version 1.0 is >>>>>>>>>>> not likely to be very widely deployed, especially if the >>>>>>>>>>> roadmap to 1.1/2.0 is not too long. On the other hand if >>>>>>>>>>> these are the only important changes in the roadmap we might >>>>>>>>>>> just take that time and hope that 1.0 will be long lived. >>>>>>>>>>> >>>>>>>>>>> I'm leaning toward 3) right now. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Tomas >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Arshad Noor wrote: >>>>>>>>>>>> Tomas, >>>>>>>>>>>> >>>>>>>>>>>> Including a Request ID in a current SKSML response that >>>>>>>>>>>> includes a >>>>>>>>>>>> key is easy. It just means adding an extra element to the >>>>>>>>>>>> response. >>>>>>>>>>>> >>>>>>>>>>>> However, returning an SKSML response that only includes a >>>>>>>>>>>> Request ID >>>>>>>>>>>> and a PENDING status element does require defining a new >>>>>>>>>>>> Response >>>>>>>>>>>> type. >>>>>>>>>>>> >>>>>>>>>>>> So, the choices we have are: >>>>>>>>>>>> >>>>>>>>>>>> 1) Do nothing for 1.0 and add all this in the next version >>>>>>>>>>>> of the >>>>>>>>>>>> protocol; >>>>>>>>>>>> >>>>>>>>>>>> 2) Add the RequestID element to a full SKSML response (with >>>>>>>>>>>> the key) >>>>>>>>>>>> and add the new Polling Request and the Pending Response >>>>>>>>>>>> messages >>>>>>>>>>>> in 2.0; >>>>>>>>>>>> >>>>>>>>>>>> 3) Add the new messages in 1.0, but delay the 1.0 >>>>>>>>>>>> standard. Right, now, if we assume we want to add the >>>>>>>>>>>> Error/Message Codes and Standard Messages to the >>>>>>>>>>>> specification, that is going to take at least a month, >>>>>>>>>>>> and then we have to go through a TC vote (I think) >>>>>>>>>>>> and a 15-day Public Review period. We would then be >>>>>>>>>>>> right where we >>>>>>>>>>>> are now in terms of the process. >>>>>>>>>>>> >>>>>>>>>>>> Since I have heard positive responses to the need for >>>>>>>>>>>> adding standard >>>>>>>>>>>> codes/messages, it looks like we're going to have to go >>>>>>>>>>>> through this >>>>>>>>>>>> 45-50 day delay anyway, so we could use the opportunity >>>>>>>>>>>> to include >>>>>>>>>>>> the Polling Request/Pending Response message to the >>>>>>>>>>>> protocol. >>>>>>>>>>>> >>>>>>>>>>>> What do you all think? >>>>>>>>>>>> >>>>>>>>>>>> Arshad >>>>>>>>>>>> >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> From: "Tomas Gustavsson" <tomas@primekey.se> >>>>>>>>>>>> To: "Arshad Noor" <arshad.noor@strongauth.com> >>>>>>>>>>>> Cc: "Anil Saldhana" <Anil.Saldhana@redhat.com>, >>>>>>>>>>>> ekmi@lists.oasis-open.org >>>>>>>>>>>> Sent: Thursday, October 2, 2008 9:42:22 AM (GMT-0800) >>>>>>>>>>>> America/Los_Angeles >>>>>>>>>>>> Subject: Re: [ekmi] Request ID or entire request in sksml >>>>>>>>>>>> response >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> It's a common approach in other protocols to allow both >>>>>>>>>>>> methods, either synchronous or asynchronous. When using the >>>>>>>>>>>> asynchronous mode the server just returns the requestId in >>>>>>>>>>>> the reply with a "pending" status, and optionally some time >>>>>>>>>>>> interval when the client should check back. >>>>>>>>>>>> The polling type message from the client is definitely the >>>>>>>>>>>> way to go I think. >>>>>>>>>>>> >>>>>>>>>>>> This is how both SCEP and CMP (I think) work, and it's >>>>>>>>>>>> common in PKI since some people keep insisting on using >>>>>>>>>>>> off-line CAs and such unnecessary things. Or they keep very >>>>>>>>>>>> strict network separation with an RA/proxy in between so >>>>>>>>>>>> polling is needed. >>>>>>>>>>>> >>>>>>>>>>>> I'm not suggesting that we implement this polling in the >>>>>>>>>>>> first version of the protocol, but It might be a good idea >>>>>>>>>>>> to keep it in the roadmap for future revisions. After all, >>>>>>>>>>>> we don't know if if there is really need for it, and I'm >>>>>>>>>>>> against bloating the protocol if we don't have to. >>>>>>>>>>>> >>>>>>>>>>>> But... >>>>>>>>>>>> If we return the requestId in the response now, a future >>>>>>>>>>>> revision might only have to define the polling message? >>>>>>>>>>>> Since there is already a status in the response that could >>>>>>>>>>>> be used to send PENDING back to the client right? >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Tomas >>>>>>>>>>>> >>>>>>>>>>>> Arshad Noor wrote: >>>>>>>>>>>>> See below for comments and some additional questions. >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> Anil Saldhana wrote: >>>>>>>>>>>>>> The example of an email usage was just an illustration of >>>>>>>>>>>>>> possibilities of transport. Inline answers: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Arshad Noor wrote: >>>>>>>>>>>>>>> Interesting requirement, Anil. This leads to more >>>>>>>>>>>>>>> questions: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1) Should SKSML then be sent using SOAP over SMTP, or >>>>>>>>>>>>>>> using just >>>>>>>>>>>>>>> S/MIME? >>>>>>>>>>>>>> Are we not relying on ws-security? That will provide the >>>>>>>>>>>>>> message level security. >>>>>>>>>>>>> Yes we are, but the moment you bring up SMTP you'll >>>>>>>>>>>>> find a lot >>>>>>>>>>>>> of people who are going to say why aren't we using S/MIME >>>>>>>>>>>>> (something that has been around for over 15 years). >>>>>>>>>>>>> Sending SOAP >>>>>>>>>>>>> over SMTP certainly is technically feasible and >>>>>>>>>>>>> provides the >>>>>>>>>>>>> same level of security as SOAP over HTTP, so that isn't >>>>>>>>>>>>> the >>>>>>>>>>>>> issue. Just trying to figure out what answer we as a >>>>>>>>>>>>> TC have >>>>>>>>>>>>> when someone poses this question to us. >>>>>>>>>>>>> >>>>>>>>>>>>>>> 2) How should the SKS server respond under the following >>>>>>>>>>>>>>> conditions? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> a) When the mail message is unsigned spam; >>>>>>>>>>>>>>> b) When the mail message is signed spam; >>>>>>>>>>>>>>> c) When the mail message is legitimate SKSML, but >>>>>>>>>>>>>>> signed with >>>>>>>>>>>>>>> an invalid certificate? >>>>>>>>>>>>>> What if it is a controlled environment? >>>>>>>>>>>>> I should've clarified that by "spam", in this context, >>>>>>>>>>>>> I meant >>>>>>>>>>>>> any e-mail that did not contain a valid SKSML message. >>>>>>>>>>>>> >>>>>>>>>>>>>>> 3) Are there other transports we should be considering >>>>>>>>>>>>>>> besides HTTP >>>>>>>>>>>>>>> and SMTP? >>>>>>>>>>>>>> Why tie the spec to any transport? >>>>>>>>>>>>> Good point. We're not doing that in the current DRAFT, >>>>>>>>>>>>> so we >>>>>>>>>>>>> should continue that practice. >>>>>>>>>>>>> >>>>>>>>>>>>>> I do not understand what difficulties arise in sending >>>>>>>>>>>>>> some id about the request back in the response :). I am >>>>>>>>>>>>>> just looking at usage in an asynchronous manner such as >>>>>>>>>>>>>> Async WS. >>>>>>>>>>>>>> http://java.sun.com/blueprints/webservices/using/webservbp3.html >>>>>>>>>>>>>> >>>>>>>>>>>>> No difficulty at all, Anil. The SKMS architecture does >>>>>>>>>>>>> have >>>>>>>>>>>>> a request ID assigned to each request. I just didn't >>>>>>>>>>>>> think >>>>>>>>>>>>> that a client might be interested in that information. >>>>>>>>>>>>> >>>>>>>>>>>>> Since the business use-case is to have the clients get >>>>>>>>>>>>> keys >>>>>>>>>>>>> asynchronously (essentially to not have the application >>>>>>>>>>>>> sit >>>>>>>>>>>>> there and wait for a key), here is another way of >>>>>>>>>>>>> solving the >>>>>>>>>>>>> problem (which is supported in StrongKey, but is not >>>>>>>>>>>>> emphasized >>>>>>>>>>>>> because it did not have any bearing on the standards >>>>>>>>>>>>> effort): >>>>>>>>>>>>> >>>>>>>>>>>>> The KeyCachePolicy essentially tells clients how long >>>>>>>>>>>>> they may >>>>>>>>>>>>> cache keys, as well as how frequently to check with the >>>>>>>>>>>>> SKS >>>>>>>>>>>>> server for updates to policy. >>>>>>>>>>>>> >>>>>>>>>>>>> While one tends to think of the business application >>>>>>>>>>>>> using the >>>>>>>>>>>>> Symmetric Key Client Library (SKCL) to "manage" this >>>>>>>>>>>>> cache, >>>>>>>>>>>>> technically, there is nothing to prevent a little utility >>>>>>>>>>>>> linked to the SKCL whose sole job is to manage the >>>>>>>>>>>>> cache. It >>>>>>>>>>>>> can be configured to run periodically and update the cache >>>>>>>>>>>>> with new/used keys as defined by the KCP. >>>>>>>>>>>>> >>>>>>>>>>>>> Since this "KCP-Utility" will run independently of the >>>>>>>>>>>>> business >>>>>>>>>>>>> application, in essence, even though the KCP-Utility makes >>>>>>>>>>>>> synchronous SKSML calls, the business application gets >>>>>>>>>>>>> the keys >>>>>>>>>>>>> "asynchronously". That is, when it needs a key, it >>>>>>>>>>>>> calls the >>>>>>>>>>>>> SKCL; the SKCL checks the cache, and lo & behold, there >>>>>>>>>>>>> is a key >>>>>>>>>>>>> always over there. >>>>>>>>>>>>> >>>>>>>>>>>>> The business application never has to wait >>>>>>>>>>>>> synchronously for the >>>>>>>>>>>>> SKS server to respond to a request, because the SKCL >>>>>>>>>>>>> will always >>>>>>>>>>>>> find it in the local cache. The KCP-Utility can be >>>>>>>>>>>>> configured >>>>>>>>>>>>> to run as frequently as desired on the client, so that >>>>>>>>>>>>> it is >>>>>>>>>>>>> always making synchronous requests of the SKS server, but >>>>>>>>>>>>> providing the keys to the business-application >>>>>>>>>>>>> asynchronously. >>>>>>>>>>>>> >>>>>>>>>>>>> Does this design address the business problem you have? >>>>>>>>>>>>> >>>>>>>>>>>>> Another way of dealing with this business requirement >>>>>>>>>>>>> is for >>>>>>>>>>>>> the business application to call the SKCL and make the >>>>>>>>>>>>> request. >>>>>>>>>>>>> (It would have to be a different API method in the SKCL >>>>>>>>>>>>> that >>>>>>>>>>>>> would returns a flag indicating if a key is available >>>>>>>>>>>>> locally >>>>>>>>>>>>> in the cache for use). The business-application then >>>>>>>>>>>>> goes onto >>>>>>>>>>>>> doing whatever it does while waiting for the key, but >>>>>>>>>>>>> periodically, it calls the SKCL to see if the key is >>>>>>>>>>>>> available. >>>>>>>>>>>>> If it is, then the application makes the normal SKCL >>>>>>>>>>>>> call which >>>>>>>>>>>>> returns the key from the local cache. >>>>>>>>>>>>> >>>>>>>>>>>>> In both cases, this does not require modifying the >>>>>>>>>>>>> current DRAFT >>>>>>>>>>>>> of the SKSML and does not have to require supporting >>>>>>>>>>>>> asynch >>>>>>>>>>>>> communications for the protocol. >>>>>>>>>>>>> >>>>>>>>>>>>> I have nothing against asynchronous communications, >>>>>>>>>>>>> Anil; I'm >>>>>>>>>>>>> just trying to keep the protocol simple and finding >>>>>>>>>>>>> other ways >>>>>>>>>>>>> that can solve the problem. >>>>>>>>>>>>> >>>>>>>>>>>>> If you - and others - believe that it should be in the >>>>>>>>>>>>> protocol, >>>>>>>>>>>>> then adding the request ID to the response is easy >>>>>>>>>>>>> enough. But, >>>>>>>>>>>>> we will then have to add a new message-type for polling >>>>>>>>>>>>> the SKS >>>>>>>>>>>>> server with an existing request ID. Alternatively, we >>>>>>>>>>>>> have to >>>>>>>>>>>>> modify the SKCL to receive asynchronous responses from >>>>>>>>>>>>> the SKS >>>>>>>>>>>>> server (will businesses be open to that? It will mean >>>>>>>>>>>>> having >>>>>>>>>>>>> to open up firewall ports on the client to allow SKS >>>>>>>>>>>>> messages >>>>>>>>>>>>> to reach the SKCL asynchronously). >>>>>>>>>>>>> >>>>>>>>>>>>> Arshad >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Arshad >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Anil Saldhana wrote: >>>>>>>>>>>>>>>> Hi Arshad, >>>>>>>>>>>>>>>> at least two use cases come into my mind. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> a) In enterprise software, typically transport is the >>>>>>>>>>>>>>>> variant. So I should be able to send sksml requests via >>>>>>>>>>>>>>>> smtp for example. :) With JMS for example, I may >>>>>>>>>>>>>>>> get a response later and the only thing that I will have >>>>>>>>>>>>>>>> is either the request id or the optional request element. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> b) With clients in low bandwidth and tough terrain, such >>>>>>>>>>>>>>>> as hand held devices, you cannot always rely on >>>>>>>>>>>>>>>> synchronous communication. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I would at least like to have the request id sent back >>>>>>>>>>>>>>>> from the response. That should be sufficient for clients. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> Anil >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Arshad Noor wrote: >>>>>>>>>>>>>>>>> Hi Anil, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Can you provide a business scenario where this is >>>>>>>>>>>>>>>>> necessary and >>>>>>>>>>>>>>>>> where synchronous communication with the SKS server >>>>>>>>>>>>>>>>> does not >>>>>>>>>>>>>>>>> address the problem. Thanks. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Arshad >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Anil Saldhana wrote: >>>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>>> I would like to open the discussion to the use case >>>>>>>>>>>>>>>>>> of asynchronous/batch requests for keys. This will >>>>>>>>>>>>>>>>>> require that we need to return a request id or the >>>>>>>>>>>>>>>>>> entire request (which can be an optional element) in >>>>>>>>>>>>>>>>>> the response. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>> Anil >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>>> generates this mail. Follow this link to all your TCs in OASIS at: >>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]