[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [kmip] PKCS#12 Proposal: Clarification of Question in TC
On 22/05/2015 6:47 AM, John Leiseboer wrote: > Should operations, such as Register, that take as input a Key Object, where the Key Block specifies a Key Type of PKCS#12 return an error? If so, should the standard state that it is an error to attempt to Register a PKCS#12 key type? Asking the question in generic form and applying it to all versions of the specification you are basically asking if there should be specific text in the specification or error codes or return values when a user provides input that mismatches - i.e. nothing in the specification states you should return an error if someone performs a register with a Key Format Type of (for example) EC Private Key for a Certificate managed object. The item I raised on the TC call in response to your query was that this is not a transformation of a managed object into a different format context - i.e. this is not a parameter to an operation - Get has they Key Format Type as a parameter and Register does not. In the context of Register the server is free to simply keep the information and not perform any transformation on it at all (nor is a server precluded from transforming into whatever internal representation - be it one specified in KMIP in the existing Key Format Type enumeration or something entirely else). The two contexts are entirely different - one explicitly is about transformation (Get) and the other is not (Register). Putting aside the specific context (PKCS#12 and this proposal) for a moment - there is nothing in section 11.4 (Register) for the error conditions related to mismatches between Key Format Type and the requirements of the underlying managed object representation - the specification contains no text or guidance or requirements or even error codes for that sort of thing. The closest is the Result Reason of Key Format Type Not Supported - but that is noted in the error table in section 11.12 (Get) We already have an allocated work item from the face to face to review the error codes to determine if they should be changed - and adding this type of error condition into that list (i.e. how should requests which are inconsistent or illogical be handled) for consideration might make sense. This is not a PKCS#12 specific or a proposal specific issue - and if we haven't faced this as a pressing issue in the core specification in existing contexts that needs addressing then we should decide if it should be addressed generically and not as an item in a specific proposal. It is also handy that we have an allocated work item that this would fit within. Tim.