[erlang-questions] public_key:pem_decode/1 and public_key:verify/4

Seth Falcon seth@REDACTED
Mon Jan 24 17:12:45 CET 2011


On Mon, Jan 24, 2011 at 2:51 AM, Ingela Andin <ingela.andin@REDACTED> wrote:
> I think that the decoding of  'SubjectPublicKeyInfo',  from
> pem_decode_public_key, should rather be handled in the
> function pem_entry_decode. As I think the normal thing is that you
> want the actual key and not a 'SubjectPublicKeyInfo', that would
> mean just a little more decoding is done by pem_entry_decode. (You can
> match on the 'SubjectPublicKeyInfo' in the function head to
> create a clause for this.)

Sure.  I agree that the common case is that you want the public key in
a form that can be used for encrypt/decrypt as easily as possible.
I'll try reworking things so that this happens inside pem_entry_decode
-- and then remove the pem_decode_public_key function.

Can you point me at docs on how to run the tests for the public_key
module?

> It will not then be a 100 % symmetric with pem_entry_encode but I
> think  that is ok, it could be mentioned in the documentation.
> Another reason that this is a good idea is that it will not then be
> sensitive to that the public_key is the only entry in the file.
> PEM files may contain several entries which is not handled by your
> function.

Do you think it should be possible to reproduce the
SubjectPublicKeyInfo-style PEM file given an 'RSAPublicKey' record
type?  I think this has some value, aside from symmetry, because it is
the default output of openssl.

I admit that I haven't yet worked through the encoding cases in any
detail, so perhaps I'm not clear on how this is supposed to work.

> When it comes to the function der_decode_publick_key I am not sure it
> is needed as I think it
> is uncommon that you end up with a "DER-blob" that you do not know how
> it is encoded.

ok, will remove.

+ seth

-- 
Seth Falcon | @sfalcon | http://userprimary.net/


More information about the erlang-questions mailing list