Re: [kmip] PKCS#12 Proposal: Clarification of Question in TC

[Tim Hudson <tjh@cryptsoft.com>]

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.