> On 16 May 2023, at 15:00, Jan Dušátko <jan=40dusatko....@dmarc.ietf.org> 
> wrote:
> 
> Hi,
> I would like to ask how you feel about the possibility of changing the 
> conditions for DKIM keys stored in DNS. Best in some future RFC release about 
> DKIM itself. I have a practical experience during review and cleaning of 
> thousands of domain, which is exhausting. And discussion about that keys also 
> with 3rd party is sometimes hard. In situation that you would like to discuss 
> that, I can provide kind of examples.
> 1) At this moment, the use of the tag "v=DKIM1;" is only RECOMMENDED and if 
> this tag is used, it must be the first. Unlike, for example, SPF and DMARC, 
> this is not a REQUIRED (MANDATORY) record. In case of an attempt to identify 
> DKIM records, then there is a situation where it is not possible to determine 
> which records are DKIM keys. Often, these keys are in other places where they 
> allow to create CNAME to the expected location of the selector. These 
> locations may be application dependent or may be with third parties 
> configuration. From my perspective, MANDATORY record "v=DKIM1;" could help to 
> identify DKIM keys much easily.

A DKIM key will only ever be found in DNS under a name of the form 
<selector>._domainkey.<something_else>. If you find a TXT record under a name 
like that it’s either a valid domain key record, or it’s invalid. No other sort 
of TXT
record will live there. See section 3.6.2.1 of RFC 6376.

If you publish wildcard TXT records then you may end up inadvertently 
publishing other TXT records underneath the _domainkey record. Don’t do that.

> 2) Is it possible to specify precisely under which conditions the DKIM key is 
> valid? Some third party records contain only an empty record "", others 
> contain only revoked key like "p=" or it is a reference to a non-existent 
> record. Unfortunately, RFCs do not provide unambiguous information on under 
> which conditions this record is invalid. From my perspective, use of 
> non-existing records or empty strings can draw that key useless, but rules 
> specifying that in RFC or BCP will be welcome.

It must be a TXT record that lives under the hostname I described above, and it 
must contain a (possibly empty) p= field. An empty TXT record is not a valid 
DKIM public key.

It’s - obviously - possible to create a TXT record of that form that’s 
unusable. A DKIM validator will return a not signed result in that case.

> 3) The "p=key" information containing the key material information encoded by 
> Base64 should occur in the key exactly once. I did not find a condition in 
> RFC for the existence of this record.

Section 3.2 of RFC 6376 says “ Tags with duplicate names MUST NOT occur within 
a single tag-list; if a tag name does occur more than once, the entire tag-list 
is invalid.”

Section 3.6.1 of RFC 6376 describes the p= value as REQUIRED.

So there must be exactly one p= in a valid DKIM public key (in text format, as 
would be published via DNS, anyway).

> I found only information on implementation behavior, when "p=", i.e. an empty 
> key material, is considered revoked. However, it is not unambiguous whether 
> this approach is acceptable. Also specification of that rules can make my 
> life much easier.

Cheers,
  Steve

_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Reply via email to