[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] Groups - KMIP-One Time Pad.pdf uploaded
|
Chuck, Jerry, A few comments: 1.
Slide 9, line 10. “Encrypt” should be “Decrypt” 2.
The examples do not demonstrate the use of the OTP enumeration (in the sense that the XML does not actually show the Cryptographic
Algorithm being specified or returned). I assume that whatever objects identified in the Locate response contain an attribute with the OTP algorithm value, which is interpreted within the server during the Encrypt/Decrypt operations. 3.
Given that the examples show Encrypt and Decrypt operations, some questions arise:
a.
Does the Encrypt operation fail if the Fresh attribute is False? (To reduce possibility of encrypting with the same one-time
pad more than once.)
b.
How does Decrypt behave for different values of the Fresh attribute? How should it behave?
c.
When is the one-time pad destroyed?
d.
Are streaming operations supported? How? Does the server need to maintain state for the offset into the key stream between
encrypt/decrypt parts? 4.
How does the one-time pad key stream get onto the server? Create? Register? 5.
Can a one-time pad key stream be read from the server; e.g. using Get? 6.
Can a one-time pad be extended, or is it always a fixed length immutable value? 7.
Usually a modulo addition operation - typically XOR for binary encoded data - is used as the one-time pad cipher, but in
general almost any invertible function can be used, and some systems do use other functions. I assume that you mean the OTP to be XOR, but this should be clearly stated. 8.
I was expecting to see use cases presented to help the TC understand the purpose and use of the OTP algorithm with more
context. I think this is missing from the proposal. I realise that all you are asking for is the addition of the OTP Cryptographic Algorithm enumeration, but one-time pad operations are sufficiently different, in my opinion, to fixed key length crypto operations
to deserve better than the Locate, Encrypt, Decrypt examples you’ve supplied. I’ve provided use cases for one-time operations in the past that would not be satisfied by the simple request for addition of an Algorithm enumeration. Maybe the TC will take more
kindly to your request than mine. Given several years’ experience in the market with one-time pad support in a KMIP server though, I’m pretty certain of what customers need and want, what can be done within the standard, and what is required of the standard
for sufficient flexibility and interoperability. 9.
I do agree that a managed object is required for support of one-time pad operations. But following on from the previous
point, I do not agree that adding an OTP algorithm to a Symmetric Key object (which is what I assume you are proposing) is sufficient. It is limiting and inflexible. It may be more constructive to discuss this offline. I am happy to share use cases and expand on my reasons for preferring an alternative
solution. It is hard using email, and the TC call to discuss this in the detail it deserves. And I am conscious of wasting other TC members’ time. Perhaps a concall between just those of us with OTP requirements would be more efficient? Regards, John From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org]
On Behalf Of Charles White Submitter's message
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]