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: 6674
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Christian Böhme
Date Reported: 2021-09-01

Section Appendix C says:

This results in the file rsa.public containing the key information
similar to this:

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

This public-key data (without the BEGIN and END tags) is placed in
the DNS:

$ORIGIN _domainkey.example.org.

It should say:

This results in the file rsa.public containing the key information
similar to this (long output lines truncated):

openssl asn1parse -i -inform PEM -in rsa.public
    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

openssl asn1parse -i -inform PEM -in rsa.public -strparse 18
    0:d=0  hl=3 l= 137 cons: SEQUENCE          
    3:d=1  hl=3 l= 129 prim:  INTEGER           :F02113FF502DD206C126…
  135:d=1  hl=2 l=   3 prim:  INTEGER           :010001

The result of

openssl asn1parse -i -inform PEM -in rsa.public -offset 22 -out /dev/stdout -noout | openssl base64

is then placed in the DNS:

$ORIGIN _domainkey.example.org.
brisbane IN  TXT  ("v=DKIM1; p=MIGJAoGBAPAhE/9QLdIGwSYapn1klbf8OQ"


Empirical evidence suggests that MSPs have taken the command lines in
Appendix C literally, and, by doing so, have deviated from the specification
laid out in Section 3.6.1. for the k= and p= tags.

Specifically, the openssl rsa command, used with its -pubout option
as demonstrated in Appendix C, produces a SubjectPublicKeyInfo-typed result
instead of a RSAPublicKey-typed one. It does so for both DER and PEM
arguments to the -outform option.

What is more, had Section 3.6.1., p= tag, specified a base64-encoded
SubjectPublicKeyInfo-typed value instead of a RSAPublicKey-typed one,
Section 3.6.1., k= tag, could have been dispensed of entirely, since
the SubjectPublicKeyInfo type contains an AlgorithmIdentifier-typed
attribute for that purpose.

That indeed an RSAPublicKey-typed result for the p= tag was intended
by RFC 6376 can be confirmed by comparison with RFC 8463, Section 4.2.,
which specifies that a "raw" Ed25519 public key be used, instead of
a SubjectPublicKeyInfo-typed one such as defined in RFC 8410,
Section 4. Subject Public Key Fields.

The Corrected Text uses the same public key data from the Original Text.

Report New Errata

Advanced Search