[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [kmip] RE: [kmip-comment] Issue with KMIP 1.1 Profiles document
Adding PKCS#1 to the list of formats makes sense to me and also adding RAW to support non-RSA "binary" formats seems reasonable. Removing the Transparent RSA formats is not a step I think is sensible as if you already have an RSA key in is logical parts (i.e. in data structures within existing applications) then if the transparent formats are removed an application would have to construct a PKCS#1 form of the key in order to be able to register it. The Transparent formats were meant to be the "portable" version of key containers without a requirement for a client or server to have to support ASN.1 encoding or decoding in their handling of managed objects (at least that is my understanding of the rationale behind some of the early decisions). They should remain mandatory. Looking at the current profiles document we have an inconsistency in that we do not list the transparent formats as mandatory in the "Asymmetric Key Store" (something which is inconsistent with the the symmetric key store). It would make sense to have the transparent formats across all the profiles. I for one have assumed that "RAW" in the context of RSA actually means the same as PKCS#1 - i.e. RAW is the "native binary format" for the key. I haven't heard or seen a different (meaningful) definition of what RAW is meant to be in the context of anything other than a symmetric key. Thanks, Tim.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]