Re: UseKeyWith

Hi Berin,

We briefly discussed this on yesterday's call and the answer is
"yep - those are deliberately not addressed" as you thought.

> I think the following two issues are purposely not addressed by the 
> standard (in that applications can make the decisions), but I thought it 
> worth asking the questions to make sure I haven't missed something obvious.

Good idea to do so! Do let us know if this causes any implementation
problems in your code.

> 1.  If I have a QueryKeyBinding with both a KeyInfo and a set of 
> UseKeyWith elements, and the two constructs refer to different keys (or 
> sets of keys), I assume the resultant response is implementation 
> dependant?  (I.e. union vs. intersection of keys found under the two 
> sets of conditions.)

Yes. I can imagine the union vs. intersection result being influenced
by who's asking, from where, about whom, with which UseKeyWith, etc.
I could also imagine a responder treating all such cases as an error
for validate and doing a union for locate!

> 2  If I have a QueryKeyBinding with a UseKeyWith item, and there are 
> actually multiple applications defined for the key that is found, should 
> the LocateResult have all the potential applications defined in the 
> response UseKeyWith items, or just the intersection between those 
> originally requested and the full list?  (Again, I assume application 
> dependant?)

Again, YMMV. Some keys can be shared across applications (e.g. S/MIME
and TLS client auth), others might be mandated not to be so shared
e.g. a VPN or SET cert (ok ignoring that SET is kind of dead-ish, but
it did specifically mandate that its certs not be used for other
apps.)

Hope that helps, (but you knew anyway:-)
Stephen.