Subject: [ietf-dkim] Ticket #10: public key example -- no change needed

From: "John Levine" <[email-masked]>
Date: 26 Apr 2011 23:25:11 -0000

Whether the name in the DNS record should be brisbane or
brisbane._domainkey or brisbane._domainkey.example.org depends
entirely on the most recent $ORIGIN line in the master file.  If the
$ORIGIN is _domainkey.example.org, an entirely plausible scenario, the
current text is correct.

I see no reason to change it, suggest closing the ticket.

R's,
John
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Apr 2011 21:14:34 -0400

> I see no reason to change it, suggest closing the ticket.

-1

Not everyone uses your unstated $ORIGIN line format, nor knows what it 
is nor even is given a clue is to be presumed when its not even 
mentioned in the section.

The fact is, for the the ZONE files I see Windows DNS servers, the 
public key record will be shown in the subdomain format:

brisbane._domainkey   TXT ("v=DKIM1; p=...")

So if the section can not be generic to cover all bases, "Being 
Specific is terrific!"

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Apr 2011 21:56:23 -0400

What is surreal about this brush back to make a SIMPLE change is that 
it touches base with the often stated concern about DKIM DNS 
management complexities as one of the barriers for adoption.

In a perfect DKIM spec world, this section should cover the expected 
markets of DKIM operators to decrease the barriers:

  o Creating Public/Private Keys

   If your DKIM software does not offer public/private key
   management, there are tools available to help:

   - using OpenSSL
   - using CAPI

   o Publishing Public Key for brisbane._domainkey

   - Using ISP managed DNS zones
   - Using your *nix wienies DNS server zones
   - Using your Windozes DNS Server zones

Instead, its only:

   o Creating Public/Private Keys using OpenSSL
   o Publishing Public Key for brisbane for *nix wienies

But the issue posting is not asking to get crazy with idealism. Only a 
simple clarification is all that is needed.

If the domain considering DKIM is one that uses a ISP managed DNS zone 
or  has a Windows DNS Server and manages it directly via a ZONE file 
or interactively, that section will throw these domains off base.

The former will get the idea he needs to add a TXT record for the 
subdomain "brisbane", the result will be queries for

      brisbane.<zone-domain>

Same with the interactive Windows DNS GUI method which he right clicks 
"Add TXT Record" and it ask for the subdomain.

For the Windows geek who uses ZONE files directly, he may get a faster 
clue the DKIM section has an incomplete example targeted at *nix geeks 
because he will know record will need to be:

Sure, practical insights of reduce real possible DKIM deployments 
confusion is in the eyes of the beholder. My motivation is to help 
reduce these questions not for US because will have the GUI softare, 
but in general for all.  Levine may not need help, but others might.

Adding the complete public subdomain "brisbane._domainkey" is better 
than just having "brisbane" and if you must explain the initial ZONE 
assumption.

-- 
HLS

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 27 Apr 2011 11:02:30 +0200

> simple clarification is all that is needed.

-1. I suggest to add clarifications etc. to a future update of RFC5863 
(deployment and operations document).

/rolf

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 27 Apr 2011 11:27:57 +0200

> $ORIGIN is _domainkey.example.org, an entirely plausible scenario, the

Thus, the example can be enhanced by adding it:

   This public-key data (without the BEGIN and END tags) is placed in
   the DNS, for example using [RFC1035] syntax like this:
   $ORIGIN _domainkey.example.org.
   brisbane IN  TXT  ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
                      "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt"
                      "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
                      "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi"
                      "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Wed, 27 Apr 2011 06:47:31 -0400

> (deployment and operations document).

So you agree clarification is required but not for RFC4871bis?

Interesting. Lets see:

1) A few words clarification for DKIM-BASE standard. A little
    confusion for Windows people and domains using
    ISP managed DNS zones.

versus

2) Add new section in RFC5863 to match Create/Publish examples
    hopefully covering all bases.  Hope, Maybe?

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Wed, 27 Apr 2011 06:56:48 -0400

>                       "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")

WFM

-- 
HKS

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 27 Apr 2011 15:19:04 +0200

On 4/27/11 12:47 PM, Hector Santos wrote:
> Rolf E. Sonneveld wrote:
>
>> -1. I suggest to add clarifications etc. to a future update of 
>> RFC5863 (deployment and operations document).
>

No. Just: IF clarification is required, it has to be in an 
operations-/Informational- /BCP-type document. Together with some other 
DKIM related DNS advise (for example: last couple of months I came 
across three different cases of DNS admins, which broke up DKIM (and 
SPF) records in multiple pieces enclosed by double-quotes, as their DNS 
management interface didn't support input of long records).

>    confusion for Windows people and domains using

Well, maybe it's time Windows people leave their .local zones and 
discover a whole world beyond those windows...

/rolf

---

From: Hector Santos <[email-masked]>
Date: Wed, 27 Apr 2011 09:58:25 -0400

Rolf E. Sonneveld wrote:

>>    [LESS] confusion for Windows people and domains using
>>    ISP managed DNS zones.
>

Consolidation is always a solution too! :-)

Thanks for your input

-- 
HLS