[ietf-dkim] ok
___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Fwd: [Lurk] Another outside the "box" use case: DKIM
On 3/2/2016 1:35 AM, Stephen Farrell wrote: > LURK is an IETF mailing list that's discussing developing a > solution to the "offload TLS without giving the CDN my private > key" problem. The premise seems to be that there is a single private key. DKIM permits an arbitrary of private keys to be associated with the domain name. So assigning one solely for use by a third-party -- and deciding when to terminate it -- is convenient and carries no effect on other uses. 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] Fwd: [Lurk] Another outside the "box" use case: DKIM
On 4/21/2016 10:30 AM, Jon Callas wrote: > Most of all, we planned for similar uses. Not CDNs in particular, but the > reason DKIM talks about the "administrative domain" (Dave's term) is because > we knew that CDNs and other people (heck, like outsourced email senders) > would need to be able to have the ability to do whatever. Completely ancillary notational trivia: The term 'administrative domain' is in the Email Architecture spec, RFC 5598. I used it there, with some irony, after its previous use for the OSI/CCITT X.400 specifications. They used the term (Administrative management domain) to refer to the public carriers, as distinct from the local enterprises. In the Internet's architecture, such distinctions are operational, not architectural. Architecturally, all domains are equal... 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] Fwd: [Lurk] Another outside the "box" use case: DKIM
> On Apr 21, 2016, at 7:23 AM, Dave Crocker wrote: > > On 3/2/2016 1:35 AM, Stephen Farrell wrote: >> LURK is an IETF mailing list that's discussing developing a >> solution to the "offload TLS without giving the CDN my private >> key" problem. > > > The premise seems to be that there is a single private key. > > DKIM permits an arbitrary of private keys to be associated with the > domain name. So assigning one solely for use by a third-party -- and > deciding when to terminate it -- is convenient and carries no effect on > other uses. I concur. All you have to do with DKIM is to make sure that the key associated with a given message is available, and having that be non-uniform is a feature of the base protocol. The private key is owned by the sending machinery -- potentially an edge MTA -- only. The cost of destroying a key (remember, they're keys, not certs) is only that the messages presently in-flight might not verify. Most of all, we planned for similar uses. Not CDNs in particular, but the reason DKIM talks about the "administrative domain" (Dave's term) is because we knew that CDNs and other people (heck, like outsourced email senders) would need to be able to have the ability to do whatever. Jon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Fwd: [Lurk] Another outside the "box" use case: DKIM
On 4/21/2016 11:50 AM, John Levine wrote: > The reason DKIM doesn't have the LURK problem is that the key issuer > directly controls the verification key with no intermediary doing > certification. The text I was commenting on cited an issue with handing out "my private key". That DKIM might have other benefits is nice, and might be added benefits, they weren't the issue that was raised. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html