RE: [kmip] minimal client conformance statement

["Fitzgerald, Indra" <indra.fitzgerald@hp.com>]

All,

Further modifications are required to this section (Section 8) of the KMIP specification. It seems unnecessary and redundant to include the certificate used during the SSL handshake in the Credential object. If an incorrect or invalid certificate was provided, the handshake will fail. If the client or server do not have the corresponding private key, the handshake will fail. The Usage Guide no longer requires the client certificate to be contained in the Credential object. The two paragraphs that address this were removed from the Usage Guide and I would suggest for us to remove this from the specification. 

We also need to clarify whether a server is required to support both the SSL/TLS and HTTPS profiles or just one profile. The spec currently requires both profiles to be supported. The Usage Guide also requires both; however, 'Mandatory' only appears to be specified for the SSL/TLS profile (Section 3.1).

Regards,
Indra 

-----Original Message-----
From: Mills, Hyrum L [mailto:hmills@mitre.org] 
Sent: Tuesday, September 01, 2009 6:56 AM
To: kmip@lists.oasis-open.org
Subject: Re: [kmip] minimal client conformance statement

All -
  Having reviewed parts of the spec again this morning, I am reminded that section 8 says:
  "-SSL/TLS authentication. If the transport protocol uses a normal TCP stream, then that stream
  should use an SSL/TLS encryption layer, and the client and server authentication features must
  be enabled unless otherwise specified in the operation. The Credential object contained in the
  Authentication field in all request messages will contain the client's certificate. The server should
  use this certificate to identify the client for policy enforcement purposes, and should verify that
  this certificate matches the one used for SSL/TLS authentication.

 -HTTPS authentication. If the transport protocol is HTTP over TCP, then the HTTPS protocol
 should be used, and the client and server authentication features enabled unless otherwise
 specified in the operation. The contents and use of the Credential object are the same as in the
 bullet above."

I propose changing two sentences of the above text:

First: "If the transport protocol uses a normal TCP stream, then that stream **shall** use an SSL/TLS encryption layer, and the client and server authentication features must be enabled unless otherwise specified in the operation,"
Second: "The server **shall** use this certificate to identify the client for policy enforcement purposes, and **shall** verify that this certificate matches the one used for SSL/TLS authentication. **A failure to match this certificate with the one used for SSL/TLS authentication shall result in an error and failure to proceed.**"

(proposed changes are surrounded by **)

If these changes were made, I would agree that the network proxy issue is addressed and that no client conformance statement is necessary.  Are these changes acceptable?

Respectfully, 
Hyrum Mills
The MITRE Corporation

Larry.Hofer@Emulex.Com<mailto:Larry.Hofer@Emulex.Com> wrote:

Hello all,

Given there seemed to be a near-consensus at yesterday's call for having no client clause at all, I'd suggest that we start with this, minimal statement for clients, if we have any statement for clients compliance:

Client implementations of the KMIP protocol may implement any subset of the KMIP protocol. For example, a client may implement only the Get and Locate operations for symmetric keys. A client must be able to make at least one request that is compatible with server compliance requirements in this standard to claim client compliance .

I think starting with no client clause in v1 would save the committee time though, with no harm to adoption of KMIP,
Larry H

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php