OASIS Key Management Interoperability Protocol (KMIP) TC

Expand all | Collapse all

question regarding conformance statement for KMIP

  • 1.  question regarding conformance statement for KMIP

    Posted 05-14-2009 00:36
    Hi -
    
    Rather than convening a meeting on conformance (as I'd suggested a
    couple of meetings ago), I'd like to pose the question I've been
    wondering about and see if there is an issue or not:
    
    -	Should we modify the language in Section 5 of the Usage Guide to
    clarify what "support all objects etc" means? In particular, do we need
    to clarify whether this means a) the server has to implement all
    mandatory objects etc or b) the server has to understand requests
    related to all mandatory objects etc (but can return back an "object not
    supported" message). 
    
    In drafting the conformance language currently included in the Usage
    Guide, I followed the advice expressed in the Conformance Testing
    document available at http://xml.coverpages.org/conform20000112.html:
    that is, "the requirements or criteria for conformance must be specified
    in the standard or specification. This is usually in a conformance
    clause or conformance statement..."
    
    The conformance statement in section 5 of the KMIP Usage Guide
    distinguishes between conformance requirements for KMIP servers and
    clients:
    
    "Server implementations of the KMIP protocol must support all objects,
    attributes, operations and profiles not specified as "optional" in the
    KMIP Specification in order to be conformant to the specification.
    Server implementations that do not support objects, attributes,
    operations and profiles defined as "optional" can claim KMIP
    conformance, though they may be limited in terms of interoperability
    with other KMIP implementations.
    
    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. In order to claim conformance,
    however, such a client must implement all aspects of any elements of the
    protocol (objects, attributes, operations, profiles) that it claims to
    support. In the example of Get/Locate support for symmetric keys,
    therefore, a conforming client implementation must support all required
    attributes for symmetric keys."
    
    In re-reading the conformance statement for server implementations, it
    looks to me that I made it more restrictive than I intended - that the
    language should perhaps have been something like:
    
    "Server implementations of the KMIP protocol shall accept and respond to
    client requests for all objects, operations and profiles not specified
    as 'optional' in the KMIP Specification in order to be conformant to the
    specification; a conformant response can be 'this object etc is not
    supported.'" 
    
    But perhaps it's better to have the more restrictive language, after
    all?
    
    I'd appreciate your thoughts!
    
    Regards,
    
    Bob
    


  • 2.  RE: [kmip] question regarding conformance statement for KMIP

    Posted 05-14-2009 01:58
    Robert -
    
    My opinion is that an implementation that wants to claim compliance to
    the standard would be required to respond accurately to all
    required/mandatory objects.  A response of "not supported" would only be
    appropriate for an optional object.
    
    - Peter 
    
    


  • 3.  RE: [kmip] question regarding conformance statement for KMIP

    Posted 05-14-2009 03:40
    I'd like to understand the resolution of mapping of IEEE 1619.3 to KMIP first.
    
    Regards,
    Larry H 
    
    


  • 4.  RE: [kmip] question regarding conformance statement for KMIP

    Posted 05-14-2009 13:27

    Peter,

    I'm not sure what you meant by "mandatory object".  It would seem that all objects are optional, as the server's response to a Query Objects operation specifies those objects that the server supports, and all the managed objects are potential entries in that list. So if a server does not wish to support registration of SplitKey, then it would simply omit SplitKey from the list of objects that it claims it will support (if the client bothers to ask via Query Objects).

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



    From: "Zelechoski, Peter" <pzelechoski@essvote.com>
    To: <robert.griffin@rsa.com>
    Cc: <kmip@lists.oasis-open.org>
    Date: 05/13/2009 08:57 PM
    Subject: RE: [kmip] question regarding conformance statement for KMIP





    Robert -

    My opinion is that an implementation that wants to claim compliance to
    the standard would be required to respond accurately to all
    required/mandatory objects.  A response of "not supported" would only be
    appropriate for an optional object.

    - Peter


    mailto:robert.griffin@rsa.com]
    Sent: 2009-05-13 7:36 PM
    To: kmip@lists.oasis-open.org
    Subject: [kmip] question regarding conformance statement for KMIP

    Hi -

    Rather than convening a meeting on conformance (as I'd suggested a
    couple of meetings ago), I'd like to pose the question I've been
    wondering about and see if there is an issue or not:

    -                 Should we modify the language in Section 5 of the Usage Guide to
    clarify what "support all objects etc" means? In particular, do we need
    to clarify whether this means a) the server has to implement all
    mandatory objects etc or b) the server has to understand requests
    related to all mandatory objects etc (but can return back an "object not
    supported" message).

    In drafting the conformance language currently included in the Usage
    Guide, I followed the advice expressed in the Conformance Testing
    document available at
    http://xml.coverpages.org/conform20000112.html:
    that is, "the requirements or criteria for conformance must be specified
    in the standard or specification. This is usually in a conformance
    clause or conformance statement..."

    The conformance statement in section 5 of the KMIP Usage Guide
    distinguishes between conformance requirements for KMIP servers and
    clients:

    "Server implementations of the KMIP protocol must support all objects,
    attributes, operations and profiles not specified as "optional" in the
    KMIP Specification in order to be conformant to the specification.
    Server implementations that do not support objects, attributes,
    operations and profiles defined as "optional" can claim KMIP
    conformance, though they may be limited in terms of interoperability
    with other KMIP implementations.

    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. In order to claim conformance,
    however, such a client must implement all aspects of any elements of the
    protocol (objects, attributes, operations, profiles) that it claims to
    support. In the example of Get/Locate support for symmetric keys,
    therefore, a conforming client implementation must support all required
    attributes for symmetric keys."

    In re-reading the conformance statement for server implementations, it
    looks to me that I made it more restrictive than I intended - that the
    language should perhaps have been something like:

    "Server implementations of the KMIP protocol shall accept and respond to
    client requests for all objects, operations and profiles not specified
    as 'optional' in the KMIP Specification in order to be conformant to the
    specification; a conformant response can be 'this object etc is not
    supported.'"

    But perhaps it's better to have the more restrictive language, after
    all?

    I'd appreciate your thoughts!

    Regards,

    Bob

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


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





  • 5.  RE: [kmip] question regarding conformance statement for KMIP

    Posted 05-14-2009 13:38
    
    
    
    
    
    Bruce -
     
    OK, I understand what you are saying.  However, I wonder about a standard with no required exchanges for claiming conformance.  There should be something the system must handle to claim conformance.  If you can answer "not supported" to every object and still say you are conformant, you have delivered nothing of value and that waters down the claims of truly conformant systems.
     
    - Peter


    From: Bruce Rich [mailto:brich@us.ibm.com]
    Sent: 2009-05-14 8:27 AM
    To: Zelechoski, Peter
    Cc: kmip@lists.oasis-open.org; robert.griffin@rsa.com
    Subject: RE: [kmip] question regarding conformance statement for KMIP


    Peter,

    I'm not sure what you meant by "mandatory object".  It would seem that all objects are optional, as the server's response to a Query Objects operation specifies those objects that the server supports, and all the managed objects are potential entries in that list. So if a server does not wish to support registration of SplitKey, then it would simply omit SplitKey from the list of objects that it claims it will support (if the client bothers to ask via Query Objects).

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



    From: "Zelechoski, Peter" <pzelechoski@essvote.com>
    To: <robert.griffin@rsa.com>
    Cc: <kmip@lists.oasis-open.org>
    Date: 05/13/2009 08:57 PM
    Subject: RE: [kmip] question regarding conformance statement for KMIP





    Robert -

    My opinion is that an implementation that wants to claim compliance to
    the standard would be required to respond accurately to all
    required/mandatory objects.  A response of "not supported" would only be
    appropriate for an optional object.

    - Peter


    mailto:robert.griffin@rsa.com]
    Sent: 2009-05-13 7:36 PM
    To: kmip@lists.oasis-open.org
    Subject: [kmip] question regarding conformance statement for KMIP

    Hi -

    Rather than convening a meeting on conformance (as I'd suggested a
    couple of meetings ago), I'd like to pose the question I've been
    wondering about and see if there is an issue or not:

    -                 Should we modify the language in Section 5 of the Usage Guide to
    clarify what "support all objects etc" means? In particular, do we need
    to clarify whether this means a) the server has to implement all
    mandatory objects etc or b) the server has to understand requests
    related to all mandatory objects etc (but can return back an "object not
    supported" message).

    In drafting the conformance language currently included in the Usage
    Guide, I followed the advice expressed in the Conformance Testing
    document available at
    http://xml.coverpages.org/conform20000112.html:
    that is, "the requirements or criteria for conformance must be specified
    in the standard or specification. This is usually in a conformance
    clause or conformance statement..."

    The conformance statement in section 5 of the KMIP Usage Guide
    distinguishes between conformance requirements for KMIP servers and
    clients:

    "Server implementations of the KMIP protocol must support all objects,
    attributes, operations and profiles not specified as "optional" in the
    KMIP Specification in order to be conformant to the specification.
    Server implementations that do not support objects, attributes,
    operations and profiles defined as "optional" can claim KMIP
    conformance, though they may be limited in terms of interoperability
    with other KMIP implementations.

    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. In order to claim conformance,
    however, such a client must implement all aspects of any elements of the
    protocol (objects, attributes, operations, profiles) that it claims to
    support. In the example of Get/Locate support for symmetric keys,
    therefore, a conforming client implementation must support all required
    attributes for symmetric keys."

    In re-reading the conformance statement for server implementations, it
    looks to me that I made it more restrictive than I intended - that the
    language should perhaps have been something like:

    "Server implementations of the KMIP protocol shall accept and respond to
    client requests for all objects, operations and profiles not specified
    as 'optional' in the KMIP Specification in order to be conformant to the
    specification; a conformant response can be 'this object etc is not
    supported.'"

    But perhaps it's better to have the more restrictive language, after
    all?

    I'd appreciate your thoughts!

    Regards,

    Bob

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


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





  • 6.  RE: [kmip] question regarding conformance statement for KMIP

    Posted 05-14-2009 15:17

    Peter,

    I agree that conformance needs to mean something.  I was merely looking at the current specification to see if it says anything that reads on the current discussion point.  It seems to indicate that all managed objects are optional.

    If we want KMIP conformance claims to be meaningful, it may mean that we either change the specification, or that we introduce profiles over the top of the specification.  (This was basically the approach used with the Web Services specs, where WS-I introduced profiles of the specs that had meaningful, interoperable subsets).

    <possibleRatHole>
    I would love it if KMIPv1 did not require support of Key Wrapping Specification (as not needed over SSL-protected session),  but if I say that I support any ManagedObject on the Query Objects call, then it looks like I need to (with some set of CryptographicParameters).  The current Query doesn't seem to allow me to tell clients not to ask for or to send wrapped keys.

    I would also love it if KMIPv1 did not require support of the Derive Key operation (with 7 defined derivation mechanisms), but if I say that I support SymmetricKey on the Query Objects call, then it looks like I need to, as Query doesn't have a way for me to report this either.  This would simply be a matter of adding Derive Key to the optional operations list that Query Operations can report on.
    </possibleRatHole>

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



    From: "Zelechoski, Peter" <pzelechoski@essvote.com>
    To: Bruce Rich/Austin/IBM@IBMUS
    Cc: <kmip@lists.oasis-open.org>, <robert.griffin@rsa.com>
    Date: 05/14/2009 08:38 AM
    Subject: RE: [kmip] question regarding conformance statement for KMIP





    Bruce -
     
    OK, I understand what you are saying.  However, I wonder about a standard with no required exchanges for claiming conformance.  There should be something the system must handle to claim conformance.  If you can answer "not supported" to every object and still say you are conformant, you have delivered nothing of value and that waters down the claims of truly conformant systems.
     
    - Peter


    From: Bruce Rich [mailto:brich@us.ibm.com]
    Sent:
    2009-05-14 8:27 AM
    To:
    Zelechoski, Peter
    Cc:
    kmip@lists.oasis-open.org; robert.griffin@rsa.com
    Subject:
    RE: [kmip] question regarding conformance statement for KMIP



    Peter,


    I'm not sure what you meant by "mandatory object".  It would seem that all objects are optional, as the server's response to a Query Objects operation specifies those objects that the server supports, and all the managed objects are potential entries in that list. So if a server does not wish to support registration of SplitKey, then it would simply omit SplitKey from the list of objects that it claims it will support (if the client bothers to ask via Query Objects).


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



    From: "Zelechoski, Peter" <pzelechoski@essvote.com>
    To: <robert.griffin@rsa.com>
    Cc: <kmip@lists.oasis-open.org>
    Date: 05/13/2009 08:57 PM
    Subject: RE: [kmip] question regarding conformance statement for KMIP






    Robert -

    My opinion is that an implementation that wants to claim compliance to
    the standard would be required to respond accurately to all
    required/mandatory objects.  A response of "not supported" would only be
    appropriate for an optional object.

    - Peter


    mailto:robert.griffin@rsa.com]
    Sent: 2009-05-13 7:36 PM
    To: kmip@lists.oasis-open.org
    Subject: [kmip] question regarding conformance statement for KMIP

    Hi -

    Rather than convening a meeting on conformance (as I'd suggested a
    couple of meetings ago), I'd like to pose the question I've been
    wondering about and see if there is an issue or not:

    -                 Should we modify the language in Section 5 of the Usage Guide to
    clarify what "support all objects etc" means? In particular, do we need
    to clarify whether this means a) the server has to implement all
    mandatory objects etc or b) the server has to understand requests
    related to all mandatory objects etc (but can return back an "object not
    supported" message).

    In drafting the conformance language currently included in the Usage
    Guide, I followed the advice expressed in the Conformance Testing
    document available at
    http://xml.coverpages.org/conform20000112.html:
    that is, "the requirements or criteria for conformance must be specified
    in the standard or specification. This is usually in a conformance
    clause or conformance statement..."

    The conformance statement in section 5 of the KMIP Usage Guide
    distinguishes between conformance requirements for KMIP servers and
    clients:

    "Server implementations of the KMIP protocol must support all objects,
    attributes, operations and profiles not specified as "optional" in the
    KMIP Specification in order to be conformant to the specification.
    Server implementations that do not support objects, attributes,
    operations and profiles defined as "optional" can claim KMIP
    conformance, though they may be limited in terms of interoperability
    with other KMIP implementations.

    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. In order to claim conformance,
    however, such a client must implement all aspects of any elements of the
    protocol (objects, attributes, operations, profiles) that it claims to
    support. In the example of Get/Locate support for symmetric keys,
    therefore, a conforming client implementation must support all required
    attributes for symmetric keys."

    In re-reading the conformance statement for server implementations, it
    looks to me that I made it more restrictive than I intended - that the
    language should perhaps have been something like:

    "Server implementations of the KMIP protocol shall accept and respond to
    client requests for all objects, operations and profiles not specified
    as 'optional' in the KMIP Specification in order to be conformant to the
    specification; a conformant response can be 'this object etc is not
    supported.'"

    But perhaps it's better to have the more restrictive language, after
    all?

    I'd appreciate your thoughts!

    Regards,

    Bob

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


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






  • 7.  RE: [kmip] question regarding conformance statement for KMIP

    Posted 05-14-2009 15:34
    
    
    
    
    
    Bruce -
     
    I think we are in agreement.  Although you have been able to assess what the implications are for you; I haven't gotten there yet.
     
    - Peter


    From: Bruce Rich [mailto:brich@us.ibm.com]
    Sent: 2009-05-14 10:17 AM
    To: Zelechoski, Peter
    Cc: kmip@lists.oasis-open.org
    Subject: RE: [kmip] question regarding conformance statement for KMIP


    Peter,

    I agree that conformance needs to mean something.  I was merely looking at the current specification to see if it says anything that reads on the current discussion point.  It seems to indicate that all managed objects are optional.

    If we want KMIP conformance claims to be meaningful, it may mean that we either change the specification, or that we introduce profiles over the top of the specification.  (This was basically the approach used with the Web Services specs, where WS-I introduced profiles of the specs that had meaningful, interoperable subsets).

    <possibleRatHole>
    I would love it if KMIPv1 did not require support of Key Wrapping Specification (as not needed over SSL-protected session),  but if I say that I support any ManagedObject on the Query Objects call, then it looks like I need to (with some set of CryptographicParameters).  The current Query doesn't seem to allow me to tell clients not to ask for or to send wrapped keys.

    I would also love it if KMIPv1 did not require support of the Derive Key operation (with 7 defined derivation mechanisms), but if I say that I support SymmetricKey on the Query Objects call, then it looks like I need to, as Query doesn't have a way for me to report this either.  This would simply be a matter of adding Derive Key to the optional operations list that Query Operations can report on.
    </possibleRatHole>

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



    From: "Zelechoski, Peter" <pzelechoski@essvote.com>
    To: Bruce Rich/Austin/IBM@IBMUS
    Cc: <kmip@lists.oasis-open.org>, <robert.griffin@rsa.com>
    Date: 05/14/2009 08:38 AM
    Subject: RE: [kmip] question regarding conformance statement for KMIP





    Bruce -
     
    OK, I understand what you are saying.  However, I wonder about a standard with no required exchanges for claiming conformance.  There should be something the system must handle to claim conformance.  If you can answer "not supported" to every object and still say you are conformant, you have delivered nothing of value and that waters down the claims of truly conformant systems.
     
    - Peter


    From: Bruce Rich [mailto:brich@us.ibm.com]
    Sent:
    2009-05-14 8:27 AM
    To:
    Zelechoski, Peter
    Cc:
    kmip@lists.oasis-open.org; robert.griffin@rsa.com
    Subject:
    RE: [kmip] question regarding conformance statement for KMIP



    Peter,


    I'm not sure what you meant by "mandatory object".  It would seem that all objects are optional, as the server's response to a Query Objects operation specifies those objects that the server supports, and all the managed objects are potential entries in that list. So if a server does not wish to support registration of SplitKey, then it would simply omit SplitKey from the list of objects that it claims it will support (if the client bothers to ask via Query Objects).


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



    From: "Zelechoski, Peter" <pzelechoski@essvote.com>
    To: <robert.griffin@rsa.com>
    Cc: <kmip@lists.oasis-open.org>
    Date: 05/13/2009 08:57 PM
    Subject: RE: [kmip] question regarding conformance statement for KMIP






    Robert -

    My opinion is that an implementation that wants to claim compliance to
    the standard would be required to respond accurately to all
    required/mandatory objects.  A response of "not supported" would only be
    appropriate for an optional object.

    - Peter


    mailto:robert.griffin@rsa.com]
    Sent: 2009-05-13 7:36 PM
    To: kmip@lists.oasis-open.org
    Subject: [kmip] question regarding conformance statement for KMIP

    Hi -

    Rather than convening a meeting on conformance (as I'd suggested a
    couple of meetings ago), I'd like to pose the question I've been
    wondering about and see if there is an issue or not:

    -                 Should we modify the language in Section 5 of the Usage Guide to
    clarify what "support all objects etc" means? In particular, do we need
    to clarify whether this means a) the server has to implement all
    mandatory objects etc or b) the server has to understand requests
    related to all mandatory objects etc (but can return back an "object not
    supported" message).

    In drafting the conformance language currently included in the Usage
    Guide, I followed the advice expressed in the Conformance Testing
    document available at
    http://xml.coverpages.org/conform20000112.html:
    that is, "the requirements or criteria for conformance must be specified
    in the standard or specification. This is usually in a conformance
    clause or conformance statement..."

    The conformance statement in section 5 of the KMIP Usage Guide
    distinguishes between conformance requirements for KMIP servers and
    clients:

    "Server implementations of the KMIP protocol must support all objects,
    attributes, operations and profiles not specified as "optional" in the
    KMIP Specification in order to be conformant to the specification.
    Server implementations that do not support objects, attributes,
    operations and profiles defined as "optional" can claim KMIP
    conformance, though they may be limited in terms of interoperability
    with other KMIP implementations.

    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. In order to claim conformance,
    however, such a client must implement all aspects of any elements of the
    protocol (objects, attributes, operations, profiles) that it claims to
    support. In the example of Get/Locate support for symmetric keys,
    therefore, a conforming client implementation must support all required
    attributes for symmetric keys."

    In re-reading the conformance statement for server implementations, it
    looks to me that I made it more restrictive than I intended - that the
    language should perhaps have been something like:

    "Server implementations of the KMIP protocol shall accept and respond to
    client requests for all objects, operations and profiles not specified
    as 'optional' in the KMIP Specification in order to be conformant to the
    specification; a conformant response can be 'this object etc is not
    supported.'"

    But perhaps it's better to have the more restrictive language, after
    all?

    I'd appreciate your thoughts!

    Regards,

    Bob

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


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






  • 8.  RE: [kmip] question regarding conformance statement for KMIP

    Posted 06-10-2009 16:46
    
    
    
    
    
    I agree with Bruce that this level of support granularity needs to be able to be conveyed via a Query:
     
    <possibleRatHole>
    I would love it if KMIPv1 did not require support of Key Wrapping Specification (as not needed over SSL-protected session),  but if I say that I support any ManagedObject on the Query Objects call, then it looks like I need to (with some set of CryptographicParameters).  The current Query doesn't seem to allow me to tell clients not to ask for or to send wrapped keys.


    I would also love it if KMIPv1 did not require support of the Derive Key operation (with 7 defined derivation mechanisms), but if I say that I support SymmetricKey on the Query Objects call, then it looks like I need to, as Query doesn't have a way for me to report this either.  This would simply be a matter of adding Derive Key to the optional operations list that Query Operations can report on.

    </possibleRatHole>

     
    One possible way would be for the Query response on Query Operations to include a 'template' of the supported operation fields for each supported operation.  Then for a 'Get' operation (for example), support for both the Unique Identifier and Key Wrapping Specification fields could be indicated by returning a payload template as supported by the server (e.g., the template may omit the Key Wrapping Specification, indicating it is not supported in a Get request).
     
    I think this is related to the general compliance discussion, but should at least be an item for KMIPv1.
     
    thanks,
     
    Rod Wideman
    Quantum Corporation
    (please disregard the confidentiality statement below)
     


    From: Bruce Rich [mailto:brich@us.ibm.com]
    Sent: Thursday, May 14, 2009 10:17 AM
    To: Zelechoski, Peter
    Cc: kmip@lists.oasis-open.org
    Subject: RE: [kmip] question regarding conformance statement for KMIP


    Peter,

    I agree that conformance needs to mean something.  I was merely looking at the current specification to see if it says anything that reads on the current discussion point.  It seems to indicate that all managed objects are optional.

    If we want KMIP conformance claims to be meaningful, it may mean that we either change the specification, or that we introduce profiles over the top of the specification.  (This was basically the approach used with the Web Services specs, where WS-I introduced profiles of the specs that had meaningful, interoperable subsets).

    <possibleRatHole>
    I would love it if KMIPv1 did not require support of Key Wrapping Specification (as not needed over SSL-protected session),  but if I say that I support any ManagedObject on the Query Objects call, then it looks like I need to (with some set of CryptographicParameters).  The current Query doesn't seem to allow me to tell clients not to ask for or to send wrapped keys.

    I would also love it if KMIPv1 did not require support of the Derive Key operation (with 7 defined derivation mechanisms), but if I say that I support SymmetricKey on the Query Objects call, then it looks like I need to, as Query doesn't have a way for me to report this either.  This would simply be a matter of adding Derive Key to the optional operations list that Query Operations can report on.
    </possibleRatHole>

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



    From: "Zelechoski, Peter" <pzelechoski@essvote.com>
    To: Bruce Rich/Austin/IBM@IBMUS
    Cc: <kmip@lists.oasis-open.org>, <robert.griffin@rsa.com>
    Date: 05/14/2009 08:38 AM
    Subject: RE: [kmip] question regarding conformance statement for KMIP





    Bruce -
     
    OK, I understand what you are saying.  However, I wonder about a standard with no required exchanges for claiming conformance.  There should be something the system must handle to claim conformance.  If you can answer "not supported" to every object and still say you are conformant, you have delivered nothing of value and that waters down the claims of truly conformant systems.
     
    - Peter


    From: Bruce Rich [mailto:brich@us.ibm.com]
    Sent:
    2009-05-14 8:27 AM
    To:
    Zelechoski, Peter
    Cc:
    kmip@lists.oasis-open.org; robert.griffin@rsa.com
    Subject:
    RE: [kmip] question regarding conformance statement for KMIP



    Peter,


    I'm not sure what you meant by "mandatory object".  It would seem that all objects are optional, as the server's response to a Query Objects operation specifies those objects that the server supports, and all the managed objects are potential entries in that list. So if a server does not wish to support registration of SplitKey, then it would simply omit SplitKey from the list of objects that it claims it will support (if the client bothers to ask via Query Objects).


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



    From: "Zelechoski, Peter" <pzelechoski@essvote.com>
    To: <robert.griffin@rsa.com>
    Cc: <kmip@lists.oasis-open.org>
    Date: 05/13/2009 08:57 PM
    Subject: RE: [kmip] question regarding conformance statement for KMIP






    Robert -

    My opinion is that an implementation that wants to claim compliance to
    the standard would be required to respond accurately to all
    required/mandatory objects.  A response of "not supported" would only be
    appropriate for an optional object.

    - Peter


    mailto:robert.griffin@rsa.com]
    Sent: 2009-05-13 7:36 PM
    To: kmip@lists.oasis-open.org
    Subject: [kmip] question regarding conformance statement for KMIP

    Hi -

    Rather than convening a meeting on conformance (as I'd suggested a
    couple of meetings ago), I'd like to pose the question I've been
    wondering about and see if there is an issue or not:

    -                 Should we modify the language in Section 5 of the Usage Guide to
    clarify what "support all objects etc" means? In particular, do we need
    to clarify whether this means a) the server has to implement all
    mandatory objects etc or b) the server has to understand requests
    related to all mandatory objects etc (but can return back an "object not
    supported" message).

    In drafting the conformance language currently included in the Usage
    Guide, I followed the advice expressed in the Conformance Testing
    document available at
    http://xml.coverpages.org/conform20000112.html:
    that is, "the requirements or criteria for conformance must be specified
    in the standard or specification. This is usually in a conformance
    clause or conformance statement..."

    The conformance statement in section 5 of the KMIP Usage Guide
    distinguishes between conformance requirements for KMIP servers and
    clients:

    "Server implementations of the KMIP protocol must support all objects,
    attributes, operations and profiles not specified as "optional" in the
    KMIP Specification in order to be conformant to the specification.
    Server implementations that do not support objects, attributes,
    operations and profiles defined as "optional" can claim KMIP
    conformance, though they may be limited in terms of interoperability
    with other KMIP implementations.

    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. In order to claim conformance,
    however, such a client must implement all aspects of any elements of the
    protocol (objects, attributes, operations, profiles) that it claims to
    support. In the example of Get/Locate support for symmetric keys,
    therefore, a conforming client implementation must support all required
    attributes for symmetric keys."

    In re-reading the conformance statement for server implementations, it
    looks to me that I made it more restrictive than I intended - that the
    language should perhaps have been something like:

    "Server implementations of the KMIP protocol shall accept and respond to
    client requests for all objects, operations and profiles not specified
    as 'optional' in the KMIP Specification in order to be conformant to the
    specification; a conformant response can be 'this object etc is not
    supported.'"

    But perhaps it's better to have the more restrictive language, after
    all?

    I'd appreciate your thoughts!

    Regards,

    Bob

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


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





    The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum Corporation. Furthermore, Quantum Corporation is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.


  • 9.  RE: question regarding conformance statement for KMIP

    Posted 05-16-2009 17:09
    
    
    
    
    
    
    I agree there should be additions to the conformance section.  I have included several proposed changes (as requested a few meetings ago) as a place to start.  They include conformance claims, a table of required vs. optional items for both client and server (to be filled in), reference guidelines when claiming conformance by another standard and usage guidelines when using KMIP without claiming conformance.
     
     
    Not sure if this is what you were looking for from me Bob & Tony when you asked but this is what I have so far.  Looking for feedback.
     
    Bob L.
     

    Robert A. (Bob) Lockhart

    Senior Solutions Architect

    THALES Information Systems Security

     

    -------------------------------------------------------

    T:      +1 408 457 7711 (Direct)

    M:     +1 510 410 0585

    F:      +1 408 457 7681

    E:      rlockhart@ncipher.com

    W:     www.nCipher.com

     

             nCipher product line. See www.nCipher.com


    From: robert.griffin@rsa.com [robert.griffin@rsa.com]
    Sent: Wednesday, May 13, 2009 5:35 PM
    To: kmip@lists.oasis-open.org
    Subject: [kmip] question regarding conformance statement for KMIP

    Hi -

    Rather than convening a meeting on conformance (as I'd suggested a
    couple of meetings ago), I'd like to pose the question I've been
    wondering about and see if there is an issue or not:

    -       Should we modify the language in Section 5 of the Usage Guide to
    clarify what "support all objects etc" means? In particular, do we need
    to clarify whether this means a) the server has to implement all
    mandatory objects etc or b) the server has to understand requests
    related to all mandatory objects etc (but can return back an "object not
    supported" message).

    In drafting the conformance language currently included in the Usage
    Guide, I followed the advice expressed in the Conformance Testing
    document available at http://xml.coverpages.org/conform20000112.html:
    that is, "the requirements or criteria for conformance must be specified
    in the standard or specification. This is usually in a conformance
    clause or conformance statement..."

    The conformance statement in section 5 of the KMIP Usage Guide
    distinguishes between conformance requirements for KMIP servers and
    clients:

    "Server implementations of the KMIP protocol must support all objects,
    attributes, operations and profiles not specified as "optional" in the
    KMIP Specification in order to be conformant to the specification.
    Server implementations that do not support objects, attributes,
    operations and profiles defined as "optional" can claim KMIP
    conformance, though they may be limited in terms of interoperability
    with other KMIP implementations.

    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. In order to claim conformance,
    however, such a client must implement all aspects of any elements of the
    protocol (objects, attributes, operations, profiles) that it claims to
    support. In the example of Get/Locate support for symmetric keys,
    therefore, a conforming client implementation must support all required
    attributes for symmetric keys."

    In re-reading the conformance statement for server implementations, it
    looks to me that I made it more restrictive than I intended - that the
    language should perhaps have been something like:

    "Server implementations of the KMIP protocol shall accept and respond to
    client requests for all objects, operations and profiles not specified
    as 'optional' in the KMIP Specification in order to be conformant to the
    specification; a conformant response can be 'this object etc is not
    supported.'"

    But perhaps it's better to have the more restrictive language, after
    all?

    I'd appreciate your thoughts!

    Regards,

    Bob

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



    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 +1 (781) 994 4000 or email ussales@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 Inc.


  • 10.  KMIP to P1619.3 Mapping

    Posted 05-16-2009 17:17
    
    
    
    
    
    
    Since we have not had time during the weekly phone calls I would like to mention several things about the mapping process.
     
    I would like to open it up to P1619.3 to get their feedback.  The document is public and can be accessed by them currently and it was brought up in the most recent meeting. 
     
    Within P1619.3 there has been a proposal although deferred to move P1619.3 to conform (there is that word again) with KMIP and use it as the binary messaging format.  Once we have a formal liaison in place (status?) can we discuss this?
     
    I would like to get this and the conformance discussion on the agenda for this next weeks meeting and would like to plan for 15 minutes for each topic with any additional conversation occuring via email reflector due to time constraints we currently have in the meeting.
     
    Thanks,
     
    Bob L.
     

    Robert A. (Bob) Lockhart

    Senior Solutions Architect

    THALES Information Systems Security

     

    -------------------------------------------------------

    T:      +1 408 457 7711 (Direct)

    M:     +1 510 410 0585

    F:      +1 408 457 7681

    E:      rlockhart@ncipher.com

    W:     www.nCipher.com

     

             nCipher product line. See www.nCipher.com

     


    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 +1 (781) 994 4000 or email ussales@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 Inc.


  • 11.  Re: [kmip] KMIP to P1619.3 Mapping

    Posted 05-17-2009 06:56
    I'm not sure that I agree that this should be a priority. It seems to be
    more a distraction than anything else. Is there a reason KMIP should be
    pegged against P1619.3? Just curious why this is seen as important, but
    mapping to other standards committees is not.
    
    -ben
    
    -- 
    Benjamin Tomhave, MS, CISSP
    falcon@secureconsulting.net
    LI: http://www.linkedin.com/in/btomhave
    Blog: http://www.secureconsulting.net/
    Photos: http://photos.secureconsulting.net/
    Web: http://falcon.secureconsulting.net/
    
    [ Random Quote: ]
    Parkinson's Law: "Work expands so as to fill the time available for its
    completion."
    http://globalnerdy.com/2007/07/18/laws-of-software-development/
    
    Robert Lockhart wrote:
    > Since we have not had time during the weekly phone calls I would like to
    > mention several things about the mapping process.
    >  
    > I would like to open it up to P1619.3 to get their feedback.  The
    > document is public and can be accessed by them currently and it was
    > brought up in the most recent meeting. 
    >  
    > Within P1619.3 there has been a proposal although deferred to move
    > P1619.3 to conform (there is that word again) with KMIP and use it as
    > the binary messaging format.  Once we have a formal liaison in place
    > (status?) can we discuss this?
    >  
    > I would like to get this and the conformance discussion on the agenda
    > for this next weeks meeting and would like to plan for 15 minutes for
    > each topic with any additional conversation occuring via email reflector
    > due to time constraints we currently have in the meeting.
    >  
    > Thanks,
    >  
    > Bob L.
    >  
    > 
    > *Robert A. (Bob) Lockhart *
    > 
    > Senior Solutions Architect
    > 
    > *THALES* Information Systems Security
    > 
    >  
    > 
    > -------------------------------------------------------
    > 
    > *T*:      +1 408 457 7711 (Direct)
    > 
    > *M*:     +1 510 410 0585
    > 
    > *F*:      +1 408 457 7681
    > 
    > *E*:      rlockhart@ncipher.com
    > 
    > *W*:     www.nCipher.com 


  • 12.  Re: [kmip] KMIP to P1619.3 Mapping

    Posted 05-17-2009 12:40
    KMIP and P1619.3 focus on different areas of Key
    Management Service architecture (see Bob Lockhart's
    slide deck for further details).  Where there is overlap, there
    appears to be close alignment.  A number of vendors are
    pursuing both complementary standards.
    
    We believe that it is extremely important that implementations
    have the opportunity to be both KMIP and P1619.3 compliant.
    We welcome Bob Lockhart's proposal to receive P1619.3
    feedback on the public document.
    
    chongo (Landon Curt Noll) /\oo/\
    
    =-=
    
    On 2009-May-16, at 23:55, Benjamin Tomhave wrote:
    
    > I'm not sure that I agree that this should be a priority. It seems  
    > to be
    > more a distraction than anything else. Is there a reason KMIP should  
    > be
    > pegged against P1619.3? Just curious why this is seen as important,  
    > but
    > mapping to other standards committees is not.
    >
    > Robert Lockhart wrote:
    >> Since we have not had time during the weekly phone calls I would  
    >> like to
    >> mention several things about the mapping process.
    >>
    >> I would like to open it up to P1619.3 to get their feedback.  The
    >> document is public and can be accessed by them currently and it was
    >> brought up in the most recent meeting.
    >>
    >> Within P1619.3 there has been a proposal although deferred to move
    >> P1619.3 to conform (there is that word again) with KMIP and use it as
    >> the binary messaging format.  Once we have a formal liaison in place
    >> (status?) can we discuss this?
    >>
    >> I would like to get this and the conformance discussion on the agenda
    >> for this next weeks meeting and would like to plan for 15 minutes for
    >> each topic with any additional conversation occuring via email  
    >> reflector
    >> due to time co