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] 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]