Stephen Farrell wrote:
I don't think that exchanging public (or even private, yuk) keys between
ADMDs is internal. Nor do I think that encouraging such would be likely
to sit well when our specs are reviewed later on. (E.g. by secdir, where
I would raise the issue if I drew the document - must check if that can
happen:-)
Yeah, that's what I thought you were going to say.
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.
There are lots of inter-organization activities needed for administering many
different Internet protocols, and we do not specify how they are done. For
example, do we specify how coordination must be done between a domain name
holder and the third party administering their DNS entries?
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?
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.)
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.
2. We cannot dictate how frequently key are changed.
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.
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.
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.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html