Issue 4444: PKI Repository issue (pki-ftf) Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) Nature: Uncategorized Issue Severity: Significant Summary: After going through the PKI Repository module in more detail I'm running into a number of problems concerning implied implementation approach that is forced on the developer (effectively the implied implementation is an LDAP directory). It seems that the Repository is defined with the assumption that (a) storage slot attribute names are passed as parameters and (b) the storage values for attributes are always an any. This complicates the implementation approach if you have alternative "more structured" storage systems available (e.g. PSS - for example, using PSS I can store CORBA values and object references directly with complete type safety and practically zero additional code. This "implementation constraint" is a supposedly "implementation independent" spec is a significant issue. Resolution: see above Revised Text: The changes proposed cause the following text changes in the document. a) Replace the first paragraph in Chapter 1.6.3 Repository with the following 2 paragraphs: "The repository is a service where information can be stored and retrieved. Primarily this is used for storage and retrieval of principal information such as certificates. It is also commonly used to store information such as Certificate Revocation Lists (CRLs). Effectively there are 2 definitions of repository interfaces in this specification. There is a simple interface described in PKIRepository and also a more intricate interface that is designed to be able to interact with repositories that are based around X500 and LDAP implementations. The simplified version is hoped to be the more commonly used interface allowing implementors and clients to interact with ease. However since the backend could well be LDAP or X500 in existing services that may be wrapped by these interfaces the PKIExtension module allows for this interaction. The operations in PKIRepository are simple and self explanatory but the PKIExtension module contains a more detailed approach. "The PKIExtension module describes a data storage service which generally has a schema that mandates the form and the content of the data stored therein. As much as possible, the type of repository implementation, and the exact details of the schema that oversees the data storage service, should be hidden from the client of the PKI repository service. In general, when a client wishes to publish information in the repository, it is assumed that the repository implementation has enough information to create the appropriate entry in the underlying data storage service according to the back-end schema. However, it may be the case that a repository implementation cannot gather the required information in order to create an entry for a principal when a request is made by the client to store information in the repository. For example, a database implementation of the PKI repository may require that all entries contain a value for the "favorite milkshake" field. In such cases, the repository implementation may ask for further information from the client. The PKIPrincipal type in the IDL allows the client to pass additional attribute information as required." etc. b) Current 2.4 moved to 2.5 Module PKIExtension. c) 2.4.1 Interface Repository moved to 2.5.1 Interface LDAPRepository d) New chapter 2.4 will contain text describing new simplified interface. 2.4.1 PKIPrincipalValue "Valuetype supporting fields containing relevant information related to a particular principal." 2.4.2 Interface Repository "Interface for storage and retrieval of certificates and CRLs." 2.4.2.1 attribute RepositoryProviderInfo info "Operation to return a valuetype containing information pertaining to this particular repository implementation." 2.4.2.2 publish "Enter a new PKIPrincipalValue into the repository." 2.4.2.3 locate "Get a PKIPrincipalValue for a particular name." 2.4.2.4 delete "Deletes a principal in the repository using name as the lookup key." 2.4.2.5 update "Replaces an existing principal in the repository with the supplied PKIPrincipalValue object." Actions taken: August 2, 2001: received issue July 5, 2002: closed issue Discussion: Simplify implementation for the Repository by creating a simplified interface that is friendly to other possible implementations such as the Persistent State Storage. However it is important to keep the LDAP-centric current definition to still handle the case where LDAP is used providing operations for dealing with finer grained details. In essence propose we have 2 modules one for a new simpler interface and ane for the current repository IDL. module PKIRepository { // contain simplified interfaces and valuetypes }; module PKIExtension { // current repository stuff }; In detail: ----------------------- // PKIRepository.idl #ifndef __PKIREPOSITORY_IDL #define __PKIREPOSITORY_IDL #include <PKI.idl> #pragma prefix "omg.org" module PKIRepository { valuetype RepositoryProviderInfo { public string standardDescription; public string standardVersion; public string productDescription; public string productVersion; public string productVendor; public PKI::CertificateInfoList supportedCertificates; public PKI::CRLInfoList supportedCRLs; public PKI::CertificateInfoList supportedCrossCertificates; }; exception UnknownPrincipal { string name; }; exception RepositoryError { string name; }; exception DuplicatePrincipal { string name; }; valuetype PKIPrincipalValue { private string name; private PKI::CertificateList certificates; private PKI::CertificatePairList; private PKI::CRL crl; private PKI::CRL delta; private PKI::CRL arl; }; interface Repository { readonly attribute RepositoryProviderInfo info; void publish( in PrincipalValue principal ) raises ( DuplicatePrincipal, RepositoryError ); PKIPrincipalValue locate ( in string name ) raises ( UnknownPrincipal, RepositoryError ); void delete ( in string name ) raises ( UnknownPrincipal, RepositoryError ); void update ( in PrincipalValue principal ) raises ( UnknownPrincipal, RepositoryError); }; }; #endif ------------------------ // PKIExtension.idl #include<PKI.idl> #include<PKIRepository.idl> module PKIExtension { // current repository stuff valuetype RepositoryMappingInfo { public string user_attribute_name; public string ca_attribute_name; public string crl_attribute_name; public string certificatePair_attribute_name; public string deltaCRL_attribute_name; public string arl_attribute_name; }; typedef string PKIName; typedef sequence <PKIName> PKINameList; struct PKIAttribute { string name; any value; }; typedef sequence <PKIAttribute> PKIAttributeList; struct PKIPrincipal { PKIName name; PKIAttributeList attributes; }; struct Schema { PKIAttributeList attribute_defs; PKIAttributeList syntax_defs; }; enum PrincipalAttributeErrorReason { MissingPKIAttributes, InvalidPKIAttributes }; exception PrincipalAttributeError { PrincipalAttributeErrorReason reason; PKIPrincipal principal; PKINameList attribute_names; }; // rename to LDAPRepository interface LDAPRepository : PKIRepository::Repository { // New method RepositoryMappingInfo mapping(); Schema get_schema(); void publish_certificate( in PKIPrincipal principal, in PKI::Certificate certificate, in string attr_name) raises (PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CertificateList get_certificate( in PKIPrincipal principal, in string attr_name) raises (PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_certificate( in PKIPrincipal principal, in PKI::Certificate certificate, in string attr_name) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_crl(in PKIPrincipal principal, in PKI::CRL crl, in string attr_name) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CRL get_crl(in PKIPrincipal principal, in string attr_name) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_crl(in PKIPrincipal principal, in PKI::CRL crl,in string attr_name) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_certificate_pair( in PKIPrincipal principal, in PKI::CertificatePair certPair, in string attr_name) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CertificatePairList get_certificate_pair( in PKIPrincipal principal, in string attr_name) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_certificate_pair( in PKIPrincipal principal, in PKI::CertificatePair certificate_pair, in string attr_name) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_user_certificate(in PKIPrincipal principal, in PKI::Certificate certificate) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CertificateList get_user_certificate(in PKIPrincipal principal) raises(UnknownPrincipal,RepositoryError); void delete_user_certificate(in PKIPrincipal principal, in PKI::Certificate certificate) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_ca_certificate( in PKIPrincipal principal, in PKI::Certificate certificate) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CertificateList get_ca_certificate(in PKIPrincipal principal) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_ca_certificate(in PKIPrincipal principal, in PKI::Certificate certificate) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_default_crl(in PKIPrincipal principal, in PKI::CRL crl) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CRL get_default_crl(in PKIPrincipal principal) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_default_crl(in PKIPrincipal principal, in PKI::CRL crl) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_default_certificate_pair(in PKIPrincipal principal, in PKI::CertificatePair certificate_pair) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CertificatePairList get_default_certificate_pair( in PKIPrincipal principal) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_default_certificate_pair(in PKIPrincipal principal, in PKI::CertificatePair certificate_pair) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_delta_crl(in PKIPrincipal principal, in PKI::CRL delta_crl) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CRL get_delta_crl(in PKIPrincipal principal) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_delta_crl(in PKIPrincipal principal, in PKI::CRL delta_crl) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_arl(in PKIPrincipal principal, in PKI::CRL arl) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CRL get_arl(in PKIPrincipal principal) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_arl(in PKIPrincipal principal, in PKI::CRL arl) raises(PKIRepository::UnknownPrincipal, RPKIRepository::epositoryError); }; }; End of Annotations:===== From: "Stephen McConnell" To: Subject: PKI Repository issue (biggish email) Date: Thu, 2 Aug 2001 09:37:02 +0200 Message-ID: <000501c11b25$eb7444d0$0a01a8c0@osm.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <000001c11b08$99d78050$0a01a8c0@osm.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Content-Type: text/plain; charset="Windows-1252" X-UIDL: %`)e9~dYd9:A!!!T?*!! After going through the PKI Repository module in more detail I'm running into a number of problems concerning implied implementation approach that is forced on the developer (effectively the implied implementation is an LDAP directory). It seems that the Repository is defined with the assumption that (a) storage slot attribute names are passed as parameters and (b) the storage values for attributes are always an any. This complicates the implementation approach if you have alternative "more structured" storage systems available (e.g. PSS - for example, using PSS I can store CORBA values and object references directly with complete type safety and practically zero additional code. This "implementation constraint" is a supposedly "implementation independent" spec is a significant issue. A solution to this issue is to separate the operations and structures that assume LDAP from the implementation independent operations and structures into different modules and to include an appropriate compliance statement. An initial assessment suggested that the existing operations could be split to reflect the different concerns, however, tf you take a look at the operations in the Repository interface you come up with a list of operations that require attribute parameters and those that don't. Operations that set attributes where the cardinality of the value relative to the PKIPrincipal is 1 do not expose the attribute parameter, however, the operations dealing with the publication, location and deletion of user and CA certificates (where cardinality is *) require attribute names to be passed in (i.e. the attribute names define the keys for the values). So, to summarise the issue: - the definition of Repository, PKIPrincipal and elements of RepositoryProviderInfo force an implementation approach that is friendly to LDAP but decidedly unfriendly to alternative storage system implementations, and secondly, the approach forces a significantly higher number of remote invocations (while at the same time providing the benefit of fine-grain operation granularity) A very clean solution to this problem would be to define a super-type to Repository that is implementation independent, together with conformance criteria that separates LDAP oriented services as an optional compliance point. Here is an example of an implementation independent Repository interface and valuetype that could be used in conjunction with the current Repository interface - I've used the name "Repository" as the super-type, and LDAPRepository as the sub-type: // Definition of the principal datastructure as a single // valuetype so we can get all of the information for a given // principal in one hit valuetype PKIPrincipalValue { private string name; private PKI::CertificateList certificates; private PKI::CertificatePairList; private PKI::CRL crl; private PKI::CRL delta; private PKI::CRL arl; } interface Repository { readonly attribute RepositoryProviderInfo info; void publish( in PrincipalValue principal; ) throws ( DuplicatePrincipal, RepositoryError ); PrincipalValue locate ( in string name; ) throws ( UnknownPrincipal, RepositoryError ); void delete ( in string name; ) throws ( UnknownPrincipal, RepositoryError ); void update ( in PrincipalValue principal; ) throws ( UnknownPrincipal, RepositoryError ); } // The following is a fragment based on the existing Repository // interface with a minor modification to the inheritance graph // and info accessor. The inheritance is modified such that // it is a specialisation of the Repository defined above, and the // info accessor is provided to enable access to attribute name // mapping information. interface LDAPRepository : Repository { // // accessor for the info dealing with attribute name mapping // that is currently declared inside RepositoryProviderInfo // readonly attribute RepositoryMappingInfo map; // // the rest is as is currently specified // } Finally, to complete the service/implementation separation we need to break the current RepositoryProviderInfo into two separate structures (one containing the general information and one containing the implementation related information). valuetype RepositoryProviderInfo { // // equivalent to the current RepositoryProviderInfo // without attribute name declarations // public string standardDescription; public string standardVersion; public string productDescription; public string productVersion; public string productVendor; public PKI::CertificateInfoList supportedCertificates; public PKI::CRLInfoList supportedCRLs; public PKI::CertificateInfoList supportedCrossCertificates; }; valuetype RepositoryMappingInfo { // // without attribute name declarations from the // the current RepositoryProviderInfo struct // public string user_attribute_name; public string ca_attribute_name; public string crl_attribute_name; public string certificatePair_attribute_name; public string deltaCRL_attribute_name; public string arl_attribute_name; }; Finally, I think that the implementation independent interface should be separated from LDAP oriented interfaces through a module - PKIRepository for the implementation independent interfaces and PKIExtension for the LDAP oriented extensions. Summary of the solution: ======================== >From the point of view of an LDAP oriented implementation the above refactoring of the IDL adds the requirement for implementation of operations supporting publication of, access to, updating, and deletion of principals (one hit operations respectively). This should not pose any problem. From the perspective of the non-LDAP implementation this change means that approximately 27 repository operations would no-longer be required (and that's *good* news). Actions ======= I'll continue to go through the other modules of the PKI spec on the assumption that the proposed changes are not likely to cause and problems -- i.e. I'm assuming quick feedback if there are problems with the above. For reference I'm maintaining a set of IDL sources that include changes I've been discussing - if anyone wants a copy just post an email and I'll shoot them through. If there's no substantive discussion on this in the next couple of days I'll go ahead and post this as an issue to the OMG for FTF resolution ASAP. Cheers, Steve. Stephen J. McConnell, OSM sarl digital products for a global economy http://www.osm.net mailto:mcconnell@osm.net X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Stephen McConnell" cc: pki-ftf@emerald.omg.org, gibson@dstc.qut.edu.au Subject: Re: PKI Repository issue (biggish email) In-Reply-To: Message from "Stephen McConnell" of "Thu, 02 Aug 2001 09:37:02 +0200." <000501c11b25$eb7444d0$0a01a8c0@osm.net> Mime-Version: 1.0 Date: Mon, 06 Aug 2001 15:18:15 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: BkH!!^l_d9+b:!!jY:e9 Stephen, Firstly when we put together the Repository stuff it had a focus of LDAP as this is the common case but is/should be independent of that. What you have looks pretty cool but I do have reservations about the changes and whether they are applicable in an FTF. I will have to have a better look at it and find out whether we can do it. One comment now though is that LDAPRepository isn't quite accurate as its still not tied to LDAP strictly speaking, but I can see the overall use of a generic simple interface. If there is consensus with this we may well be able to sort it along these lines. Simon > > After going through the PKI Repository module in more detail I'm > running > into a number of problems concerning implied implementation approach > that is > forced on the developer (effectively the implied implementation is > an LDAP > directory). It seems that the Repository is defined with the > assumption > that (a) storage slot attribute names are passed as parameters and > (b) the > storage values for attributes are always an any. This complicates > the > implementation approach if you have alternative "more structured" > storage > systems available (e.g. PSS - for example, using PSS I can store > CORBA > values and object references directly with complete type safety and > practically zero additional code. > > This "implementation constraint" is a supposedly "implementation > independent" spec is a significant issue. > > A solution to this issue is to separate the operations and > structures that > assume LDAP from the implementation independent operations and > structures > into different modules and to include an appropriate compliance > statement. > An initial assessment suggested that the existing operations could > be split > to reflect the different concerns, however, tf you take a look at > the > operations in the Repository interface you come up with a list of > operations > that require attribute parameters and those that don't. Operations > that set > attributes where the cardinality of the value relative to the > PKIPrincipal > is 1 do not expose the attribute parameter, however, the operations > dealing > with the publication, location and deletion of user and CA > certificates > (where cardinality is *) require attribute names to be passed in > (i.e. the > attribute names define the keys for the values). > > So, to summarise the issue: > > - the definition of Repository, PKIPrincipal and elements of > RepositoryProviderInfo force an implementation approach that > is friendly to LDAP but decidedly unfriendly to alternative > storage system implementations, and secondly, the approach > forces a significantly higher number of remote invocations > (while at the same time providing the benefit of fine-grain > operation granularity) > > A very clean solution to this problem would be to define a > super-type > to Repository that is implementation independent, together with > conformance criteria that separates LDAP oriented services as an > optional compliance point. > > Here is an example of an implementation independent Repository > interface and valuetype that could be used in conjunction with > the current Repository interface - I've used the name "Repository" > as > the super-type, and LDAPRepository as the sub-type: > > > // Definition of the principal datastructure as a single > // valuetype so we can get all of the information for a given > // principal in one hit > > valuetype PKIPrincipalValue > { > private string name; > private PKI::CertificateList certificates; > private PKI::CertificatePairList; > private PKI::CRL crl; > private PKI::CRL delta; > private PKI::CRL arl; > } > > interface Repository > { > readonly attribute RepositoryProviderInfo info; > > void publish( > in PrincipalValue principal; > ) throws ( > DuplicatePrincipal, RepositoryError > ); > > PrincipalValue locate ( > in string name; > ) throws ( > UnknownPrincipal, RepositoryError > ); > > void delete ( > in string name; > ) throws ( > UnknownPrincipal, RepositoryError > ); > > void update ( > in PrincipalValue principal; > ) throws ( > UnknownPrincipal, RepositoryError > ); > } > > // The following is a fragment based on the existing Repository > // interface with a minor modification to the inheritance graph > // and info accessor. The inheritance is modified such that > // it is a specialisation of the Repository defined above, and > the > // info accessor is provided to enable access to attribute name > // mapping information. > > interface LDAPRepository : Repository > { > > // > // accessor for the info dealing with attribute name mapping > // that is currently declared inside > RepositoryProviderInfo > // > > readonly attribute RepositoryMappingInfo map; > > // > // the rest is as is currently specified > // > > } > > Finally, to complete the service/implementation separation we need > to break > the > current RepositoryProviderInfo into two separate structures (one > containing > the > general information and one containing the implementation related > information). > > valuetype RepositoryProviderInfo > { > > // > // equivalent to the current RepositoryProviderInfo > // without attribute name declarations > // > > public string standardDescription; > public string standardVersion; > public string productDescription; > public string productVersion; > public string productVendor; > public PKI::CertificateInfoList supportedCertificates; > public PKI::CRLInfoList supportedCRLs; > public PKI::CertificateInfoList supportedCrossCertificates; > }; > > valuetype RepositoryMappingInfo > { > // > // without attribute name declarations from the > // the current RepositoryProviderInfo struct > // > > public string user_attribute_name; > public string ca_attribute_name; > public string crl_attribute_name; > public string certificatePair_attribute_name; > public string deltaCRL_attribute_name; > public string arl_attribute_name; > }; > > Finally, I think that the implementation independent interface > should be > separated from LDAP oriented interfaces through a module - > PKIRepository for > the implementation independent interfaces and PKIExtension for the > LDAP > oriented extensions. > > Summary of the solution: > ======================== > > From the point of view of an LDAP oriented implementation the above > refactoring of the IDL adds the requirement for implementation of > operations > supporting publication of, access to, updating, and deletion of > principals > (one hit operations respectively). This should not pose any > problem. From > the perspective of the non-LDAP implementation this change means > that > approximately 27 repository operations would no-longer be required > (and > that's *good* news). > > Actions > ======= > > I'll continue to go through the other modules of the PKI spec on the > assumption that the proposed changes are not likely to cause and > problems -- > i.e. I'm assuming quick feedback if there are problems with the > above. For > reference I'm maintaining a set of IDL sources that include changes > I've > been discussing - if anyone wants a copy just post an email and I'll > shoot > them through. If there's no substantive discussion on this in the > next > couple of days I'll go ahead and post this as an issue to the OMG > for FTF > resolution ASAP. > > Cheers, Steve. > > Stephen J. McConnell, OSM sarl > digital products for a global economy > http://www.osm.net > mailto:mcconnell@osm.net > > > X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Polar Humenn cc: Stephen McConnell , pki-ftf@emerald.omg.org, gibson@dstc.qut.edu.au Subject: Re: PKI Repository issue (biggish email) In-Reply-To: Message from Polar Humenn of "Tue, 07 Aug 2001 08:48:43 -0400." Mime-Version: 1.0 Date: Wed, 08 Aug 2001 11:50:11 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: np$!!k,!e9FZ*e9P=Pd9 Polar, Fair enough. I think its best to sort it out now rather than later for sure. I was just a bit unsure with regard to overstepping the mark for an FTF, I didn't think major IDL changes were desired. If everyone is happy with these types of changes then I guess its no problem. Simon > > Simon, > > I will agree with Steve on this point. I think its well in scope of > the > FTF. And as long as all parties agree, I don't see a problem. > > Cheers, > -Polar > > > > On Tue, 7 Aug 2001, Stephen McConnell wrote: > > > > > Simon: > > > > As far as I understand, DSTC and OSM are the two organisations > > implementing the spec at this stage. I think this is an excellent > > opportunity to sort out the spec because we are both implementing > > from very different backgrounds, different business interests and > > different underlying technologies. What this assures is that we > > will end up with one hell of a good quality spec - and I think > > that's well within the scope of an FTF! > > > > Cheers, Steve. > > > > > > Simon Gibson wrote: > > > > > > Stephen, > > > > > > Firstly when we put together the Repository stuff it had a focus > of LDAP > > > as this is the common case but is/should be independent of that. > > > > > > What you have looks pretty cool but I do have reservations about > the > > > changes and whether they are applicable in an FTF. I will have > to have a > > > better look at it and find out whether we can do it. One comment > now > > > though is that LDAPRepository isn't quite accurate as its still > not tied > > > to LDAP strictly speaking, but I can see the overall use of a > generic > > > simple interface. > > > If there is consensus with this we may well be able to sort it > > > along these lines. > > > > > > Simon > > > > > > > > > > > After going through the PKI Repository module in more detail > I'm running > > > > into a number of problems concerning implied implementation > > > approach that is > > > > forced on the developer (effectively the implied > implementation > > > is an LDAP > > > > directory). It seems that the Repository is defined with the > assumption > > > > that (a) storage slot attribute names are passed as parameters > > > and (b) the > > > > storage values for attributes are always an any. This > complicates the > > > > implementation approach if you have alternative "more > > > structured" storage > > > > systems available (e.g. PSS - for example, using PSS I can > store CORBA > > > > values and object references directly with complete type > safety and > > > > practically zero additional code. > > > > > > > > This "implementation constraint" is a supposedly > "implementation > > > > independent" spec is a significant issue. > > > > > > > > A solution to this issue is to separate the operations and > > > structures that > > > > assume LDAP from the implementation independent operations and > > > structures > > > > into different modules and to include an appropriate > compliance > > > statement. > > > > An initial assessment suggested that the existing operations > > > could be split > > > > to reflect the different concerns, however, tf you take a look > at the > > > > operations in the Repository interface you come up with a list > > > of operations > > > > that require attribute parameters and those that don't. > > > Operations that set > > > > attributes where the cardinality of the value relative to the > > > PKIPrincipal > > > > is 1 do not expose the attribute parameter, however, the > > > operations dealing > > > > with the publication, location and deletion of user and CA > certificates > > > > (where cardinality is *) require attribute names to be passed > > > in (i.e. the > > > > attribute names define the keys for the values). > > > > > > > > So, to summarise the issue: > > > > > > > > - the definition of Repository, PKIPrincipal and elements of > > > > RepositoryProviderInfo force an implementation approach > that > > > > is friendly to LDAP but decidedly unfriendly to > alternative > > > > storage system implementations, and secondly, the approach > > > > forces a significantly higher number of remote invocations > > > > (while at the same time providing the benefit of > fine-grain > > > > operation granularity) > > > > > > > > A very clean solution to this problem would be to define a > super-type > > > > to Repository that is implementation independent, together > with > > > > conformance criteria that separates LDAP oriented services as > an > > > > optional compliance point. > > > > > > > > Here is an example of an implementation independent Repository > > > > interface and valuetype that could be used in conjunction with > > > > the current Repository interface - I've used the name > "Repository" as > > > > the super-type, and LDAPRepository as the sub-type: > > > > > > > > > > > > // Definition of the principal datastructure as a single > > > > // valuetype so we can get all of the information for a > given > > > > // principal in one hit > > > > > > > > valuetype PKIPrincipalValue > > > > { > > > > private string name; > > > > private PKI::CertificateList certificates; > > > > private PKI::CertificatePairList; > > > > private PKI::CRL crl; > > > > private PKI::CRL delta; > > > > private PKI::CRL arl; > > > > } > > > > > > > > interface Repository > > > > { > > > > readonly attribute RepositoryProviderInfo info; > > > > > > > > void publish( > > > > in PrincipalValue principal; > > > > ) throws ( > > > > DuplicatePrincipal, RepositoryError > > > > ); > > > > > > > > PrincipalValue locate ( > > > > in string name; > > > > ) throws ( > > > > UnknownPrincipal, RepositoryError > > > > ); > > > > > > > > void delete ( > > > > in string name; > > > > ) throws ( > > > > UnknownPrincipal, RepositoryError > > > > ); > > > > > > > > void update ( > > > > in PrincipalValue principal; > > > > ) throws ( > > > > UnknownPrincipal, RepositoryError > > > > ); > > > > } > > > > > > > > // The following is a fragment based on the existing > Repository > > > > // interface with a minor modification to the inheritance > graph > > > > // and info accessor. The inheritance is modified such > that > > > > // it is a specialisation of the Repository defined above, > and the > > > > // info accessor is provided to enable access to attribute > name > > > > // mapping information. > > > > > > > > interface LDAPRepository : Repository > > > > { > > > > > > > > // > > > > // accessor for the info dealing with attribute name > mapping > > > > // that is currently declared inside > RepositoryProviderInfo > > > > // > > > > > > > > readonly attribute RepositoryMappingInfo map; > > > > > > > > // > > > > // the rest is as is currently specified > > > > // > > > > > > > > } > > > > > > > > Finally, to complete the service/implementation separation we > > > need to break > > > > the > > > > current RepositoryProviderInfo into two separate structures > > > (one containing > > > > the > > > > general information and one containing the implementation > related > > > > information). > > > > > > > > valuetype RepositoryProviderInfo > > > > { > > > > > > > > // > > > > // equivalent to the current RepositoryProviderInfo > > > > // without attribute name declarations > > > > // > > > > > > > > public string standardDescription; > > > > public string standardVersion; > > > > public string productDescription; > > > > public string productVersion; > > > > public string productVendor; > > > > public PKI::CertificateInfoList supportedCertificates; > > > > public PKI::CRLInfoList supportedCRLs; > > > > public PKI::CertificateInfoList > supportedCrossCertificates; > > > > }; > > > > > > > > valuetype RepositoryMappingInfo > > > > { > > > > // > > > > // without attribute name declarations from the > > > > // the current RepositoryProviderInfo struct > > > > // > > > > > > > > public string user_attribute_name; > > > > public string ca_attribute_name; > > > > public string crl_attribute_name; > > > > public string certificatePair_attribute_name; > > > > public string deltaCRL_attribute_name; > > > > public string arl_attribute_name; > > > > }; > > > > > > > > Finally, I think that the implementation independent interface > should be > > > > separated from LDAP oriented interfaces through a module - > > > PKIRepository for > > > > the implementation independent interfaces and PKIExtension for > the LDAP > > > > oriented extensions. > > > > > > > > Summary of the solution: > > > > ======================== > > > > > > > > From the point of view of an LDAP oriented implementation the > above > > > > refactoring of the IDL adds the requirement for implementation > > > of operations > > > > supporting publication of, access to, updating, and deletion > of > > > principals > > > > (one hit operations respectively). This should not pose any > > > problem. From > > > > the perspective of the non-LDAP implementation this change > means that > > > > approximately 27 repository operations would no-longer be > required (and > > > > that's *good* news). > > > > > > > > Actions > > > > ======= > > > > > > > > I'll continue to go through the other modules of the PKI spec > on the > > > > assumption that the proposed changes are not likely to cause > > > and problems -- > > > > i.e. I'm assuming quick feedback if there are problems with > the > > > above. For > > > > reference I'm maintaining a set of IDL sources that include > changes I've > > > > been discussing - if anyone wants a copy just post an email > and > > > I'll shoot > > > > them through. If there's no substantive discussion on this in > the next > > > > couple of days I'll go ahead and post this as an issue to the > > > OMG for FTF > > > > resolution ASAP. > > > > > > > > Cheers, Steve. > > > > > > > > Stephen J. McConnell, OSM sarl > > > > digital products for a global economy > > > > http://www.osm.net > > > > mailto:mcconnell@osm.net > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 7 Aug 2001 08:48:43 -0400 (EDT) From: Polar Humenn To: Stephen McConnell cc: Subject: RE: PKI Repository issue (biggish email) In-Reply-To: <000101c11f28$3ea33200$0a01a8c0@osm.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: E,Ud9S@[!!FKYd9Z1!!! Simon, I will agree with Steve on this point. I think its well in scope of the FTF. And as long as all parties agree, I don't see a problem. Cheers, -Polar On Tue, 7 Aug 2001, Stephen McConnell wrote: > > Simon: > > As far as I understand, DSTC and OSM are the two organisations > implementing the spec at this stage. I think this is an excellent > opportunity to sort out the spec because we are both implementing > from very different backgrounds, different business interests and > different underlying technologies. What this assures is that we > will end up with one hell of a good quality spec - and I think > that's well within the scope of an FTF! > > Cheers, Steve. > > > Simon Gibson wrote: > > > > Stephen, > > > > Firstly when we put together the Repository stuff it had a focus >of LDAP > > as this is the common case but is/should be independent of that. > > > > What you have looks pretty cool but I do have reservations about >the > > changes and whether they are applicable in an FTF. I will have to >have a > > better look at it and find out whether we can do it. One comment >now > > though is that LDAPRepository isn't quite accurate as its still >not tied > > to LDAP strictly speaking, but I can see the overall use of a >generic > > simple interface. > > If there is consensus with this we may well be able to sort it > > along these lines. > > > > Simon > > > > > > > > After going through the PKI Repository module in more detail I'm >running > > > into a number of problems concerning implied implementation > > approach that is > > > forced on the developer (effectively the implied implementation > > is an LDAP > > > directory). It seems that the Repository is defined with the >assumption > > > that (a) storage slot attribute names are passed as parameters > > and (b) the > > > storage values for attributes are always an any. This >complicates the > > > implementation approach if you have alternative "more > > structured" storage > > > systems available (e.g. PSS - for example, using PSS I can store >CORBA > > > values and object references directly with complete type safety >and > > > practically zero additional code. > > > > > > This "implementation constraint" is a supposedly "implementation > > > independent" spec is a significant issue. > > > > > > A solution to this issue is to separate the operations and > > structures that > > > assume LDAP from the implementation independent operations and > > structures > > > into different modules and to include an appropriate compliance > > statement. > > > An initial assessment suggested that the existing operations > > could be split > > > to reflect the different concerns, however, tf you take a look >at the > > > operations in the Repository interface you come up with a list > > of operations > > > that require attribute parameters and those that don't. > > Operations that set > > > attributes where the cardinality of the value relative to the > > PKIPrincipal > > > is 1 do not expose the attribute parameter, however, the > > operations dealing > > > with the publication, location and deletion of user and CA >certificates > > > (where cardinality is *) require attribute names to be passed > > in (i.e. the > > > attribute names define the keys for the values). > > > > > > So, to summarise the issue: > > > > > > - the definition of Repository, PKIPrincipal and elements of > > > RepositoryProviderInfo force an implementation approach that > > > is friendly to LDAP but decidedly unfriendly to alternative > > > storage system implementations, and secondly, the approach > > > forces a significantly higher number of remote invocations > > > (while at the same time providing the benefit of fine-grain > > > operation granularity) > > > > > > A very clean solution to this problem would be to define a >super-type > > > to Repository that is implementation independent, together with > > > conformance criteria that separates LDAP oriented services as an > > > optional compliance point. > > > > > > Here is an example of an implementation independent Repository > > > interface and valuetype that could be used in conjunction with > > > the current Repository interface - I've used the name >"Repository" as > > > the super-type, and LDAPRepository as the sub-type: > > > > > > > > > // Definition of the principal datastructure as a single > > > // valuetype so we can get all of the information for a >given > > > // principal in one hit > > > > > > valuetype PKIPrincipalValue > > > { > > > private string name; > > > private PKI::CertificateList certificates; > > > private PKI::CertificatePairList; > > > private PKI::CRL crl; > > > private PKI::CRL delta; > > > private PKI::CRL arl; > > > } > > > > > > interface Repository > > > { > > > readonly attribute RepositoryProviderInfo info; > > > > > > void publish( > > > in PrincipalValue principal; > > > ) throws ( > > > DuplicatePrincipal, RepositoryError > > > ); > > > > > > PrincipalValue locate ( > > > in string name; > > > ) throws ( > > > UnknownPrincipal, RepositoryError > > > ); > > > > > > void delete ( > > > in string name; > > > ) throws ( > > > UnknownPrincipal, RepositoryError > > > ); > > > > > > void update ( > > > in PrincipalValue principal; > > > ) throws ( > > > UnknownPrincipal, RepositoryError > > > ); > > > } > > > > > > // The following is a fragment based on the existing >Repository > > > // interface with a minor modification to the inheritance >graph > > > // and info accessor. The inheritance is modified such that > > > // it is a specialisation of the Repository defined above, >and the > > > // info accessor is provided to enable access to attribute >name > > > // mapping information. > > > > > > interface LDAPRepository : Repository > > > { > > > > > > // > > > // accessor for the info dealing with attribute name >mapping > > > // that is currently declared inside RepositoryProviderInfo > > > // > > > > > > readonly attribute RepositoryMappingInfo map; > > > > > > // > > > // the rest is as is currently specified > > > // > > > > > > } > > > > > > Finally, to complete the service/implementation separation we > > need to break > > > the > > > current RepositoryProviderInfo into two separate structures > > (one containing > > > the > > > general information and one containing the implementation >related > > > information). > > > > > > valuetype RepositoryProviderInfo > > > { > > > > > > // > > > // equivalent to the current RepositoryProviderInfo > > > // without attribute name declarations > > > // > > > > > > public string standardDescription; > > > public string standardVersion; > > > public string productDescription; > > > public string productVersion; > > > public string productVendor; > > > public PKI::CertificateInfoList supportedCertificates; > > > public PKI::CRLInfoList supportedCRLs; > > > public PKI::CertificateInfoList >supportedCrossCertificates; > > > }; > > > > > > valuetype RepositoryMappingInfo > > > { > > > // > > > // without attribute name declarations from the > > > // the current RepositoryProviderInfo struct > > > // > > > > > > public string user_attribute_name; > > > public string ca_attribute_name; > > > public string crl_attribute_name; > > > public string certificatePair_attribute_name; > > > public string deltaCRL_attribute_name; > > > public string arl_attribute_name; > > > }; > > > > > > Finally, I think that the implementation independent interface >should be > > > separated from LDAP oriented interfaces through a module - > > PKIRepository for > > > the implementation independent interfaces and PKIExtension for >the LDAP > > > oriented extensions. > > > > > > Summary of the solution: > > > ======================== > > > > > > From the point of view of an LDAP oriented implementation the >above > > > refactoring of the IDL adds the requirement for implementation > > of operations > > > supporting publication of, access to, updating, and deletion of > > principals > > > (one hit operations respectively). This should not pose any > > problem. From > > > the perspective of the non-LDAP implementation this change means >that > > > approximately 27 repository operations would no-longer be >required (and > > > that's *good* news). > > > > > > Actions > > > ======= > > > > > > I'll continue to go through the other modules of the PKI spec on >the > > > assumption that the proposed changes are not likely to cause > > and problems -- > > > i.e. I'm assuming quick feedback if there are problems with the > > above. For > > > reference I'm maintaining a set of IDL sources that include >changes I've > > > been discussing - if anyone wants a copy just post an email and > > I'll shoot > > > them through. If there's no substantive discussion on this in >the next > > > couple of days I'll go ahead and post this as an issue to the > > OMG for FTF > > > resolution ASAP. > > > > > > Cheers, Steve. > > > > > > Stephen J. McConnell, OSM sarl > > > digital products for a global economy > > > http://www.osm.net > > > mailto:mcconnell@osm.net > > > > > > > > > > > > > > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: "Stephen McConnell" To: Subject: RE: PKI Repository issue (biggish email) Date: Tue, 7 Aug 2001 12:03:45 +0200 Message-ID: <000101c11f28$3ea33200$0a01a8c0@osm.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200108060518.f765IFm02486@thunder.dstc.qut.edu.au> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Content-Type: text/plain; charset="Windows-1252" X-UIDL: HK%!!n:#!!6SJ!!,k7e9 Simon: As far as I understand, DSTC and OSM are the two organisations implementing the spec at this stage. I think this is an excellent opportunity to sort out the spec because we are both implementing from very different backgrounds, different business interests and different underlying technologies. What this assures is that we will end up with one hell of a good quality spec - and I think that's well within the scope of an FTF! Cheers, Steve. Simon Gibson wrote: > > Stephen, > > Firstly when we put together the Repository stuff it had a focus of LDAP > as this is the common case but is/should be independent of that. > > What you have looks pretty cool but I do have reservations about the > changes and whether they are applicable in an FTF. I will have to have a > better look at it and find out whether we can do it. One comment now > though is that LDAPRepository isn't quite accurate as its still not tied > to LDAP strictly speaking, but I can see the overall use of a generic > simple interface. > If there is consensus with this we may well be able to sort it > along these lines. > > Simon > > > > > After going through the PKI Repository module in more detail I'm running > > into a number of problems concerning implied implementation > approach that is > > forced on the developer (effectively the implied implementation > is an LDAP > > directory). It seems that the Repository is defined with the assumption > > that (a) storage slot attribute names are passed as parameters > and (b) the > > storage values for attributes are always an any. This complicates the > > implementation approach if you have alternative "more > structured" storage > > systems available (e.g. PSS - for example, using PSS I can store CORBA > > values and object references directly with complete type safety and > > practically zero additional code. > > > > This "implementation constraint" is a supposedly "implementation > > independent" spec is a significant issue. > > > > A solution to this issue is to separate the operations and > structures that > > assume LDAP from the implementation independent operations and > structures > > into different modules and to include an appropriate compliance > statement. > > An initial assessment suggested that the existing operations > could be split > > to reflect the different concerns, however, tf you take a look at the > > operations in the Repository interface you come up with a list > of operations > > that require attribute parameters and those that don't. > Operations that set > > attributes where the cardinality of the value relative to the > PKIPrincipal > > is 1 do not expose the attribute parameter, however, the > operations dealing > > with the publication, location and deletion of user and CA certificates > > (where cardinality is *) require attribute names to be passed > in (i.e. the > > attribute names define the keys for the values). > > > > So, to summarise the issue: > > > > - the definition of Repository, PKIPrincipal and elements of > > RepositoryProviderInfo force an implementation approach that > > is friendly to LDAP but decidedly unfriendly to alternative > > storage system implementations, and secondly, the approach > > forces a significantly higher number of remote invocations > > (while at the same time providing the benefit of fine-grain > > operation granularity) > > > > A very clean solution to this problem would be to define a super-type > > to Repository that is implementation independent, together with > > conformance criteria that separates LDAP oriented services as an > > optional compliance point. > > > > Here is an example of an implementation independent Repository > > interface and valuetype that could be used in conjunction with > > the current Repository interface - I've used the name "Repository" as > > the super-type, and LDAPRepository as the sub-type: > > > > > > // Definition of the principal datastructure as a single > > // valuetype so we can get all of the information for a given > > // principal in one hit > > > > valuetype PKIPrincipalValue > > { > > private string name; > > private PKI::CertificateList certificates; > > private PKI::CertificatePairList; > > private PKI::CRL crl; > > private PKI::CRL delta; > > private PKI::CRL arl; > > } > > > > interface Repository > > { > > readonly attribute RepositoryProviderInfo info; > > > > void publish( > > in PrincipalValue principal; > > ) throws ( > > DuplicatePrincipal, RepositoryError > > ); > > > > PrincipalValue locate ( > > in string name; > > ) throws ( > > UnknownPrincipal, RepositoryError > > ); > > > > void delete ( > > in string name; > > ) throws ( > > UnknownPrincipal, RepositoryError > > ); > > > > void update ( > > in PrincipalValue principal; > > ) throws ( > > UnknownPrincipal, RepositoryError > > ); > > } > > > > // The following is a fragment based on the existing Repository > > // interface with a minor modification to the inheritance graph > > // and info accessor. The inheritance is modified such that > > // it is a specialisation of the Repository defined above, and the > > // info accessor is provided to enable access to attribute name > > // mapping information. > > > > interface LDAPRepository : Repository > > { > > > > // > > // accessor for the info dealing with attribute name mapping > > // that is currently declared inside RepositoryProviderInfo > > // > > > > readonly attribute RepositoryMappingInfo map; > > > > // > > // the rest is as is currently specified > > // > > > > } > > > > Finally, to complete the service/implementation separation we > need to break > > the > > current RepositoryProviderInfo into two separate structures > (one containing > > the > > general information and one containing the implementation related > > information). > > > > valuetype RepositoryProviderInfo > > { > > > > // > > // equivalent to the current RepositoryProviderInfo > > // without attribute name declarations > > // > > > > public string standardDescription; > > public string standardVersion; > > public string productDescription; > > public string productVersion; > > public string productVendor; > > public PKI::CertificateInfoList supportedCertificates; > > public PKI::CRLInfoList supportedCRLs; > > public PKI::CertificateInfoList supportedCrossCertificates; > > }; > > > > valuetype RepositoryMappingInfo > > { > > // > > // without attribute name declarations from the > > // the current RepositoryProviderInfo struct > > // > > > > public string user_attribute_name; > > public string ca_attribute_name; > > public string crl_attribute_name; > > public string certificatePair_attribute_name; > > public string deltaCRL_attribute_name; > > public string arl_attribute_name; > > }; > > > > Finally, I think that the implementation independent interface should be > > separated from LDAP oriented interfaces through a module - > PKIRepository for > > the implementation independent interfaces and PKIExtension for the LDAP > > oriented extensions. > > > > Summary of the solution: > > ======================== > > > > From the point of view of an LDAP oriented implementation the above > > refactoring of the IDL adds the requirement for implementation > of operations > > supporting publication of, access to, updating, and deletion of > principals > > (one hit operations respectively). This should not pose any > problem. From > > the perspective of the non-LDAP implementation this change means that > > approximately 27 repository operations would no-longer be required (and > > that's *good* news). > > > > Actions > > ======= > > > > I'll continue to go through the other modules of the PKI spec on the > > assumption that the proposed changes are not likely to cause > and problems -- > > i.e. I'm assuming quick feedback if there are problems with the > above. For > > reference I'm maintaining a set of IDL sources that include changes I've > > been discussing - if anyone wants a copy just post an email and > I'll shoot > > them through. If there's no substantive discussion on this in the next > > couple of days I'll go ahead and post this as an issue to the > OMG for FTF > > resolution ASAP. > > > > Cheers, Steve. > > > > Stephen J. McConnell, OSM sarl > > digital products for a global economy > > http://www.osm.net > > mailto:mcconnell@osm.net > > > > > > > > > X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: pki-ftf@omg.org Subject: Discussion for issue #4444 Mime-Version: 1.0 Date: Tue, 20 Nov 2001 10:56:25 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: 9"X!!iVkd9 #include module PKIExtension { // current repository stuff valuetype RepositoryMappingInfo { public string user_attribute_name; public string ca_attribute_name; public string crl_attribute_name; public string certificatePair_attribute_name; public string deltaCRL_attribute_name; public string arl_attribute_name; }; typedef string PKIName; typedef sequence PKINameList; struct PKIAttribute { string name; any value; }; typedef sequence PKIAttributeList; struct PKIPrincipal { PKIName name; PKIAttributeList attributes; }; struct Schema { PKIAttributeList attribute_defs; PKIAttributeList syntax_defs; }; enum PrincipalAttributeErrorReason { MissingPKIAttributes, InvalidPKIAttributes }; exception UnknownPrincipal { string name; }; exception RepositoryError { string name; }; exception PrincipalAttributeError { PrincipalAttributeErrorReason reason; PKIPrincipal principal; PKINameList attribute_names; }; // rename to LDAPRepository interface LDAPRepository { PKIRepository::RepositoryProviderInfo get_provider_info(); // New method RepositoryMappingInfo mapping(); Schema get_schema(); void publish_certificate( in PKIPrincipal principal, in PKI::Certificate certificate, in string attr_name) raises (UnknownPrincipal, PrincipalAttributeError, RepositoryError); PKI::CertificateList get_certificate( in PKIPrincipal principal, in string attr_name) raises (UnknownPrincipal, RepositoryError); void delete_certificate( in PKIPrincipal principal, in PKI::Certificate certificate, in string attr_name) raises(UnknownPrincipal, RepositoryError); void publish_crl(in PKIPrincipal principal, in PKI::CRL crl, in string attr_name) raises(UnknownPrincipal,PrincipalAttributeError, RepositoryError); PKI::CRL get_crl(in PKIPrincipal principal, in string attr_name) raises(UnknownPrincipal, RepositoryError); void delete_crl(in PKIPrincipal principal, in PKI::CRL crl,in string attr_name) raises(UnknownPrincipal, RepositoryError); void publish_certificate_pair( in PKIPrincipal principal, in PKI::CertificatePair certPair, in string attr_name) raises(UnknownPrincipal, PrincipalAttributeError, RepositoryError); PKI::CertificatePairList get_certificate_pair( in PKIPrincipal principal, in string attr_name) raises(UnknownPrincipal, RepositoryError); void delete_certificate_pair( in PKIPrincipal principal, in PKI::CertificatePair certificate_pair, in string attr_name) raises(UnknownPrincipal,RepositoryError); void publish_user_certificate(in PKIPrincipal principal, in PKI::Certificate certificate) raises(UnknownPrincipal,PrincipalAttributeError,RepositoryError ); PKI::CertificateList get_user_certificate(in PKIPrincipal principal) raises(UnknownPrincipal,RepositoryError); void delete_user_certificate(in PKIPrincipal principal, in PKI::Certificate certificate) raises(UnknownPrincipal,RepositoryError); void publish_ca_certificate( in PKIPrincipal principal, in PKI::Certificate certificate) raises(UnknownPrincipal, PrincipalAttributeError,RepositoryErro r); PKI::CertificateList get_ca_certificate(in PKIPrincipal principal) raises(UnknownPrincipal,RepositoryError); void delete_ca_certificate(in PKIPrincipal principal, in PKI::Certificate certificate) raises(UnknownPrincipal,RepositoryError); void publish_default_crl(in PKIPrincipal principal, in PKI::CRL crl) raises(UnknownPrincipal,PrincipalAttributeError,RepositoryError); PKI::CRL get_default_crl(in PKIPrincipal principal) raises(UnknownPrincipal,RepositoryError); void delete_default_crl(in PKIPrincipal principal, in PKI::CRL crl) raises(UnknownPrincipal,RepositoryError); void publish_default_certificate_pair(in PKIPrincipal principal, in PKI::CertificatePair certificate_pair) raises(UnknownPrincipal,PrincipalAttributeError,RepositoryError ); PKI::CertificatePairList get_default_certificate_pair( in PKIPrincipal principal) raises(UnknownPrincipal,RepositoryError); void delete_default_certificate_pair(in PKIPrincipal principal, in PKI::CertificatePair certificate_pair) raises(UnknownPrincipal,RepositoryError); void publish_delta_crl(in PKIPrincipal principal, in PKI::CRL delta_crl) raises(UnknownPrincipal,PrincipalAttributeError,RepositoryError); PKI::CRL get_delta_crl(in PKIPrincipal principal) raises(UnknownPrincipal,RepositoryError); void delete_delta_crl(in PKIPrincipal principal, in PKI::CRL delta_crl) raises(UnknownPrincipal,RepositoryError); void publish_arl(in PKIPrincipal principal, in PKI::CRL arl) raises(UnknownPrincipal,PrincipalAttributeError,RepositoryError); PKI::CRL get_arl(in PKIPrincipal principal) raises(UnknownPrincipal,RepositoryError); void delete_arl(in PKIPrincipal principal, in PKI::CRL arl) raises(UnknownPrincipal,RepositoryError); }; }; ------------------------ X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: pki-ftf@omg.org Subject: Request Vote issue #4444 Mime-Version: 1.0 Date: Mon, 26 Nov 2001 16:26:16 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: `NO!!N9]!!5Ind9&,Z!! Hi There, I am in the middle of writing up the report for the FTF which must close on the 15th of Dec. So if you could have a look at this issue which is the last of the long issues then I can finish up the report. Simon Issue 4444: PKI Repository issue (pki-ftf) Click here for this issue's archive. Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) Nature: Uncategorized Issue Severity: Significant Summary: After going through the PKI Repository module in more detail I'm running into a number of problems concerning implied implementation approach that is forced on the developer (effectively the implied implementation is an LDAP directory). It seems that the Repository is defined with the assumption that (a) storage slot attribute names are passed as parameters and (b) the storage values for attributes are always an any. This complicates the implementation approach if you have alternative "more structured" storage systems available (e.g. PSS - for example, using PSS I can store CORBA values and object references directly with complete type safety and practically zero additional code. This "implementation constraint" is a supposedly "implementation independent" spec is a significant issue. Proposed Resolution for discussion: Simplify implementation for the Repository by creating a simplified interface that is friendly to other possible implementations such as the Persistent State Storage. However it is important to keep the LDAP-centric current definition to still handle the case where LDAP is used providing operations for dealing with finer grained details. In essence propose we have 2 modules one for a new simpler interface and ane for the current repository IDL. module PKIRepository { // contain simplified interfaces and valuetypes }; module PKIExtension { // current repository stuff }; In detail: ----------------------- // PKIRepository.idl #ifndef __PKIREPOSITORY_IDL #define __PKIREPOSITORY_IDL #include #pragma prefix "omg.org" module PKIRepository { valuetype RepositoryProviderInfo { public string standardDescription; public string standardVersion; public string productDescription; public string productVersion; public string productVendor; public PKI::CertificateInfoList supportedCertificates; public PKI::CRLInfoList supportedCRLs; public PKI::CertificateInfoList supportedCrossCertificates; }; exception UnknownPrincipal { string name; }; exception RepositoryError { string name; }; exception DuplicatePrincipal { string name; }; valuetype PKIPrincipalValue { private string name; private PKI::CertificateList certificates; private PKI::CertificatePairList; private PKI::CRL crl; private PKI::CRL delta; private PKI::CRL arl; }; interface Repository { readonly attribute RepositoryProviderInfo info; void publish( in PrincipalValue principal ) raises ( DuplicatePrincipal, RepositoryError ); PKIPrincipalValue locate ( in string name ) raises ( UnknownPrincipal, RepositoryError ); void delete ( in string name ) raises ( UnknownPrincipal, RepositoryError ); void update ( in PrincipalValue principal ) raises ( UnknownPrincipal, RepositoryError); }; }; #endif ------------------------ // PKIExtension.idl #include #include module PKIExtension { // current repository stuff valuetype RepositoryMappingInfo { public string user_attribute_name; public string ca_attribute_name; public string crl_attribute_name; public string certificatePair_attribute_name; public string deltaCRL_attribute_name; public string arl_attribute_name; }; typedef string PKIName; typedef sequence PKINameList; struct PKIAttribute { string name; any value; }; typedef sequence PKIAttributeList; struct PKIPrincipal { PKIName name; PKIAttributeList attributes; }; struct Schema { PKIAttributeList attribute_defs; PKIAttributeList syntax_defs; }; enum PrincipalAttributeErrorReason { MissingPKIAttributes, InvalidPKIAttributes }; exception PrincipalAttributeError { PrincipalAttributeErrorReason reason; PKIPrincipal principal; PKINameList attribute_names; }; // rename to LDAPRepository interface LDAPRepository : PKIRepository::Repository { // New method RepositoryMappingInfo mapping(); Schema get_schema(); void publish_certificate( in PKIPrincipal principal, in PKI::Certificate certificate, in string attr_name) raises (PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CertificateList get_certificate( in PKIPrincipal principal, in string attr_name) raises (PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_certificate( in PKIPrincipal principal, in PKI::Certificate certificate, in string attr_name) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_crl(in PKIPrincipal principal, in PKI::CRL crl, in string attr_name) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CRL get_crl(in PKIPrincipal principal, in string attr_name) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_crl(in PKIPrincipal principal, in PKI::CRL crl,in string attr_name) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_certificate_pair( in PKIPrincipal principal, in PKI::CertificatePair certPair, in string attr_name) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CertificatePairList get_certificate_pair( in PKIPrincipal principal, in string attr_name) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_certificate_pair( in PKIPrincipal principal, in PKI::CertificatePair certificate_pair, in string attr_name) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_user_certificate(in PKIPrincipal principal, in PKI::Certificate certificate) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CertificateList get_user_certificate(in PKIPrincipal principal) raises(UnknownPrincipal,RepositoryError); void delete_user_certificate(in PKIPrincipal principal, in PKI::Certificate certificate) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_ca_certificate( in PKIPrincipal principal, in PKI::Certificate certificate) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CertificateList get_ca_certificate(in PKIPrincipal principal) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_ca_certificate(in PKIPrincipal principal, in PKI::Certificate certificate) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_default_crl(in PKIPrincipal principal, in PKI::CRL crl) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CRL get_default_crl(in PKIPrincipal principal) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_default_crl(in PKIPrincipal principal, in PKI::CRL crl) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_default_certificate_pair(in PKIPrincipal principal, in PKI::CertificatePair certificate_pair) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CertificatePairList get_default_certificate_pair( in PKIPrincipal principal) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_default_certificate_pair(in PKIPrincipal principal, in PKI::CertificatePair certificate_pair) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_delta_crl(in PKIPrincipal principal, in PKI::CRL delta_crl) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CRL get_delta_crl(in PKIPrincipal principal) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_delta_crl(in PKIPrincipal principal, in PKI::CRL delta_crl) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void publish_arl(in PKIPrincipal principal, in PKI::CRL arl) raises(PKIRepository::UnknownPrincipal, PrincipalAttributeError, PKIRepository::RepositoryError); PKI::CRL get_arl(in PKIPrincipal principal) raises(PKIRepository::UnknownPrincipal, PKIRepository::RepositoryError); void delete_arl(in PKIPrincipal principal, in PKI::CRL arl) raises(PKIRepository::UnknownPrincipal, RPKIRepository::epositoryError); }; }; ------------------------ Text Changes: The changes proposed cause the following text changes in the document. a) Replace the first paragraph in Chapter 1.6.3 Repository with the following 2 paragraphs: "The repository is a service where information can be stored and retrieved. Primarily this is used for storage and retrieval of principal information such as certificates. It is also commonly used to store information such as Certificate Revocation Lists (CRLs). Effectively there are 2 definitions of repository interfaces in this specification. There is a simple interface described in PKIRepository and also a more intricate interface that is designed to be able to interact with repositories that are based around X500 and LDAP implementations. The simplified version is hoped to be the more commonly used interface allowing implementors and clients to interact with ease. However since the backend could well be LDAP or X500 in existing services that may be wrapped by these interfaces the PKIExtension module allows for this interaction. The operations in PKIRepository are simple and self explanatory but the PKIExtension module contains a more detailed approach. "The PKIExtension module describes a data storage service which generally has a schema that mandates the form and the content of the data stored therein. As much as possible, the type of repository implementation, and the exact details of the schema that oversees the data storage service, should be hidden from the client of the PKI repository service. In general, when a client wishes to publish information in the repository, it is assumed that the repository implementation has enough information to create the appropriate entry in the underlying data storage service according to the back-end schema. However, it may be the case that a repository implementation cannot gather the required information in order to create an entry for a principal when a request is made by the client to store information in the repository. For example, a database implementation of the PKI repository may require that all entries contain a value for the "favorite milkshake" field. In such cases, the repository implementation may ask for further information from the client. The PKIPrincipal type in the IDL allows the client to pass additional attribute information as required." etc. b) Current 2.4 moved to 2.5 Module PKIExtension. c) 2.4.1 Interface Repository moved to 2.5.1 Interface LDAPRepository d) New chapter 2.4 will contain text describing new simplified interface. 2.4.1 PKIPrincipalValue "Valuetype supporting fields containing relevant information related to a particular principal." 2.4.2 Interface Repository "Interface for storage and retrieval of certificates and CRLs." 2.4.2.1 attribute RepositoryProviderInfo info "Operation to return a valuetype containing information pertaining to this particular repository implementation." 2.4.2.2 publish "Enter a new PKIPrincipalValue into the repository." 2.4.2.3 locate "Get a PKIPrincipalValue for a particular name." 2.4.2.4 delete "Deletes a principal in the repository using name as the lookup key." 2.4.2.5 update "Replaces an existing principal in the repository with the supplied PKIPrincipalValue object." 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: ReRequest on issue #4444 Mime-Version: 1.0 Date: Wed, 05 Dec 2001 10:15:36 +1000 From: Simon Gibson Content-Type: text/plain; charset=us-ascii X-UIDL: :gb!!iM9e9AfA!!'5F!! Status: RO Guys, So we have only 3 votes for the issue related to the repository. Is there any more interest in this? Simon From: "Stephen McConnell" To: Subject: RE: ReRequest on issue #4444 Date: Wed, 5 Dec 2001 07:50:37 +0100 Message-ID: <000001c17d59$25102160$0a01a8c0@osm.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200112050015.fB50Fam25014@thunder.dstc.qut.edu.au> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Content-Type: text/plain; charset="Windows-1252" X-UIDL: [B?e9>-=e9gBBe97j6e9 Hi everyone: The issue that Simon has mentioned below is important and needs your votes. The issue concerns the inclusion of X500 specific data structures in the spec concerning the certificate repository. Based on the changes currently adapter (valuetype stuff) the interfaces the deal with the repository DO NOT NEED to expose repository implementation details. The issue raised addresses two points (a) that several of the X500 related information was not documented (and remains undocumented), and (b) the X500 details are not needed to build a system. The issue I posted recommended the relocation of these "undocumented attributes" to a separate module the extended the implementation independent defining of the repository. I did does not enhance the specification - only simplifies. There is also a conformance point here - I don't want to be obliged to support X500 as my storage mechanisms (although I'm not precluded from this approach - BUT its an implmetation decision and should not be exposed in an IDL interface). To close this issue I guess we need a couple of extra vote. So please consider this a email as a request to review and vote on the issue :-) Cheers, Steve. > -----Original Message----- > From: Simon Gibson [mailto:gibson@dstc.qut.edu.au] > Sent: Wednesday, 05 December, 2001 01:16 > To: Patrick McLaughlin; Polar Humenn; Gene Garboe; Bill Binko; Stephen > McConnell; Ron Monzillo; Simon Gibson; Christopher Milsom; Igor Balabine > Cc: pki-ftf@omg.org > Subject: ReRequest on issue #4444 > > > Guys, > > So we have only 3 votes for the issue related to the repository. Is there > any more interest in this? > > Simon >