Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque
On Sun, Apr 05, 2009 at 12:21:51AM +0100, John R. Levine wrote: >>> One of us should send in a separate technical erratum saying that DKIM >>> key records SHOULD be published only for SDID domains that have >>> corresponding MX or A records and can receive mail. >> >> I believe your later posting on this retracted the suggestion, but this >> issue >> strike me as one that is very easy (and common) to misunderstand. So it's >> worth emphasizing. Might be worth adding tidbits to the Deployment draft? >> >> The d= domain name is permitted to have /no relationship/ to any >> mail-sending >> or mail-receiving domain name. Hence, no A, MX, or possibly /any(!)/ DNS >> resource records for the name. > >Right. You have to control the branch of the DNS tree where the d= domain >would exist, since you need that to be able to install the key records, >but the domain doesn't have to exist otherwise. Once you remember that >the big advance of DKIM over its predecessors is to separate the signing >domain from the domains in various other headers, this is clearly the >right way for it to work. +1 my thinking has always been 3243242.rep.example.net. -- Jeff Macdonald jmacdon...@e-dialog.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque
>> One of us should send in a separate technical erratum saying that DKIM >> key records SHOULD be published only for SDID domains that have >> corresponding MX or A records and can receive mail. > > I believe your later posting on this retracted the suggestion, but this issue > strike me as one that is very easy (and common) to misunderstand. So it's > worth emphasizing. Might be worth adding tidbits to the Deployment draft? > > The d= domain name is permitted to have /no relationship/ to any mail-sending > or mail-receiving domain name. Hence, no A, MX, or possibly /any(!)/ DNS > resource records for the name. Right. You have to control the branch of the DNS tree where the d= domain would exist, since you need that to be able to install the key records, but the domain doesn't have to exist otherwise. Once you remember that the big advance of DKIM over its predecessors is to separate the signing domain from the domains in various other headers, this is clearly the right way for it to work. > There might prove to be some benefits in choosing to have the d= name > match the name used for other purposes, but the design of DKIM does not > require it and it's essential that signers retain the choice. The more I think about what it would mean to assert that an address in a From: or other header is "real", the less I understand it. Sure, there are trivial cases (that is, trivial semantics, not necessarily small numbers of mailboxes) where an organization forces a 1-1 mapping between mailboxes and people, but there's a whole lot of other ways that mail works. What does it mean for the address sa...@examp1e.com to be real when there are 100 people in the sales department? Don't answer that, just note that there is more than one possible answer. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
John Levine wrote: > One of us should send in a separate technical erratum saying that DKIM > key records SHOULD be published only for SDID domains that have > corresponding MX or A records and can receive mail. I believe your later posting on this retracted the suggestion, but this issue strike me as one that is very easy (and common) to misunderstand. So it's worth emphasizing. Might be worth adding tidbits to the Deployment draft? The d= domain name is permitted to have /no relationship/ to any mail-sending or mail-receiving domain name. Hence, no A, MX, or possibly /any(!)/ DNS resource records for the name. There might prove to be some benefits in choosing to have the d= name match the name used for other purposes, but the design of DKIM does not require it and it's essential that signers retain the choice. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
On Fri, Mar 27, 2009 at 11:37:10AM -, John Levine wrote: >>> well, now I'm completely confused. to my eyes, your example fits >>> exactly what 'registered' and 'resolvable' mean, but I guess you >>> have something else in mind. > >Steve is quite right. Since the DKIM key records are at different >names from the related MX or A record, the existence of one doesn't >require or imply the existence of the other. > >I don't want to hold up this errata/update/whatever any more than it >already is, so I'd suggest taking out any wording about the DNS status >of the SDID. > >One of us should send in a separate technical erratum saying that DKIM >key records SHOULD be published only for SDID domains that have >corresponding MX or A records and can receive mail. -1 please don't, or at least, please explain. The following shouldn't be discouraged: From: f...@bar.com DKIM-Signature: ... d=43343.rep.bar.com ... where 43343.rep.bar.com doesn't have any MX or A record. -- Jeff Macdonald jmacdon...@e-dialog.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
> The following shouldn't be discouraged: > > From: f...@bar.com > DKIM-Signature: ... d=43343.rep.bar.com ... > > where 43343.rep.bar.com doesn't have any MX or A record. On further reflection, you're right. The signature isn't an email address or a web site, so there's no reason it needs anything more than a key records. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
On Sat, Mar 28, 2009 at 10:34 PM, Dave CROCKER wrote: > Hence the wording should be: "A single domain name that..." for both SDID and > AUID. > > Does this match everyone's assessment of consensus? Acceptable. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Folks,
My intent with the suggested wording was *only* to make the language exactly
match what DKIM requires. It was an exercise in precision, accuracy and
completeness, not modification or enhancement. That is, nothing new was
intended.
It clearly did not achieve that goal.
I'm reading the dominant sense of the considerable set of postings on this
topic
as being: Return to the original wording of the Errata draft.
Hence the wording should be: "A single domain name that..." for both SDID and
AUID.
Does this match everyone's assessment of consensus?
d/
Dave CROCKER wrote:
> I think this does motivate two improvements to the draft language, one for
> SDID
> and one for AUID:
>
>> 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
> ...
>> New:
>>A single domain name that is the mandatory payload output of
>>DKIM and that refers to the identity claiming responsibility for
>>introduction of a message into the mail stream. For DKIM
>>processing, the name has only basic domain name semantics; any
>>possible owner-specific semantics is outside the scope of DKIM.
>
> A single domain name -> A single, registered domain name
>
>
>> 7. RFC4871 Section 2.10 Agent or User Identifier (AUID)
> ...
>> New:
>>A single domain name that identifies the agent or user on behalf
>>of whom the SDID has taken responsibility. For DKIM
>>processing, the name has only basic domain name semantics; any
>>possible owner-specific semantics is outside the scope of DKIM.
>
> A single domain name -> A single, syntactically valid domain name
>
> {{ no, I'm not in love that that wording choice. /d }}
>
>
> How much indigestion does this cause?
>
> d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Steve Atkins wrote: > Not only does hatstand.beartrap.blighty.com not resolve, it's not > registered anywhere. It exists solely as a substring of the string > that's actually queried - > banjo.aardvark._domainkey.hatstand.beartrap.blighty.com > > The only thing that can be said about the SDID in DNS terms is that > the signer of the mail has the ability to add TXT records in the > subtree rooted at that domain. > > Given that, trying to make more specific statements about what the > SDID is than something vague like "a domain name" is likely to lead to > something that's misleading or plain wrong. > > -1 on "registered" or "resolvable". Sounds like the real requirement is that a DKIM verifier be able to figure out which key to use, based on that string. There must be an IETF standard way to describe that -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
On Mar 27, 2009, at 8:04 AM, Tony Hansen wrote: > Siegel, Ellen wrote: >> Sorry for top-posting, but couldn't we sidestep all of the analysis >> by simply saying that the *syntax* (rather than the *semantics*) >> matches that of domain names? > > When all is said and done, it's the combination of the "selector > +_domainkey + SDID" that must be a valid domain name whose TXT > records can be accessed using DNS. This is the *only* name out of > all of these that MUST be in the DNS. A valid DKIM signature confirms the signing agent is controlled by the domain indicated in SDID. A valid signature also establishes an authority to assert UAID values that must reside at or under the domain. (A valid DKIM signature verifies the UAID assertion by the SDID.) When UAID values do not match against email-addresses within signed header fields, portions of the UAID namespace below the SDID may not represent an valid email destination. However, the UAID value always represents an SDID identifier for on whose behalf their signature was added. The SDID value could be seen as analogous to a State issuing a drivers license. A valid signature could be analogous to untampered laser- scribed laminate and seals. The License Number could be analogous to that of the UAID, where it might be replaced by a State email-address of the driver. Such replacement can be denoted by its use within signed header fields. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
I understand the desire to constrain the SDID to be a registered name or under one, but is there a need to make this normative? DKIM verification simply won't work if the SDID doesn't meet that criterion, and perhaps that's good enough. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
> Has any reader of this spec actually been confused? I sure > haven't seen it, and the advent of zillions of web resources in case > there were any question at all makes this seem like a rather academic > debate. I agree with Mike. Let's leave the text as it is, and move on. Barry (participant) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Tony Hansen wrote: > Siegel, Ellen wrote: >> Sorry for top-posting, but couldn't we sidestep all of the analysis >> by simply saying that the *syntax* (rather than the *semantics*) >> matches that of domain names? > > When all is said and done, it's the combination of the "selector + > _domainkey + SDID" that must be a valid domain name whose TXT records > can be accessed using DNS. This is the *only* name out of all of these > that MUST be in the DNS. Has any reader of this spec actually been confused? I sure haven't seen it, and the advent of zillions of web resources in case there were any question at all makes this seem like a rather academic debate. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Siegel, Ellen wrote: > Sorry for top-posting, but couldn't we sidestep all of the analysis > by simply saying that the *syntax* (rather than the *semantics*) > matches that of domain names? When all is said and done, it's the combination of the "selector + _domainkey + SDID" that must be a valid domain name whose TXT records can be accessed using DNS. This is the *only* name out of all of these that MUST be in the DNS. Tony Hansen t...@att.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
On Mar 27, 2009, at 4:37 AM, John Levine wrote: >>> well, now I'm completely confused. to my eyes, your example fits >>> exactly what 'registered' and 'resolvable' mean, but I guess you >>> have something else in mind. > > Steve is quite right. Since the DKIM key records are at different > names from the related MX or A record, the existence of one doesn't > require or imply the existence of the other. > > I don't want to hold up this errata/update/whatever any more than it > already is, so I'd suggest taking out any wording about the DNS status > of the SDID. +1 > One of us should send in a separate technical erratum saying that DKIM > key records SHOULD be published only for SDID domains that have > corresponding MX or A records and can receive mail. Any reason for that? It doesn't strike me as an obviously good idea. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
before we get too semantically bogged down, a domain name implys dns registration otherwise it is a label of convenience Bill Oxley Messaging Engineer Cox Communications, Inc 404-847-6397 -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Thursday, March 26, 2009 9:21 PM To: DKIM IETF WG Subject: Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque) On Mar 26, 2009, at 6:10 PM, Dave CROCKER wrote: > > > Steve Atkins wrote: >> On Mar 26, 2009, at 3:49 PM, Dave CROCKER wrote: >>>> 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) >>> ... >>>>New: >>>> A single domain name that is the mandatory payload output of >>>> DKIM and that refers to the identity claiming >>>> responsibility for >>>> introduction of a message into the mail stream. For DKIM >>>> processing, the name has only basic domain name semantics; any >>>> possible owner-specific semantics is outside the scope of >>>> DKIM. >>> A single domain name -> A single, registered domain name >> Registered with who? >> If the SDID is, say, hatstand.beartrap.blighty.com? > > > Registered with the DNS, the global distributed hierarchical service. > > From the other uses of this language I'm seeing on the net, this > isn't said explicitly. Do you really feel that the meaning is not > clear? Registered means that the string is registered with a registry. That's not something I'd want the language to even hint at, let alone actually say. It's going to lead to confusion when explaining this to people, as you'll need to directly contradict the wording in the spec when you reassure them that, no, there is no central DKIM registry. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
SM wrote: > Hi Hector, > At 23:22 26-03-2009, Hector Santos wrote: >> Who is the document addressed to? I must be the only one here that is >> having trouble with the "new" lingo in communications. > > The document is addressed to DKIM implementors. The document can also > be used as a base for extensions built upon DKIM. Well, before you can have DKIM implementators, they probably have something to first with electronic mail, and at some point it all has to revert back to layman terms (as we know it today) for customers to enjoy. The question I ask to myself is this: Can someone successful implement DKIM using RFC 4871 without having to resort to this errata? Or does errata significant enough in fixing the original functional specifications that makes it mandatory to have? -- Sincerely Hector Santos http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Sorry for top-posting, but couldn't we sidestep all of the analysis by simply
saying that the *syntax* (rather than the *semantics*) matches that of domain
names?
Ellen
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Dave CROCKER
> Sent: Thursday, March 26, 2009 6:50 PM
> To: Jim Fenton
> Cc: DKIM IETF WG
> Subject: [ietf-dkim] (registered) domain name (Re: errata revision:
> opaque)
>
>
>
> Jim Fenton wrote:
>
> > Just for completeness, I'll point out that some might feel that the
> > (indirect) statement that the domain name portion of the AUID has domain
> > name semantics is too strong. The subdomain portion (the portion, if
> > any, that is a subdomain of the SDID) doesn't need to be an actual
> > domain at all.
> >
> > I'm not sure it's necessary to clutter the definition with this detail,
> > however. I'm happy with it the way it is.
>
>
> Well, I think we should make sure that clarification text doesn't wind up
> diverging from the precise semantics of what it is trying to clarify, lest
> we
> create ambiguity.
>
> So while this might be a pain, I think it's good you caught this issue and
> raised it.
>
> I don't claim to know the nuances of this issue well enough. For
> starters, I
> did some searching around, which might or might not have improved my
> understanding...
>
> The best I can find is two kinds of distinction. The term "hostname"
> refers to
> a constraint on use of the full Domain Name namespace. The term
> "registered"
> appears to be the way of distinguishing names that appear in the
> operational
> service, ie, the public database.
>
> That is, the former refers to names and the latter refers to a query
> mechanism.
>
> When we say "actual", I think it translates into what the documents I'm
> seeing
> are calling "registered".
>
> RFC4871's i= text says:
>
> "The domain part of the address MUST be the same as or a subdomain
> of the
> value of the "d=" tag"
>
> which does not imply registration or non-registration. Either appears to
> be legal.
>
> I think this does motivate two improvements to the draft language, one for
> SDID
> and one for AUID:
>
> > 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
> ...
> > New:
> >A single domain name that is the mandatory payload output of
> >DKIM and that refers to the identity claiming responsibility for
> >introduction of a message into the mail stream. For DKIM
> >processing, the name has only basic domain name semantics; any
> >possible owner-specific semantics is outside the scope of DKIM.
>
> A single domain name -> A single, registered domain name
>
>
> >
> > 7. RFC4871 Section 2.10 Agent or User Identifier (AUID)
> ...
> > New:
> >A single domain name that identifies the agent or user on behalf
> >of whom the SDID has taken responsibility. For DKIM
> >processing, the name has only basic domain name semantics; any
> >possible owner-specific semantics is outside the scope of DKIM.
>
> A single domain name -> A single, syntactically valid domain name
>
> {{ no, I'm not in love that that wording choice. /d }}
>
>
> How much indigestion does this cause?
>
> d/
> --
>
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Hi Hector, At 23:22 26-03-2009, Hector Santos wrote: >Who is the document addressed to? I must be the only one here that >is having trouble with the "new" lingo in communications. The document is addressed to DKIM implementors. The document can also be used as a base for extensions built upon DKIM. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
>> well, now I'm completely confused. to my eyes, your example fits >> exactly what 'registered' and 'resolvable' mean, but I guess you >> have something else in mind. Steve is quite right. Since the DKIM key records are at different names from the related MX or A record, the existence of one doesn't require or imply the existence of the other. I don't want to hold up this errata/update/whatever any more than it already is, so I'd suggest taking out any wording about the DNS status of the SDID. One of us should send in a separate technical erratum saying that DKIM key records SHOULD be published only for SDID domains that have corresponding MX or A records and can receive mail. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
SM wrote: > Hi Dave, > At 15:49 26-03-2009, Dave CROCKER wrote: >> The best I can find is two kinds of distinction. The term >> "hostname" refers to >> a constraint on use of the full Domain Name namespace. The term "registered" >> appears to be the way of distinguishing names that appear in the operational >> service, ie, the public database. > > The problem with this document is that it is not a specification > about DNS and the reader may not restrict his/her interpretation to > that only. Who is the document addressed to? I must be the only one here that is having trouble with the "new" lingo in communications. Imagine when its all said and done, someone getting into this may need to take out a dictionary and print out a legend of new acronyms and stick it on his monitor, learn how to pronounced the syllables of the new acronyms and to thinking 2-3 times to understand what they mean and reflect in email. Its all nuts. But I am the only person here that feels that way, so proceed. -- Sincerely Hector Santos http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Hi Dave, At 15:49 26-03-2009, Dave CROCKER wrote: >The best I can find is two kinds of distinction. The term >"hostname" refers to >a constraint on use of the full Domain Name namespace. The term "registered" >appears to be the way of distinguishing names that appear in the operational >service, ie, the public database. The problem with this document is that it is not a specification about DNS and the reader may not restrict his/her interpretation to that only. People commonly view the term "registered" as meaning that the domain name has been registered through a registry. You can get away with that by specifying "registered in DNS". Generally, we don't have to go to such lengths as it is implicit that the domain name should be resolvable. Given the amount of debate we have been having about DKIM, some people might prefer to have all the details nailed down so that we don't have to argue about this again in future. Some people will come up and say that "registered in DNS" means that the domain name must also be registered through a registry. > A single domain name -> A single, syntactically valid domain name I don't know and I prefer not to know, whether there are syntactically invalid domain names. :-) If I want to know what a "single domain name" is, I'll see what the RFCs say. My statement is not a case of "the RFC says so" as I am not an advocate of such an argument. I refer to the relevant text as, in my eyes, it provides a good explanation as to why we do things in a particular manner. There isn't any requirement that DKIM must only be used on the public Internet. In practice, most users of the technology will be on the Internet. Let's agree about the term without constraining where DKIM can be used. I suggest using "a domain name". I don't see the point of having "single" in that text as the public key retrieval will fail if we use more than one domain name. If the WG wants to be precise, I'm fine with that. The interpretation of domain name here is within the context of DNS. For those of you who don't understand what that means, please talk with the DNS folks. They are highly skilled in the art of frustrating application designers when that question is raised. :-) Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
On Mar 26, 2009, at 7:05 PM, Dave CROCKER wrote: > well, now I'm completely confused. to my eyes, your example fits > exactly what 'registered' and 'resolvable' mean, but I guess you > have something else in mind. > hatstand.beartrap.blighty.com doesn't resolve. A query for it returns NXDOMAIN, and it doesn't exist in DNS in any way: steve$ dig hatstand.beartrap.blighty.com txt ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12223 Yet it's potentially a valid SDID, because banjo.aardvark._domainkey.hatstand.beartrap.blighty.com *does* return a TXT record. steve$ dig +short banjo.aardvark._domainkey.hatstand.beartrap.blighty.com txt "I am a public key - no, really!" Not only does hatstand.beartrap.blighty.com not resolve, it's not registered anywhere. It exists solely as a substring of the string that's actually queried - banjo.aardvark._domainkey.hatstand.beartrap.blighty.com The only thing that can be said about the SDID in DNS terms is that the signer of the mail has the ability to add TXT records in the subtree rooted at that domain. Given that, trying to make more specific statements about what the SDID is than something vague like "a domain name" is likely to lead to something that's misleading or plain wrong. -1 on "registered" or "resolvable". Cheers, Steve > RFC 1034 and RFC 1035 make many references to resolvers. > > d/ > > Steve Atkins wrote: >> On Mar 26, 2009, at 6:36 PM, Dave CROCKER wrote: >>> >>> Steve Atkins wrote: On Mar 26, 2009, at 6:26 PM, Barry Leiba wrote: > We could say "DNS-resolvable". We could, but it's not actually a requirement that the SDID resolve in the DNS (and in many cases it won't). >>> >>> Really? >>> >>> Then how does the receiver obtain the public key for performing >>> verification? >>> >>> key retrieval is defined as using d=. >> If you receive an email with a selector of banjo.aardvark and an >> SDID of hatstand.beartrap.blighty.com then you'll hopefully be >> able to resolve >> banjo.aardvark._domainkey.hatstand.beartrap.blighty.com, but >> that's all you can say about ability to resolve any query in the >> domain tree under the SDID, including the SDID itself. >> At least, that's how I understand it. >> Cheers, >> Steve >> ___ >> NOTE WELL: This list operates according to >> http://mipassoc.org/dkim/ietf-list-rules.html > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
well, now I'm completely confused. to my eyes, your example fits exactly what 'registered' and 'resolvable' mean, but I guess you have something else in mind. RFC 1034 and RFC 1035 make many references to resolvers. d/ Steve Atkins wrote: > On Mar 26, 2009, at 6:36 PM, Dave CROCKER wrote: > >> >> Steve Atkins wrote: >>> On Mar 26, 2009, at 6:26 PM, Barry Leiba wrote: We could say "DNS-resolvable". >>> We could, but it's not actually a requirement that the SDID resolve >>> in the DNS (and in many cases it won't). >> >> Really? >> >> Then how does the receiver obtain the public key for performing >> verification? >> >> key retrieval is defined as using d=. > > If you receive an email with a selector of banjo.aardvark and an SDID > of hatstand.beartrap.blighty.com then you'll hopefully be able to > resolve banjo.aardvark._domainkey.hatstand.beartrap.blighty.com, but > that's all you can say about ability to resolve any query in the > domain tree under the SDID, including the SDID itself. > > At least, that's how I understand it. > > Cheers, >Steve > > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
On Mar 26, 2009, at 6:36 PM, Dave CROCKER wrote: > > > Steve Atkins wrote: >> On Mar 26, 2009, at 6:26 PM, Barry Leiba wrote: >>> We could say "DNS-resolvable". >> We could, but it's not actually a requirement that the SDID resolve >> in the DNS (and in many cases it won't). > > > Really? > > Then how does the receiver obtain the public key for performing > verification? > > key retrieval is defined as using d=. If you receive an email with a selector of banjo.aardvark and an SDID of hatstand.beartrap.blighty.com then you'll hopefully be able to resolve banjo.aardvark._domainkey.hatstand.beartrap.blighty.com, but that's all you can say about ability to resolve any query in the domain tree under the SDID, including the SDID itself. At least, that's how I understand it. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Steve Atkins wrote: > On Mar 26, 2009, at 6:26 PM, Barry Leiba wrote: >> We could say "DNS-resolvable". > > We could, but it's not actually a requirement that the SDID resolve in > the DNS (and in many cases it won't). Really? Then how does the receiver obtain the public key for performing verification? key retrieval is defined as using d=. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
On Mar 26, 2009, at 6:26 PM, Barry Leiba wrote: > We could say "DNS-resolvable". We could, but it's not actually a requirement that the SDID resolve in the DNS (and in many cases it won't). I think "domain name" is just vague enough to avoid these problems. If you try and make it more specific without making it misleading, it's going to take more than just a couple of words to describe accurately. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
We could say "DNS-resolvable". Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
On Mar 26, 2009, at 6:10 PM, Dave CROCKER wrote: > > > Steve Atkins wrote: >> On Mar 26, 2009, at 3:49 PM, Dave CROCKER wrote: 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) >>> ... New: A single domain name that is the mandatory payload output of DKIM and that refers to the identity claiming responsibility for introduction of a message into the mail stream. For DKIM processing, the name has only basic domain name semantics; any possible owner-specific semantics is outside the scope of DKIM. >>> A single domain name -> A single, registered domain name >> Registered with who? >> If the SDID is, say, hatstand.beartrap.blighty.com? > > > Registered with the DNS, the global distributed hierarchical service. > > From the other uses of this language I'm seeing on the net, this > isn't said explicitly. Do you really feel that the meaning is not > clear? Registered means that the string is registered with a registry. That's not something I'd want the language to even hint at, let alone actually say. It's going to lead to confusion when explaining this to people, as you'll need to directly contradict the wording in the spec when you reassure them that, no, there is no central DKIM registry. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Steve Atkins wrote: > On Mar 26, 2009, at 3:49 PM, Dave CROCKER wrote: >>> 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) >> ... >>> New: >>> A single domain name that is the mandatory payload output of >>> DKIM and that refers to the identity claiming responsibility >>> for >>> introduction of a message into the mail stream. For DKIM >>> processing, the name has only basic domain name semantics; any >>> possible owner-specific semantics is outside the scope of DKIM. >>A single domain name -> A single, registered domain name > > Registered with who? > > If the SDID is, say, hatstand.beartrap.blighty.com? Registered with the DNS, the global distributed hierarchical service. From the other uses of this language I'm seeing on the net, this isn't said explicitly. Do you really feel that the meaning is not clear? -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
On Mar 26, 2009, at 3:49 PM, Dave CROCKER wrote: > >> 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) > ... >> New: >> A single domain name that is the mandatory payload output of >> DKIM and that refers to the identity claiming responsibility >> for >> introduction of a message into the mail stream. For DKIM >> processing, the name has only basic domain name semantics; any >> possible owner-specific semantics is outside the scope of DKIM. > >A single domain name -> A single, registered domain name Registered with who? If the SDID is, say, hatstand.beartrap.blighty.com? Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
>> 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) ... > A single domain name -> A single, registered domain name ... >> 7. RFC4871 Section 2.10 Agent or User Identifier (AUID) ... > A single domain name -> A single, syntactically valid domain name Well, to make them similar, how about this for 7?: A single domain name -> A single domain name, not necessarily registered, Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
On Thu, Mar 26, 2009 at 03:49:38PM -0700, Dave CROCKER wrote:
>> 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
>...
>> New:
>>A single domain name that is the mandatory payload output of
>>DKIM and that refers to the identity claiming responsibility for
>>introduction of a message into the mail stream. For DKIM
>>processing, the name has only basic domain name semantics; any
>>possible owner-specific semantics is outside the scope of DKIM.
>
>A single domain name -> A single, registered domain name
>
>
>>
>> 7. RFC4871 Section 2.10 Agent or User Identifier (AUID)
>...
>> New:
>>A single domain name that identifies the agent or user on behalf
>>of whom the SDID has taken responsibility. For DKIM
>>processing, the name has only basic domain name semantics; any
>>possible owner-specific semantics is outside the scope of DKIM.
>
>A single domain name -> A single, syntactically valid domain name
>
>{{ no, I'm not in love that that wording choice. /d }}
>
>
>How much indigestion does this cause?
none for me. +1
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
On Thu, Mar 26, 2009 at 07:59:48PM -0400, Jeff Macdonald wrote:
> On Thu, Mar 26, 2009 at 03:49:38PM -0700, Dave CROCKER wrote:
>>> 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
>> ...
>>> New:
>>>A single domain name that is the mandatory payload output of
>>>DKIM and that refers to the identity claiming responsibility for
>>>introduction of a message into the mail stream. For DKIM
>>>processing, the name has only basic domain name semantics; any
>>>possible owner-specific semantics is outside the scope of DKIM.
>>
>>A single domain name -> A single, registered domain name
>>
>>
>>>
>>> 7. RFC4871 Section 2.10 Agent or User Identifier (AUID)
>> ...
>>> New:
>>>A single domain name that identifies the agent or user on behalf
>>>of whom the SDID has taken responsibility. For DKIM
>>>processing, the name has only basic domain name semantics; any
>>>possible owner-specific semantics is outside the scope of DKIM.
>>
>>A single domain name -> A single, syntactically valid domain name
>>
>> {{ no, I'm not in love that that wording choice. /d }}
>>
>>
>> How much indigestion does this cause?
>
> none for me. +1
oh, and +1 for the others
--
Jeff Macdonald
jmacdon...@e-dialog.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Jim Fenton wrote:
> Just for completeness, I'll point out that some might feel that the
> (indirect) statement that the domain name portion of the AUID has domain
> name semantics is too strong. The subdomain portion (the portion, if
> any, that is a subdomain of the SDID) doesn't need to be an actual
> domain at all.
>
> I'm not sure it's necessary to clutter the definition with this detail,
> however. I'm happy with it the way it is.
Well, I think we should make sure that clarification text doesn't wind up
diverging from the precise semantics of what it is trying to clarify, lest we
create ambiguity.
So while this might be a pain, I think it's good you caught this issue and
raised it.
I don't claim to know the nuances of this issue well enough. For starters, I
did some searching around, which might or might not have improved my
understanding...
The best I can find is two kinds of distinction. The term "hostname" refers to
a constraint on use of the full Domain Name namespace. The term "registered"
appears to be the way of distinguishing names that appear in the operational
service, ie, the public database.
That is, the former refers to names and the latter refers to a query mechanism.
When we say "actual", I think it translates into what the documents I'm seeing
are calling "registered".
RFC4871's i= text says:
"The domain part of the address MUST be the same as or a subdomain of the
value of the "d=" tag"
which does not imply registration or non-registration. Either appears to be
legal.
I think this does motivate two improvements to the draft language, one for SDID
and one for AUID:
> 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
...
> New:
>A single domain name that is the mandatory payload output of
>DKIM and that refers to the identity claiming responsibility for
>introduction of a message into the mail stream. For DKIM
>processing, the name has only basic domain name semantics; any
>possible owner-specific semantics is outside the scope of DKIM.
A single domain name -> A single, registered domain name
>
> 7. RFC4871 Section 2.10 Agent or User Identifier (AUID)
...
> New:
>A single domain name that identifies the agent or user on behalf
>of whom the SDID has taken responsibility. For DKIM
>processing, the name has only basic domain name semantics; any
>possible owner-specific semantics is outside the scope of DKIM.
A single domain name -> A single, syntactically valid domain name
{{ no, I'm not in love that that wording choice. /d }}
How much indigestion does this cause?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
