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