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