pkcs11 — archive

[Michael StJohns]

On 4/11/2013 2:04 AM, Peter Gutmann wrote: Michael StJohns <msj@nthpermutation.com> writes: It's probably a bit more than that. It may make sense (in the sections for each type of public key) to provide DER templates that can just be filled in. It's actually not that bad, if you look at: Sequence { Sequence { Object Identifier, id-ecPublicKey Object Identifier id for the curve } Bit String (0 extra bits) { Encoding of Octet String { X9.63 representation of an uncompressed point { 0x04 X Y} } } } then the token (well, lets face it, the driver) already has to provide the OID and the encoded point as DER data (so the no-DER rule is already violated), which means that the inner SEQUENCE and the OIDs are a static blob, as is the encoded point. All the "DER encoder" needs to add is the inner BIT STRING header and the outer SEQUENCE header. In addition for all but P521 curves the length will be encodable in a single byte, so the encoding is just: data[ 0 ] = 0x30; data[ 1 ] = length; data[ ... ] = OIDs blob data[ n ] = 0x03 data [n + 1] = 2 * key size + 4 (1 for spare bits, 2 for octet string header, 1 for ec point format byte) data [n + 2] = 0x00 data [n + 3] = 0x04 data [n + 4] = 2 * key size + 1 data [ ... ] { 0x04 X Y } data[ n+1 ] = 0x00 data[ ... ] = point blob In practice you'd probably have an "encodeSequence()" and "encodeBitString()" that inserted the tag + length and use that for RSA, DSA, ECDSA, etc. Peter. I think we're in violent agreement though that this is minimal work, even inside a token. But that's not required. As a minimum, the low level code in the HSM has to do a "generatePublicKeyFromPrivate()" and return that value to the driver. The driver can then (in user space) format the SubjectPublicKeyInfo.