I too agree with Michael (and John) that Fresh should be set for the new object and should not be copied out of the original object. This applies to both ReKey and ReKeyKeyPair. This is how the Cryptsoft C interop server handles things - i.e. Fresh is always set to true for the replacement object. Tim. On 2/07/2012 3:45 PM, John Leiseboer wrote: > What should be done with the fresh attribute after a rekey operation? The specification indicates that it should be copied from the key being replaced if you believe Table 131 (and therefore could be false even though the new key has never been served up to a client), or should be set to true if you believe section 3.34. > > I agree with Michael (see below) that the fresh attribute should be set to true after a rekey operation. Does anyone have another opinion? > > John > > -----Original Message----- > From: Michael [ mailto:
ms@quintessencelabs.com ] > Sent: Friday, 29 June 2012 5:29 PM > To: John Leiseboer > Subject: Small omission in KMIP standard > > Hi John, > > I'm looking at the re-key operation right now. This creates a new object that takes the name from an existing object. Now, in my understanding, this SHOULD reset the Fresh attribute (since the new object is new and has never been supplied to a client, Fresh should be TRUE), but table 131, which lists the attributes that are not copied directly from the attributes, does not include Fresh. > > So, is the table missing an item, or is the description of the Fresh attribute missing an odd special case? > > -- Michael > > > --------------------------------------------------------------------- > To unsubscribe, e-mail:
kmip-interop-tech-unsubscribe@lists.oasis-open.org > For additional commands, e-mail:
kmip-interop-tech-help@lists.oasis-open.org >