Re: Public-key fixes (was "info for OASIS PKCS 11 TC concall/meeting")

[Stef Walter <stefw@redhat.com>]

On 03.04.2013 02:26, Peter Gutmann wrote:
> Michael StJohns <msj@nthpermutation.com> writes:
> 
>> I've gone back and forth on whether this is the right place for this. Mostly
>> the contract for C_DeriveKey is for secret keys with TLS and SSL mechanisms
>> being the notable examples 
> 
> I think it was picked as the least awful option rather than because it was a 
> perfect fit :-).
> 
>> Getting back to the current issue - I think it may make sense to instead do
>> this as an attribute - CKA_EC_PUBLIC_POINT associated with both a public and
>> private key - for the public key this is just the alias of the CKA_EC_POINT.
>> If the attribute doesn't exist, then implementation can synthesize it.
>>
>> Likewise CKA_DSA_PUBLIC_VALUE and CKA_VALUE for DSA keys.
> 
> Yeah, that certainly makes more sense.
> 
>> Alternately, CKA_PUBLIC_KEY which can be used for any of RSA, DSA and EC and
>> produces a SubjectPublicKeyInfo blob of the appropriate type.
> 
> That would be good too, because at the moment you need to cobble together all
> sorts of bits and pieces, often in weird formats (does anyone know why the EC
> objects use X9.62-format information in a non-X9.62 form?).  Just getting the
> SubjectPublicKeyInfo would be the best solution in my case.

I agree. The need for an attribute that contains the full DER
SubjectPublicKeyInfo is also something we ran into when trying to work
out a more complete trust model on top of PKCS#11.

Cheers,

Stef