Issue 4197: issues in the PKI spec need to be brought into line with AMI. (pki-ftf) Source: DSTC (Mr. Simon Gibson, gibson@dstc.edu.au) Nature: Uncategorized Issue Severity: Summary: The detail to which the specification deals with issues regarding asynchronous messaging. The specification deals directly with concepts concerned with Asynchronous Message Invocation (AMI) and issues in the PKI spec need to be brought into line with AMI. Resolution: see above Revised Text: Actions taken: February 5, 2001: received issue July 5, 2002: closed issue Discussion: Simply, the changes proposed simplify the interfaces in PKIAuthority by removing anything related to callbacks and polling not using AMI. This simplifies the specification dramatically. Specifically changes proposed are: 1) IDL Changes a) Remove interface RegistrationAuthority_CB b) Remove interface CertificateAuthority_CB c) Remove interface CertificateCallback d) Remove interface RevocationCallback e) Remove interface KeyUpdateCallback f) Remove interface KeyRecoveryCallback 2) Text Changes a) Remove section 2.3.2 RegistrationAuthority_CB b) Remove section 2.3.4 CertificateAuthority_CB c) Remove section 2.3.10 CertificateCallback d) Remove section 2.3.11 RevocationCallback e) Remove section 2.3.12 KeyUpdateCallback f) Remove section 2.3.13 KeyRecoveryCallback g) Modify Paragraph 2 in section 1.4 removing references to callback or polling to: "In addressing the interactive nature of PKI messaging additional interfaces have been added. These are the RequestManager interfaces. A RequestManager object is created by the authority. This is then used for any subsequent operations and status enquiries for a particular request. Asynchronous behaviorcan be addressed by using Asynchronous Method Invocation (AMI) described in CORBA Messaging." h) Modify Figure 1-2 removing Callback object and associated text. i) Remove the term Polling is section 1.4.3 to "Certificate Request". j) Remove section 1.4.4 Certificate Request Using a Callback k) Modify text in section 1.6.2 to: "A significant design decision for this specification was in addressing the potential for asynchronous behavior combined with the potential for a level of interactivity between client and target entities. Each certification domain will have its own policy with which to manage certificate functionality. Depending on this policy it is possible for significant delays to occur between an initial request and a returned result due to the possible need for an out of band exchange. For example, a CA may require that a phone call or some interaction via email is made as part of the authentication process adding a significant delay. A synchronous invocation may block during this delay. This can be handled using an AMI aware ORB or simply ignored and wait for the invocation to be returned. The potential for interactivity between an authority (CA or RA) and a client is also possible. An example of this interactivity might be where a certificate request has been made using a public key, the authority requires assurance that the client is in possession of the associated private key and policy dictates the use of a challenge response. This will require an extra exchange of messages and that the client may also be directly involved (by needing to supply a passphrase to unlock the private key). This interactivity for a request is addressed using the RequestManager interfaces. When a request is initiated a RequestManager object reference is returned, and this is used to perform further interaction, status checking, or to return results for that particular request. The interaction of client and authority entities in a PKI domain is typically a combination of both an interactive dialogue, with state being maintained on the server side, combined with asynchronous messaging behavior. The RequestManager interface is created by the authority and encapsulates everything that relates to this a particular request. The client entity receives a reference to a interface after an initial request and continues to use it for as long as the request is outstanding. Resources related to RequestManagers can be reclaimed by the CertificateAuthority or RegistrationAuthority after either a status of either PKISuccess, PKISuccessWithWarning or PKIFailed. For a status of PKISuccessAfterConfirm the resources can be reclaimed after the confirm_content() operation has been invoked." End of Annotations:===== From: webmaster@omg.org Message-Id: <200102060226.f162Qkr19189@emerald.omg.org> Date: 05 Feb 2001 22:27:59 -0500 To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Issue/Bug Report Content-Type: Text/html; charset=windows-1252 X-UIDL: I5@!![;Od9Oip!!24K!! Name: Simon Gibson Company: DSTC mailFrom: gibson@dstc.edu.au Notification: No Specification: Public Key Infrastructure Section: 1.6.2 FormalNumber: dtc/2001-02-01 Version: 1 RevisionDate: 02/01/2001 Page: 1-9 Nature: Revision Severity: Significant HTTP User Agent: Mozilla/4.75 [en] (X11; U; SunOS 5.8 sun4u) Description The detail to which the specification deals with issues regarding asynchronous messaging. The specification deals directly with concepts concerned with Asynchronous Message Invocation (AMI) and issues in the PKI spec need to be brought into line with AMI. X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: pmclaughlin@baltimore.com (Patrick McLaughlin), polar@adiron.com (Polar Humenn), gjarboe@promia.com (Gene Garboe), cwbinko@trcinc.com (Bill Binko), mcconnell@osm.net (Stephen McConnell), dflinn@iona.com (Don Flinn), Ronald.Monzillo@east.sun.com (Ron Monzillo), gibson@dstc.edu.au (Simon Gibson), christopher_milsom@hp.com (Christopher Milsom) cc: pki-ftf@emerald.omg.org Subject: PKI FTF issue # 4197 Mime-Version: 1.0 Date: Thu, 15 Feb 2001 09:02:47 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: <Manager_L2 interfaces deriving from equivalent interface in PKIAuthority. Adding operations void register_callback(in callback) void unregister_callback(in callback) PKI::PKIStatus get_request__result_L2 (in long timeout, ) Where timeout indicates length of time to wait before returning regardless of result status. 0 means return straight away, MAX_INT wait forever. iii) (IDL change) Remove all interfaces that have the _CB postfix. iv) (IDL change) In struct PKIAuthority::AuthorityProviderInfo remove field boolean callbackSupport v) (IDL change) Add exception PKIAuthorityLevel2::InvalidPollingException Exception used for reporting invalid use of polling. For example this exception is thrown if a callback object is registered with the Request*Manager_L2, and a call is made to get_certificate_*_result_L2. vi) Remove final 2 paragraphs from Section 1.6.2 and replace with the following. Note that this includes proposed changes for issue # 4195. The interaction between client and target is potentially a combination of both an interactive dialogue, with state held on the target side, combined with asynchronous messaging behaviour due to potentially lengthy delays. To handle interactive behaviour this specification provides RequestManager interfaces that are used to encapsulate all interaction related to a particular request. In this way the RequestManager is in effect providing functionality equivalent to a unique identifier. Existing PKI implementations may actually use unique identifiers for each transaction and this is made available to the client through the transaction_ID attribute, but in the CORBA environment a specific unique identifier is not required. Resources related to RequestManagers can be reclaimed by the CertificateAuthority or RegistrationAuthority after both a status of either PKISuccess, PKISuccessWithWarning or PKIFailed is obtained and a call to get__result has been made. For a status of PKISuccessAfterConfirm the resources can be reclaimed after the confirm_content operation has been invoked. To handle asynchronous behaviour the CORBA Asynchronous Message Invocation (AMI) standard addresses these issues completely. However currently AMI aware ORBs are not common place and so this specification adds the PKIAuthorityLevel2 module that provides interfaces for asynchronous behaviour by polling or client side callback objects. This module is to be deprecated when such time as AMI is ubiquitous. The PKIAuthorityLevel2 module describes new RequestManager_L2 interfaces that inherit operations from their counter parts in the PKIAuthority module. The new interfaces allow callback objects to be registered and unregistered and also provide an operation to obtain results. This operation is similar to the base interface but has an extra parameter for a timeout. The reason for a timeout parameter is due to a change in semantics with regard to polling for a result. Using an AMI aware ORB the server side is not changed in any way and so a long running asynchronous operation simply does not return until complete. In client side polling a result should return regardless of whether the server side operation is complete. An AMI aware ORB will create a poller object for this and allow the invocation to return even though the server side has not actually returned a result. To allow polling in a non AMI aware ORB the client uses the getresult_L2 operation stating a timeout to wait before returning i.e. 0 to return immediately, MAX_INT to wait forever or anything in between. vii) Replace 1.4.3, 1.4.4 and add 1.4.5 with 1.4.3 Certificate Request (Using AMI) The following example is that of a client making a request to have a certificate issued by a CA or RA. After constructing a certificate request message, using a supported standard, the message can be encapsulated and invoked through the request_certificate operation. This returns a reference to a RequestCertificateManager object. Results are obtained using get_certificate_request_result operation. To use polling or callbacks on this operation use the AMI aware ORB functionality that provides this. After processing, if more interaction is required, (for example proving possession of the private key through a challenge response) then this is made through the same manager object using the continue_request_certificate operation until a success (or failure) is reached. To use polling or callbacks on this operation use the AMI aware ORB functionality that provides this. 1.4.4 Polling Certificate Request (Non AMI) The following example is that of a client making a request to have a certificate issued by a CA or RA without an AMI aware ORB using the extra functionality provided in module PKIAuthorityLevel2. After constructing a certificate request message, using a supported standard, the message can be encapsulated and invoked through the request_certificate operation. This returns a reference to a RequestCertificateManager object. The client can narrow the object reference to that of PKIAuthorityLevel2::RequestCertificateManager_L2. (Note: If the narrow fails, indicating the server side must not support PKIAuthorityLevel2, then without an AMI aware ORB the base operation of get_certificate_request_result can still be used but the call will hang until a result is available). The client can then poll using get_certificate_request_result_L2 operation and check the status until a change occurs. Results can then be processed. After processing, if more interaction is required, (for example proving possession of the private key through a challenge response) then this is made through the same manager object using the continue_request_certificate operation until a success (or failure) is reached. 1.4.5 Certificate Request Using A Callback (Non AMI) This example uses a call back to request issuance of a certificate from an authority without an AMI aware ORB using the extra functionality provided in module PKIAuthorityLevel2. After constructing a request, using a supported standard, the message can be encapsulated and invoked through the request_certificate operation. A reference to a RequestCertificateManager object is also returned (as in the above example) to be used if more interaction is required for this request. The client can narrow the object reference to that of PKIAuthorityLevel2::RequestCertificateManager_L2. The client can create a CertificateCallback object and register it with the RequestCertificateManager_L2 object. (Note: If the narrow fails, indicating the server side must not support PKIAuthorityLevel2, then without an AMI aware ORB the base operation of get_certificate_request_result can still be used but the call will hang until a result is available). The client can then wait (or perform other tasks) until the callbacks notify_result operation is called by the target. Once notified the results can be processed. After processing, if more interaction is required, (for example proving possession of the private key through a challenge response) then this is made through the manager object using the continue_request_certificate operation until a success (or failure) is reached, again using the callback object for notification from the target unless it is unregistered. X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: pmclaughlin@baltimore.com (Patrick McLaughlin), polar@adiron.com (Polar Humenn), gjarboe@promia.com (Gene Garboe), cwbinko@trcinc.com (Bill Binko), mcconnell@osm.net (Stephen McConnell), dflinn@iona.com (Don Flinn), Ronald.Monzillo@east.sun.com (Ron Monzillo), gibson@dstc.edu.au (Simon Gibson), christopher_milsom@hp.com (Christopher Milsom) cc: pki-ftf@emerald.omg.org Subject: Request Comments on Proposed Solution issue #4197 Mime-Version: 1.0 Date: Wed, 27 Jun 2001 14:39:32 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: Up&e9Xo*!!BX@!!SIDe9 This is issue # 4197 Simon Gibson gibson@dstc.edu.au issues in the PKI spec need to be brought into line with AMI. The detail to which the specification deals with issues regarding asynchronous messaging. The specification deals directly with concepts concerned with Asynchronous Message Invocation (AMI) and issues in the PKI spec need to be brought into line with AMI. -------------------------------- Proposed Solution Back in February (the 15th) I proposed a solution for this. In short it involved adding a new module "PKIAuthorityLevel2" and move everything related to AMI into it with the plan to deprecate at a later date when AMI was ubiquitous. I now think that the best solution would be to remove anything related to callbacks and polling completely and leave it at that. This cleans up the spec dramatically and makes it more usable. Asynchronicity is still an issue but I guess use AMI or each implementor could do it in the application. In essence these changes are to remove anything with _CB postfix and the Callback postfix. There would also be text changes to the doc to reflect this. I can outline this specifically later. I would be interested in any opinions on this. My feelings are that requesting a certificate in the general case where it could take a long time are only done irregularly as normal id certs have a reasonable lifetime. I have been using the pki interfaces for an access control mechanism using the RAD interfaces and generating attribute certificates for access control enforcement which are short lived tickets and so simplifying the interface is desirable and asynchronous behaviour is not an issue. Simon =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-==-=-=- Simon Gibson, Telephone: +61 7 3864 5120 Research Scientist, Security Unit, Facsimile: +61 7 3864 1282 CRC for Enterprise Distributed Systems Technology (DSTC Pty Ltd), Queensland University of Technology, Brisbane Qld 4001, Australia. email: DSTC is W3C's Australian Office http://www.dstc.edu.au =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: pmclaughlin@baltimore.com (Patrick McLaughlin), polar@adiron.com (Polar Humenn), gjarboe@promia.com (Gene Garboe), cwbinko@trcinc.com (Bill Binko), mcconnell@osm.net (Stephen McConnell), dflinn@iona.com (Don Flinn), Ronald.Monzillo@east.sun.com (Ron Monzillo), gibson@dstc.edu.au (Simon Gibson), christopher_milsom@hp.com (Christopher Milsom) cc: pki-ftf@emerald.omg.org Subject: Request Vote on Issue #4197 Mime-Version: 1.0 Date: Fri, 06 Jul 2001 16:43:57 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: pl+!!~kU!!P4C!![hT!! This is issue # 4197 Simon Gibson gibson@dstc.edu.au issues in the PKI spec need to be brought into line with AMI. The detail to which the specification deals with issues regarding asynchronous messaging. The specification deals directly with concepts concerned with Asynchronous Message Invocation (AMI) and issues in the PKI spec need to be brought into line with AMI. -------------------------------- Proposed Solution This in essence removes anything to do with polling or callbacks. Specifically the following sections have been modified with relation to this issue. The changes are reflected in the document sent in my previous post. The specific changes for this issue are summarised as: Section 1.4 Modify paragraphs 2 and 3 Modify diagram Figure 1-2 Section 1.4.3 Modify bullet point 2 Section 1.4.4 Remove Section 1.4.4 Section 1.6.2 Modify paragraphs 1,3 and add paragraph 4. Section 2.3 Remove Section 2.3.2 Remove section 2.3.4 Remove Section 2.3.10 Remove Section 2.3.11 Remove Section 2.3.12 Remove Section 2.3.13 Appendix A Remove Exception InvalidCallBackException Remove interface RegistrationAuthority_CB Remove interface RequestRevocationManager_CB Remove interface RequestUpdateManager_CB Remove interface RequestRecoveryManager_CB Remove interface CertificateAuthority_CB Remove interface CertificateCallback Remove interface RevocationCallback Remove interface KeyUpdateCallback Remove interface KeyRecoveryCallbck Appendix B Remove complete appendix Simon X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: pmclaughlin@baltimore.com (Patrick McLaughlin), polar@adiron.com (Polar Humenn), gjarboe@promia.com (Gene Garboe), cwbinko@trcinc.com (Bill Binko), mcconnell@osm.net (Stephen McConnell), Ronald.Monzillo@east.sun.com (Ron Monzillo), gibson@dstc.edu.au (Simon Gibson), christopher_milsom@hp.com (Christopher Milsom), IBalabine@iona.com (Igor Balabine) cc: pki-ftf@omg.org Subject: Vote on issue 4197 Mime-Version: 1.0 Date: Wed, 07 Nov 2001 12:13:23 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: ;_j!!Z3E!!IL1e9/+He9 Hi There, This is an issue regarding the use of AMI. When we authored this specification we felt it was important to deal with asynchronous behaviour. AMI can address these issues we had and so this issue is about removing all references to asynchronous or polling behaviour. This really simplifies the IDL and specification. Simon ----------------------------- Issue 4197: issues in the PKI spec need to be brought into line with AMI. (pki-ftf) Click here for this issue's archive. Source: DSTC (Mr. Simon Gibson, gibson@dstc.edu.au) Nature: Uncategorized Issue Severity: Summary: The detail to which the specification deals with issues regarding asynchronous messaging. The specification deals directly with concepts concerned with Asynchronous Message Invocation (AMI) and issues in the PKI spec need to be brought into line with AMI. Proposed Resolution: Simply, the changes proposed simplify the interfaces in PKIAuthority by removing anything related to callbacks and polling not using AMI. This simplifies the specification dramatically. Specifically changes proposed are: 1) IDL Changes a) Remove interface RegistrationAuthority_CB b) Remove interface CertificateAuthority_CB c) Remove interface CertificateCallback d) Remove interface RevocationCallback e) Remove interface KeyUpdateCallback f) Remove interface KeyRecoveryCallback 2) Text Changes a) Remove section 2.3.2 RegistrationAuthority_CB b) Remove section 2.3.4 CertificateAuthority_CB c) Remove section 2.3.10 CertificateCallback d) Remove section 2.3.11 RevocationCallback e) Remove section 2.3.12 KeyUpdateCallback f) Remove section 2.3.13 KeyRecoveryCallback g) Modify Paragraph 2 in section 1.4 removing references to callback or polling to: "In addressing the interactive nature of PKI messaging additional interfaces have been added. These are the RequestManager interfaces. A RequestManager object is created by the authority. This is then used for any subsequent operations and status enquiries for a particular request. Asynchronous behaviorcan be addressed by using Asynchronous Method Invocation (AMI) described in CORBA Messaging." h) Modify Figure 1-2 removing Callback object and associated text. i) Remove the term Polling is section 1.4.3 to "Certificate Request". j) Remove section 1.4.4 Certificate Request Using a Callback k) Modify text in section 1.6.2 to: "A significant design decision for this specification was in addressing the potential for asynchronous behavior combined with the potential for a level of interactivity between client and target entities. Each certification domain will have its own policy with which to manage certificate functionality. Depending on this policy it is possible for significant delays to occur between an initial request and a returned result due to the possible need for an out of band exchange. For example, a CA may require that a phone call or some interaction via email is made as part of the authentication process adding a significant delay. A synchronous invocation may block during this delay. This can be handled using an AMI aware ORB or simply ignored and wait for the invocation to be returned. The potential for interactivity between an authority (CA or RA) and a client is also possible. An example of this interactivity might be where a certificate request has been made using a public key, the authority requires assurance that the client is in possession of the associated private key and policy dictates the use of a challenge response. This will require an extra exchange of messages and that the client may also be directly involved (by needing to supply a passphrase to unlock the private key). This interactivity for a request is addressed using the RequestManager interfaces. When a request is initiated a RequestManager object reference is returned, and this is used to perform further interaction, status checking, or to return results for that particular request. The interaction of client and authority entities in a PKI domain is typically a combination of both an interactive dialogue, with state being maintained on the server side, combined with asynchronous messaging behavior. The RequestManager interface is created by the authority and encapsulates everything that relates to this a particular request. The client entity receives a reference to a interface after an initial request and continues to use it for as long as the request is outstanding. Resources related to RequestManagers can be reclaimed by the CertificateAuthority or RegistrationAuthority after either a status of either PKISuccess, PKISuccessWithWarning or PKIFailed. For a status of PKISuccessAfterConfirm the resources can be reclaimed after the confirm_content() operation has been invoked." Revised Text: Actions taken: February 5, 2001: received issue ----------------------------- Y/N/Abstain | | ---------------------------------------------------------------------------