[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
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]