[erlang-questions] public_key & OpenSSL format weirdness

[zxq9]

On 2015年2月26日 木曜日 12:18:48 zxq9 wrote:
> On 2015年2月26日 木曜日 11:01:22 zxq9 wrote:
> > So it appears there are 24 extra bytes appended to the OpenSSL generated
> > DER that are confusing the asn1 import function, but only in the case of
> > public RSA keys, as private OpenSSL generated DER keys match what is
> > expected.
> Apparently OpenSSL adds an asn1 header, either on its own or because PKCS#1
> demands it (or PKCS#8? I haven't found a clear reference, but it should be
> one of those), and Erlang, iOS and a few other environments that expect a
> public RSA key in DER format do not expect this header.

Ah ha! So... perhaps the big problem is really a lack of documentation. It 
also seems that the canonical PKCS#1 asn1 definition is a bit ambiguous. In 
any case, there is an openssl tool that has the same effect as chopping off 
the first 24 bytes if invoked that way:

$ openssl asn1parse -strparse 24 -inform DER -in rsa3.pub.der.openssl -out 
rsa3.pub.der.asn1parse
    0:d=0  hl=4 l=1034 cons: SEQUENCE          
    4:d=1  hl=4 l=1025 prim: INTEGER           :CAA7829...
 1033:d=1  hl=2 l=   3 prim: INTEGER           :010001
$ cmp -b rsa3.pub.der.asn1parse rsa3.pub.der.erlang
$
# No differences now!

This stupid little issue was really bothersome to get to the bottom of (and 
whatever the problem with using PEM formatted private keys is, it is probably 
related, since PEM is a base64 encoded DER binary inside). If our tools are 
going to be built on OpenSSL I think they should at least detect and comply 
with whatever (silly, maybe even wrong) output it produces instead of failing 
on the most likely form it is likely to encounter.

The asn1 defintion in lib/public_key-0.22.1/asn1/PKCS-1.asn1 should be changed 
to allow a CHOICE type among the current canonical RSAPublicKey and an 
'OpenSSL-RSAPublicKey' option, OpenSSL upstream should be "fixed" (if its even 
wrong, which technically it probably isn't) and document this to make it less 
of a pointless speedbump, or we might want to add an optional clause to 
public_key.erl to make sure we can accept the actual output of OpenSSL (since 
adding an OID header to RSA public keys appears to be what its always done).

-Craig