RE: [kmip] Proposed update to Profiles document

[Jon Geater <Jon.Geater@thales-esecurity.com>]

Just a picky point of interpretation on this.

 

The new proposed text says:

 

“”

In the presence of Credential information in the request header, KMIP servers SHALL factor such Credential information into their evaluation of client authenticity and identity, along with the authenticity and identity derived from the channel.  

“”

 

I would like for it to be possible to ignore the channel credentials entirely for certain operations when credentials are provided in the header.  Are we comfortable that the text allows that?  Perhaps:

 

“”

In the presence of Credential information in the request header, KMIP servers SHALL use such Credential information to determine client authenticity and identity, and MAY factor such information together with the authenticity and identity derived from the channel.  

“”

 

I appreciate the grammar’s not perfect but I have an hour less to do this than I thought this week...

 

Jon

 

From: Bruce Rich [mailto:brich@us.ibm.com]
Sent: 29 October 2009 02:42
To: kmip@lists.oasis-open.org
Cc: indra.fitzgerald@hp.com
Subject: [kmip] Proposed update to Profiles document

 

At last week's TC call, Indra and I were tasked with coming up with mutually-agreed text to close our issues with the Profile document.
We would propose replacing sections 3.1.3.and 3.1.4 of the Profiles document with the following:
============== Beginning of replacement text ============================
3.1.3 Client authenticity and identity

For authenticated services (all operations save Query) KMIP servers SHALL require the use of channel (SSL/TLS) mutual authentication to prove client authenticity.

In the absence of Credential information in the request header, KMIP servers SHALL use the identity derived from the channel authentication as the client identity.

In the presence of Credential information in the request header, KMIP servers SHALL factor such Credential information into their evaluation of client authenticity and identity, along with the authenticity and identity derived from the channel.  The exact mechanisms for such evaluation are outside the scope of this specification.

3.1.4 Object creator

KMIP objects have a creator. For those KMIP requests that result in new managed objects the client identity SHALL be used as the creator of the managed object.  For those operations that only access pre-existent managed objects, the client identity SHALL be checked against the creator, and access SHALL be controlled as detailed in section 3.13 of [KMIP].
============== End of replacement text ============================

I won't clutter up this note with a whole lot of background material, but on the TC call we can certainly discuss some of the rationale that led us to this proposal. (Or not)

Thanks,
Bruce A Rich
brich at-sign us dot ibm dot com

---

nCipher Corporation Limited is incorporated in England and Wales with company registration number 3169278. Its registered office is located at Jupiter House, Station Road, Cambridge, Cambs, CB1 2JD.

The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +44 (0)1223 723600 or email sales@ncipher.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of nCipher Corporation Limited.