Public Key Infrastructure Avatar
  1. OMG Specification

Public Key Infrastructure — Closed Issues

  • Acronym: PKI
  • Issues Count: 17
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Issues Descriptions

AuthorityProviderInfo - supplementary info desirable

  • Key: PKI-22
  • Legacy Issue Number: 4481
  • Status: closed  
  • Source: Fujitsu ( Stephen McConnell)
  • Summary:

    The AuthorityProviderInfo contains a set of information about the a
    provider.
    It is desirable that this be extended to include the public key of
    the provider and URLs to provider specific information.

    valuetype AuthorityProviderInfo

    { public string standardVersion; public string standardDescription; public string productVersion; public string productDescription; public string productVendor; public PKI::CertificateInfoList supportedCertificates; public PKI::CRLInfoList supportedCRLs; public PKI::CertificateRequestInfoList supportedCertRequestTypes; public PKI::CertificateRevocationInfoList supportedCertRevocationTypes; public PKI::KeyRecoveryInfoList supportedKeyRecoveryTypes; // proposed addition public PKI::Certificate publicKey; public string providerHomeURL; public string providerPublicKeyURL; }

    ;

    These additions enable a consistent mechanism to (a) access a CA or RA
    public
    key, (b) provide a hint to an out-of-band mechanisms through which public
    key
    verification can be enacted, and (c) provide access to provider information
    such as published certification policy, etc.

    If there are not objections - I'll raise this as an FTF issue.

  • Reported: PKI 1.0b1 — Tue, 14 Aug 2001 04:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PKIAuthority module - definition of RequestManager

  • Key: PKI-21
  • Legacy Issue Number: 4480
  • Status: closed  
  • Source: Fujitsu ( Stephen McConnell)
  • Summary:

    Under the PKIAuthority module there is an interface call
    RegistrationAuthority. This interface basically provides operations through
    which the client gets a reference to a object derived from RequestManager.
    For all practical purposes the RequestManager is an abstract type, whereas
    the derived managers (certificate request manager, key revocation manager,
    key recovery manager, key update manager) are concrete. As such, the
    definition of RequestManager should be changed from a concrete to an
    abstract interface.

    /**

    • Generic interface for a manager object.
      */
      abstract interface RequestManager
      { ..... }

      ;

  • Reported: PKI 1.0b1 — Wed, 8 Aug 2001 04:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    Change IDL to make RequestManager and abstract interface

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PKI AuthorityInfoType - missing documentation

  • Key: PKI-20
  • Legacy Issue Number: 4479
  • Status: closed  
  • Source: Fujitsu ( Stephen McConnell)
  • Summary:

    The following structure and contantns are declared in the PKI IDL but
    are not defined within the PKI specification:

    typedef unsigned long AuthorityInfoType;
    const AuthorityInfoType UnkownMessage = 0;
    const AuthorityInfoType PKIXCMPGeneralMessage = 1;
    const AuthorityInfoType CustomMessage = 0x8000;

  • Reported: PKI 1.0b1 — Sat, 4 Aug 2001 04:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PKI RegistrationAuthority QUERY

  • Key: PKI-19
  • Legacy Issue Number: 4477
  • Status: closed  
  • Source: Fujitsu ( Stephen McConnell)
  • Summary:

    The specification of the get_authority_info operation on the
    RegistrationAuthority
    interface does seem to has sufficient information describing the expected
    semantics.
    I have included the extract of the javadoc description that I have put
    together based
    on the spec, however, this isn't a sufficient description to implement
    against.
    Secondly, the method and argument names don't seem to be symmetric with the
    intent of
    the operation. As far as I understand, the operation "get_authority_info"
    actually
    serves as a post-message-get-reply operation, and the arguments
    "AuthorityInfo" are
    actually the messages in and out. If that's correct, then both operation
    and
    argument types should be renamed to imply this.

    Any clarification on this would be appreciated.

    /**

    • Message exchange between a client entity and authority. For example
    • this may provide a method for a client to determine the authentication
    • policy of the authority.
      *
    • @param in_authority_info The encoded message input to authority.
    • @param out_authority_info The encoded returned message from
    • authority.
    • @return Status value.
    • @exception UnsupportedTypeException
    • @exception UnsupportedEncodingException
    • @exception MalformedDataException
      */
      public int get_authority_info(AuthorityInfo in_authority_info,
      AuthorityInfoHolder out_authority_info)
      throws UnsupportedTypeException, UnsupportedEncodingException,
      MalformedDataException { return 0; }
  • Reported: PKI 1.0b1 — Sun, 5 Aug 2001 04:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PKI Repository issue

  • Key: PKI-18
  • Legacy Issue Number: 4444
  • Status: closed  
  • Source: Fujitsu ( Stephen McConnell)
  • 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.

  • Reported: PKI 1.0b1 — Thu, 2 Aug 2001 04:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PKI - RepositoryProviderInfo defintion

  • Key: PKI-17
  • Legacy Issue Number: 4443
  • Status: closed  
  • Source: Fujitsu ( Stephen McConnell)
  • Summary:

    The current spec defines RepositoryProviderInfo as an struct.
    Given that it has approximately 14 state members, I suggest we
    redefine it as a valuetype simply on the grounds that it is more
    easily modifiable in the future (using a valuetype will maintain
    backward compatibility because we can extend it if needed). It
    also means that implementations could provide supplementary
    information without breaking interfaces or interoperability.

    This is the current definition:

    struct RepositoryProviderInfo

    { string standardDescription; string standardVersion; string productDescription; string productVersion; string productVendor; PKI::CertificateInfoList supportedCertificates; PKI::CRLInfoList supportedCRLs; PKI::CertificateInfoList supportedCrossCertificates; string user_attribute_name; string ca_attribute_name; string crl_attribute_name; string certificatePair_attribute_name; string deltaCRL_attribute_name; string arl_attribute_name; }

    ;

    I propose we change this to:

    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; 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; }

    ;

    The same case may apply for some of the other info types - but for the
    moment I'm focussing on the repository interfaces - more question later!

  • Reported: PKI 1.0b1 — Thu, 2 Aug 2001 04:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming of RepresentationType

  • Key: PKI-16
  • Legacy Issue Number: 4207
  • Status: closed  
  • Source: DSTC ( Simon Gibson)
  • Summary:

    The name "RepresentationType" would indicate that the type is a definition of a particular representation type, when in fact is a structure carrying a particular set of encoded information. For clarity this type should be renaming to something like "EncodedInformation".

  • Reported: PKI 1.0b1 — Mon, 19 Feb 2001 05:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specification of CertificateType

  • Key: PKI-15
  • Legacy Issue Number: 4206
  • Status: closed  
  • Source: DSTC ( Simon Gibson)
  • Summary:

    Section 2 "PKI Interface" does not define CertificateType. For completeness CertificateType should be declared under section 2, probably following the definition of EncodingType (see issue B).

  • Reported: PKI 1.0b1 — Mon, 19 Feb 2001 05:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specification of EncodingType

  • Key: PKI-14
  • Legacy Issue Number: 4205
  • Status: closed  
  • Source: DSTC ( Simon Gibson)
  • Summary:

    Section 2 "PKI Interface" does not define EncodingType. There is a an introduction to this is section 1, and details in the IDL, however, for completeness - EncodingType should be declared under section 2, probably following the definition of Opaque.

  • Reported: PKI 1.0b1 — Mon, 19 Feb 2001 05:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

