RFC Errata

Errata Search

Source of RFC  
Summary Table Full Records

RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures", September 2011

Note: This RFC has been updated by RFC 8301, RFC 8463, RFC 8553, RFC 8616

Source of RFC: dkim (sec)

Errata ID: 7001
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Ori Bernstein
Date Reported: 2022-06-21

Section 3.6.1 says:

   k= Key type (plain-text; OPTIONAL, default is "rsa").  Signers and
      Verifiers MUST support the "rsa" key type.  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="

It should say:

   k= Key type (plain-text; OPTIONAL, default is "rsa").  Signers and
      Verifiers MUST support the "rsa" key type.  The "rsa" key type
      indicates that an ASN.1 DER-encoded [ITU-X660-1997] SubjectPublicKeyInfo
      (see [RFC5280], Section 4.1) is being used in the "p="


The format specified for RSA keys is not what is used
either in the wild, or in the examples in this RFC.

The current citation for the RSAPublicKey format is
listed below for reference:

RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e

Taking the example public key in this RFC document:

-----END PUBLIC KEY-----

We can decode it as asn.1, and see that it is not in the format

$ openssl asn1parse -i -inform pem -in /home/ori/ykey.pem
0:d=0 hl=3 l= 159 cons: SEQUENCE
3:d=1 hl=2 l= 13 cons: SEQUENCE
5:d=2 hl=2 l= 9 prim: OBJECT :rsaEncryption
16:d=2 hl=2 l= 0 prim: NULL
18:d=1 hl=3 l= 141 prim: BIT STRING

The openssl documentation unhelpfully says that it's generated
in the "traditional SSLEay format". Poking around, that seems
to correspond to SubjectPublicKeyInfo in RFC5280:

SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }

When generating a key that conforms to the RSAPublicKey
encoding, multiple sites (including gmail) reject the key,
claiming a failure to parse the tag -- this is also the
error that openssl has when attempting to parse an RSA
public key in this format; for example:

-----END PUBLIC KEY-----

$ openssl asn1parse -i -inform pem -in /home/ori/key.pem
0:d=0 hl=3 l= 137 cons: SEQUENCE
3:d=1 hl=3 l= 129 prim: INTEGER :E3E47888BBFA404·.
135:d=1 hl=2 l= 3 prim: INTEGER :010001
$ openssl rsa -pubin -in /home/ori/key.pem -text
unable to load Public Key
140290635060544:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:../crypto/asn1/tasn_dec.c:1149:
140290635060544:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:309:Type=X509_ALGOR
140290635060544:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:646:Field=algor, Type=X509_PUBKEY
140290635060544:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:../crypto/pem/pem_oth.c:33:

While in theory it would be better to fix the examples,
I think that ship has sailed, and it's better instead
to fix the citation in the specification.

Report New Errata

Advanced Search