Stephen Farrell wrote:
With respect to the interaction between signer and validator -- and that is
what -base does -- in fact the exchange of private keys is *entirely* an
internal matter for the signer to deal with.
You make an ostensibly reasonable case; one with which I disagree as it
happens.
Only ostensibly?
More importantly, I was making a factual assertion about -base. If you know of
text in it that specifies key management between domain name owner and signers,
please point it out. All I can see is the brief Section 1.4 that describes lack
of need for a separate key management service.
Almost as an aside, I should note a point that Michael made to me separately,
which is that outsourced signing has a choice for communicating a key: The
signer can receive the private key from the domain owner, or the signer can
provide the public key to the domain owner. The latter has the rather large
benefit of not needing to share secret information.
I think that more importantly, for the point of this thread, is that this
demonstrates that key management is its own topic and that the current work, at
most, merely needs to make note of that fact.
What makes the specifics of communicating private keys, among consenting
organizations, a matter to count as a *prerequisite* for approving the
interaction between signers and validators?
Well, because private keys are not meant to be sent about willy-nilly, that's
an inherent part of the game. And they're mostly not simple values that are
exchanged like strings either (see pkcs#12 if you like self-inflicted
pain;-). Even public keys are generally transported in odd formats like
certificates etc. that easily generate a lack of interop. if different folks
implement things differently.
I think the question, here, is whether you are suggesting that we boil the ocean
of extensive issues surrounding every component of an integrated, end-to-end
service? Perhaps that sounds like an over-the-top concern, but I am not seeing
what the boundary to this path is.
You appear to be introducing a brand new issue for the group and appear to be
suggesting that it be handled before -base be released.
I'm probably wrong about one or both of these, but it would be helpful to
clarify it.
* What actions are you suggesting?
* When are you suggesting they be performed?
* What do you see as being required to wait for that to be done?
It seems to be pretty frequent that folks confuse the concept of
internal/external for an Internet service's architecture, with the vagaries
of administrative mix, for portions of the service. This leads to
requiring too much up-front specification, delaying release of work that is
factorable and entirely useful on its own. (A classic "big system
syndrome" problem for standards and systems designers.)
You do have a point, but I don't agree that it applies in this case.
It would be helpful if you explained why.
Where the delagatee supplies a public key to the delegator then its quite
likely that that public key will never get updated. That's a bad thing.
1. We are not specifying how frequently keys must be changed.
Correct. But neither do we think its ok to have most keys never change,
right?
We do not say anything about such key management. -base specifies a protocol;
it is not an administrative practices document. So I am not understanding what
the point of your question, here, is.
2. We cannot dictate how frequently key are changed.
Sure. But if change is needed, IMO we need to say how to do it (at least one
way) to get interop.
1. It's not relevant to the signer/validator specification, which is what -base
is. If it is relevant to SSP, please explain how it affects the current work.
2. In other words, it is a separable issue and all sorts of similar services
work just fine, without having a standard for this particular component. The
difference between MTA-MTA exchanges and MUA-MSA (or MUA-MDA) seem directly
equivalent. I do not recall seeing a specification for the way key management
be done, between end-users and the servers they log into. This lack has not
seemed to restrict the ability to have Internet mail operate.
3. Your assertion that there is, somehow, a particular human/operations
impact when the private key crosses the boundary between partner
organizations is interesting. Do you have an empirical basis for asserting
it? The observation is likely to have a significant impact on quite a bit
of Internet administration and the standards for it.
Do I have quotable stats? Not offhand. Have I seen this happen in the real
world.
An existence proof does not seem like a strong basis for creating a burden on
the standard where lots of variations are possible. All sorts of peculiarities
can happen in isolation, but do not warrant changes to a standard for *common*
activity.
Yes. Numerous times. And with messages between banks involving
payments.
What you seem to be doing is making a case for this being a general issue; hence
it is not clear why DKIM somehow has to be required to solve it.
I'm *not* saying that we have to invent any kind of key management, but
if keys are to be sent between domains (even in a minority of cases),
then we do need to have analysed those cases and shown that there's an
easy way to handle them.
No we don't. That is why it is important to recognize that the issue is
*entirely* internal, with respect to the portion of the service that we
*are* designing.
Fair enough. We disagree.
It is deeper, than that, Stephen. You are creating a new requirement and it is
for a component of the service that we have not been working on. You need to
define and justify it.
IMO, the SSP DSD mechanism is potentially better from this angle since
its ok to exchange signer names once and
Yes, path registration is a very appealing concept... except for the
problems with it, such as completeness and keeping things current.
If I am understanding the DSD concept, it pertains to publication of an
authorization list. So I think you are confusing publication of signer
agent name, with the choice between NS delgation to an outsourced signer
vs. giving a private key to them.
Stated differently: I believe that publication of domains authorized to do
signing provides the same functionality as NS delegation of a sub-domain,
albeit with more mechanism, more complexity, and more risk. But it has
nothing to do with the way private keys are exchanged.
Offhand, I am not seeing why the communication of private keys is all that
different when the signing group is outsourced than when it is exchanged
within an organization.
I think Jon answered the above better than I could, so I won't make it
worse:-)
I do not know what statements by Jon you are referring to. I do not see him
explaining how DSD solves key management issues. Please clarify.
Even more problematic, is that I have not seen how our inventing a mechanism
that burdens receivers with making authorization assessments of delegatees is
somehow better than using DNS sub-domain names. I have asked folks to explain
this, but have not seen a response yet.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html