Eric Cronin wrote:
...
> I'm working on an implementation of forward-secure signature
> algorithms, whose keys can sometimes contain multiple RSA/DSA/ECDSA/etc
> keys. I haven't tackled the best way to PKCS encode these
> forward-secure keys yet, so in the meantime I have just been using a
> simple obj1_size||obj1_blob||obj2_size||obj2_blob||... encoding, using
> i2d_DSAPublicKey and the like when I needed to dump out an OpenSSL key.
> I will probably switch to putting the raw keys into an EVP_PKEY for
> the encoding as Steve suggested, but my original goal was just to use
> the simplest encoding possible since the code will all be removed once
> a real encoding is decided upon.
I think you should use, as Steve suggested, the X509 DER encoded
SubjectPublicKeyInfo object because a simple EC public key
(without parameters) isn't really useful.
...
> > The ECPublicKey_{set|get}_octet_string() functions should simply return
> > (or set) the public key as an octet string (as the name suggest). They
> > have
> > nothing to do with ASN1 DER encoding => no i2d or d2i prefix.
> > Note: the ec public key in the X509 SubjectPublicKeyInfo object is not
> > DER encoded (the most significant bit of the public key (encoded
> > as an octet string) becomes the most significant bit of the bit
> > string).
>
> OK, maybe "encoding" is the wrong term to have used. What I meant is
> that all the other (OpenSSL internal datastructure) <-> (char * buffer)
> functions I can think of have the side effect of advancing the output
> buffer's pointer after copying the data (unless it allocated the
> buffer, in which case it doesn't)... The ECPublicKey_{set,get} ones,
> while having that same common function signature, do not. Maybe this
> is just i2d/d2i functions vs. all other functions of this nature, in
> which case I've unfairly singled out ECPublicKey_{set,get}/
>
> I'm not saying that advancing the buffer pointer is the best design
I guess the reason for this was to simplify the OpenSSL ASN1 macros/
functions (you can call the corresponding de- encode functions in a
row, without taking care of the pointer).
> (personally I think side effects like that just to save the caller from
> a simple += are bad), but it would at least be nice if all of OpenSSL's
> foo_convert(object * foo, char **out) had the same behavior regarding
> if (!out), if (out && !*out) and if (out && *out) and similarly for the
> conversion back to in internal datastructure.
Ack => I will think about it ...
Regards,
Nils
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
