Re: [ekmi] Request ID or entire request in sksml response

[Arshad Noor <arshad.noor@strongauth.com>]

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