Locate/Validate Requests for Multiple Keys

Here's a writeup discussing possible enhanced functionality I brought up
at the recent f2f.  I'll be interested to hear from others as to whether
they  believe this  adds sufficient value to justify adding it to the
spec and whether the proposed approach is adequate.

There are applications that need to locate the public keys (or Certs)
for multiple entities on a regular basis.  As one example, consider a
secure email application.  To send a secure email to multiple people one
must first locate their public key(s).  Unless these are locally cached
based on some prior exchange, one must contact a service to find them,
or each individual using some out-of-band mechanisms.  Similarly, there
could be a subscription service handling batch distribution of content.
It might be told the addresses of current subscribers, but might need to
locate their key material itself to secure the transmission.

For such applications, one could use the XKMS Locate and/or Validate
interfaces as presently defined.  However, the current interfaces assume
that a given request is only for a single key, i.e, the request contains
a single KeyInfo.  The response may return multiple KeyInfo structures
that reflect matches against the supplied KeyInfo request information.
These may reflect different registrations/certifications of the key or
an ambiguity in the request.  But, this wasn't designed for obtaining
information about multiple keys. 

Consequently, an application would need to make 'N' XKMS requests in
order to find information about 'N' keys.  This can be quite inefficient
due to the overhead in making network requests and processing the
associated SOAP messages.

It would make sense to provide a way to request info for multiple keys
in the Locate and Validate interfaces.  Naturally, this only makes sense
if we avoid introducing processing and protocol complexities that offset
the potential gains.  A suggested approach is to allow an array of
KeyInfo structures in a request, one per key of interest.  Such a Locate
request would look like:

<soap:Envelope>
  <soap:Body>
    <Locate xmlns="http://www.xkms.org/schema/xkms-2001-01-20">
      <Query>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
          <KeyName>Joe's Key</KeyName>
        </KeyInfo>
      </Query>
      <Query>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
          <KeyName>Bob's Key</KeyName>
        </KeyInfo>
      </Query>
      <RespondWith>
        <string>KeyName</string>
        <string>KeyValue</string>
      </Respond>
    </Locate>
  </soap:Body>
</soap:Envelope>

where, one or more Query element are allowed in the request.  For a
Validate request one would allow one or more Prototype elements.

The Locate response to this request would look like:

<soap:Envelope>
  <soap:Body>
    <LocateResult xmlns="http://www.xkms.org/schema/xkms-2001-01-20">
      <ResultMajor>Success</ResultMajor>
      <Answer>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
          <KeyName>Joe's Key</KeyName>
          <KeyValue>
            <RSAKeyValue>
              <Modulus>mpk9qt0uwUb8KyMNiHEK6Y1efkBVBC3FE=</Modulus>
              <Exponent>AQAB</Exponent>
            </RSAKeyValue>
          </KeyValue>
       </KeyInfo>
      </Answer>
      <Answer>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
          <KeyName>Bob's Key</KeyName>
          <KeyValue>
            <RSAKeyValue>
              <Modulus>98ABCb8KyMNiHEK6Y1efkBVBC3FEUb8K=</Modulus>
              <Exponent>AQAB</Exponent>
            </RSAKeyValue>
          </KeyValue>
       </KeyInfo>
      </Answer>
    </LocateResult>
  </soap:Body>
</soap:Envelope>


This raises a couple of issues, though none seem particularly difficult
to deal with.

Issue #1 - Allowing an XKMS client to send a request with an unbounded
number of KeyInfo's may be a problem.  First, it may take an excessive
amount of time to process a response forcing both the client and server
to maintain an open session.  Second, a single user could negatively
impact service behavior for other clients.  Third, it's a ripe avenue to
creating DoS attacks.

There are two simple approaches to limiting client behavior. First, a
server could impose an arbitrary limit on the number of KeyInfos in an
incoming request message and fail any exceeding this limit.  This isn't
the best solution as it forces clients to guess at what is allowed in a
request.  Second, a server could simply state the limit it supports
using a constant - communicated via WSDL, its policy statement, etc.
This value should also become part of a defined fault message construct
to inform the client as to the maximum number of KeyInfos allowed in a
single request when it sends a request exceeding the limit.

Issue #2 - If one asks for information about 'N' keys the service will
likely respond with 'R' KeyInfo structures (where R >= N).  This begs
the question as to how the client knows which KeyInfos in the response
correspond to the KeyInfos in the request.  I do not believe this is a
new issue.  The client already must be prepared to deal with multiple
responses and be able to parse these to determine which is appropriate
to its needs.

The only difference is that they must now parse these to match up the
returned KeyInfos against multiple keys in the request.  This seems like
a trivial pattern matching problem between the request and response
KeyInfos.  Using the above example, this amounts to matching KeyName
values.  If others feel this is inadequate, then I suggest we introduce
a new child element of KeyInfo to provide a locally unique Request
Sequence Number (e.g., <xkms:RequestSeqNum>1</xkms:RequestSeqNum>).  The
client would simply tag each KeyInfo in the Request with an integer
unique to that request, the service would return this value in each
corresponding response KeyInfo

Issue #3 - If we allow requests for info about multiple keys how do we
indicate when some, but not all, can be satisfied.  I believe our result
codes are already adequate for this and suggest a ResultMajor = Success
combined with ResultMinor=Incomplete be used to indicate the partial
satisfaction case.

Regards,
Blair Dillaway