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] RE: ReKey Link Attribute Query


Thanks a lot guys J

 

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: 09 June 2017 01:36
To: kmip@lists.oasis-open.org
Subject: Re: [kmip] RE: ReKey Link Attribute Query

 

And note that under KMIP 2.0 as per the face to face decisions, the behaviour of destroy is explicitly changed to match the original intent - meta-data has to be kept (which happens to match the majority of deployed servers in the market to date and the original intention of the KMIP 1.0 specification) and unique identifiers cannot be re-used.

 

Tim.

 

On Fri, Jun 9, 2017 at 2:29 AM, Bruce Rich <bar@cryptsoft.com> wrote:

Nitin,

 

I would give a different answer, with a different picture for the outcome of create key 1, then rekey key1, then rekey key 2, then destroy key2.

 

If one does more than the KMIP spec calls for, then you can end up with the pictures you showed, and the question you posed.  However, if one only does what the spec requires..."the key material for the specified Managed Object SHALL be destroyed", then you end up with my picture.  If on Destroy, one does not destroy the object, but just the key material, then all the UIDs remain assigned, all the metadata remains, only the key material for "Key 2" is rendered inaccessible/unusable (which I tried to depict by spraypainting over the "Key 2" text).  One can sidestep the discussion of UID reuse, as the UIDs are still in use, and auditors can see the history of what has transpired.  I would also note that one of the things that one can Query of the server is its CapabilityInformation, which includes what "Shredding Algorithm" it will perform on the key material of Destroy'd objects (and spraypainting over the key material is NOT actually one of the options).

 

Regards,

Bruce Rich

 

On Thu, Jun 8, 2017 at 10:19 AM, John Leiseboer <JL@quintessencelabs.com> wrote:

The values of the link attributes should not change. Of course for servers that re-use unique identifiers this could be an issue. But this would also be an issue for links between public and private keys, and public keys and certificates. In fact anywhere that UIDs of keys are stored in attributes or even in applications outside of servers, re-use of UIDs would be problematic.

 

John

 

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Jain Nitin
Sent: Thursday, 8 June 2017 11:54 PM
To: kmip@lists.oasis-open.org
Subject: [kmip] ReKey Link Attribute Query

 

Dear KMIP TC Members,

 

I want to discuss the behaviour of Link attributes while doing Re-Key operation.

Suppose there are  3 Keys: Key1, Key2 and Key3

Where Key2 created by Re-Key on key1 and key3 is created by Re-Key on Key2, as shown in below dig:

 

 

 

 

My question is :

If someone deletes Key2, then what should be expected behaviour ?

 

Should it be like below:

 

 

Or Should it be like below:

 

 

 

Thanks & Regards,

Nitin Jain | Software Development | Gemalto (Safenet)


This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd.
______________________________________________________________________

 



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

 


This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.


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