pkcs11 — archive

[Stef Walter]

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