[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,
I have a doubt.
===========================================================
<xsd:element name="SymkeyResponse">
<xsd:complexType>
<xsd:choice>
<xsd:sequence>
<xsd:element ref="ekmi:Symkey" minOccurs="1"
maxOccurs="unbounded"/>
<xsd:element ref="ekmi:SymkeyError" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="ekmi:SymkeyWorkInProgress"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:sequence>
<xsd:element ref="ekmi:SymkeyError" minOccurs="1"
maxOccurs="unbounded"/>
<xsd:element ref="ekmi:SymkeyWorkInProgress"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:sequence>
<xsd:element ref="ekmi:SymkeyWorkInProgress"
minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:choice>
</xsd:complexType>
</xsd:element>
===========================================================
What this is saying is that:
<ekmi:SymkeyResponse>
<ekmi:SymKey/>
<ekmi:SymKeyWorkInProgress/>
</ekmi:SymkeyResponse>
or
<ekmi:SymkeyResponse>
<ekmi:SymKeyError/>
<ekmi:SymKeyWorkInProgress/>
</ekmi:SymkeyResponse>
or
<ekmi:SymkeyResponse>
<ekmi:SymKey/>
<ekmi:SymKeyError/>
</ekmi:SymkeyResponse>
are all valid constructs.
Regards,
Anil
Tomas Gustavsson wrote:
>
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]