Thanks, these are some of the specifics I have been looking for. I like the
proposed reorganized text. As for the proposed additional text I have this
question: Why is it critical-path to specify q=xkms is the core document?
What is achieved by doing so that you can not achieve elsewise?
--
Arvel
----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
To: "Dave Crocker" <dcrocker(_at_)bbiw(_dot_)net>; "ietf-mailsig"
<ietf-mailsig(_at_)imc(_dot_)org>
Sent: Wednesday, July 27, 2005 1:33 PM
Subject: RE: alternate key server mechanisms
Currently the text in 3.5 reads:
q=
A colon-separated list of query methods used to retrieve the
public key (plain-text; OPTIONAL, default is "dns"). Each query method
is of the form "type[/options]", where the syntax and semantics of the
options depends on the type. If there are multiple query mechanisms
listed, the choice of query mechanism MUST NOT change the interpretation
of the signature. Currently the only valid value is "dns" which defines
the DNS lookup algorithm described elsewhere in this document. No
options are defined for the "dns" query type, but the string "dns" MAY
have a trailing "/" character. Verifiers and signers MUST support "dns".
This text needs reorganization in any case: I propose:
q=
A colon-separated list of query methods used to retrieve the public key
(plain-text; OPTIONAL, default is "dns"). Each query method is of the
form "type[/options]", where the syntax and semantics of the options
depends on the type. If there are multiple query mechanisms listed, the
choice of query mechanism MUST NOT change the interpretation of the
signature. The following value is defined:
dns
the DNS lookup algorithm described elsewhere in this document.
No options are defined for the "dns" query type, but the string "dns"
MAY have a trailing "/" character. Verifiers and signers MUST support
the "dns" query type.
I propose to add:
xkms
The key may be retrieved using the XKMS [ref] protocol. The
XKISS LOCATE request is used to request a public key that supports the
SIGNATURE key use and the <uri identifying this protocol> UseKeyWith
mechanism. Support for the xkms key retrieval mechanism is optional for
both signers and verifiers.
Separately we need to modify the policy document so that the signing
policy can state the q= options that may be contained in a signature.
We do not need to provide any more information on the use of XKMS than
we currently provide for the DNS mechanism. Both are described
elsewhere, the dns mechanism in a different part of the same document,
the XKMS mechanism in a completely different document.