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

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

As promised, here is a zip file that contains the modified
XSD to include support for asynchronous request/responses
between SKMS clients and servers.

Here is a synopsis of the change notes in the 3 files I've
included in the zip-file:

EKMICoreLibrary.xsd
-------------------

01) Created the SymkeyWorkInProgressType to support asynchronous
     requests and responses between SKCLs and SKS servers.  While
     the SKSML request will still be enclosed in a SOAP element
     with a digital signature, the request may now be sent over
     other protocols besides HTTP (such as SMTP).

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.

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