The PKIStatus constants are not explained sufficiently.
see below
Insufficient semantic detail to cover the lifetime of Request<sometype>Manager objects ie when can the server clean up resources.
see below
In section 2.3.5.2 a transaction_ID is introduced without sufficient explanation.
see above
The exceptions listed in Appendix A are not described in section 2.
see below
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.
see above
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.
see above
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".
see above
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).
see above
The use of "any" rather than a union to handle the representation_type in structures for Certificates, CRLs etc. Sections 2.2.3-7
see abobe
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.
Add raises clause where appropriate
The term "local value object type" used in 2.2 should probably be replaced by "value type". Sections 2.2.3-7
Change the incorrect term to "valuetype" in text in Sections 2.2.3-7.
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.
see above
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
;
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!
see above
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.
/**
see above
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.
/**
;
Change IDL to make RequestManager and abstract interface
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;
see above
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
;
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.
see above