issues in the PKI spec need to be brought into line with AMI.

  • Key: PKI-13
  • Legacy Issue Number: 4197
  • Status: closed  
  • Source: DSTC ( Simon Gibson)
  • 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.

  • Reported: PKI 1.0b1 — Mon, 5 Feb 2001 05:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The exceptions listed in Appendix A are not described in section 2.

  • Key: PKI-12
  • Legacy Issue Number: 4196
  • Status: closed  
  • Source: DSTC ( Simon Gibson)
  • Summary:

    The exceptions listed in Appendix A are not described in section 2.

  • Reported: PKI 1.0b1 — Mon, 5 Feb 2001 05:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Insufficient semantic detail

  • Key: PKI-11
  • Legacy Issue Number: 4195
  • Status: closed  
  • Source: DSTC ( Simon Gibson)
  • Summary:

    Insufficient semantic detail to cover the lifetime of Request<sometype>Manager objects ie when can the server clean up resources.

  • Reported: PKI 1.0b1 — Mon, 5 Feb 2001 05:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In section 2.3.5.2 a transaction_ID is introduced without sufficient explan

  • Key: PKI-10
  • Legacy Issue Number: 4194
  • Status: closed  
  • Source: DSTC ( Simon Gibson)
  • Summary:

    In section 2.3.5.2 a transaction_ID is introduced without sufficient explanation.

  • Reported: PKI 1.0b1 — Mon, 5 Feb 2001 05:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The PKIStatus constants are not explained sufficiently.

  • Key: PKI-9
  • Legacy Issue Number: 4193
  • Status: closed  
  • Source: DSTC ( Simon Gibson)
  • Summary:

    The PKIStatus constants are not explained sufficiently.

  • Reported: PKI 1.0b1 — Mon, 5 Feb 2001 05:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Replace the term "local value object type" as used in 2.2

  • Key: PKI-8
  • Legacy Issue Number: 4192
  • Status: closed  
  • Source: DSTC ( Simon Gibson)
  • Summary:

    The term "local value object type" used in 2.2 should probably be replaced by "value type". Sections 2.2.3-7

  • Reported: PKI 1.0b1 — Mon, 5 Feb 2001 05:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    Change the incorrect term to "valuetype" in text in Sections 2.2.3-7.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

use of "any"

  • Key: PKI-7
  • Legacy Issue Number: 4191
  • Status: closed  
  • Source: DSTC ( Simon Gibson)
  • Summary:

    The use of "any" rather than a union to handle the representation_type in structures for Certificates, CRLs etc. Sections 2.2.3-7

  • Reported: PKI 1.0b1 — Mon, 5 Feb 2001 05:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    see abobe

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In IDL in Section 2 the raises clause has been left out

  • Key: PKI-6
  • Legacy Issue Number: 4190
  • Status: closed  
  • Source: DSTC ( Simon Gibson)
  • Summary:

    In IDL in Section 2 the raises clause has been left out. This is in contrast to the IDL in the appendix and is confusing.

  • Reported: PKI 1.0b1 — Mon, 5 Feb 2001 05:00 GMT
  • Disposition: Resolved — PKI 1.0
  • Disposition Summary:

    Add raises clause where appropriate

  • Updated: Fri, 6 Mar 2015 20:58 GMT