If I haven't missed any important update to the DKIM spec, I consider the following as valid:
RFC6376, Section 3.6.1:
The "rsa" key type
indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey
(see [RFC3447], Sections 3.1 and A.1.1) is being used in the "p="
tag. (Note: the "p=" tag further encodes the value using the
base64 algorithm.) Unrecognized key types MUST be ignored.
Errata exist (https://www.rfc-editor.org/errata/eid3017) that extend this to
The "rsa" key type
indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey
(see [RFC3447], Sections 3.1 and A.1.1), which MAY be contained in
a SubjectPublicKeyInfo (see [RFC5280], Section A.1), is being used
in the "p=" tag.
I'm aware that appearantly the whole world uses SubjectPublicKeyInfo in published DNS records and I also noticed that, e.g. libopendkim is in its current state is also not able to parse a RSAPublicKey which is not contained in a SubjectPublicKeyInfo from the 'p=' tag in a TXT record. But still, the RFC defines the RSAPublicKey-represenation definitely as valid and therefore I think it would be somehow correct to support it.
Fortunately, dkimpy does the ASN1-parsing all by itself, so a patch to support parsing of RSAPublicKey Syntax directly could be as trivial as:
diff --git a/dkim/crypto.py b/dkim/crypto.py
index 144bbde..f2c7e89 100644
--- a/dkim/crypto.py
+++ b/dkim/crypto.py
@@ -119,7 +119,10 @@ def parse_public_key(data):
x = asn1_parse(ASN1_Object, data)
pkd = asn1_parse(ASN1_RSAPublicKey, x[0][1][1:])
except ASN1FormatError as e:
- raise UnparsableKeyError('Unparsable public key: ' + str(e))
+ try:
+ pkd = asn1_parse(ASN1_RSAPublicKey, data)
+ except:
+ raise UnparsableKeyError('Unparsable public key: ' + str(e))
pk = {
'modulus': pkd[0][0],
'publicExponent': pkd[0][1],
I successfully tested this patch agains a mixture of both key represenations.
I should probably have added, that dkimpy fails to parse a non-nested RSAPublicKey-
ERROR:dkimverif