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 - kmip-cs-profile-v1.0-wd01-review.doc uploaded


On 28/06/2013 4:09 PM, John Leiseboer wrote:

Thanks for the response Tim.

 

I still have a question about BCM and padding. This is an interop question, not an attempt to reopen old debate about the merits of the cryptographic operations. I accept that these attributes are modifiable by a client. But the Encrypt and Decrypt operations are not modifying them. Can these operations temporarily override the BCM and padding rules associated with a key? Or should/must the server return an error if a client requests BCM/Padding that is not defined for the key?


Quoting the specification (using Encrypt as the example):

"The Cryptographic Parameters (Block Cipher Mode, Padding Method, RandomIV) corresponding to the particular encryption method requested. If omitted then the Cryptographic Parameters associated with the Managed Cryptographic Object with the lowest Attribute Index SHALL be used. If there are no Cryptographic Parameters associated with the Managed Cryptographic Object and the algorithm requires parameters then the operation SHALL return with a Result Status of Operation Failed."

Stating it differently since it seems your email indicates that style of text used throughout the specification text is (in your view) unclear:
    use the value from the message if it is present;
    otherwise use the lowest index value from the associated attributes for the object;
    if no parameters and parameters are required then this is an error.

At no point within the specification of those operations is there any requirement stated for a server to "match" the requested parameters against what may or may not be associated with the object. That was a deliberate choice in the specification of those operations and discussed when the draft was circulated almost a year ago and on each subsequent version and discussion.

A server of course may elect to implement whatever policy it wants for handling this - however that would be outside the base specification - and may not support clients that depend on this behaviour. The right place and mechanism for defining dependencies on behaviours and subsets where the specification allows a range of options is in a profile - and it would be interesting to work through defining a profile which matches what you have described - however such things do not (by consensus) belong within the specification itself.

Tim.




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