ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

2006-08-25 03:50:03
Stephen Farrell wrote:


Jim,

I look forward to your seeing further problems with this DSD thing.

Meanwhile, I just want to clarify one thing, since I seem to have
confused a number of folks:

Jim Fenton wrote:

Key delegation is already introduced in -base, and we have already
described how the key management works (in DNS, anyway).  SSP DSD isn't
a new key management scheme, but rather a way of authorizing other
domains to sign using the existing scheme.


I agree. (Well, I can't recall if key delegation is really specified
in base, as opposed to allowed-for by base, but anyway.)

My point is that without the DSD mechanism, key delegation is arguably
much more likely to be used. And if true, that means we have to do more
work analysing key management. With DSD, key delegation is arguably
much less likely to be used, or at least can be more easily avoided, in
which case analysis of key management is less of an issue for us.

What occurs to me is that I can't keep up with the acronyms, and I suspect
that I'm not alone. Given what Jim writes above, I'm guessing that DSD is
delegated signing domain? Or is it designated signing domain? And is this
what I called "outsourced first party signing" in the requirements draft, or
does this have something to do with DNS delegation?

It seems that if we could all use the same language and acronyms here, we'd
probably help on the talking past each other part.

      Mike
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>