OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [kmip] Groups - Key Format Type spec updates uploaded


Interesting. It turns out we already had this reason code in the spec, both 1.x and 2.0 (down near the Key Compression reason), so we're not adding a new reason code per se. We would have to tweak the explanation a bit, as it currently reads "The object exists, but the server is unable to provide it in the desired Key Format Type", which is not quite right any more. And we'd need to add that reason code to a few more "Error Handling" tables.

The question about Register remains, though.

Bruce

On Thu, Jul 12, 2018 at 3:10 PM, Bruce Rich <bar@cryptsoft.com> wrote:
Hey, I won't be on today's call, but a couple of things came up that I thought maybe we could talk about on the mailing list.
1) The spec update I submitted on Key Format Type didn't require the server to create the Digest for the default key format type on a Register. That seems short-sighted on my part (wasn't really mentioned one way or the other in the original proposal at the F2F). I've attached an updated version of tc-181 that shows how it would look if the server also did the Digest on the default format (see the output from the second GetAttributes). If the point is interoperability, then requiring it on Register as well (if it's not a metadata-only object) makes sense.
2) Folks were interested in a new ReasonCode for "couldn't handle that key format". We could do that. But we already had this case in the 1.x protocol, as one could do a Get and specify a particular format for the key that the server couldn't handle. That case could have used this reason code as well, but we apparently didn't see the wisdom of it then. Is it a good thing now? What changed? Possibly we're now smarter than "those people back then"? So thought I'd ask, "Are you sure?" In theory, folks with 1.x and 2.0 servers should not surface this 2.0 reason code to 1.x clients, so it is not without impacts.

BruceÂ

---------- Forwarded message ----------
From: Bruce Rich <bar@cryptsoft.com>
Date: Wed, Jun 20, 2018 at 3:05 PM
Subject: [kmip] Groups - Key Format Type spec updates uploaded
To: kmip@lists.oasis-open.org


Document Name: Key Format Type spec updates

Description
Spec update from F2F topic...see
https://www.oasis-open.org/apps/org/workgroup/kmip/download.php/62857/KeyFormatType.pptx
Download Latest Revision
Public Download Link

Submitter: Mr. Bruce Rich
Group: OASIS Key Management Interoperability Protocol (KMIP) TC
Folder: Drafts
Date submitted: 2018-06-20 12:05:32





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]