Phillip, thank you sir!
Leaving aside the issue as to whether XKMS is qualified to serve as a
key-fetching mechanism for the moment, what does the group think about
Phillips basic assertions:
(A) It is critical-path that we define at least one other value in order to
prove that it is, in fact, possible to do so.
(B) It is critical-path that we define at least one other value because
failing to do so will result in the policy mechanism being insufficiently
considered.
(C) It is critical-path that we define at least one other value because
somebody named Russ Housley wishes it.
These are the arguments and they've been made honestly and openly. We
should now be able to quickly dispatch this topic (yes, I'm a newb). What
say the group?
--
Arvel
It is critical path to demonstrate that it is possible to provide AT
LEAST ONE other value. If that is not done in the core the chance that
the policy mechanisms will allow a transition is small.
NOTE: These issues are discussed at some length by Russ Housley in:
http://www.ietf.org/internet-drafts/draft-housley-mass-sec-review-00.txt
Russ is the Security AD with responsibility for MASS.
The reason for proposing XKMS is that of the alternative key management
systems that might be used in conjunction with DKIM it is by far the
most likely to be used.
* XKMS is architecturally a very close match to the DNS mechanism, by
far the closest match
* XKMS is designed to provide an interface to ANY underlying key
management mechanism, including X.509/PKIX.
* XKMS allows complex PKI topologies such as the federal bridge CA.
* XKMS defines a key registration protocol and tools for management of
the entire private key lifecycle through the XKRSS subset. It thus
provides a feature complete key management mechanism
* Angle brackets, Web Services and XML are the current fashion, any
new proposal will inevitably get translated into the XML syntax. There
are plenty of development tools available.
XKMS was developed with the support of the leading PKI product vendors
including VeriSign, Baltimore, Microsoft, Entrust, RSA, IBM and Sun.
What is achieved by doing so that you can not achieve elsewise?
If the issue of defining values for q= other than the default is
deferred until after deployement the policy mechanism is not going to be
considered in sufficient detail.
This is one of the principle concerns raised by Russ.