Hi
thank you for answers. Seems that I overlooked some details inside RFCs
and my idea are not needed as I think
Murray S. Kucherawy wrote:
> if it's a TXT record and it is in a DKIM DNS naming path, it better
be a DKIM record.
You are right. I trying to do strict syntax check, but I also looking
for arguments, which let me to remove invalid keys.
Dne 16. 5. 2023 v 17:52 Murray S. Kucherawy napsal(a):
On Tue, May 16, 2023 at 7:00 AM Jan Dušátko <jan=
40dusatko....@dmarc.ietf.org> wrote:
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.
I don't get the impression that identifying a record that contains a valid
DKIM key record is hard. The ABNF is pretty clear. It's certainly easier
to say "does this start v=DKIM1;?" than it is to run a full parser on it,
but I imagine if you try to stuff a random string through a DKIM key
parser, it'll know pretty quickly most of the time that the record isn't
valid given the second character pretty much has to be "=" which is going
to trim a lot of cruft right away.
Also, a change to make this REQUIRED would take forever for the world to
adapt. There's a great deal of inertia out there, and the benefit of such
a change isn't going to be obvious to the broader community, so you're
going to find records in the current format for years to come, and
implementations would justifiably accept the old format for some long
transition period.
I understand and accept this approach, but I would like to make a few
comments based on the timeline. Domainkey was standardized in 2007, in
the same year it was replaced by DKIM. This standard was replaced in
2011 by a newer one, which continues to expand. In my opinion, for the
sake of interoperability, it is also necessary to address the gradual
transition to more complex technologies, as well as to prepare these
technologies for possible replacement. In my opinion, this is the
purpose of header records. Then the question is, is 16 years enough
time, given the age of email 50 years? Currently, technologies like DKIM
are used to protect the domain (brand) from misuse, and the importance
of these technologies will continue to grow.
Dave Crocker wrote:
If a version change marks a change to the basic standard -- ie, a change
that is incompatible with the previous version -- then it is not a
version change. It is creation of a new protocol.
I understand. I did not take proper care about former DomainKey, which can make
everything worse. Simple backward compatibility and I forget it.
Are you talking about DKIM records out in the general Internet, or only
within domains you control?
I talking about domains under my control. But part of records has been
provided by 3rd party, I would like to enforce strict compliance with
current RFCs (SPF, DKIM, DMARC ...)
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.
I disagree that this is ambiguous. An empty string isn't a valid DKIM key
record. An empty "p=" value is a valid DKIM key record indicating "there
was a key here, but it's been revoked".
Steve Aktins wrote:
Section 3.6.1 of RFC 6376 describes the p= value as REQUIRED.
I overlooked that before, which make negotiation about compliance harder.
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. 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.
I also disagree that this is ambiguous. The RFC is pretty clear about what
an empty "p=" means.
-MSK
Regards
Jan
--
-- --- ----- -
Jan Dušátko
Tracker number: +420 602 427 840
e-mail: j...@dusatko.org
GPG Signature: https://keys.dusatko.org/E535B585.asc
GPG Encrypt: https://keys.dusatko.org/B76A1587.asc
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
