errata logo graphic

Found 4 records.

Status: Verified (1)

RFC6376, "DomainKeys Identified Mail (DKIM) Signatures", September 2011

Source of RFC: dkim (sec)

Errata ID: 3192

Status: Verified
Type: Technical

Reported By: John Hawthorn
Date Reported: 2012-04-14
Verifier Name: Barry Leiba
Date Verified: 2012-04-14

Section Appendix A says:

   From: Joe SixPack <joe@football.example.com>
   To: Suzie Q <suzie@shopping.example.net>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <20030712040037.46341.5F8J@football.example.com>

   Hi.

   We lost the game.  Are you hungry yet?

   Joe.

It should say:

   From: Joe SixPack <joe@football.example.com>
   To: Suzie Q <suzie@shopping.example.net>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <20030712040037.46341.5F8J@football.example.com>

   Hi.

   We lost the game. Are you hungry yet?

   Joe.

Notes:

This text appears three times, in A.1, A.2, and A.3. Notice the double space after "game.", which renders the body hashes in A.2 and A.3 invalid.

The corrected text, which is the same as that in RFC 4871, removes the extra space.


Status: Rejected (3)

RFC6376, "DomainKeys Identified Mail (DKIM) Signatures", September 2011

Source of RFC: dkim (sec)

Errata ID: 3017

Status: Rejected
Type: Technical

Reported By: Vernon Tang
Date Reported: 2011-11-05
Rejected by: Sean Turner
Date Rejected: 2011-11-12

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="
      tag.  (Note: the "p=" tag further encodes the value using the
      base64 algorithm.)  Unrecognized key types MUST be ignored.

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] 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.  (Note: the "p=" tag further encodes the value
      using the base64 algorithm.)  Unrecognized key types MUST be
      ignored.

Notes:

The procedure in Appendix C results in a public key in SubjectPublicKeyInfo format. Accordingly, most current implementations will accept such keys. Furthermore, it is trivial to distinguish whether a key is encapsulated in a SubjectPublicKeyInfo.
--VERIFIER NOTES--
This is changing a requirement. This is not the way to update a draft - you'd need to produce a draft explaining this change.


Errata ID: 3758

Status: Rejected
Type: Technical

Reported By: Majid Tajamolian & Nazilla Karkon
Date Reported: 2013-10-20
Rejected by: Barry Leiba
Date Rejected: 2013-10-20

Section 3.6.1. says:

v= Version of the DKIM key record (plain-text; RECOMMENDED, default
      is "DKIM1").  If specified, this tag MUST be set to "DKIM1"
      (without the quotes).  This tag MUST be the first tag in the
      record.  Records beginning with a "v=" tag with any other value
      MUST be discarded.  Note that Verifiers must do a string
      comparison on this value; for example, "DKIM1" is not the same as
      "DKIM1.0".

It should say:

v= Version of the DKIM key record (plain-text; RECOMMENDED, default
      is "1").  If specified, this tag MUST be set to "1"
      (without the quotes).  This tag MUST be the first tag in the
      record.  Records beginning with a "v=" tag with any other value
      MUST be discarded.  Note that Verifiers must do a string
      comparison on this value; for example, "1" is not the same as
      "1.0".

Notes:

The "DKIM" prefix in the version field is unnecessary.
for example the followings are snipped from an actual email via gmail.com:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to:content-type;
bh=46j07/8gDec8jTto/znsrAKiXDj6YJ7Wa2DCoZuhwXc=;
b=h6SViP6DcHgPwydJD6aztqyKd0UmCN3SdwmqZd0uCHmqrprphjN8qQ8AnBDhbwDhAa
DfHIDS8RSegELKtzsp95u+DnIFg1uNhIukKVpGT+9MqxfCSAFk7WpMe2O/2gcLruilTe
MxkKJ29s64NGevYewKtI8s73xHmbzD1NFH9ugdow8i9E16kgQ+vAx56qvbFTBwdEEw8I
6Bteu3tXEsYYbU/9Akm2GXS+6PFiDSbv47u3EmhRQIOK3e8DvcobrpicjL7vUwBCpQuf
J/c+Acdq4GZQoMoG9imzku0K2o0w33CZ1xUR1bARJKCVaJfWeHiEMQ2OJ9A6ZtqpyK0z
1Ftg==
--VERIFIER NOTES--
The reporters are confused. The text in Section 3.6.1 is about the key records in the DNS, and the document is correct. Section 3.5 is where the dkim-signature header field is described (and that is also correct).


Errata ID: 3759

Status: Rejected
Type: Editorial

Reported By: Majid Tajamolian & Nazila Karkon
Date Reported: 2013-10-20
Rejected by: Barry Leiba
Date Rejected: 2013-10-20

Section 3.6.1. says:

   h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
      allowing all algorithms).  A colon-separated list of hash
      algorithms that might be used.  Unrecognized algorithms MUST be
      ignored.  Refer to Section 3.3 for a discussion of the hash
      algorithms implemented by Signers and Verifiers.  The set of
      algorithms listed in this tag in each record is an operational
      choice made by the Signer.

It should say:

   a= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
      allowing all algorithms).  A colon-separated list of hash
      algorithms that might be used.  Unrecognized algorithms MUST be
      ignored.  Refer to Section 3.3 for a discussion of the hash
      algorithms implemented by Signers and Verifiers.  The set of
      algorithms listed in this tag in each record is an operational
      choice made by the Signer.

Notes:

The correct tag is "a=" for algorithms not "h=". The latter is used for the "List of Included Headers in the Signature"
--VERIFIER NOTES--
The reporters are confused. The text in Section 3.6.1 is about the key records in the DNS, and the document is correct. Section 3.5 is where the dkim-signature header field is described (and that is also correct).


Report New Errata