OASIS Key Management Interoperability Protocol (KMIP) TC

 View Only
  • 1.  KMIP TC Meeting Minutes Posted - January 16, 2024



  • 2.  RE: KMIP TC Meeting Minutes Posted - January 16, 2024

    Posted 26 days ago
    The discussion on PQC formats was a consensus that we would remain aligned with PKCS#11 as usual and allow SEED but not require it and the wait and see bit was just about what the various SDKs end up doing as that would impact our interop testing. If a vendor uses an SDK that doesn't have flexibility they may have challenges to interoperate fully.

    That doesn't come through in the minutes as clearly as it needs to for those who weren't in the meeting.

    Tim.

    On Thu, 23 Jan 2025, 01:54 Jeff Bartell via OASIS, <Mail@mail.groups.oasis-open.org> wrote:
    Minutes from the January 16, 2024 TC Meeting are available for review at the following locations groups.oasis-open.org/higherlogic/ws/groups/...... -posted to the "OASIS Key Management Interoperability Protocol (KMIP) TC" community

    OASIS Key Management Interoperability Protocol (KMIP) TC

    Post New Message
    KMIP TC Meeting Minutes Posted - January 16, 2024
    Reply to Group Reply to Sender via Email
    Jan 22, 2025 10:55 AM
    Jeff Bartell
    Minutes from the January 16, 2024 TC Meeting are available for review at
    the following locations

    groups.oasis-open.org/higherlogic/ws/groups/...
    github.com/oasis-tcs/kmip/wiki/...

    Thanks,
    Jeff
      Reply to Group via Email   Reply to Sender via Email   View Thread   Recommend   Forward  



     
    You are subscribed to "OASIS Key Management Interoperability Protocol (KMIP) TC" as tjh@cryptsoft.com. To change your subscriptions, go to My Subscriptions. To unsubscribe from this community discussion, go to Unsubscribe.





  • 3.  RE: KMIP TC Meeting Minutes Posted - January 16, 2024

    Posted 26 days ago

    Tim,

     

    I don't disagree that KMIP tends to remain aligned with PKCS#11, but there was no formal motion made in the meeting to state that KMIP 3.0 would align with the approach that PKCS#11 was taking on the private key format, so I don't think one could say there was consensus.    I for one thought the discussion was an update on the challenges with implementing the new algorithms and the different interpretations being taken around private key formats.   An issue that has to be sorted out out across the industry/standard bodies otherwise there would be interoperability issues.   But it was not clear in the meeting that were were making our decision for what we would do in KMIP 3.0.    Nor was it clear that KMIP was going to be mentioned in the letter that was being sent to the IETF LAMPs WG.

     

    Judy

     


    Internal Use - Confidential

    From: Tim Hudson via OASIS <Mail@mail.groups.oasis-open.org>
    Sent: Wednesday, January 22, 2025 6:20 PM
    To: Furlong, Judith <Judith.Furlong@dell.com>
    Subject: RE: OASIS Key Management Interoperability Protocol (KMIP) TC : KMIP TC Meeting Minutes Posted - January 16, 2024

     

    [EXTERNAL EMAIL]

    The discussion on PQC formats was a consensus that we would remain aligned with PKCS#11 as usual and allow SEED but not require it and the wait... -posted to the "OASIS Key Management Interoperability Protocol (KMIP) TC" community






  • 4.  RE: KMIP TC Meeting Minutes Posted - January 16, 2024

    Posted 26 days ago
    The discussion was very clear about the challenge of FIPS140 validation and that we do not currently support SEED at all in our currrent working draft at of the meeting last week - it isn't there. 

    I said I would add it so we could be SEED or KEY with a recommendation to be both which is aligned with PKCS#11 and allows for interop with all implementions. 

    There were no objections and no counter views expressed that we should do something different.

    WD17 has *no* support for SEED at all.
    There has been no suggested updates.

    WD18 allows one or the other or both which allows for maximum interoperability.

    How PKCS#8 usage turns out is being debated now - but with WD18 we can express the need details independent of PKCS8. I cannot create test cases with PKCS8 without the issue being resolved but I can create them using the new key format type which will let us proceed with some additional testing. We also cannot use the RAW format either as what should it be? Right now all the test cases do not have SEED in them. That could be changed. But then it would be SEED only. We should not have length based heuristics to determine which of SEED or KEY or both we have to deal with.

    That letter expressed my view of the consensus of the committee and the conversations to date. I do not think it is at all in conflict with the discussions to date.

    We have not voted on the issue in a formal sense as we are waiting to see how things turn out - but there was a clear consensus. We form a consensus view without votes all the time. And we validate that set of things when we vote on working drafts which we haven't done as yet for any of this work. 

    If we elected to take a view contrary to PKCS#11 on this topic we would introduce real concrete interoperability issues and the TC has never knowingly made such a choice.

    If anyone had raised the possibility of a different view I would have called a vote to test the consensus. That didn't happen.

    The letter that was sent was very focused on the SDK side of things and the PKCS#11 and KMIP was showing that other standards bodies have not aligned to *mandate* SEED.

    This is a true statement and until WD18 there was no mechanism in KMIP to support SEED at all. The discussion to date was to add that but not to mandate it. 

    If you truely believe I have misrepresented the consensus view of the KMIP TC please confirm that and I will resign as the liaison between the groups (in both TCs). I do not believe I have and I have been very careful in how I have presented my understanding of the TC. There simply is no way to perform that role if a co-chair believes things have been misrepresented.

    I'm travelling at the moment, but once I get your confirmation I'll send in the resignation letter and the TC can vote to appoint someone else as the liaison.

    Tim.


    On Thu, 23 Jan 2025, 10:01 Judith Furlong via OASIS, <Mail@mail.groups.oasis-open.org> wrote:
    Tim, I don't disagree that KMIP tends to remain aligned with PKCS#11, but there was no formal motion made in the meeting to state that KMIP...

    OASIS Key Management Interoperability Protocol (KMIP) TC

    Post New Message
    Re: KMIP TC Meeting Minutes Posted - January 16, 2024
    Reply to Group Reply to Sender via Email
    Jan 22, 2025 7:01 PM
    Judith Furlong

    Tim,

     

    I don't disagree that KMIP tends to remain aligned with PKCS#11, but there was no formal motion made in the meeting to state that KMIP 3.0 would align with the approach that PKCS#11 was taking on the private key format, so I don't think one could say there was consensus.    I for one thought the discussion was an update on the challenges with implementing the new algorithms and the different interpretations being taken around private key formats.   An issue that has to be sorted out out across the industry/standard bodies otherwise there would be interoperability issues.   But it was not clear in the meeting that were were making our decision for what we would do in KMIP 3.0.    Nor was it clear that KMIP was going to be mentioned in the letter that was being sent to the IETF LAMPs WG.

     

    Judy

     


    Internal Use - Confidential

     

    [EXTERNAL EMAIL]

    The discussion on PQC formats was a consensus that we would remain aligned with PKCS#11 as usual and allow SEED but not require it and the wait... -posted to the "OASIS Key Management Interoperability Protocol (KMIP) TC" community



      Reply to Group via Email   Reply to Sender via Email   View Thread   Recommend   Forward  




     
    You are subscribed to "OASIS Key Management Interoperability Protocol (KMIP) TC" as tjh@cryptsoft.com. To change your subscriptions, go to My Subscriptions. To unsubscribe from this community discussion, go to Unsubscribe.



    Original Message:
    Sent: 1/22/2025 7:01:00 PM
    From: Judith Furlong
    Subject: RE: KMIP TC Meeting Minutes Posted - January 16, 2024

    Tim,

     

    I don't disagree that KMIP tends to remain aligned with PKCS#11, but there was no formal motion made in the meeting to state that KMIP 3.0 would align with the approach that PKCS#11 was taking on the private key format, so I don't think one could say there was consensus.    I for one thought the discussion was an update on the challenges with implementing the new algorithms and the different interpretations being taken around private key formats.   An issue that has to be sorted out out across the industry/standard bodies otherwise there would be interoperability issues.   But it was not clear in the meeting that were were making our decision for what we would do in KMIP 3.0.    Nor was it clear that KMIP was going to be mentioned in the letter that was being sent to the IETF LAMPs WG.

     

    Judy

     


    Internal Use - Confidential

    From: Tim Hudson via OASIS <Mail@mail.groups.oasis-open.org>
    Sent: Wednesday, January 22, 2025 6:20 PM
    To: Furlong, Judith <Judith.Furlong@dell.com>
    Subject: RE: OASIS Key Management Interoperability Protocol (KMIP) TC : KMIP TC Meeting Minutes Posted - January 16, 2024

     

    [EXTERNAL EMAIL]

    The discussion on PQC formats was a consensus that we would remain aligned with PKCS#11 as usual and allow SEED but not require it and the wait... -posted to the "OASIS Key Management Interoperability Protocol (KMIP) TC" community




    Original Message:
    Sent: 1/22/2025 6:20:00 PM
    From: Tim Hudson
    Subject: RE: KMIP TC Meeting Minutes Posted - January 16, 2024

    The discussion on PQC formats was a consensus that we would remain aligned with PKCS#11 as usual and allow SEED but not require it and the wait and see bit was just about what the various SDKs end up doing as that would impact our interop testing. If a vendor uses an SDK that doesn't have flexibility they may have challenges to interoperate fully.

    That doesn't come through in the minutes as clearly as it needs to for those who weren't in the meeting.

    Tim.

    On Thu, 23 Jan 2025, 01:54 Jeff Bartell via OASIS, <Mail@mail.groups.oasis-open.org> wrote:
    Minutes from the January 16, 2024 TC Meeting are available for review at the following locations groups.oasis-open.org/higherlogic/ws/groups/...... -posted to the "OASIS Key Management Interoperability Protocol (KMIP) TC" community

    OASIS Key Management Interoperability Protocol (KMIP) TC

    Post New Message
    KMIP TC Meeting Minutes Posted - January 16, 2024
    Reply to Group Reply to Sender via Email
    Jan 22, 2025 10:55 AM
    Jeff Bartell
    Minutes from the January 16, 2024 TC Meeting are available for review at
    the following locations

    groups.oasis-open.org/higherlogic/ws/groups/...
    github.com/oasis-tcs/kmip/wiki/...

    Thanks,
    Jeff
      Reply to Group via Email   Reply to Sender via Email   View Thread   Recommend   Forward  



     
    You are subscribed to "OASIS Key Management Interoperability Protocol (KMIP) TC" as tjh@cryptsoft.com. To change your subscriptions, go to My Subscriptions. To unsubscribe from this community discussion, go to Unsubscribe.